Reorganização do Desenvolvimento
Emissão:
22/08/2007
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
www.tracksource.org.br
Reorganização do Desenvolvimento
Emissão:
22/08/2007
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
www.tracksource.org.br
Reorganização do Desenvolvimento
Novas Rotinas para Compilação
Emissão:
22/08/2007
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
www.tracksource.org.br
Reorganização do Desenvolvimento
Novas Rotinas para Compilação
Emissão:
5.
22/08/2007
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 “1Recebidos 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
www.tracksource.org.br
Reorganização do Desenvolvimento
Novas Rotinas para Compilação
Emissão:
7.
22/08/2007
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
www.tracksource.org.br