OpenStreetMap

Diary Entries in Portuguese

Recent diary entries

Ativar camada Strava de alta resolução + OpenStreetMap (JOSM ou ID)

Posted by erickdeoliveiraleal on 20 October 2020 in Portuguese (Português)

Geração da URL

1-Baixe o plugin para o Chrome nesta URL: https://github.com/janosrusiczki/strava-heatmap-to-osm-background/archive/master.zip 2-Descompacte o plugin em alguma pasta do seu computador. 3-dentro da pasta descompactada do plugin edite o arquivo manifest.json (com bloco de notas), na linha 16 mude de [“heatmapToOSM.js”] para [“background.js”] 4-Abra o Chrome, clique nos 3 pontos e clique em Mais Ferramentas > extensões. 4 -Selecione a pasta descompactada e clique em carregar sem compactação 5 -Acesse o site https://www.strava.com/heatmap e faça o login. 6-após feito o login clique no ícone da extensão, isso copiará o endereço com os parâmetros necessários para vermos a camada em alta resolução. Image 1

Uso no ID:

1-Entre em http://www.openstreetmap.org e clique em editar. 2-Dentro do modo de edição clique no botão de Camadas. 3-Clique em customizado e cole o endereço copiado da extensao do Chrome. Image 2 Como na imagem abaixo No edito ID tem um limite de aproximação infelizmente.

Uso no JOSM:

1-Clique em Camadas > Preferências de Camada Image 3 2-Selecione a camada Strava e clique em ativar. 3-Dê dois cliques sobre a camada do Strava no quadro verde. Image 4 4-Modifique o endereço, colocando 15 no lugar de 11 e de https em diante cole o endereço que você copiou no Chrome. Pronto só utilizar o JOSM normalmente agora. 5-Também ative a camada Locator Overlay layer para você ter uma ideia geral do que está faltando, desalinhado etc. Image 5 Se você não quiser utilizar a extensão do Chrome você pode ver o modo manual neste endereço: https://nuxx.net/blog/2020/05/24/high-resolution-strava-global-heatmap-in-josm/

Toponímia de Lisboa em formato OpenStreetMap

Posted by hvalentim on 3 October 2020 in Portuguese (Português)

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.

Os habitantes do Workshop 2020.1 Unisinos.

Posted by ferkrum on 9 July 2020 in Portuguese (Português)

Os habitantes do Workshop 2020.1 Unisinos.

Location: Boa Vista, Porto Alegre, Região Geográfica Imediata de Porto Alegre, Região Geográfica Intermediária de Porto Alegre, Rio Grande do Sul, Região Sul, Brasil

Mapas para bicicleta

Posted by Peter Kings on 27 March 2020 in Portuguese (Português)

Bom dia Como consigo arranjar mapas top para voltas de bicicleta. Mapa de Portugal.

Obrigado

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)

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

Mapeamento hidrográfico do Ceará

Posted by narceliodesa on 16 February 2020 in Portuguese (Português)

Motivação e Objetivo

Em 2016 eu realizei uma experiência no OSM, o objetivo é realizar o mapeamento básico do município de Jaguaribe-CE ( veja mais sobre esse projeto aqui: https://www.openstreetmap.org/user/narceliodesa/diary/39113 ) . Ao realizar o mapeamento dos rios percebi que praticamente só os grandes rios do Ceará estavam mapeados, e muitos de forma incompleta. Foi ai que resolvi dar um passo além, e em fevereiro de 2018 resolvi trazer para o OSM todo o mapeamento hidrográfico do Ceará.

Sobre a base de Dados

Para o mapeamento Hidrográfico utilizei a Base Hidrográfica Ottocodificada das Bacias Hidrográficas do Atlântico Nordeste Oriental e Base Hidrográfica Ottocodificada da Bacia do Rio Parnaíba produzida pela Agência Nacional de Águas - ANA. As bases pode ser obtida no Geo network da ANA no seguinte endereço http://bit.ly/2nsDa46 e https://metadados.ana.gov.br/geonetwork/srv/pt/main.home?uuid=6f9c7237-1ffd-46db-a095-98cc80c36482

Base Hidrográfica Ottocodificada das Bacias Hidrográficas do Atlântico Nordeste Oriental para importação no OSM Base Hidrográfica Ottocodificada das Bacias Hidrográficas do Atlântico Nordeste Oriental para importação no OSM

Primeira bacia mapeada no OSM Primeira bacia mapeada no OSM

Passados dois anos desde o início desse trabalho velho informar que enfim os dados foram importados para o OSM. A partir de hoje o mapa do Ceará - Brasil no OpenStreetMap conta com mais de 106.842 km de rios mapeados, o suficiente para dar 2,5 voltas ao redor do planeta.

Mapa dos Rios no OSM Atual situação do mapeamento hidrográfico do Ceará no OSM

Passos futuros

Ainda existe muito trabalho a ser feito, como: correções de topologia, intersecções com vias (mapeamento do pontes ou túneis) , Correção de Fluxos, ajustes de posição, dentre outros.

Além, é claro, do mapeamento dos açudes do Ceará. São 155 açudes de grande e médio porte monitorados http://www.hidro.ce.gov.br/reservatorios/volume e mais de 25.000 pequenos reservatórios.

Açudes Monitorados Açudes monitorados, alguns deles ainda não estão mapeados no OSM.

reservatórios Levantamento com mais de 25.000 reservatórios do estado do Ceará.

Criei uma wiki para nortear os trabalhos de qualificação da base, vocês podem acessar aqui: https://wiki.openstreetmap.org/wiki/Brazil/CE/Hidrovias

Location: Centro, Brasil

Corrigindo endereços do portal BHMap, produzido pela Prefeitura de Belo Horizonte

Posted by aoalmeida on 15 February 2020 in Portuguese (Português)

Introdução

A Prefeitura de Belo Horizonte possui um portal de dados georreferenciados aberto ao público, disponível sob a licença ODbL. O portal possui diversos dados que seriam interessantes se fossem importados para o OSM, aumentando a cobertura do mapa na cidade de Belo Horizonte (atualmente apenas 2% dos prédios existentes em BH foram mapeados).

Como parte do meu projeto de importação destes dados, uma camada crucial para aumentar a quantidade de dados disponíveis na cidade é a de endereçamento, onde cada ponto representa um endereço diferente. Acredito que o OpenStreetMap poderá se beneficiar com a importação destes endereços, que, conforme observado acima, estão em falta em BH, devido à ausência de dados mapeados.

O problema

O grande problema deste projeto de importação é que os dados do portal da prefeitura não possuem as etiquetas utilizadas pelo OpenStreetMap, ou seja, se os dados fossem importados do jeito que estão, não haveria informação útil que pudesse ser extraída dos dados recém-importados. Portanto, o processo de importação requer uma intervenção para adequar a camada da prefeitura ao OpenStreetMap. Isso pode ser feito manualmente através do QGIS ou com o uso de scripts.

Para a camada de endereços, resolvi baixar em formato GeoJSON, por ser mais fácil modificar e extrair informações usando um script. A camada, em GeoJSON, possui diversos campos úteis para endereçamento e numeração predial. O objetivo do script é justamente converter estes campos para que possam ser utilizados pelo OSM.

Falando assim, parece até simples, mas o problema é que cada informação do endereço está dividida em diversos campos. Quando vemos o nome de uma rua em uma placa, por exemplo, “Avenida Raja Gabáglia”, automaticamente associamos que o nome da rua é o que está escrito na placa. No entanto, o “nome” que estamos acostumados a ler e ver é composto por duas partes: tipo de logradouro e nome. A camada da prefeitura faz essa distinção, porém o tipo do logradouro está abreviado, então um dos objetivos do script é justamente criar um nome legível-para-humanos com base nas informações do ponto de endereço, para que possa ser utilizado na etiqueta addr:street do OpenStreetMap.

Dados desatualizados

Fazendo uma conferência dos resultados produzidos pelo script, percebi que havia várias ruas com nomes sem pontuação e com as iniciais de cada palavra que compõe o nome da rua em maiúsculas. Descobri que o naoliv já tinha feito um script que corrige o nome de ruas, e resolvi adaptá-lo para o meu uso.

O script adaptado separa cada palavra do endereço, compara com uma tabela, e substitui cada palavra sem acentuação pela palavra com a grafia correta, caso esteja na tabela. Não me lembro muito bem a quantidade certa, mas sei que era um número na casa dos 10 mil, por aí, de endereços únicos, e adicionar a correção para cada palavra seria um trabalho imenso.

Procurando no Google, consegui achar um estudo que classificava os logradouros brasileiros por gênero. Os autores obtiveram acesso a um banco de dados que relaciona CEP com logradouros, separado por cidade e unidade federativa. Pelo que entendi, eles tiveram que formatar os dados para facilitar o seu uso no estudo, e disponibilizaram os dados formatados numa pasta do Google Drive. Resolvi baixar, conferi alguns arquivos e consegui obter um arquivo CSV que possuía a relação de cada logradouro com seu CEP.

Então, resolvi modificar o script, e adicionei uma nova função: a leitura deste arquivo CSV relacionando cada logradouro com um CEP. O script faz a leitura do arquivo CSV, depois a leitura da camada de endereços do BHMap, e faz uma comparação entre eles. Resolvi priorizar os dados da prefeitura, pois estes são mais atualizados (última atualização em 2018, salve engano) que a base do estudo, que foi produzida em 2017.

Basicamente, o script faz uma lista de CEPs, e os logradouros sem CEP são incluídos numa chave contendo todos os endereços do arquivo CSV que não possuem CEP (segue abaixo parte do código que realiza esta função). Depois, ele lê o arquivo GeoJSON da camada da prefeitura, e faz uma comparação com essa lista de CEPs, retirando a acentuação dos nomes. Então, ele faz uma lista em arquivo de texto simples com os nomes de logradouros que diferem entre as duas base de dados. Resta apenas fazer a leitura desta lista e transformar o nome antigo (da base de CEPs) no nome novo (da base da prefeitura), e então os endereços estarão prontos para serem utilizados no projeto de importação. Graças a isso, a quantidade de correções a serem feitas caiu de, entre 10 mil, para, aproximadamente, 600.

Segue abaixo a criação da lista de logradouros com e sem CEP da lista de CEPs; para cada logradouro, um objeto é criado contendo o nome do logradouro e a regional a qual pertence (que será modificada na leitura dos dados do BHMap), e a lista é separada por CEP, ou seja, cada CEP possuirá um objeto contendo as informações do logradouro, e caso o logradouro não possua CEP, ele será incluído dentro da chave SEM_CEP, que nada mais é que uma lista de objetos de logradouros sem CEP associado.

with open(ARQUIVO_LISTA_CEP_ENDERECO, 'r') as f:
    reader = csv.DictReader(f, delimiter='|')
    for row in reader:
        if row['id_cidade'] == ID_CIDADE:
            nome_logra = row['logradouro']
            tipo_logra = row['tipo_logradouro']
            cep = int(row['cep'])

            nome_logra = re.sub('^((Rua)|(Avenida)|(Praça)|(Alameda))', '', nome_logra).strip()
            nome_logra = re.sub('(\s\d.*)', '', nome_logra).strip()
            
            if tipo_logra:
                nome_logra = f'{tipo_logra} {nome_logra}'

                #if nome_logra in trocas_ruas.keys():
                #    nome_logra = trocas_ruas[nome_logra]

                if not cep in logradouros.keys():
                    logradouros[cep] = {'nome': nome_logra, 'regional': 0}

Resolvi escrever um diário porque acredito que este tipo de informação não cabe na página do projeto. Desculpe pela parede de texto, mas busquei explicar todo o meu processo de pensamento por trás do script.

Ah, e caso esteja se perguntando, sim, eu publicarei o script no GitHub ou similar, ainda não consegui achar tempo para terminá-lo, resta apenas a parte de correção dos dados da base de CEPs.

Precisão, limites e constrangimentos

Posted by luisforte on 26 November 2019 in Portuguese (Português)

A base de dados que contém os dados do ecossistema OSM tem várias regras que resultam em constrangimentos, normalmente impostos pela lógica e bom senso ou ainda pelo impacto que pode ter no seu desempenho da base de dados.
A precisão geográfica, por exemplo, é algo que não é suficientemente perturbador para levantar qualquer preocupação a quem mapeia ou a quem consulta o mapa.
As coordenadas geográficas de um node, são registadas no SGBD PostgreSQL utilizando o sistema de referência WGS84.
Dado que esta base de dados (core do OSM) não usa quaisquer tipos de dados geométricos proporcionados pela extensão postgis, os valores de latitude e longitude são guardados em duas colunas de tipo inteiro, após multiplicar aqueles valores por 1E7; O Cristo-Rei (Almada), situado aproximadamente no ponto ( -9.17133, 38.6785918) ficará registado com o valor -91713300 na coluna longitude e 386785918 na coluna latitude.
Esta resolução, com precisão de até 0,0000001 do grau, permite localizar com precisão objectos do tamanho de uma moeda de 2 euros.
Não será um constrangimento para este tipo de aplicação.
Relativamente a conteúdos, existem diversos constrangimentos. Às tag aplicadas a qualquer elemento: quer o nome da tag quer o seu conteúdo não podem ultrapassar os 255 caracteres, cada.
Outro constrangimento, daqueles que praticamente nunca depararemos, é o limite de 50.000 elementos afectados num Changeset.
Um outro constrangimento, este mais conhecido, é o limite de 2.000 nodes por way.

Experiência no SotM 2019

Posted by Betaslb on 21 October 2019 in Portuguese (Português)

Quando pensei em acompanhar 4 jovens portugueses, numa mobilidade Erasmus+, a Heidelberg, com mais um colega professor e participar no State of the Map 2019, considerei que deveris ser interessante, mas que para alguém das áreas das TIC ou da Geografia deveria ser MESMO fantástico. Para mim, alguém das literaturas, seria mais uma etapa de aprendizagem, como todas as que se relacionam com o nosso maravilhoso projeto, EuYoutH OSM. Estava enganada, redondamente enganada… Foi, para quem gosta de aprender, das experiências mais ricas e profícuas que já abracei. em 3 dias de SotM 2019 interagi pessoas oriundas de: Colômbia, Nicarágua, Bolívia, Estados Unidos da América, França, senegal, Burundi, Burkina Faso, Canadá, Alemanha, Espanha, Irlanda, Roménia; Uganda, Japão, Togo, Turquia, Hungria, Tanzânia, Madagáscar, Guiné-Conacri, Croácia, Brasil, Itália, Inglaterra, Escócia, Congo, Índia, Bélgica… Acho que não me esqueci de nenhum… Trocámos ideias, pontos de vista e alargamos a nossa mundividência. Falar do SotM e não falar das conferências, não faria sentido. Se quiserem ler sobre a perspetiva de quem gosta do OSM, mas não é perita em OSM, aui vai: umas conferências foram mais técnicas, outras tão acessíveis, como foi o caso da de Pierzen ou de Manfred Reiter… Em todas entrei uma e saí outra, saí mais rica. A organização foi excelente, tudo a horas, com boas condições técnicas e físicas. Um sucesso! E, de repente, dei por mim, no meio de tanta gente tão diferente, de tantas latitudes e longitudes e a pensar: “eu tenho tanta sorte de fazer parte deste grupo de gente que partilha comigo a ideia fulcral do OSM - o conhecimento é feito por todos e para todos!”. Por último, tenho de acabar esta pequena reflexão, agradecendo ao meu mentor OSM que, em boa hora, nos desafiou a participar no SotM 2019 e a crescer mais um pouco. Obrigada derFred.

Location: Angra do Heroísmo, Angra (N. Senhora da Conceição, Angra do Heroísmo, Terceira, Açores, Portugal

Overpass -Mapas estilizados

Posted by luisforte on 15 October 2019 in Portuguese (Português)

(There is an english draft of this entry on http://saltamocas.blogspot.com/2019/10/overpass-mapcss.html )

Overpass é uma poderosa ferramenta de data minning para o OpenStreetMap. Normalmente utilizada para extrair dados, esta ferramenta também nos permite realizar análises de dados, com o objetivo de verificar a fiabilidade, consistência e validade dos dados. Um exemplo deste uso é descrito na entrada anterior deste diário.
Embora os métodos mais comuns para analisar dados sejam feitos por meio de observação de dados e gráficos, para informações geográficas a componente visual desempenha um papel ainda mais importante; certamente não será fácil identificar o desalinhamento entre um prédio e a estrada próxima, quando pretendemos ter um mapa agradável e harmonioso, apenas olhando nomes e números numa folha de cálculo.
Pela simples observação do mapa, esse desalinhamento é clara e facilmente identificado.

Overpass permite a utilização de uma linguagem simples, semelhante ao CSS, para estilizar os elementos geográficos no mapa, designada MapCSS. Dessa forma, é muito fácil colorir estradas com vermelho e os rios com azul. Ou alterar a largura das estradas de acordo com sua classificação.
O exemplo aqui utilizado, foca-se em elementos de água como rios, ribeiros e canais. Visualizando o mapa com um zoom baixo e, portanto, não muito detalhado, permite-nos ter uma visão geral da área que pretendemos analisar. visão geral Por uma questão de clareza, para salientar os elementos que queremos analisar, a opacidade do mapa foi reduzida para um valor de 0,4 (na opção Configurações> Mapa> Opacidade das Telas). Para reduzir o ruído no mapa, desmarca-se a opção “Mostrar algumas estatísticas sobre dados carregados e exibidos”, bem como é activada a opção “Não mostrar elementos pequenos como os POIs.”, nesse mesmo ecrã de configurações.
Ocultar a aba lateral esquerda do editor de código, clicando o botão “Mostrar mapa largo” por baixo dos botões de zoom, permite visualizar um mapa mais amplo.
Todos os elementos relacionados com água, são representados em azul opaco. Pequenos elementos, como um vau (ford=yes), são representados através de pequenos círculos castanhos. Elementos suspeitos são exibidos em vermelho. A intermitência das linhas é representada com linhas tracejadas.
Os cursos de água menos importantes, como as valas ou canais, são representadas por uma linha pontilhada fina.
Todos esses atributos são definidos com nossos próprios critérios na área MapCSS do script.
Como exemplo, a linha


way[waterway=river]{text:name;opacity:1; color:blue; width:5;}


estiliza rios com uma linha opaca azul com a espessura de 5 pixel. Apresenta ainda o nome (name) do rio.
A espessura da linha pode assim representar a importância da hidrovia. Um rio tem uma representação mais espessa do que um riacho.
Esta metodologia permite identificar visualmente situações suspeitas, como um rio que flui para uma ribeira.
Para que um elemento seja considerado um erro, é necessário definir qual a condição para que a sua representação passe a vermelho. As regras para definir um erro, poderão ser as regras que encontramos no wiki.openstreetmap: um rio deve ser uma linha, portanto, qualquer nó ou área com a tag waterway = river será considerada incorreta.
Dessa forma, definimos em MapCSS, que uma área contendo a tag waterway = river deverá ser representado a vermelho.


area[waterway=river]{text:name;opacity:1; color:red; width:5;}


Assim, podemos observar pelo menos duas situações duvidosas na imagem acima, considerando o alerta vermelho. Ao ampliar o mapa e clicar nos elementos vermelhos, obtemos as informações necessárias para entender e corrigir o problema. O elemento vermelho é um curso de água, waterway = canal, definido numa área. Isso não será adequado, pois um canal só pode ser tag de uma linha.
Nestes casos considerados de erro, os elementos podem ainda não ser renderizados corretamente no mapa. Neste caso específico, o mapa desenha uma linha azul a envolver uma área transparente, que não corresponde ao que pretendemos visualizar, uma área preenchida a azul.

visão geral

Outras situações suspeitas não são representadas em vermelho e só podem ser detectadas por observação.
Intermitências alternativas de um fluxo de água, linhas quebradas ou rios que não desaguam, são situações que merecem a nossa observação e eventual correção:

visão geral

visão geral

visão geral
As relações são apresentadas por uma linha violeta transparente sobre os nós ou as linhas que a constituem. Não deverão ser consideradas situações de erro.

Resumindo, Overpass permite

  • Consultar e extrair informação
  • Criar resumos quantitativos
  • Criar mapas analíticos

A query utilizada neste exemplos pode ser executada em https://overpass-turbo.eu/s/NaE. Está incompleta e poderá conter incorreções.
A query é aplicada na área visível do mapa em ecrã, pelo que grandes áreas poderão implicar maiores quantidades de dados a importar bem como um maior tempo de execução.

A aplicação dos estilos, poderá auxiliar na análise de inúmeras situações distintas; a rede viária ou a integração dos landuse residential, comercial e industrial nas áreas urbanas, são dois de mil exemplos que poderiam ser aqui dados.

Dados geográficos sobre os Açores

Posted by pvt on 2 October 2019 in Portuguese (Português)

Dado o desafio mensal, aqui ficam algumas ligações úteis sobre os Açores:

Nota: uso de servidores WMS com o JOSM

Overpass - Os valores das tags

Posted by luisforte on 28 September 2019 in Portuguese (Português)

Inúmeras vezes deparamos com tags que apresentam valores incorrectos, algo designado como “dirty data” nos sistemas de armazenamento de dados. [building=casa], é um exemplo que todos já terão visto. Alguns destes erros são causados por distração, outros pelo desconhecimento das regras que indicam quais os valores aplicáveis a uma tag.
A identificação de todos estes erros num só passo, é a melhor forma de permitir a sua correcção, ao invés daquela que fazemos ao editar o mapa quando deparamos casualmente com um exemplo isolado.
Overpass QL possibilita a extração desta informação numa qualquer região.
Vamos aqui analisar, como exemplo, a sanidade da tag waterway.
Neste exemplo, a listagem de todos os valores contidos na tag waterway e do respectivo número de ocorrências em Portugal, pode ser obtido com a execução da query https://overpass-turbo.eu/s/MGf .
Os resultados desta query discriminam o somatório por tipo de objecto ( node, way e relation), sendo apresentada a soma destes três valores na coluna total.
Hoje, 28 de Setembro, a execução desta query devolve o seguinte resultado:


waterway	nodes	ways	relations	total
boatyard	13	25	5	43
canal	0	4836	11	4847
dam	42	692	25	759
ditch	0	2091	1	2092
dock	7	34	3	44
drain	1	3890	3	3894
fairway	0	1	0	1
fish_pass	0	1	0	1
fountain	1	0	0	1
fuel	9	0	0	9
harbour	0	1	0	1
lake	0	12	0	12
lock	2	0	0	2
lock_gate	25	4	0	29
pressurised	0	2	0	2
pumping_station	3	1	0	4
reservoir	0	79	1	80
resservoir	0	2	0	2
river	0	2800	116	2916
riverbank	0	875	98	973
sanitary_dump_station	0	1	0	1
screen	2	0	0	2
spillway	0	1	0	1
stream	4	29510	80	29594
turning_point	1	0	0	1
water	0	1	0	1
water control box	1	0	0	1
water_point	1	1	0	2
water_well	1	5	0	6
waterfall	335	17	0	352
weir	238	459	2	699
yes	4	42	0	46


Esta tabela pode ser copiada e colada em Excel/Numbers/Calc ou qualquer outra folha de cálculo, para melhor claridade.
Observando o resultado da query rapidamente identificamos valores aparentemente incorrectos ou imprecisos . Muitas vezes carecem apenas de uma ligeira correção. Outras vezes poderão ser eliminadas as geometrias, caso se trate de objectos inexistentes no terreno.
Um water_well, bem como reservoir, não se enquadram nesta tag. resservoir não se enquadrará em nenhuma tag. O valor yes para esta tag deverá ser requalificado para uma correcta caracterização do elemento. A existência de 4 nodes com o valor de stream nesta tag também é objecto de análise.
Valores, como boatyard, não existem na página da wiki referente a waterway; isso não implica contudo que o valor da tag seja inválido. Em caso de dúvida, procurar o termo na wiki será sempre útil, dado que este valor boatyard existe para esta tag, embora numa página distinta.
Para possibilitar a visualização/edição das geografias que apresentam um dos valores incorrectos apresentados na lista acima, poderá ser aplicada a seguinte query em Overpass QL, neste caso para obter todas as geometrias que contém a tag [waterway=yes]


area[name=Portugal];
nwr["waterway"="yes"](area);
out;
>;
out;


Para analisar os 4 nodes, referidos anteriormente, que contém [waterway=stream], convirá isolar os nodes dos restantes objectos, ways e relations, para permitir a sua fácil visualização no mapa, com a seguinte query:


area[name=Portugal];
node(area)["waterway"="stream"];
out;


semelhante à query anterior, mas onde a palavra nwr é substituída por node, além da redução das duas linhas finais.
Curiosamente todos estes 4 nodes têm esta tag incorrectamente atríbuida, não estado sequer integradas em cursos de água, como se pode verificar no resultado desta query. Eventualmente serão nodes candidatos a serem eliminados.


Considerando a primeira query aqui referida, que devolve as tags existentes e respectivo número de ocorrências:

  • Neste exemplo foram analisados os valores contidos na tag waterway. Para analisar a sanidade de outras tags, todas as (5) ocorrências da palavra waterway deverão ser substituídas pela tag que se pretende analisar, como por exemplo man_made. Executar a query para verificar os valores existentes na tag amenity é certamente mais divertido dada a variedade de valores apresentados, cerca de 300.

  • Uma vez que esta query não devolve quaisquer dados com coordenadas geográficas, o mapa não vai apresentar qualquer informação. Para visualizar os dados deverá ser seleccionada a secção "Data", no canto superior direito.


Não fiz qualquer alteração ou correção aos elementos referidos neste texto, de forma a permitir que ao ser executada qualquer das queries se possam verificar as observações aqui feitas. Se os resultados diferirem será devido a alterações posteriores a esta data.

Encontro de editores OSM no SotM 2019

Posted by Betaslb on 22 September 2019 in Portuguese (Português)

Alguns editores do WeeklyOSM tiveram a possibilidade de se encontrar e conhecer, durante o grandioso evento State of the MAP 2019, em Heidelberg, na Alemanha. Foi muito curioso poder ver o rosto de cada nickname que vemos, semana após semana, a traduzir e a levar ao mundo as notícias da comunidade OSM. Juntos assistimos à palestra de Manfred Reiter, na qual pudemos aperfeiçoar os nossos conhecimentos editoriais de weeklyOSM. Na primeira fotografia, podemos ver derFred (DE-Alemanha), Yoviajo (ES-Bolivia), polyglot (EN-ES-FR Belgica), jcoupey (FR-Francia), pierzen (FR-Canada), SK53 (EN-UK), NunoMASAzevedo (PT-Azores), Betaslb (PT-Azores). Na segunda fotografia, podemos ver Nakaner (DE-Alemanha), Doktorpixel14 (DE), - new member Kleper (ES-Colombia), - SK53 (EN-UK), NunoMASAzevedo (PT-Azores), Betaslb (PT-Azores)., co-funder of weeklyOSM arta_ionescu (EN-Romania), derFred (DE), Jinalfoflia (EN-India), Yoviajo (ES-Bolivia).

SotM 2019

Editores

Mobilidade euYoutH_OSM

Posted by Betaslb on 18 September 2019 in Portuguese (Português)

Quatro alunos e dois professores da Escola Secundária Jerónimo Emiliano de Andrade participam esta semana na Conferência Mundial de OpenStreetMap em Heidelberg, na Alemanha.

O projeto Erasmus+ European Youth Humanitarian OpenStreetMap tem de 18 e 23 de setembro, em Heidelberg, na Alemanha, mais uma mobilidade, na qual os alunos e professores trabalham diversos programas e aplicações informáticas que permitem elaborar mapas no âmbito humanitário. Assim sendo, nos primeiros três dias, 18 a 20 de setembro, os alunos e professores reúnem-se numa ala da Universidade de Heidelberg, onde estão a realizar mapeamento humanitário preventivo de situações de catástrofe, utilizando MapOsMatic, Overpass Turbo e Umap e assistem, participando ativamente num workshop de QGIS, com dois colaboradores das organizações Médicos Sem Fronteiras e Cruz Vermelha Internacional. Fazem, também, tarefas práticas de treino, como por exemplo o mapeamento do Zoo de Heidelberg, utilizando o OpenStreetCam, Mapillary e StreetComplete. Nos últimos três dias, de 21 a 23 de setembro, os alunos e professores terão a oportunidade única de participar numa conferência mundial de OpenStreetMap, denominada SoTM - State of the Map 2019. Esta conferência reúne 800 participantes vindos de todas as partes do mundo. Durante a conferência, diversos temas serão debatidos, tendo como pano de fundo o tema dos dados abertos e como se pode contribuir para que o conhecimento não seja detido por duas ou três gigantes tecnológicas, mas por todos. Para além de assistirem/participarem em workshops e palestras, procederão ao mapeamento de transportes públicos e ciclovias em Heidelberg e participarão num Mapathon (maratona de mapas). Aprenderão a utilizar tecnologias como o OSMC, para construção/manutenção do Semanário OSM, do qual os professores responsáveis por este projeto são editores, isto é, só existe uma versão em língua portuguesa porque os professores Elizabete Oliveira e Nuno Azevedo, semanalmente, traduzem e editam a referida publicação online, levando este projeto e este tema a todo o mundo que fala português. A Escola Secundária Jerónimo Emiliano de Andrade orgulha-se de, mais uma vez, levar os Açores a todo o mundo e todo o mundo aos seus alunos.

DIFICULDADES EM IMPORTAR TREKS PARA O OSM

Posted by Cartixa on 7 August 2019 in Portuguese (Português)

TENHO TIDO DIFICULDADES COM A IMPORTAÇÃO DOS MEUS TRILHOS PARA OSM DAME SEMPRE UM ERRO NA IMPORTAÇÃO

Parece que seu ficheiro GPX 07_08_2019_07_16_07_2019_08_07_07_16_07.gpx com a descrição jsjsjsjbdjx e com as seguintes etiquetas: jziisksnskk falhou na importação. Erro:

0 points parsed ok. Do they all have lat,lng,alt,timestamp? Pode encontrar mais informação sobre erros em importações GPX e como evitar que ocorram novamente em: https://wiki.openstreetmap.org/wiki/GPX_Import_Failures

Pato na Lagoa

Posted by pequiporaqui on 26 July 2019 in Portuguese (Português)

Lagoa da Prata estava precisando de um retoque. Tem estação de tratamento de esgoto e de água. Tem ilha no meio da lagoa pro boto se transformar e esconder. Tem um rancho top, perto do Velho Chico.

Location: Santa Helena, Luciânia, Lagoa da Prata, Microrregião Bom Despacho, Região Geográfica Intermediária de Uberaba, Minas Gerais, Região Sudeste, 35590000, Brasil

cruzamentos

Posted by Cartixa on 18 June 2019 in Portuguese (Português)

a melhor maneira de fazer estes entroncamentos e cruzamentos https://www.openstreetmap.org/edit?gpx=3018902#map=18/39.32868/-9.00256

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

Posted by hvalentim on 12 April 2019 in Portuguese (Português)

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)

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?).