[image: Imagem inline 1] Se encontrem erro nos UML que desenho, por favor, avisem-me (por e-mail), mas com calma. Poderá atá ser o caso de uma modificação intencional, com o objetivo de transmitir a mensagem com mais "coloquialidade".
Essa aí é a ideal original. Considera apenas o MongoDB. Não pretendo redesenhar. Toma tempo. Mas considerem também o que tenho escrito. Alexandre Magno Em 9 de abril de 2014 13:32, Alexandre Magno Brito de Medeiros < alexandre....@gmail.com> escreveu: > Em e-mails passados, tenho usado a palavra "extract" para me referir a > "visualizações" simplificadas dos conjuntos de dados do OpenStreetMap. > Especialmente pensando naqueles arquivos CSV gerados por "osmjs -j > OSMQualityMetrics/UserStats.js brazil.osm.pbf". Eu sei que o uso corrente > não é esse. Atualmente, o que o pessoal chama extract ainda é coisa como o > brazil.osm.pbf. Penso que podemos considerar um extract de outro extract. > Estou explicitando essa diferenciação para não fazermos confusão. > > Sim, eu penso que o caminho é usar Osmconvert, OSMIUM, osmjs, ou algo como > o new-osm-stats / > fast_stats.py<https://github.com/dpaleino/new-osm-stats/blob/master/fast_stats.py>(o > projeto do David Paleino), e até mesmo o > overpass-turbo.eu, aprendermo-los, para gerarmos as tais "visualizações", > sejam em CSV, JSON, ou já diretamente dentro de um SGBD. O unipt-stats > entrará como um utilitário de linha de comando ou lib de domínio comum para > a lida com SGBD nessas intenções; apenas o projeto deverá estar preparado > para receber novos plugues (implementações de consultas, e "conectores" de > resultados de extracts → pegar um extract e auxiliar sua importação útil no > SGDB escolhido para implementação das consultas correlatas). > > No meio de tempo, a pessoa pode apenas resolver o problema da importação, > sem criar as consultas como caso de uso dentro do unipt-stats. Daí ela > simplesmente usa um Robomongo ou Microsoft SQL Server e consulta > "manualmente" o dados que quiser. O Robomongo, por exemplo, possibilita > salvarmos e carregarmos código de consulta Javascript. Escolhendo um nome > significativo para o arquivo e comentando-o para explicar algo, já temos > uma possibilidade: ir colecionando essas consultas .js que depois poderão > ser reescritas com mínimo esforço dentro de um projeto como o unip-stats. > > Alexandre Magno > > > Em 9 de abril de 2014 10:10, Lucas Ferreira Mation > <lucasmat...@gmail.com>escreveu: > > Só para atualizar, >> >> Um problema a menos. O Peter Körner, que é o desenvolvedor do extrator >> do history file, fez um uma extração para o Brasil. >> Se alguém mais quiser usar está em: >> >> http://osm.personalwerk.de/full-history-extracts/latest/south-america/brazil.osh.pbf >> >> acho que o diretório "latest" são os arquivos históricos mais >> recentemente criados, mas cada um deles cobre os dados desde o início. >> Pelo que entendi, para acessar este arquivo preciso usar o OSMIUM ou o >> Osmconvert >> >> Enfim, agora preciso pensar sobre como fazer as "queries" sobre >> quantos notes havia em cada período, ou qual era o comprimento total >> dos ways em cada período. Não tenho idéia como proceder... >> Ou se tem que primeiro exportar os dados válidos em cada período para >> algum arquivo mais fácil de trahalhar (CSV) e depois calcular estas >> estatísticas. >> > >
<<inline: unipt-stats.png>>
_______________________________________________ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br