O meu desconhecimento de uma ferramenta que dê uma vista histórica dos objectos em OSM numa determinada área, aliada à utilidade que vejo numa ferramenta deste tipo, levou-me a procurar criar algo que preenchesse essa curiosidade.
Apesar de ser uma solução simples, a parte conceptual, mais complicada que a técnica, visa apresentar no ecrã a informação de uma forma clara e elucidativa que dê uma ideia correcta da evolução dos objectos (de momento só nodes) ao longo do tempo numa área seleccionada:
Após seleção da área pretendida, é apresentada por ordem cronológica, uma lista com todos os objectos que ao longo da sua vida tiveram pelo menos uma tag válida. Tags como created_by ou source isoladas, não fazem um node autónomo. São considerados nodes autónomos além dos habituais amenity, shop, etc, aqueles que têm uma ou mais tags mesmo que integradas numa way (highway=stop, por exemplo). Seleccionando um destes elementos permite a visualização do histórico de versões desse objecto. Este histórico permite ver o tipo de evolução desse objecto: criação, alteração de tags ou de geometria, eliminação ou recuperação (undelete).
Clicando numa qulqauer versão, poderá ser validada no mapa as suas alterações de posição.
Clicando na opção de actualizar a lista de utilizadores, é preenchida a lista de utilizadores da área seleccionada, o que permite seleccionar as edições de um só utilizador nessa área.
Após selecionar o utilizador será necessário executar uma nova query, para apresentar os dados actualizados.
Quando não é selecionado um utilizador, é apresentada uma ocorrência por cada node da área; optando pela visualização filtrada por utilizador, serão listadas todas as intervenções do utilizador, podendo por isso repetir-se o node na lista, caso o utilizador tenha alterado esse node mais que uma vez. Parece-me ser esta a melhor abordagem.

(http://85.240.54.201/osh/)
Dados actualizados a 15 de Janeiro. Adequado para uso em desktop. Só contém dados de Portugal, continente e ilhas.

O código postal foi criado nos finais do século XIX, com o objectivo de facilitar a distribuição de objectos postais.
Chegou a Portugal no final dos anos 70 do século passado.
Em OSM, é registado habitualmente com recurso às seguintes tags:

• addr:postcode, para indicar o código postal de edifícios e partes deste, bem como de pontos de interesse (POI), normalmente complementado com as restantes tags addr:*
• postal_code, para vias (highway=*) e algumas áreas quando estas partilham o código em toda a sua extensão.

Mas qual a utilidade do código postal num mapa?
Nenhuma.
No dia a dia, só utilizamos o código postal quando preenchemos um formulário num site de vendas, onde inserimos o nosso código postal para assegurar um envio expedito de uma encomenda.
Ou quando enviamos uma carta; neste caso o código postal foi-nos disponibilizado pelo destinatário, tal como a rua e o número de porta. E se algum destes elementos, rua, número de porta , código postal ou localidade, é considerado essencial, esse não será certamente o código postal.
Algumas empresas dão-lhe uso. Empresas de estudos de mercado utilizam o código postal, que é supostamente a melhor forma de retalhar uma localidade em zonas. Contudo esta é uma forma errada, e reconhecida como tal, de dividir uma localidade em regiões:

• Um código postal raramente circunscreve uma região uniforme e bem delimitada, embora existam aproximações a este conceito nalguns países que não Portugal.
• Não existe forma de associar um código postal a qualquer tipo de actividade humana ou segmentação de mercado.

E qual a utilidade do código postal para efectuar buscas com um qualquer motor de busca?
Totalmente desinteressante.
Quando procuramos algo, procuramos pelo nome, pela cidade e pela rua, por vezes incluíndo o número de policia.
Mas, procure-se “7000-899, Évora” em nominatim, onde se pretende aqui saber a zona abrangida por este código postal.
O mapa é supostamente centrado numa zona ampla, sem discriminar concretamente a zona abrangida por esse código postal.
O código postal 700-899, abrange unicamente uma pequena rua com menos de 100 metros de extensão (Rua da Freiria de Cima), mas tal nem sequer é perceptível ao avaliar o resultado da busca (Na verdade o nominatim ignora o 7000-899).
Ou faça-se a mesma busca num motor de busca mais avançado que nominatim, pelias . O resultado é completamente inútil.

Posso ou devo usar o código postal para análise geoespacial?
Nunca. Não tem qualquer utilidade prática.
Mesmo com dados plenos, estes não têm consistência ou objectividade.

O código postal (postal_code/addr:postcode), em Portugal, deve conter somente o código numérico ou deve conter ainda a designação postal?
Dentro de uma grande cidade não levanta quaisquer dúvidas; o código 1000-123 em Lisboa, resulta no texto 1000-123 LISBOA na ultima linha do endereço de um pacote postal.
Mas se formos para zonas rurais as coisas ficam diferentes: Penilhos (aldeia do concelho de Mértola), tem o código postal 7750-510, mas a sua designação postal é SÃO JOÃO DOS CALDEIREIROS. Este exemplo não é uma excepção, mas a regra nas zonas rurais.
Em OSM as tags de código postal tem, tradicionalmente, apenas o código numérico, pelo que este ultimo problema não tem solução, de momento.

Vale a pena colocar o código postal em OSM?
A informação nunca é demais em OSM. Eu, pessoalmente, actualizo códigos postais em OSM.
O código postal, complementado com a restante morada, num POI permite obter o endereço completo desse POI
(Embora quando se considere o endereço postal, o endereço em OSM só é válido assumindo que addr:postcode está complementado com addr:city, e que este city coincide com a designação postal, o que muitas vezes não sucede).
Se abusarmos na actualização do código postal, damos credibilidade a esta fonte, e esta é a forma de promover o OSM.
Os motores de busca estão permanentemente sujeitos a melhoramentos; na verdade, se fizermos a busca por “Rua da Freiria de Cima, 7000-899, Évora”, o mapa já devolve a localização com mais precisão.

Tudo isto, para insistir no que afirmo no primeiro parágrafo:
Não aplicar qualquer uma das tags addr:* a uma highway, mas a tag postal_code
Em POIs ou edifícios, não utilizar a tag postal_code mas o conjunto de tags addr:*.

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.

(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. 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.

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:

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.

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.

Levantamento e registo em OSM dos prédios rústicos do sudoeste do distrito de Évora e do noroeste do distrito de Beja. Não pretendendo ser um registo exaustivo, para tal existem as entidades oficiais, tem como objectivo permitir uma referenciação geográfica genérica fora das localidades. Os montes, mesmo que em ruínas (building:ruins), são assinalados , sendo que as herdades e hortas ficam assinaladas de modo menos preciso, não sendo sequer utilizado o centroide das mesmas, o que implica que estas propriedades não ficam delineadas nem ficando assim registada a identificação dos seus limites (São identificadas com um ou mais pontos, com a tag place:farm ou landuse:farmyard)

Acrescentar toponimia, fazer correções e ajustes a permissões de trânsito, sentidos, faixas e inserção de semáforos. Objectivo, obter um roteamento rodoviário correcto em Alvito, Torrão, Évora, Vila Nova da Baronia, Odivelas, Oriola, São Bartolomeu do Outeiro, Alcaçovas, Vila Ruiva, Alfundão, Peroguarda, Trigaches, Viana do Alentejo, São Manços, São Brissos, Vila de Frades, Alcaria da Serra, Vera Cruz, Portel, Selmes, Valverde, Aguiar, Brinches, Vila Verde de Ficalho, Ervidel, Vila Nova de São Bento, Vale de Vargo, Pias, Santa Iria, São João de Negrilhos, São Matias e Vidigueira. Validação e testes com OSRM