Transcrevo mais dicas do Peter:
2014-04-09 13:54 GMT-03:00 Alexandre Magno Brito de Medeiros < [email protected]>: > [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 < > [email protected]> 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 <[email protected] >> > 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. >>> >> >> > > _______________________________________________ > Talk-br mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/talk-br > >
<<inline: unipt-stats.png>>
_______________________________________________ Talk-br mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-br
