… See full entry

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.

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.

… See full entry

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

… See full entry

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