Scene Map: como reproduzir o dataset com Wikidata e SPARQL

Quando o mapa vira banco de dados: por que o Movie Scene Map interessa mais a devs do que a cinéfilos

Quando vi a notícia do Sapo.pt sobre o Movie Scene Map, meu primeiro instinto não foi pensar em filmes — foi pensar em query SPARQL. Um mapa interativo, sem login, sem ads, agregando 15.845 locais reais de filmagem em 166 países, com a Wikidata como espinha dorsal e um pipeline de mineração de texto na Wikipédia rodando desde agosto de 2026? Isso é um caso de estudo de knowledge graph mal disfarçado de site de curiosidades. Na minha experiência, projetos assim são onde a engenharia de dados encontra o produto final de um jeito que dá para aprender muito.

Vamos dissecar isso do ponto de vista técnico — o que tem por trás, como reproduzir a extração de dados, onde estão as armadilhas e por que vale a pena você perder 15 minutos brincando com isso.

O que é o Movie Scene Map, na prática

O Movie Scene Map é um mapa-múndi interativo onde cada pin representa um local real usado como cenário em algum filme, série ou jogo. Você entra, digita “Lord of the Rings” e vê os pontos na Nova Zelândia acenderem. Pode inverter a busca: clica num ponto em Tóquio e descobre quais produções passaram por ali.

Detalhes que a nota do Sapo.pt destaca e que fazem diferença técnica:

• 15.845 locais catalogados, espalhados por 166 países.
• Backend totalmente gratuito, sem ads, sem cadastro — modelo raro hoje.
• Animes e mangás são indexados pelo local onde a história se passa, não onde foram filmados (decisão editorial relevante para filtragem).
• Dados estruturados vêm da Wikidata via declarações “filming location” (P276).
• Desde agosto de 2026, scraping adicional do texto da Wikipédia captura locais mencionados em prosa que ainda não estão estruturados.

A arquitetura por trás do projeto — e o que devs podem aprender com ela

O stack me parece ser o clássico: um frontend de mapa (provavelmente Leaflet ou MapLibre, considerando que é gratuito e sem tracking) consumindo um endpoint que serve GeoJSON. O dado vive na Wikidata, é espelhado para um banco próprio (provavelmente PostgreSQL/PostGIS para queries geográficas rápidas), e um job periódico faz entity extraction em prosa da Wikipédia para preencher buracos.

Isso é importante: a Wikidata não é só um wiki. É um grafo de conhecimento aberto, com URIs estáveis (Q-numbers), propriedades tipadas (P-numbers) e qualificadores. Para um dev, é a maior fonte de dados estruturados do mundo que existe — e quase ninguém explora direito.

Por que a P276 muda tudo

A propriedade P276 na Wikidata é “location” — usada tanto para eventos quanto para filmagens quando combinada com o qualificador apropriado ou quando o item da obra tem uma declaração explícita “filming location”. O Movie Scene Map provavelmente faz algo assim:

SELECT ?film ?filmLabel ?location ?locationLabel ?coords WHERE {
  ?film wdt:P31/wdt:P279* wd:Q11424 .      # instância de filme
  ?film wdt:P276 ?location .                 # propriedade filming location
  ?location wdt:P625 ?coords .               # coordenadas geográficas
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en,pt". }
}
LIMIT 500

Rode isso no Query Service da Wikidata e você terá um subset do que alimenta o Movie Scene Map. Em produção, com 15k+ locais, eles devem pré-computar isso e cachear.

Na Prática: reproduzindo o dataset em 5 minutos

Se você quiser testar a abordagem antes de depender de qualquer serviço externo, dá para montar um pipeline mínimo com Python. Aqui vai um exemplo funcional usando a biblioteca qwikidata + requests:

import requests
import json

QUERY = """
SELECT ?film ?filmLabel ?location ?locationLabel ?lat ?lon WHERE {
  ?film wdt:P31 wd:Q11424 .
  ?film wdt:P276 ?location .
  ?location wdt:P625 ?coord .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }
  BIND(geof:latitude(?coord) AS ?lat)
  BIND(geof:longitude(?coord) AS ?lon)
}
LIMIT 1000
"""

def fetch_filming_locations(endpoint="https://query.wikidata.org/sparql"):
    headers = {"Accept": "application/sparql-results+json"}
    r = requests.get(endpoint, params={"query": QUERY}, headers=headers, timeout=30)
    r.raise_for_status()
    bindings = r.json()["results"]["bindings"]
    return [
        {
            "film": b["filmLabel"]["value"],
            "location": b["locationLabel"]["value"],
            "lat": float(b["lat"]["value"]),
            "lon": float(b["lon"]["value"]),
            "qid": b["location"]["value"].split("/")[-1],
        }
        for b in bindings
    ]

if __name__ == "__main__":
    data = fetch_filming_locations()
    with open("locations.geojson", "w", encoding="utf-8") as f:
        geojson = {
            "type": "FeatureCollection",
            "features": [
                {
                    "type": "Feature",
                    "geometry": {"type": "Point", "coordinates": [d["lon"], d["lat"]]},
                    "properties": {"film": d["film"], "location": d["location"], "qid": d["qid"]},
                }
                for d in data
            ],
        }
        json.dump(geojson, f, ensure_ascii=False, indent=2)
    print(f"Exportadas {len(data)} localizações")

Esse script baixa mil localizações, converte para GeoJSON e está pronto para abrir no QGIS, Kepler.gl ou direto no MapLibre. Para chegar aos 15.845 do Movie Scene Map, basta aumentar o LIMIT, paginar com OFFSET e remover o filtro restritivo wd:Q11424 (filme) — inclua wd:Q5398426 (série de TV) e wd:Q7889 (videogame).

O truque do “scraping de prosa”

O segundo pipeline, ativo desde agosto de 2026, é mais interessante tecnicamente. A Wikidata só tem o que os editores estruturaram. Mas a Wikipédia tem muito mais: parágrafos inteiros descrevendo filmagens que nunca viraram tripletas RDF. Para preencher isso, você precisa de NER (Named Entity Recognition) geográfico rodando sobre os artigos.

Em produção, o pipeline provavelmente é:

1. Para cada item “film” na Wikidata, pegar o sitelinks e puxar o texto do artigo em inglês.
2. Rodar um NER (spaCy com en_core_web_trf, ou o modelo do Google Geocoding API, ou GeoNames + heurística).
3. Resolver a entidade para um Q-item da Wikidata via wikidata entity linker.
4. Cruzar com as coordenadas da P625 e adicionar como nova declaração P276.

É NLP + knowledge graph fusion. Não é trivial — é por isso que o Movie Scene Map só foi adicionar essa camada agora.

Erros comuns que devs cometem quando mexem com dados geográficos da Wikidata

Já vi muita gente tropeçar nesses pontos. Salva tempo:

• Confundir P276 com P937. P276 é “local do evento” (inclui filmagem). P937 é “local de trabalho” (cidade onde alguém viveu). Para filmagem, é P276 com a obra como sujeito.
• Esquecer os qualificadores. Uma filmagem pode ter múltiplos P276 com qualificador P580/P582 (início/fim) ou P659 (tipo de gravação). Filtrar só pelo claim principal perde filmagens parciais ou B-roll.
• Coordenadas (0,0). A P625 às vezes tem Precision=0 ou aponta para Null Island. Sempre valide antes de plotar.
• Limites da API. O endpoint público da Wikidata limita em ~60s por query. Para datasets grandes, use OFFSET ou o novo endpoint /bigdata/namespace/wdq/.
• Idiomas. O SERVICE wikibase:label tenta todos os idiomas configurados. Se você quer só PT-BR, declare explicitamente para não pegar labels em japonês com transliteração ruim.
• Deduplicação por distância. Dois Q-items podem representar o mesmo local (Castelo de Edimburgo vs. Edinburgh Castle). Calcule distância geográfica antes de mesclar — confiar só no label dá falso positivo.

Comparação honesta: como o Movie Scene Map se posiciona contra alternativas

Você pode estar se perguntando: “Mas o TMDB e o IMDb já não têm isso?” Resposta curta: não do mesmo jeito, e por motivos diferentes.

Na minha experiência, o Movie Scene Map vence pela curadoria. Pegar a Wikidata crua resultaria num mapa poluído com estúdios genéricos, cidades de produção (não de filmagem) e falsos positivos de geocoding. Quem mantém o site fez o trabalho sujo de validar e limpar — e isso vale mais do que ter o dataset bruto.

Quando não usar dados da Wikidata

Se você precisa de dados para fins comerciais, com SLA e estabilidade de schema, a Wikidata não é a fonte certa — é wikibase, qualquer editor pode mudar estrutura. Para produção séria, faça mirror para um banco seu e congele o snapshot. Já vi sistemas quebrarem porque alguém renomeou uma propriedade num domingo à noite.

FAQ — perguntas reais que devs fazem

O Movie Scene Map tem API pública?
Pela descrição do Sapo.pt, o site é gratuito e sem cadastro, mas não menciona endpoint oficial. Para integrações, o caminho é consultar a Wikidata diretamente via SPARQL — é o que mostrei no script acima.

Os dados cobrem videogames e animes de verdade?
Videogames sim, com a ressalva de que a captura é mais fraca que filmes/séries. Animes entram pelo local narrativo, não real — então Attack on Titan aparece na Muralha Maria (Paradis), não num estúdio de Tóquio. É uma decisão de modelagem válida, mas precisa ficar clara para o usuário.

Posso contribuir com novos locais?
A Wikidata é wiki — qualquer pessoa com conta pode editar a propriedade P276 de um filme. Suas mudanças aparecem no Movie Scene Map no próximo refresh do mirror. É o jeito mais direto de “crowdsource” o dataset.

Qual a stack provável do frontend?
Aposto em MapLibre GL JS (sucessor open-source do Mapbox) sobre tiles do OpenStreetMap, com clustering nativo para não fritar o browser com 16k pontos. É a combinação padrão para projetos sem orçamento de tiles comerciais.

Esse tipo de projeto sobrevive sem financiamento?
Sobrevive enquanto o mantenedor tiver motivação pessoal. Quando a motivação acaba, o mirror fica desatualizado e o site morre silenciosamente. Se você depende disso em produção, faça seu próprio mirror. Não confie em side projects alheios como fonte crítica.

Veredito: vale os 15 minutos?

Vale, e por motivos que vão além da curiosidade geográfica. O Movie Scene Map é um exemplo limpo de como montar um produto de dados sem ter os dados — você terceiriza a curadoria para a comunidade (Wikidata), automatiza a coleta (SPARQL), complementa com NLP (Wikipedia) e entrega numa interface que qualquer pessoa entende. É o template que vale copiar.

Na minha experiência, os projetos que sobrevivem mais tempo são exatamente esses: os que constroem sobre open data em vez de brigar com ela. Se você trabalha com knowledge graphs, geolocalização ou simplesmente quer ver SPARQL em ação num contexto divertido, abra o site, rode o query acima e depois me conta o que achou.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.