Dúvidas e discussões sobre o projeto 2.
Fórum: Programação Multiparadigma
Projeto 2
No ficheiro CSV os campos latitude e longitude estão sempre vazios..., é normal?
Infelizmente, esses campos estão sempre vazios no ficheiro que foi possível arranjar. Mas convém admitir que, numa futura versão do ficheiro, algumas das caches já tenham esses campos preenchidos.
Convém atuar assim:
Quando surge uma cache nova no ficheiro CSV, essa cache nova tem se ser criada em memória. Se ela tiver coordenadas (garantidamente no mesmo formato do ficheiro GPX), então as coordenadas devem ser carregadas na nova cache. Se não existirem coordenadas, então deve ser usado internamente um valor especial para indicar que as coordenadas são desconhecidas. As caches com coordenadas desconhecidas não participam nas "yearly statistics" 5 e 6.
As caches com coordenadas desconhecidas não participam nas "yearly statistics" 5 e 6.
E quanto ás caches que não têm, por exemplo, atributo difficulty, como se calcula a yearly statistic 2? Considera-se a difficulty como 0 quando não está definida? Ou a estatistica é (soma das difficulties / numero de caches onde o atribute difficulty está definido)?
Exception in thread "main" java.lang.NumberFormatException: For input string: ""2.5""
A exceção foi causada porque a string à qual aplica o método toFloat possui aspas nas extremidades.
Boa tarde professor e caros colegas, Surgiu-me uma dúvida em relação aos dados disponibilizados do projecto.
Existem estatísticas a calcular relacionadas com caches activas e arquivadas:
- Number of active caches. [Print: count.]
- Number of archived caches. [Print: count.]
Na estrutura disponibilizada pelo professor existe uma chave que corresponde a WPT_AVAILABLE que indica true ou false. É isto que devemos considerar como uma cache activa ou inactiva? Certo?
É que depois no caso dos dados do CSV não existe nada disto. Apenas uma coluna correspondente a Status que tem múltiplos valores:
- o
- A
- D
O que é que significa cada um deles? É que queria tentar mapear para o WPT_AVAILABLE e há 3 valores (e WPT_AVAILABLE é suposto ser booleano) e não sei o que é que cada um deles significa.
dúvida em relação aos dados disponibilizados do projecto...
O valor WPT_AVAILABLE não serve para indicar que uma cache está arquivada. Serve apenas para indicar que uma cache foi temporariamente indisponibilizada pelo owner por ser necessário efetuar uma manutenção.
Lendo bem o enunciado e olhando para os ficheiros de dados vê-se que é preciso adicionar três novos campos na representação interna das caches: um campo booleano para indicar se a cache está ou não arquivada; dois campos inteiros para indicar o número de founds e not-founds.
Todas as caches carregadas a a partir do ficheiro GPX consideram-se ativas. A partir do ficheiro CSV carrega-se apenas o número de founds e de not-founds dessas caches. Para as caches que não estiverem disponíveis no ficheiro CSV usa-se zero.
Todas as caches que aparecerem no ficheiro CSV e não no ficheiro GPX consideram-se arquivadas, independentemente do que estiver na coluna Status. O ficheiro CSV é de produção amadora e podem existir incoerências, pelo que esta é a melhor maneira de lidar com o assunto. A única fonte de informação para as caches arquivada é a que se encontra no ficheiro CSV e carregam-se de lá os campos da representação interna das caches que for possível encontrar.Neste ficheiro as coordenadas das caches arquivadas estão em branco mas deve-se considerar que poderá vir a haver uma outra versão do ficheiro em que as coordenadas de algumas caches arquivadas já vêm preenchidas.
o programa explode quando tento aceder aos seguintes atributos...
Olhando para o ficheiro CSV, a maioria das linhas têm 23 elementos. Mas há uma minoria de linhas em que faltam um, dois, três elementos finais.
Para o programa não estoirar, convém usar a função length antes de começar a aceder aos elementos.
Ou melhor ainda, se os três últimos campos não forem relevantes para o projeto, mais vale ignorá-los.
Atenção
1, Na página da aula prática 10 foram colocadas as principais perguntas e respostas das aulas práticas de hoje.
2. No enunciado foram adicionados 2 esclarecimentos (assinalados no Changelog) relatívos a dúvidas que surgiram nas aulas práticas de hoje.
Já consegui corrigir.
No método getCache onde está
case WPT_TYPE => wpt(WPT_TYPE) = CacheType.encode(item.child.text)
deverá ser
case WPT_TYPE => wpt(WPT_TYPE) = item.child.text
Professor, verifiquei que não é possivel aceder aos types, através da constante WPT_TYPE vem sempre vazio.
Pode verificar o que se passa?
No contexto das estatisticas para o ultimo ano consideramos caches do ultimo ano ou até ao último ano?
Há estatísticas que só podem ser feitas para o último ano, nos faltarem dados. Essa é a única razão que faz com que o último ano tenha mais estatísticas. De resto, o espírito das estatísticas é sempre o mesmo, trate-se do ano de 2001, 2005 ou do último ano.
Por exemplo: Quantas caches arquivadas existiam em 2009? Não temos dados não é? Só sabemos o número de caches arquivadas existentes no último ano (informação no ficheiro CSV). Não fazemos ideia qual o ano em que cada uma delas foi arquivada, o que seria necessário para dar a resposta.
Outro exemplo: Qual é o Top 10 das caches com mais founds em 2009? Também não temos informação sobre o número de founds que existia nesse ano.
Boa noite, já tenho o ponto extremo norte-oeste em latitude/longitude,
no entanto não consigo encontrar a formula para saber a distancia em termos de Norte(Vertical) e em termos de Oeste(horizontal).
Alguém já descobriu a formula? Se sim, poderia disponibilizar.
Cumprimentos,
José
A quem interessar uma forma ainda mais eficiente de fazer a procura espacial:
http://en.wikipedia.org/wiki/K-d_tree
Para quem conhecer o numpy/scipy:
https://github.com/scipy/scipy/blob/master/scipy/spatial/kdtree.py
Em particular a função query_ball_point()
Também estava a pensar utilizar Kd-trees. Mas é complicado utilizar um indíce espacial com coordenadas correspondentes à superfício de uma esfera. Não se pode simplesmente considerar que se tratam de coordenadas cartesianas. No entanto, sou capaz de tentar fazer umas adaptações com esse objectivo.
Simplificando a Terra como uma esfera perfeita (que é o que a maioria do código por aí faz), parece-me que a solução aproximada é trivial: basta tranformar a distância (à superficie) na diferença de ângulo associada ( na latitude OU longitude, de forma a que a outra seja 0). Assim obtemos a "distancia" angular, que podemos usar directamente directamente numa kd-tree de latitude e longitude para calcular todos os pontos a menos dessa "distancia". Esta abordagem, para as distâncias máximas que consideramos no enunciado (100km) produz uma margem de erro na distancia (por causa da conversão incorrecta das coordenadas) de +- 1.02 metros. Se quisermos ter precisão milimétrica, pode-se sempre usar esta técnica somando um metro à distância pedida como passo inicial para reduzir o espaço de procura, e depois calcular a distância sobre o arco exacta (através da fórmula) para cada uma das caches. Mas honestamente, precisão de 1 metro parece-me "good enough" para o que estamos a fazer.
Boa tarde. Quanto às estatísticas que é preciso mostrar, temos, das que são para o "last year", simultaneamente:
- Top 10 of the caches with a larger of rate founds*difficulty*terrain. [Print: rate, code, name. (Ten lines)]
- Top 10 of the caches with a larger rate of not-founds/(difficulty*terrain). [Print: rate, code, name. (Ten lines)]
Estas duas estatísticas são muito semelhantes, mas, como se vê da parte a negrito, a expressão a calcular é diferente.
É mesmo suposto estas expressões serem assim? Ou não deverá o rácio ser semelhante nos dois casos? Isto é, não deveria o primeiro rácio ser founds/(difficulty*terrain)?
Obrigado.
Entretanto uma coisa professor, na parte da indexação da estrutura para os top 10 anuais dos raios, o que é suposto fazermos aos pontos perto dos Açores e da Madeira?
O que é suposto fazer é meditar e puxar pela imaginação.Eu só dei algumas sugestões e não pretendo que as minhas palavras sejam entendidas como receitas para serem implementadas da maneira como eu digo.
De qualquer maneira, a sugestão que dei na aula foi colocar numa lista de "outsiders" todas as caches portuguesas situadas fora do retângulo do continente, tanto no mar como nas ilhas.
Mas a sua pergunta fez-me agora fazer aqui umas continhas... Concluí que mesmo uma grelha enorme que abarque o continente e as ilhas não deve gastar assim tanta memória. Até mesmo uma grelha vazia cobrindo o planeta todo teria 4000x4000 células = 16M células = 64MB, o que não é muito numa máquina com 1 GB de memória. Eu disse grelha vazia, porque só vale a pena colocar um objeto numa posição da grelha se o quadrado correspondente tiver alguma cache lá dentro. Os quadrados completamente vazios podem ser representados na grelha por null, para poupar memória.
Boa noite professor, O único problema de criar grelhas sobre uma área qualquer do planeta (eventualmente o planeta todo) é que a terra não é plana. E é bastante complexo tentar definidir quadrados em cima de uma superfície esférica.
Temos coordenadas em graus de latitude e longitude, o problema é que um grau não é sempre igual ao longo da superfície terrestre. Varia devido à curvatura da terra. Logo não posso fazer quadrados do tipo 10km = x em x graus de longitude e latitude.
A quem interessar uma forma ainda mais eficiente de fazer a procura espacial: http://en.wikipedia.org/wiki/K-d_tree Para quem conhecer o numpy/scipy: https://github.com/scipy/scipy/blob/master/scipy/spatial/kdtree.py Em particular a função query_ball_point()
Dou-lhe os parabéns pela investigação que está a fazer. Não me perguntou, mas eu digo pode usar tudo o que descobrir assim como partilhar ideias com os colegas.
No entanto, quero dizer que este projeto não pretende forçar o estudo de técnicas especializadas avançadas. Ao escrever o enunciado, a minha ideia foi que tudo se podia resolver usando conhecimentos gerais de matemática, geometria e programação, e eu espero que a maioria dos alunos vá por este caminho, e vão muito bem...
Já agora, eu sabia que as K-d trees são ótimas para descobrir o vizinho mais próximo. Mas desconhecia, nem me parece evidente, que também servem para descobrir de forma eficiente o número de vizinhos a uma distância inferior a X. Parece interessante...
Proffesor, para fazer load do CSV podemos usar bibliotecas que encontremos na Internet? é que procurei e encontrei o opencsv e queria saber se o poderia usar...
Pode usar tudo o que quiser, desde que comandos de compilação que estão no enunciado funcionem. Parte da avaliação é feita usando "métodos industriais", usando um conjunto de scripts. É a única forma de lidar com dezenas de trabalhos... A outra parte de avaliação é feita lendo o código.
De qualquer forma, é possível carregar o CSV numa matriz (ficando os dados acessíveis por indexação) usando duas linhas de Scala com estas coisas: scala.io.Source.fromFile ... getLines() ... split("\t")
Top 10 of the caches with a larger of rate founds*difficulty*terrain. [Print: rate, code, name. (Ten lines)]
Top 10 of the caches with a larger rate of not-founds/(difficulty*terrain). [Print: rate, code, name. (Ten lines)]
Obrigado pela pergunta.
O primeiro rácio faz sentido porque o número de founds varia na razão inversa da difficulty*terrain. As caches com poucos founds até podem aparecer no top se forem ajudadas por um produto difficulty*terrain muito elevado. Assim faz-se justiça,
O segundo rácio faz sentido porque o número de not-founds varia na razão direta da difficulty*terrain.
Temos coordenadas em graus de latitude e longitude, o problema é que um grau não é sempre igual ao longo da superfície terrestre. Varia devido à curvatura da terra. Logo não posso fazer quadrados do tipo 10km = x em x graus de longitude e latitude.
O detalhe do que é um quadrado nunca chegou a ser discutido. Eu uso a palavra quadrado como uma aproximação e para facilitar o desenvolvimento de algumas ideias até costumo imaginar que estamos num plano.
Na verdade os nossos "quadrados" são superfícies ligeiramente curvas. Além disso, se é verdade que a altura de todos pode ser 10 Kms, já a largura na base é sempre um pouco maior no que a largura no topo (se estivermos no hemisfério norte, o que é o caso). Isto não oferece grande dificuldade de implementar. Eu diria que em termos de largura, só o segmento do topo dos quadrados que aparecem na primeira linha do grande retângulo é que deve ter exatamente 10 Kms de comprimento. Os vértices dos "quadrados" podem ser calculados a partir de cima, sempre a descer, dando saltos de 10 Kms.
Se a grelha for prolongada para sul, para os lados da Madeira, é possível que nessa zona os "quadrados" até tenham 20 Kms de largura em média... não sei, só vendo. De qualquer maneira a utilidade da ideia mantém-se: o que importa é que todos os quadrados tenham pelo menos 10 Kms de largura e de altura.
Boa noite Professor,
eu já criei a matrix com cada quadricula a representar 100KM^2, já tenho os resultados e agora com esta resposta fiquei um pouco perdido.
Poderia explicar melhor? Sff..
Cumprimentos
Com quadriculas de aproximadamente 100 Km^2 é fácil. Para qualquer caso do enunciado do problema só tens que visitar a quadricula onde o ponto actual se insere e outras 8. No entanto, ficas com uma quadrículas com muito mais caches, o que provoca um mais verificações.
No entanto com quadrículas mais pequenas, por exemplo de aproximadamente 10Km^2, apesar de se ter que verificar menos caches para os casos de 1, 5 e 10Km, para os casos de 20, 50 e 100Km tem que se verificar não só 9 quadriculas. Por exemplo, para 20Km tinha que se verificar 5x5 quadrículas (25) e no caso de 50 teriam que ser 11x11 (121) e finalmente para 100 seriam 21x21(441).
Claro que isto poderia ser optimizado se os quadrados tiverem tamanhos mais certinhos (tendo em conta a curvatura da terra) e se faça algum corte nos cantos dos quadrados compostos pelas quadrículas.
Atenção que tudo o que disse até agora é apenas aquilo que penso desta forma de abordar o problema.
e finalmente para 100 seriam 21x21(441)
Mas o tratamento de muitas dessas quadriculas é trivial. Se os quatro cantos duma quadrícula estiverem dentro do círculo de 100 Kms, já não é preciso testar as caches dessa quadricula. Podem ser logo todas somadas ao total. Este é um belo pormenor que foi descoberto durante a aula prática.
Imagine um quadrado com as seguintes coordenadas dos vértices:
(ax,ay) (bx,ay)
(ax,cy) (bx,cy)
Repare que os dois lados horizontais partilham as coordenadas Y e os dois lados verticais partilham as coordenadas X.
Os lados horizontais são paralelos ao equador e ficam efetivamente paralelos entre si. Mas os lados verticais situam-se sobre linhas meridianas (que passam nos polos) e não ficam exatamente paralelos entre si.
Se este quadrado tiver o lado de cima e os lados verticais todos com, digamos, 10 Kms de comprimento, o lado inferior vai ficar ligeiramente maior, digamos com 10.1 Kms.
Como por sua vez o lado inferior deste quadrado é o lado de cima do quadrado mais abaixo, o lado inferior do quadrado mais abaixo vai ficar com, digamos 10.2 Kms.
Apesar destas figuras não serem quadrados perfeitos, pelo menos elas são completamente simétricas relativamente aos dois eixos.
Para que a técnica dos quadrados funcione bem, é preciso usar "quadrados" destes, e que todos os quadrados tenham pelo menos, digamos, 100 Kms2 de área.
Se forcarmos os quadrados a terem 4 lados de 10 Kms, o primeiro quadrado até fica bem. Mas o quadrado seguinte para a direita (obtido por contas "cegas") já não é simétrico, e quanto mais se andar para a direita mais parecidas com losangos vão ficando as figuras, e pior... os losangos vão ficando cada vez mais magrinhos e completamente inúteis para resolver o nosso problema.
Conclusão: é importante usar quadrados semelhantes ao boneco acima, em que os dois lados horizontais partilham as coordenadas Y e os dois lados verticais partilham as coordenadas X. A partir daí podemos esquecer que estamos sobre uma esfera e raciocinar como se estivéssemos num plano.
No caso da Latitude pode-se considerar cerca de 111Km por grau e partir daí gerar as coordenadas aproximadas para o tamanho da quadrícula a considerar.
Mas o caso da Longitude tem muita variação. Há que ver qual a valor mínimo existente no ponto mais Norte de Portugal e usar essa ao longo de todo o país, para criar a grelha.
Em todo o caso esta é uma técnica que apenas funcionará bem para um país pequeno como o nosso. Se se pretender uma solução generalista então esta técnica não é aplicável.
Neste site têm alguns valores para os tamanhos de graus a diferentes latitudes: http://www.zodiacal.com/tools/lat_table.php
Há também sites que calculam estes valores a pedido:
http://www.csgnetwork.com/degreelenllavcalc.html
E a fórmula é algo do género: Length of 1 degree of Longitude = cosine (latitude) * length of degree at equator
Estou com muitas dúvidas em realizar o Additional statistics. Caso o último ano encontrado, caso seja no GPX ou no CSV, seja por exemplo 2012, então todas as funções dessa secção devem ser calculadas desde o primeiro ano até 2012?
Isto já foi respondido várias vezes, mas vale a pena repetir porque o Português é traiçoeiro.
A resposta é SIM. Devido a limitações dos dados, as estatísticas adicionais são feitas exclusivamente para o último ano. Mas, tal como todas as outras estatísticas, são usadas todas as caches desde 1/1/2001 até 31/12 desse ano. (Agora não me lembro se o último ano que aparece nos ficheiros é 2010 ou 2011 - em todo o caso o último ano é determinado automaticamente, como diz o enunciado).
Só para ter a certeza: pode-se assumir que os campos do csv (que é na realidade um tsv...) são sempre os mesmos e seguem sempre a mesma ordem?
Professor: no enunciado, onde está "that have been created from 1/Jan/2001 to 31/Dec/YYYY" não deveria ser "that have been created from 1/Jan/YYYY to 31/Dec/YYYY"? De outra forma, deixam de ser as estatísticas apenas do último ano.
O ficheiro CSV é de menos confiança do que os ficheiros GPX. Só se usa o que está no CSV no caso de ausência de informação.
Citação do enunciado:
Here is an incomplete CSV file (a tab delimited one) to test your program: More.csv.tgz. This file should be processed only after the GPX files. Use it only as source of new data and respect the all data already loaded from the GPX files. The CSV file provides new caches (usually archived caches) and new fields to existing caches.
... as nossas células não serão quadrados perfeitos, mas nós não estamos a conseguir perceber como implementar tal indicação.
Como eu disse atrás, convém usar figuras com as seguintes coordenadas dos vértices
(ax,ay) (bx,ay)
(ax,by) (bx,by)
em que os dois lados horizontais partilham as coordenadas Y e os dois lados verticais partilham as coordenadas X. Esta propriedade é a mesma dos quadrados no plano cartesiano que estão alinhados com os eixos!
Como também disse atrás, os vértices podem ser calculados a partir de cima, sempre a descer, dando saltos de 10 Kms (alterando a coordenada Y e mantendo a coordenada X).
Há mais do que uma forma de organizar estruturas de dados e algoritmos para usar esta ideia. Mas não fica muito diferente de tratar quadrados normais sobre o plano cartesiano.
Só para lembrar algumas partes importantes da secção "Rules", no início do enunciado...
1 - O nome dos ficheiro scala deve ter o formato "xxxxx-xxxxx.scala" (também "xxxxx-xxxxx.css", se houver algum ficheiro auxiliar..)
2 - O ficheiro .scala não deve ter declaração "package".
Professor, só uma pergunta rápida. As caches quando se procuram as que existem em volta deve-se contar com a própria cache, do tipo uma cache tem sempre si própria em volta (ou seja, todas as caches que tenham latidude e longitude têm no mínimo 1 cache em volta que é ela própria), ou ignora-se a própria cache?
Já agora confirme-me também a hora de entrega do projecto. No planeamento diz 22h e no enunciado diz 20h. Qual é a hora correcta?