Mapeando características de vias com o Osmtracker

Boa ideia.

Nossa! Eu faço algo bem parecido com o OSM Tracker, só muda os códigos e o separador. :open_mouth:

Gostei dessas abreviações.

Uma coisa que poderiamos fazer é um menu personalizado brasileiro pro OSMTracker (veja aqui: https://code.google.com/p/osmtracker-android/wiki/CustomButtonsLayouts )
Por exemplo, no menu padrão, as restrições de velocidade não se encaixam muito bem com as tradicionais brasileiras (e.g. 30 e 10 ao invés de 40 e 20)

É relativamente fácil fazer esse menu, a minha única preocupação é que se apertar mais de um botão no mesmo lugar, eles vão aparecer um em cima do outro quando for visualizar.
Alguém sabe como resolver isso facilmente? (cheguei a abrir o arquivo em um editor de texto pra ver certinho o que estava escrito)

Ih, legal, não sabia disso! Vamos criar um padrão nosso?

s

jgpacker, talvez dificilmente apareça “exatamente” no mesmo lugar. É preciso testar. Na realidade, já fiz o teste mas falta vê-lo na tela do monitor.

Criar um menu parece tão fácil que podemos ter um padrão e também ter o tutorial simplificado em português para quem quiser o seu menu personalizado.

Quando o Nighto postou a linguagem que criou, achei muito interessante. Seria possível criar um script para gerar um longo XML com todos os casos da linguagem em várias telas aninhadas. O primeiro problema poderia ser com a performance dessa gambiarra; o segundo, que no final não haveria como registrar o nome da rua no mesmo waypoint, do jeito que o OSMTracker é hoje. Eu já pensei o algoritmo por cima. Para o registro do nome do local, só alterando o código Java, para suportar a nota de texto na parada de uma recursão recebendo em algum dos parâmetros o caminho percorrido pelo usuário através das telas de botões aninhadas.

Código úteis para quem quiser pensar a questão:

osmtracker-android / src / me / guillaumin / android / osmtracker / view / TextNoteDialog.java
osmtracker-android / src / me / guillaumin / android / osmtracker / layout / UserDefinedLayout.java
osmtracker-android / src / me / guillaumin / android / osmtracker / activity / TrackLogger.java
osmtracker-android / src / me / guillaumin / android / osmtracker / listener / TextNoteOnClickListener.java

Acho que não precisa tanto, uma vez que as notas no GPX são só para o seu entendimento.

[]s

Nighto, se o que estou dizendo fosse feito, no final teríamos tudo traduzido em tags (nossa linguagem “humana” do wiki), ou até um .osm — quem sabe! não conheço os requisitos do formato — ou quase, para quem quisesse ir além.

Entendi. Mas note que esse .osm não poderia ser subido diretamente, pois teria que ser “misturado” com o que já existe no OSM, além de ter as falhas de recepção do GPS. Ou seja, não é uma alternativa válida.

Mas a ideia de ter as tags por extenso nas notas é interessante, sem dúvida.

[]s

Outra ideia mais simples que tive antes disso foi termos um fluxograma em papel plastificado para a linguagem completa do Nighto.

Atualização (27-02-2014): eu fiz File:Tutorial-viasOSMtracker-NightoLanguage.png.

Muito provavelmente esse .osm teria várias imperfeições. Eu sei disso. Eu nem uso o JOSM ainda, então devo estar falando algumas bobagens. Filtrem. Mas estou imaginando na via de um meio para ter dados abertos/importados no arquivo de trabalho do JOSM.

Então. Esse .GPX gerado pelo OSMTracker pode ser aberto no JOSM como uma camada, e as anotações aparecem como pontos na via, no lugar em que foram feitas.

Um problema em potencial (e porque eu desenvolvi este método) é porque quando você clica em mais de um botão no OSMTracker ele cria mais de uma nota na posição, ao invés de juntar as notas num único ponto. Vocês sabem se é possível mudar essa característica, ou seja, agrupar notas que sejam feitas dentro de um determinado raio?

Off-topic: vejam que interessante essa explicação de como o GPS funciona: http://wiki.openstreetmap.org/wiki/Accuracy_of_GPS_data achei enquanto procurava um screenshot de exemplo do JOSM abrindo um .GPX com notas (não achei).

[]s

Cada tela (estágio) do fluxo de ações da linguagem que você criou, levaria a uma próxima apontada por um botão ou de volta à tela inicial (cancelamento da ação). Não haveria botões fora do negócio (conjunto de decisões) da linguagem. Em todas as telas do meio do fluxo, os botões levariam a novas telas. Na última tela de decisão é que o botões gravariam a informação.

Um grave problema dessa gambiarra é que o funcionamento do menu poderia exigir muita memória, e também processamento (não sei, só testando). O XML iria contemplar nada mais do que todos os casos de decisão da linguagem (99848 :laughing:) e o hash de cada tela seria o seu caminho descrito na própria linguagem.

Depois que você está em casa, você pode editar o GPX com o GpsPrune, por exemplo. Mas não acho que vai ter o recurso de unir a informação de dois waypoints num só. Não lembro.

Hm, agora sim eu entendi a ideia. Pode funcionar, hein!? :slight_smile:

[]s

A título de referência, quero fazer constar aqui “Android development: Custom keyboard”. Ensina a criar um teclado para o Android. Viabiliza outros caminhos, os quais preferi deixar de lado (para mim).

Que interessante! Acho que essa seria uma alternativa até mais fácil, hein? (Embora certamente mais “gambiarra”.)

[]s

O teclado, mais fácil? Talvez para quem esteja praticando com Android. Para mim, não. Mas se for possível fazer um “teclado de decisão” (ou de auto complete) para toda a linguagem que você criou, eu não veria como gambiarra. Só no sentido de que o teclado ativo para todo o Android seria aquele, no momento do uso :D.

Este tutorial agora está no wiki: Pt-br:Tutorial:Mapeando características de vias com o Osmtracker.

Estou escrevendo para declarar que não vou fazer aquela “gambi” :smiley: com os botões. Eu gerei um arquivo cases.txt com 99848 “caminhos” e, ao abri-lo no editor de texto de um computador de mesa quad-core, foi notável o peso de carregamento. Tenho até medo :roll_eyes: do que aconteceria se já fosse um XML complexo sendo “aberto e processado” num mísero dispositivo Android. Por essas razões, estou abandonando essa linha.

Eu escrevi um fluxograma (Nighto.dot) e adicionei ao tutorial no wiki. Por enquanto, fiquemos só com ele. Depois, é possível que eu ou outra pessoa consiga arrumar o layout dele para acomodar numa folha de papel A4.

Para gerar o PNG em Ubuntu, executo esta linha de comando:

dot -Tpng:cairo Nighto.dot > Nighto.png

Comecei a partir do que tem na página Systems. Que eu saiba, não temos uma Extension:GraphViz ou um -Plugin for Mediawiki, então foi preciso fazer upload da imagem. “Drawing graphs with dot” foi útil como referência rápida, mas usei mais de exemplos encontrados pelo Google.

NightoLanguage! hahahaha :smiley: :sunglasses: :sunglasses: :sunglasses:

Enfim, bem maneiro, pode ajudar a visualizar.

[]s

comecei a editar ativamente os mapas do osm há poucos dias. ainda estou apanhando muito. fazendo, desfazendo e refazendo :D. sendo assim, achei muito interessante essa metodologia.

além das informações que já estão no tutorial, há mais alguma etiqueta que é importante incluir para um edição “normal”?