Toda a estrutura do Projeto Tracksource foi embasada na divisão política do Brasil, com mapas Municipais e Estaduais. Inicialmente também foi difundido, mas nem sempre cumprido, o conceito de que mapas estaduais deveriam conter apenas dados rodoviários e de que mapas municipais deveriam conter dados urbanos. Os mapas eram transparentes, poderiam ser superpostos no GPS e assim se complementariam. Assim, em função deste conceito e de diversas interpretações dos diferentes desenvolvedores, o projeto caminhou para uma clara divisão entre os desenvolvimentos estaduais e municipais com mapas contendo informações divergentes, às vezes incompletas e às vezes duplicadas. Várias foram as tentativas de ajuste nos rumos e da busca de uma maior integração entre os desenvolvedores, porém com pouco sucesso. Com a evolução dos equipamentos e dos softwares de desenvolvimento, surgiu o auto-roteamento e com ele, a necessidade de integração passou a ser imperativa. O conceito de mapas transparentes, superpostos e complementares também veio por terra, pois para possibilitar o roteamento todos os mapas devem fazer parte de um mesmo Mapset e devem ter pontos de conexão claramente definidos. Consciente das alterações que esta evolução impunha à organização do projeto, a Equipe de Coordenação se empenhou em testes e na busca de alternativas para manter a estrutura de desenvolvimento existente e promover a integração necessária entre os mapas Municipais e Estaduais. Havia também a preocupação com a disponibilidade das ferramentas de desenvolvimento. Não era viável promovermos alterações tão profundas baseados na compilação gratuita em um site de terceiros, que a qualquer momento poderia deixar de nos atender. Hoje, com o Roteamento funcionando no TRR, com a evolução dos testes de integração e principalmente com a compra do cgpsmapper, acreditamos que estamos em condições de apresentar ao grupo o modelo de integração e reestruturação que julgamos necessário para mais esta evolução do Projeto. Em primeiro lugar, gostaríamos de deixar claro que a estrutura baseada na divisão política de Estados e Municípios, acreditamos ser a mais adequada para a divisão do trabalho de desenvolvimento. Entretanto, como o roteamento exige que todas as vias estejam corretamente conectadas, sem superposições e integradas em um mesmo mapa, não podemos mais vincular esta estrutura ao produto final, segmentando desenvolvimento rodoviário e urbano entre diferentes desenvolvedores. Assim as áreas de desenvolvimento não podem mais se superpor, e devem ser complementares. No modelo que idealizamos, um Município que possua Desenvolvedor atuante seria destacado do mapa estadual e excluído da competência do Desenvolvedor Estadual. O Desenvolvedor Municipal passa a ser então o único responsável por todas as contribuições e dados internos aos limites do Município, sejam eles rodoviários ou urbanos. Por conseqüência, o Desenvolvedor Estadual passa a ser, então, responsável apenas pelos dados em áreas não cobertas por DM s atuantes. De forma similar aos municípios, também não há distinção entre dados rodoviários ou urbanos. O mapa estadual teria literalmente vários buracos e por isso o estamos chamando de Mapa Estadual Vazado. 1
A operacionalização desta nova forma de divisão de responsabilidades seria gradual e vinculada a adequação dos mapas municipais ao roteamento. O DM interage com o DE, incorpora no município os dados já roteáveis do TRR, acertam as continuidades nas fronteiras e o estadual é vazado naquele Município. Nesta operação ocorre a integração dos dados e será aproveitado, no município, o que houver de melhor entre os dois mapas. Os mapas estaduais, decorrentes desta nova organização seriam, portanto, complementares e quando agrupados formariam um grande mapa, completo, com todos os dados do Projeto, sem superposições ou duplicidades e completamente integrados, possibilitando o roteamento por todas as vias. Isto entretanto, não quer dizer que este Mapão seria o produto final do Projeto. Usando-o como base, aplicando filtros e combinando adequadamente os mapas que o integram, seriam gerados diversos produtos específicos. Como por exemplo, podemos citar: Mapas estaduais totalmente roteáveis e com detalhamento completo das vias municipais. Mapas por região (Sul, Sudeste, Centro-Oeste,etc.) Mapa rodoviário do Brasil (roteável, com a eliminação de vias secundárias e POIs distantes das rodovias) Mapa de viagem (idêntico ao anterior, com eliminação também das vias de terra) Em resumo, a metodologia consiste em desenvolver separadamente, integrar tudo em conjuntos estaduais e depois filtrar e agrupar para gerar os conjuntos. Assim, conseguimos desvincular a forma de divisão do desenvolvimento da forma de divisão e geração dos conjuntos. Evita a duplicidade de trabalho e de dados e nos dá uma total flexibilidade para gerarmos produtos distintos, adequados às mais diversas necessidades dos usuários. Nosso objetivo é ter condições de atender tanto os aparelhos de baixa capacidade, sem roteamento, como os mais sofisticados, com roteamento e comandos de voz. Novos produtos poderão ser gerados, seja pela percepção de novas necessidades, como também por sugestão do grupo. Em função das dúvidas e questionamentos que tem surgido no Fórum, estamos trazendo ao conhecimento esta nova forma de estruturação dos trabalhos. Para operacionalizá-la, entretanto, necessitamos ajustar os procedimentos de compilação (vide anexo), resolver problemas técnicos e ainda alguns aspectos dependem do desenvolvimento de ferramentas específicas. Ao longo das discussões que certamente se seguirão e à medida que forem necessárias as decisões, os detalhes específicos serão submetidos ao grupo. Coordenação do Projeto Tracksource 2
Considerando a compra do cgpsmapper e as conseqüentes mudanças nos procedimentos de compilação dos mapas do Projeto Tracksource, torna-se necessário definir alguns Padrões de forma a facilitar a preparação de rotinas automáticas e também uma eventual necessidade de troca de Compiladores. Os principais pontos detalhados neste documento são: Pastas de Instalação Pastas de Teste Pastas para montagem dos instaladores Pasta para gravação dos instaladores Pastas para compilação Nomes dos arquivos fontes e img s Nomes dos demais arquivos de configuração e instalação Informações de registro do Windows, códigos de Família e Produto Área de ftp para upload e download de testes 1. Pastas de Instalação (computadores dos usuários): Para os Mapsets em produção, usamos a path c:{pf}\tracksource\ Lá existem as pastas Municipal, MunicipalGTM, Rodoviário e RodoviarioGTM. Novos conjuntos que entrarem em produção, devem continuar com esta organização, criando novas pastas como Urbano, Integrado, Complementar, etc. 2. Pastas de Teste (computadores dos Desenvolvedores e demais envolvidos em testes): Para os Mapsets em teste, devemos ter outra path, c:{pf}\tracksource\teste\ Da mesma forma, devem existir pastas com os conjuntos em teste que hoje são TRC e TRI. À medida que algum conjunto evoluir de teste para produção, sairá de uma path e irá para a outra. É importante lembrar que tudo aqui tem que ser tratado com a variável de ambiente {pf} para que funcione em computadores com Windows em diferentes idiomas. 3. Pastas para montagem dos instaladores (computadores dos compiladores): Embora rigorosamente não seja necessário, é recomendável que as pastas para montagem dos instaladores sejam idênticas (espelho) às pastas em que ocorrerá a instalação nos computadores dos usuários. Desta forma, a possibilidade de ocorrência de problemas na construção dos instaladores é minimizada. As pastas devem conter apenas os arquivos que serão compactados pelo instalador e portanto devem ser independentes das pastas de trabalho usadas pela compilação. É importante lembrar que o Compilador deve evitar testar o instalador no mesmo computador utilizado para sua construção. Entretanto, se o fizer, posteriormente deverá apagar desta pasta os arquivos de desinstalação para que não causem problemas em futuras novas construções do instalador. Os instaladores do TRR e TRI já foram adaptados para eliminar este problema. 4. Pasta para gravação dos instaladores (computadores dos compiladores): Ao gerar o instalador deve ser indicada uma pasta para que seja gravado o exe. Em todos os instaladores que já existem esta pasta é a c:\tracksource\instaladores e a mesma deverá ser mantida para os demais que forem criados. 3
5. Pastas para compilação (computadores dos compiladores): Este é um ponto complicado pois cada compilador tem seu método de trabalho e também existem mapas fontes que podem ser utilizados em mais de um mapset, impondo peculiaridades em cada conjunto. Entretanto, devemos tentar um mínimo de padronização para facilitar o desenvolvimento de ferramentas comuns. Como já existe, conforme item 4, a pasta c:\tracksource, o ideal é que seja utilizado este path, Pelo fato de estar na Raiz C:\, simplifica muito o trabalho de desenvolvimento de ferramentas e construção de bat s comuns, não sendo necessário se preocupar com as configurações do Windows de cada Compilador. Além da pasta Instaladores, usada pelo item 4, devem ser criadas pastas específicas para cada conjunto, como TRR, TM, TRU, TRC, etc. Caso existam conjuntos que compartilhem fontes e img s, junta-se tudo em uma mesma pasta como TRR-TRI, etc. Dentro destas pastas de cada conjunto, devem existir outras para organizar o trabalho, como 1- Recebidos GTM, 2-Valida TXT, 3-Converte Validados, 4-Bat, 5-Compila, 6-Map, 7-Instala e 8-Backup. Na pasta 5-Compila ficam todos os arquivos necessários para a compilação com o cgpsmapper. A cada compilação, deve ser copiado da pasta 4-Bat para a 5-Compila o arquivo.bat mais adequado. Editar o.bat excluindo os mapas que não necessitam ser recompilados. Os arquivos.bat geram todos os img s e depois geram o Mapset. São bem simples, mas práticos, pois evitam ficar abrindo janela de prompt e digitando coisas sujeitas a erros. Diferentes mapsets criados através de combinações alternativas dos img s, também são criados de forma bem simples, apenas criando outro arquivo pv e outro bat com a combinação dos img s necessários. Depois, os arquivos necessários à construção do instalador devem ser copiados para a pasta específica já definida no item 3. Esta operação de cópia também pode ser inserida no.bat. Estando tudo padronizado, futuramente estes.bat poderão ser substituídos por alguns aplicativos de automação dos processos a serem desenvolvidos. 6. Nomes dos arquivos fontes e img s Os nomes dos arquivos fontes já estão consolidados e devem ser mantidos. Para os img s, que devem ter no máximo 8 caracteres, será utilizado o código numérico do mapa. Em alguns testes que estão sendo feitos, como TRI e TRC, os fontes estaduais são variações do fonte do TRR. Nestes casos, para que os diferentes arquivos possam permanecer na mesma pasta de compilação, é necessária uma diferenciação no nome. Assim, provisoriamente continuaremos com o critério até então utilizado de somar ao código do mapa o valor 2 para o TRI e 10 para o TRC. 4
7. Nomes dos demais arquivos de configuração e instalação: O cgpsmapper utiliza um arquivo pv onde se define uma variável chamada Filename e que é a base para o nome de todos os arquivos que são gerados para montagem do Mapset. Todos estes arquivos devem ser formados pelas siglas dos mapsets, ou seja, TRR, TRU, TRC, TRI, etc. Assim, por exemplo, no caso do TRR o pv deverá ser nomeado TRR.pv e nele deve ser definido Filename=TRR, o que irá gerar os arquivos TRR.img, TRR_mdr.img, TRR.MDX, TRR.reg e TRR.tdb O fonte do instalador chamaria TRR.iss, o instalador chamaria TRR-v405.exe e assim por diante. Para os outros conjuntos de mapa o procedimento deve ser similar. 8. Informações de registro do Windows, códigos de Família e Produto: No arquivo pv são definidos FID (Family ID) e ProductCode que também são utilizados no Registro do Windows. Tais códigos são fundamentais para agrupar a Família de mapas do GPS e para que não haja conflito com outros mapas que possam ser instalados pelo usuário no MapSource. Hoje utilizamos respectivamente: 200 106 para o TRR 203 107 para o TRI 201 -??? para o TRU??? 101 para o TM 321 321 para o TRC 332 332 para o TRC-MG 344 344 para o TRC-RS 702 702 para o TRU-BH (Rospierre) Quando da criação de novos conjuntos de mapas, deve haver um cuidado especial na definição destes códigos para evitar conflitos com os já existentes no Projeto e também com outros conjuntos de mapas que os usuários possam utilizar. 9. Área de ftp para upload e download de teste: Os instaladores dos conjuntos de mapas do Projeto ficam disponíveis no site em uma área de ftp público. Os instaladores dos conjuntos de testes deverão ficar disponíveis em uma área restrita aos desenvolvedores. 5