interruptorpt / ate-onde-chega-cultura Goto Github PK

Em miukimiu#1 adiciona-se o suporte de monumentos para este projecto (tanto nos mapas separados como na aplicação flutter).

No entanto, em miukimiu@6fecc01#diff-96ce2087d61aaa7bfb98313b870d8ecc57d63f2a1a381c6fda230f3f91259306R50 , estamos a usar para monumentos o mesmo ícone dos teatros, devíamos escolher um ícone diferente...

Era interessante poder abrir o mapa global e ter um botãozito para nos fazer zoom na nossa localização actual (se quisermos ver o que há perto de nós!).

...com headers e footers do interruptor, etc...

No seguimento do PR #1 do @marado, ir buscar as queries de Wikidata para os seguintes equipamentos culturais em Portugal:

• teatros
• cinemas
• museus
• recintos de espectáculo
• galerias de arte

O PR deve conter os ficheiros HTML.

Não sei em que estado está o flutter web, mas podiamos ter a app tb a funcionar para a web.

Ver: https://flutter.dev/web

Agora que existe uma forma de mostrar tudo num só mapa, proponho o seguinte:

• eliminar os vários ficheiros separados {bibliotecas,cinamas,galerias,...}.html
• juntar as queries num único sítio (eg: 1 ficheiro por query?)
• juntar o que está a ser feito em #28 e passar a consumir o conteúdo estático

O que te parece @marado ?

A aplicação mobile tem um .gitignore que está fora do root do projecto, não sei se isto tem implicações visto que para abrir o projecto mobile abro a pasta correspondente, mas a documentação do github diz que o .gitignore deve estar no root.

No entanto, isto também põe um problema para quem desenvolve porque se abrimos o projecto a partir do seu root verdadeiro ficamos com o projecto mobile como subpasta o que pode não dar muito jeito por exemplo no android-studio.

Qual é a solução? Ter dois .gitignore?

Além de afinarmos as queries de Wikidata (#2), convém irmos melhorando a qualidade dos dados lá disponibilizados.

• Verificação automatizada:

  • através de bases de dados com listagens de equipamentos (quais?)

• Verificação manual

O texto actual não diz nada sobre o código que está implementado.

Agora que há um mapa geral, seria boa ideia atualizar o README.md

Era boa ideia um query que tivesse tudo para termos uma ideia do mapa.
A segunda fase seria contruir o mapa. Não sei se é para ser OpenStreetMaps ou outra coisa.

A malta do Flutter podia fazer também uma app com o mapa.

Ter um

#defaultView:Map

para os várias iframes

Os dados já podem ser usados offline, mas falta ter o resto das libs do lado do servidor.

• Guardar localmente libs js e css
• Alterar os html (mapa.html) para carregar essas fontes

Em #16 (comment) temos uma visualização interessante (com divisão por distrito), que se calhar podíamos de alguma forma replicar, por uma questão de usabilidade.

Vou abrir issue separada para isto:
github actions para atualizar static-data

Originally posted by @tcarreira in #28 (comment)

No twitter reportaram que um cine-teatro em cascais já não existe. E de facto no wikidata há um comentário a dizer que foi convertido em cinema nos anos 80.

Quando resolvermos os issues #53 , #51 e #48, convinha expandir o README para explicar melhor como se pode contribuir, quer do ponto de vista dos dados no Wikidata, quer do software que os agrega e exibe (este repositório).

Na parte relativa ao Wikidata, por exemplo, algo semelhante ao que comentei aqui podia ser uma base:

A atualização é simples, basta ir ao link do item, http://www.wikidata.org/entity/Q100871052, e carregar no botão de editar aqui:

Após gravar, os dados ficam logo live, podendo haver um delay de alguns segundos para o query service o apanhar.

Além de ajustes a items existentes, fará sentido também mencionar opções de importação de dados, nomeadamente com recurso ao OpenRefine, QuickStatements, Mix'n'Match, OSM.Wikidata.link, e outras ferramentas.

Temos app flutter (android e iOS) mas quem quiser descarregar e instalar a aplicação não tem como.

Na app falta a pasta Linux, era bom que a app corresse também em Linux.

Em ba12054 acrescentámos uma lista de monumentos com página própria e na app de flutter, mas não no mapa.html .

adicionou-se ao mapa global a opção de monumentos, mas falta incluir a imagem images/account_balance24px.svg

É preciso fazer o snap da app.
Quem ficar responsável por isso vai ter também de manter o snap, porque é preciso conta no snapcraft.io
Manter o snap, é básicamente fazer um novo build, quando há actualizações de segurança (carregar num notão no site e publicar a nova build como release nos canais).
As alterações ao ficheiro de configuração do snap podem ser feitas por qualquer pessoa, não dependem da conta.

https://github.com/InterruptorPt/ate-onde-chega-cultura/runs/4029610871?check_suite_focus=true

@tcarrondo queres oferecer-te para tratar tu disto? O:-)

A intenção do projeto parece estar bem explícita, porém do ponto de vista tecnológico nem tanto. Na raiz do projeto você tem vários arquivos HTML, mas também tem uma pasta de um app mobile, não fica claro se é um projeto Web ou Mobile (ou ambos). Seria bom deixar mais claro isso no README.md principal, dizer que existem dois subprojetos etc. Além disso, deveria organizar os arquivos em pasta por subprojeto, por exemplo criar uma pasta para Web.

Temos várias páginas estáticas com mapas, mas não temos links de uns para outros, o que podia ser melhorado

Temos actualmente uma série de HTMLs estáticos em que a única coisa que muda é o texto do header e a query wikidata... Talvez usar uma ferramenta de templating ou algo do género fosse bom para manter só um .html em vez de vários "iguais".

Preparar um script que faça download dos dados das queries, e os guarde em formato estático (eg: json)
Publicar esses dados num sítio acessível (outro branch?)

• download json
• encontrar as queries nos ficheiros html
• github actions para publicar os json -> #51

O formato do JSON para a cache dos dados do Wikidata (#47) é consideravelmente ruidoso e ocupa bastante espaço com dados que não precisamos.

-{
-    "head": {
-        "vars": [
-            "item",
-            "itemLabel",
-            "geo"
-        ]
-    },
-    "results": {
-        "bindings": [
-            {
+                "geo": {
-                    "datatype": "http://www.opengis.net/ont/geosparql#wktLiteral",
-                    "type": "literal",
+                    "value": "Point(-9.147787 38.706746)"
-                },
+                "item": {
-                    "type": "uri",
+                    "value": "http://www.wikidata.org/entity/Q99845706"
-                },
+                "itemLabel": {
-                    "type": "literal",
+                    "value": "A Pequena Galeria",
-                    "xml:lang": "pt"
-                }
-            },
-            {
+                "geo": {
-                    "datatype": "http://www.opengis.net/ont/geosparql#wktLiteral",
-                    "type": "literal",
+                    "value": "Point(-16.90333 32.64816)"
-                },
+                "item": {
-                    "type": "uri",
+                    "value": "http://www.wikidata.org/entity/Q76955108"
-                },
+                "itemLabel": {
-                    "type": "literal",
+                    "value": "Capela de Nossa Senhora da Oliveira",
-                    "xml:lang": "pt"
-                }
-            }
-        ]
-    }
-}

- [
-    {
+        "item": "http://www.wikidata.org/entity/Q99845706",
+        "itemLabel": "A Pequena Galeria",
+        "geo": "Point(-9.147787 38.706746)"
-    },
-    {
+        "item": "http://www.wikidata.org/entity/Q76955108",
+        "itemLabel": "Capela de Nossa Senhora da Oliveira",
+        "geo": "Point(-16.90333 32.64816)"
-    }
-]

Ou ainda melhor, em TSV:

item	itemLabel	geo
http://www.wikidata.org/entity/Q99845706	A Pequena Galeria	Point(-9.147787 38.706746)
http://www.wikidata.org/entity/Q76955108	Capela de Nossa Senhora da Oliveira	Point(-16.90333 32.64816)

Não sei se ao implementarmos a conversão para GeoJSON (#48) iremos substituir os dados e a forma como montamos o mapa.html; mas caso decidamos manter os dados brutos em paralelo ao GeoJSON, pode ser vantajoso usar um formato mais compacto e mais legível. Citando o meu comentário em #47:

talvez possamos fazer o download em csv ou tsv? Assim os ficheiros ficam mais pequenos, e até fica mais fácil consultá-los no github porque são mostrados como tabelas.

Pode ser o link para o item no wikidata, como primeiro passo, e numa passo futuro melhorar as queries para fazer algo do género mostrar o site oficial se tiver, caso contrário mostrar a página wikipédia (pt ou en) se tiver, caso contrário mostrar o item no wikidata.

As coordenadas estão erradas, é erro no wikidata mas fica aqui apontado, para eu me lembrar de resolver ;-)

☐ download json

Em relação ao formato, penso que guardar diretamente em GeoJSON pode ser a melhor opção, porque não só os dados ficam semanticamente anotados, como quer o Leaflet quer o próprio GitHub conseguem fazer rendering diretamente de dados em GeoJSON, não sendo preciso qualquer processamento. Até dá para configurar o GeoJSON para usar ícones personalizados (do conjunto Maki) e color-coding dos pontos por categoria!

Estive a fazer umas experiências e basicamente basta transformar os dados brutos do Wikidata no GeoJSON equivalente, o que pode ser feito de forma completamente determinística. Por exemplo, esta entrada de uma lista de resultados do Wikidata (exportado como JSON):

{
  "item": "http://www.wikidata.org/entity/Q71890449",
  "itemLabel": "Biblioteca Municipal de Figueiró dos Vinhos",
  "geo": "Point(-8.273731 39.900399)"
}

...seria convertido neste GeoJSON (mostrado em notação diff para salientar as linhas correspondentes ao JSON acima):

 {
   "type": "Feature",
   "geometry": {
     "type": "Point",
+    "coordinates": [-8.273731, 39.900399]
   },
   "properties": {
+    "nome": "Biblioteca Municipal de Figueiró dos Vinhos",
     "tipo": "biblioteca",
+    "wikidata": "<a href='https://www.wikidata.org/wiki/Q71890449'>Q71890449</a>",
     "marker-symbol": "library",
     "marker-color": "#f90"
   }
 }

Criei um gist a mostrar como fica com vários tipos de entidades, ícones e cores personalizadas. Screenshot abaixo para aguçar o apetite :)

Originally posted by @waldyrious in #28 (comment)

Aparentemente os dados do WikiData não estão sincronizados com os do OSM, e o OSM também tem muitos dados relevantes e pelo menos em alguns casos melhores sobre equipamentos culturais. Será possível utilizar dados das duas fontes, mas evitando duplicações? Que alterações teriam que ser feitas?

O wikidata tem informação de alguns coretos Portugueses ( https://w.wiki/rGC ), mas não todos.

Em https://web.archive.org/web/20170708112636/http://www.meloteca.com/coretos.htm temos uma lista de coretos em Portugal, divididos por distrito, seria talvez interessante "importar" esses dados para o wikidata.

Também seria interessante geolocalizar os que já estão no wikidata, mas ainda não têm informação geográfica.