OpenStreetMap

hvalentim's diary

Recent diary entries

Toponímia de Lisboa em formato OpenStreetMap

Posted by hvalentim on 3 October 2020 in Portuguese (Português). Last updated on 5 October 2020.

Versão convertida, segundo critérios descritos aqui, para o formato OpenStreetMap (OSM-XML) dos dados fornecidos em regime aberto pela Câmara Municipal de Lisboa.

Ficheiro para descarga: CMLisboa_Toponimia.zip (~1MB)

NB: Baseado no último dataset disponível à data de Julho de 2019. Uma versão mais actualizada dos dados originais CML parece estar disponível no sudomínio geodados.

Elementos para uma avaliação da concordância entre a classificação do uso do solo no openstreetmap e na COS2018

Posted by hvalentim on 1 March 2020 in Portuguese (Português).

Trabalho a título exploratório, derivado na sequência da proposta anteriormente avançada:

http://valentim.org/elementos-para-uma-avaliacao-da-concordancia-entre-classificacao-do-uso-do-solo-no-openstreetmap-e

Tabela de correspondências entre as categorias da Carta de Ocupação do Solo 2018 e o esquema classificatório do openstreetmap

Posted by hvalentim on 24 February 2020 in Portuguese (Português). Last updated on 1 March 2020.

Instrumento de apoio para proceder à conversão entre o esquema empregue no ficheiro em formato shape, fornecido pela Direcção Geral do Território, da mais recente COS (v.2018) - descrevendo os tipos de uso de solo em Portugal e nos Açores - e o formato openstreetmap (OSM).

Detalhes aqui: http://valentim.org/tabela-de-correspondencias-entre-categorias-da-carta-de-ocupacao-do-solo-2018-e-o-esquema

Disponível: Mapa de Portugal com estilo topográfico

Posted by hvalentim on 12 April 2019 in Portuguese (Português). Last updated on 10 May 2019.

Porque, desde que o antigo IGEOE descontinuou o acesso à versão, ainda que em janela microscópica, das Cartas Militares, não há em Portugal onde consultar em linha, gratuitamente, um mapa que tal; porque a camada WMS das cartas 50K disponibilizada pela DGT, limitada ao zoom 13, é inútil; porque as razões para utilizar um mapa não têm que ser só e sobretudo promover ou procurar "negócios" nem pretextos orientados para gerar uma transacção comercial; porque o OpenStreetMap não é o OpenStreetMap.org e a respectiva arquitectura e potencialidades não se compreendem bem sem tentar executar o passo seguinte: produzir um mapa à medida. Com base nos seus dados e numa versão adaptada do estilo OpenTopoMap, disponibilizo uma versão de um mapa topográfico de Portugal (Continente e Ilhas).

O essencial da ideia é ter um algo de relativamente clean, expurgado de distracções e do excesso de cores e de informação para onde, por definição, o OSM propende e que facilite uma leitura imediata do terreno, enfatizando simultaneamente os pontos de interesse natural e cultural, mormente o património edificado e os equipamentos (museus, centros de exposições etc.), permitindo num golpe de vista reconhecer os motivos de interesse numa dada zona.

Trata-se simultaneamente de:

  1. Um WEBMAP que pode ser consultado directamente na interface disponível em map.valentim.org, com a adição de algumas funcionalidades, entre as quais:
    • Função “O que é isto?”. Permite obter informação sobre objectos no mapa mediante clique sobre os mesmos, a partir de consulta ao Overpass API.
      Dica: no caso de polígonos/áreas ao invés de clicar no centro exprimente clicar nas linhas que os delimitam. Apenas objectos com nome são apresentados.
    • Função “Pesquisa”. Permite procurar e centrar o mapa um local procurando-o pelo nome, mediante consulta ao Nominatim.
    • Função “Edite esta zona no OpenStreetMap”, abre a área para edição, à escolha, directamente num dos três editores mais populares (ID, Josm e Potlatch).
  2. Um TILESERVER que permite a qualquer um a livre inclusão do mapa nas suas próprias páginas web, bem como o consumo em aplicações compatíveis. Por exemplo:
    • Utilizando o Leaflet, basta definir uma nova camada do tipo “TileLayer”, indicando os parâmetros:
      • url base: 'http://map.valentim.org/otmpt/{z}/{x}/{y}.png'
      • maxZoom: 17
      • bounds: new L.LatLngBounds(new L.LatLng(29.879, -31.729), new L.LatLng(42.192, -6.125));
      • attribution: '<a href="http://map.valentim.org"><strong>map.valentim.org</strong></a> | Dados: Contribuidores do <a href="http://www.openstreetmap.org/about" target="_blank">OpenStreetMap</a>, <a href="https://land.copernicus.eu/imagery-in-situ/eu-dem" target="_blank">Copernicus</a> | Estilo: <a href="https://github.com/der-stefan/OpenTopoMap" target="_blank">OpenTopoMap</a>, &copy; <a href="https://creativecommons.org/licenses/by-sa/3.0/" target="_blank">CC-BY-SA</a>',
    • No QGIS, Adicionado uma camada do tipo XYZ Tiles. Menu “layer” -> "Data Source Manager" -> "XYZ Tiles" -> "clique direito do rato" -> opção “New Connection” -> Introduzir os parâmetros:
      • Name: map.valentim.org
      • URL:  http://map.valentim.org/otmpt/{z}/{x}/{y}.png
      • Min. Zoom Level: 5
      • Max. Zoom Level: 17
      • Referer: QGIS
        NB: Para visualizar a camada, no mesmo local, após definição supra -> clique direito do rato sobre o nome -> "Add Layer to Project".

Principais diferenças/acréscimos face ao estilo original OpenTopoMap:

  • Actualizado todos os dias com as modificações introduzidas pelos colaboradores do OSM (o OTM é-o apenas muito esporadicamente);
  • Hillshade e curvas de nível melhorados com base num DEM (modelo digital da elevação do terreno) personalizado, de maior resolução, incluindo, entre outros, dados Copernicus e do IGN espanhol;
  • Representa a orografia (relevo) dos fundos marinhos segundo dados GEBCO (níveis de zoom 5 a 8);
  • Incorpora a informação batimétrica (profundidade) do Instituto Hidrográfico (níveis de zoom 9 a 17);
  • Incorpora a nomenclatura "underseas feature names" (níveis de zoom 8 a 17) da Organização Hidrográfica Internacional;
  • Enfatiza o património e os pontos de interesse cultural (objectos históricos, museus e arts_centres);
  • Assinala vértices geodésicos;
  • Assinala os nomes das praias;
  • Assinala waterfalls (quedas de água);
  • Assinala parques, jardins e campos de golfe;
  • Assinala pontos de informação turística (excepto guideposts);
  • Assinala [leisure] = 'picnic' or [leisure] = 'picnic_table' or [tourism] = 'picnic_site';
  • Diferencia graficamente as zonas de protecção especial entre aquelas a valores naturais e as a património imóvel de valor histórico-cultural;
  • Enfatiza historic=archeological site com icone próprio;
  • Enfatiza os cumes;
  • Mostra todos os miradouros/pontos cénicos (o original, apenas aqueles com direcção definida);
  • Inclui o paredão das barragens;
  • Representa campos de cultivo genéricos (farmland), distinguindo ainda arrozais (campos alagados);
  • Outros pequenos pormenores (representação de shoal - áreas a descoberto na baixa-mar; colocação das curvas de nível sob, ao invés de sobre, linhas de água e edifícios et cetera).

Trata-se de trabalho em progresso. Sugestões são bem-vindas.

Património protegido (heritage): lacunas, ambiguidades e soluções para as ultrapassar

Posted by hvalentim on 6 April 2019 in Portuguese (Português). Last updated on 8 May 2019.

Reúno aqui um conjunto de reflexões avulsas sobre o mapeamento do património português classificado, mormente arquitectónico, no OSM; algumas lacunas detectadas e outras tantas propostas de melhoria/uniformização de critérios. Por facilidade, a exposição reparte-se em 8 (oito) alíneas. As sugestões de procedimento estão diferenciadas com fiundo verde.


A) COMO LIDAR COM A PLURALIDADE DE SÍTIOS DE REFERÊNCIA?

Como é sabido, temos em Portugal pelo menos três bases de dados de entidades públicas em matéria de Património imóvel, cada qual com as suas particularidades. A saber:

1 – DGPC - Direcão Geral do Património Cultural (5737 registos) - http://www.patrimoniocultural.gov.pt/pt/

  • Focada no processo formal de classificação, mantém os dados mais actualizados relativamente ao trâmites e legislação aplicável em cada caso.
  • É bastante mais consistente do que o SIPA na classificação da informação (pese embora os KITs Património, originais do IGESPAR). Tem um reduzido número de categorias – mormente “Situação Actual” e “Categoria de Protecção” - em que reparte coerentemente cada registo. No SIPA a informação foi notoriamente introduzida de forma aberta, mediante redacção manual, por distintas pessoas, ao longo dos anos – está, por conseguinte, sujeita a nomenclaturas variadas e também a maior número de imprecisões.
  • A DGPC é a melhor fonte para informação sobre (seguindo a convenção, “Campo DGPC -> key equivalente no OSM”):
    • "Categoria de Protecção" -> heritage (níveis 1,2 e 7)
    • "Categoria de Protecção" -> heritage:ref
    • "Situação Actual" -> site_status
    • Em contrapartida a base de dados DGPC é substancialmente mais lacónica quanto às classificações do património local (promovidas pelas câmaras) e totalmente omissa quanto ao regional (promovido pelas entidades dos governos autónomos dos Açores e da Madeira).

2 – SIPA – Sistema de Informação para o Património Arquitectónico (34357 registos) -  http://www.monumentos.gov.pt

3 – Portal do Arqueólogo (34605 registos) - http://arqueologia.patrimoniocultural.pt/

Fonte dilecta mormente em matéria de historic=archeological_site e derivados, fornecendo, melhor do que os outros, detalhes preciosos sobre as intervenções realizadas e o “Período” -> historic:civilization -> historic:period -> historic:era et cetera...

Assim, atendendo ainda a que:

  • 2 e 3 fornecem referências passíveis de identificar cada objecto individual ("Número IPA" e "CNS" – Código Nacional de Sítio, respectivamente).
  • A presença dessas referências (identificadores únicos), bem como de ligações (urls) para as respectivas páginas com os detalhes de enquadramento histórico, é importante não só para organização do trabalho; para referência do utilizador final que procura fontes para se documentar e comprender os locais, como, finalmente, e não menos importante, para assegurar, se for caso disso, a possibilidade de benefício do trabalho dos colaboradores do OSM para melhoria das fontes públicas (não sendo incomum constatar-se que as localizações do OSM são mais precisas e diferem substancialmente das oficiosas - por vezes meras aproximações grosseiras).

Prefigura-se, finalmente, para o que nos interessa, um cenário em que, no limite, se quisermos incluir um imóvel com o máximo de completude, será possível encontrar casos com até 5 (cinco) urls (sendo património mundial, estando presente nos 3 inventários oficiais e possuindo ainda uma página própria, independente deles – e.g. sendo coincidentemente um Museu aberto ao público…) e 2 (dois) identificadores (IPA e CNS).

Colocando-se a questão: como organizar tanta informação de forma coerente e sem atropelo?

A.1 - Proposta de solução para a multiplicidade de urls/websites

Prefixar a key heritage:website com o acrónimo da entidade, excepto no caso da dgpc que se assume como principal fonte de referência, reservando-se para ela, também por questão de compatibilidade e expectativa das aplicações que eventualmente possam consumir os dados, a key básica heritage_website, sem prefixo.

Assim teríamos a possibilidade de coexistência de:
heritage:website:whc=<url no whc.unesco.org>
heritage:website=<url no patrimoniocultural.pt - DGPC> (1)
heritage:website:sipa=<url no monumentos.pt - SIPA> (2)
heritage:website:arqueologia=< url no arqueologia.patrimoniocultural.pt - Portal do Arqueólogo>
website=<url de página própria específica, quando exista, por exemplo com os detalhes de horário, tipicamente mantida pelo operador do monumento>

A.2 - Proposta de solução para a multiplicidade de identificadores únicos:
Discriminar as referências, consoante a fonte, adoptando
ref:whc=<Número no Inventário do Património Mundial UNESCO>
ref:ipa=<Número IPA. Inteiro, expurgado de prefixos e consoante é por exemplo usado no url, após o “=”>
ref:cns=<Número CNS>
ref:dgpc=Opcional, porém útil para o cruzamento dos dados. Correpondente ao número final constante no URL da página de detalhes de cada registo no patrimoniocultural.pt (valor 74178 no exemplo dado nas notas imediatamente a seguir). Trata-se de um identificador artificioso para fim puramente prático.

(1) A forma mais comum de URL é passível de abreviação. Assim:
http://www.patrimoniocultural.gov.pt/pt/patrimonio/patrimonio-imovel/pesquisa-do-patrimonio/classificado-ou-em-vias-de-classificacao/geral/view/74178
funciona igualmente sob a forma, mais curta:
http://patrimoniocultural.pt/pt/patrimonio/pesquisa/geral/patrimonioimovel/detail/74178
(2) Funciona sob, pelo menos, um par de domínios:
http://www.monumentos.gov.pt
http://monumentos.pt
Será conveniente dar preferência ao mais simples: monumentos.pt (segunda fórmula).


B) AUSÊNCIA DO NÍVEL 4 (PATRIMÓNIO CLASSIFICADO PELOS GOVERNOS REGIONAIS)

Constata-se a existência de algumas dezenas de ocorrências (para exemplos consulte-se o monumentos.pt - em "pesquisa avançada") recaindo numa categoria não contemplada na documentação do original da key heritage no OSM. Trata-se de património classificado pelas entidades das regiões autónomas.

B.1 - Proposta de solução

Adicionar à documentação o nível:

Imóvel de Interesse Regional
heritage=4

  • heritage:ref=
    • CAVR - Conjunto Arquitetónico de Valor Regional
    • CCIP - Conjunto Classificado de Interesse Público
    • VCL - Valor Cultural Local
    • VR - Valor Regional

C) AMBIGUIDADE QUANTO AO CONTEÚDO (VALOR) DO HERITAGE:REF

A laconicidade da documentação suscita dúvida quanto a se o valor se deve limitar apenas ao acrónimo (forma abreviada – por exemplo, "MN") ou se se deve incluir simultaneamente este e a sua forma por extenso, separados por um travessão (por exemplo "MN – Monumento Nacional")?

Do estrito ponto de vista da base de dados que é o OSM a redução ao acrónimo é preferível. Já do ponto de vista do utilizador final (por exemplo ao consultar os detalhes do objecto no openstreetmap.org) a forma completa resulta mais facilmente inteligível.

C.1 - Proposta de solução:

Separar a abreviatura e a respectiva forma longa em campos/keys distintos:

  • Manter, como elemento mínimo e legado retrocompatível heritage:ref=ABREVIATURA (ex.: MN)
  • Acrescentar facultativamente a key protection_title=FORMA POR EXTENSO (ex.: Monumento Nacional)

D) AMBIGUIDADE NO USO DOS VALORES HERITAGE=NO E HERITAGE=YES

D..1 - Sugestão de desambiguação

heritage=no
Reservado aqueles casos presentes no inventário dos sítios supra, porém não sujeitos a protecção legal (processos dados como arquivados ou caducados)

heritage=yes
Deve ser evitado e não faz normalmente sentido. Se é “sim” (classificado) tem que ter um heritage:ref com a categoria respectiva.
Só se concebe nos casos em que:
- funciona como mnemónica temporária (o utilizador está com pressa e prefere preencher o valor mais tarde);
- o processo de classificação foi iniciado, porém ainda não foi definida a categoria a atribuir (ver a alínea seguinte).


E) CASOS DO PATRIMÓNIO COM PROCESSO DE CLASSIFICAÇÃO A DECORRER

Nos casos com homologação ou em vias de classificação com estatuto especifico já designado/atribuído deveria adicionar-se as keys heritage e heritage:ref com os valores homologados, adicionando ainda o campo site_status (veja-se a segunda tabela, infra) para os diferenciar,

Assim, tudo somado, com base na DGPC, teríamos as seguintes "tabelas de equivalências":

"Categoria de Proteccão" (consoante a DGPC) heritage heritage:ref protection_title site_status
Classificado como CIM - Conjunto de Interesse Municipal 7 CIM Conjunto de Interesse Municipal ver tabela seguinte
Classificado como CIP - Conjunto de Interesse Público 2 CIP Conjunto de Interesse Público
Classificado como IIP - Imóvel de Interesse Público 2 IIP Imóvel de Interesse Público
Classificado como IM - Interesse Municipal 7 IM Interesse Municipal
Classificado como MIM - Monumento de Interesse Municipal 7 MIM Monumento de Interesse Municipal
Classificado como MIP - Monumento de Interesse Público 2 MIP Monumento de Interesse Público
Classificado como MN - Monumento Nacional 2 MN Monumento Nacional
Classificado como SIM - Sítio de Interesse Municipal 7 SIM Sítio de Interesse Municipal
Classificado como SIP - Sítio de Interesse Público 2 SIP Sítio de Interesse Público
Em Vias de Classificação (com Despacho de Abertura) yes
Em Vias de Classificação (Homologado como IIP -... 2 IIP Imóvel de Interesse Público
Em Vias de Classificação (Homologado como IM -... 2 IM Interesse Municipal
Em Vias de Classificação (Homologado como MN -... 2 MN Monumento Nacional
Em Vias de Classificação para CIM - Conjunto... 7 CIM Conjunto de Interesse Municipal
Em Vias de Classificação para IM - Interesse... 7 IM  Interesse Municipal
Em Vias de Classificação para MIM - Monumento... 7 MIM Monumento de Interesse Municipal
Em Vias de Classificação para SIM - Sítio... 7 SIM Sítio de Interesse Municipal
Não aplicável no
Procedimento encerrado / arquivado (processo individual). Abrangido em… no (*)

(*) Quase sempre, excepto 5 casos integrados em conjunto com protecção.

site_status=
"Situação Actual" (consoante a DGPC), um de:
heritage=
Classificado 1,2,4 ou 7 consoante a categoria de protecção.
Desclassificado - sem protecção legal no
Em Estudo - sem protecção legal no
Em Estudo com Despacho de Abertura - sem... no
Em Vias de Classificação 1,2,4 ou 7 consoante a categoria de protecção.
Integrado em conjunto com protecção legal yes
Procedimento caducado - sem protecção legal no
Procedimento encerrado / arquivado - sem protecção legal no
Sem protecção legal no

F) NECESSIDADE DE CLARIFICAÇÃO DOS USOS DE heritage:since, inscription_date e start_date

heritage:since= Data do diploma que promulga a classificação do património.

O seu uso está generalizado e não faz muito sentido mudar.

Ainda assim, nos casos em que se regista uma dupla inscrição (como é o caso do património mundial) este tag pode coexistir com:
whc: inscription_date=<Data de inscrição pela UNESCO>.

start_date=
A documentação entra em conflito.
Na lógica da classificação do objecto histórico https://wiki.openstreetmap.org/wiki/Key:historic:civilization sugere que start_date é o ano de construção;
já na lógica da classificação do património protegido https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area sugere que é a data do início da protecção.

Atendendo a que ambas as classificações tendem a coexistir num mesmo objecto (os alvos de protecção têm quase sempre significado histórico), é melhor optar pela primeira definição, reservando start_date para o momento da construção.


G): ABUSO DA APLICAÇÃO INDIFERENCIADA DA KEY leisure=nature_reserve AO PATRIMÓNIO HISTÓRICO

Dado que o estilo mapnik empregue na geração do sítio openstreetmap.org (carto) não contempla (isto é omite) a reprodução de linhas (boundaries) relativamente a património alvo de outra protecção que não a identificada com a key leisure=nature_reseve ("protected area of importance for wildlife, flora, fauna or features of geological or other special interest") esta é frequentemente usada, ainda que com prejuízo do rigor, de forma indiferenciada, com base num critério compreensível, porém eminentemente cosmético (a vontade de gerar uma linha em torno do objecto).

No mínimo convém sempre diferenciar os objectos em que se protegem os valores naturais (Paisagem Protegida, Reserva Natural etc...) daqueles em que se protege a importância histórico-cultural, adoptando e acrescentando sempre a key protect_class - para os segundos, quase sempre com o valor 22 (activos culturais).


H) COMO PROCEDER À CATEGORIZAÇÂO DAS ZONAS DE PROTECÇÂO ESPECIAL (A IMÓVEL/PATRIMÓNIO EDIFICADO)?

Quando necessário discriminar níveis de protecção diferenciada para um mesmo sítio (eg. "zona de protecção parcial", "zona não edificável", "zona de protecção complementar"...), a documentação OSM sugere que se desenhem múltiplos perimetros (boundaries), aplicando-lhes “site_zone”diferenciadas e articulando-os depois numa relação.

Os detalhes permanecem todavia uma zona algo cinzenta. Mormente seria conveniente definir, face à legislação portuguesa, quais os valores possíveis e como os referenciar (estabelecendo uma equivalência numérica - eg. do maior nível de protecção para o menor?; adoptando uma abreviatura?).