Documentando o que descobri depois de uma discussão que se iniciou no Telegram do RS.
As seguintes coisas funcionam hoje com o nosso principal geocoder, o Nominatim:
Código postal para elementos específicos
Onde não há outras alternativas, o Nominatim tem atribuído o código postal pela proximidade de elementos com addr:postcode. Então se você mapear um café com addr:postcode e do lado mapear um banco sem addr:postcode, ele atribuirá o CEP do banco automaticamente por estar próximo do café, que é um ponto com CEP conhecido. Quase sempre isso funciona bem.
addr:postcode também tem precedência sobre as abordagens a seguir, então pode ser usado para mapear CEPs excepcionais (ex.: agências dos Correios costumam ter CEP diferente do lugar onde se encontram).
Quando levantei essa questão na lista tagging, algumas respostas sugeriram sim usar addr:postcode em tudo, mesmo que isso replique o dado. Daria bastante trabalho fazer manutenção nisso.
Uma possível ideia seria não atribuir os CEPs aos pontos de interesse (amenity=, leisure=, etc.) e sim aos endereços, caso as duas coisas sejam desacopladas (ex.: onde se estiver mapeando com interpoladores ou seguindo a filosofia de um elemento diferente para cada coisa).
Mesmo código postal para uma localidade inteira
Uma “localidade” para os Correios tipicamente é um município ou um distrito, mas talvez inclua outras áreas.
A relação boundary=postal_code nos permite fazer isso sem precisar adicionar addr:postcode a cada elemento da área.
A grande maioria dos municípios brasileiros têm população pequena e apenas um código postal para todo o município. Nesse caso, basta criar uma relação com as etiquetas:
-
type=boundary
-
boundary=postal_code
-
postal_code=[CEP do município]
-
(opcional) postal_code_level=8
-
(opcional) note=[CEP do município] [nome do município]
Se eventualmente algum elemento ainda tiver CEP próprio, basta adicionar addr:postcode ao elemento. Testei isso em Mariana Pimentel com um caso típico e um caso atípico.
O único inconveniente é que isso essencialmente duplica as relações dos municípios e as duas coisas podem perder sincronia com o tempo. Mas quem mantém as relações de municípios geralmente usa o JOSM, que torna isso bem evidente, então acho que o risco de acidentes é pequeno.
Tudo isso também vale para distritos ou outras localidades conforme a definição dos Correios.
Código postal igual dos dois lados da rua
postal_code em trechos da rua nos permite fazer isso sem precisar adicionar addr:postcode a cada elemento da rua.
Isso é comum nos municípios maiores. Em algumas ruas, o código pode inclusive mudar por trecho. Nesse caso, é necessário quebrar a rua no trecho e atribuir um código diferente para cada um. Testei isso na avenida Bahia em Porto Alegre, que tem três trechos com códigos postais diferentes. Um exemplo em cada trecho: primeiro trecho, segundo trecho, terceiro trecho.
Como o geocoder tenta atribuir pela distância do elemento à rua, às vezes o cálculo dá errado, o que é mais comum nas esquinas. Nesses casos, ainda seria possível adicionar addr:postcode ao elemento para forçar a atribuição correta do CEP.
Código postal diferente em cada lado da rua
O que mais se aproxima disso seriam as etiquetas tiger:zip_left e tiger:zip_right em trechos da rua. Mas temos dois problemas.
Primeiro, não funciona direito. Testei isso na avenida Pátria em Porto Alegre. Depois de atribuir as etiquetas às vias, adicionei um ponto de interesse no lado esquerdo, cujo CEP foi corretamente atribuído pelo lado. Então, adicionei outro do lado direito, e ao invés de atribuir conforme o lado, o Nominatim atribuiu pela proximidade com o elemento mais próximo com CEP (o elemento que eu adicionei anteriormente). Resultado: ambos acabaram com o CEP de um único lado da rua.
Segundo, essas etiquetas foram definidas para a importação TIGER nos Estados Unidos, e portanto não se generalizam para o resto do mundo. Nota-se que muitas vias lá têm o mesmo CEP dos dois lados da via, o que pode significar que o problema anterior passou despercebido pelos desenvolvedores do Nominatim.
Conforme o TagInfo, zip_left e zip_right são relativamente bem usadas também, muito mais do que postal_code:left, postal_code:right, postal_code:side:odd e postal_code:side:even, mas nenhuma destas é atualmente suportada.
Uma alternativa seria realmente mapear as áreas dos códigos postais. Dessa forma o resultado é exato mas dá bastante trabalho, embora bem menos do que adicionar o CEP pra cada elemento. A Wikipedia cita que esse desenho é a interpretação correta, mas acho que deveríamos discutir se é mesmo.
Sugestão: refinamento progressivo
Em todos os municípios com CEP único, já podemos criar as relações boundary=postal_code e remover postal_code das vias e addr:postcode dos elementos (contanto que sejam iguais aos do município). Isso por si só cobre a maior parte da área do país. Como citado pelo @santamarisene, há várias outras localidades (partes de municípios) onde isso também poderia ser feito.
Nos demais lugares, postal_code pode ser atribuído às vias num primeiro momento. Onde for diferente de cada lado, usa-se addr:postcode nos elementos e/ou nos endereços. Num segundo momento, o postal_code das vias e o addr:postcode dos elementos podem ser convertidos em relações boundary=postal_code para garantir a exatidão da informação. Naturalmente, se alguém quiser já pode ir mapeando da forma final.
Nota: a introdução/alteração de postal_code no código postal leva dias para se refletir no Nominatim (não consegui descobrir bem quantos). Então, um ponto de interesse que você adicionou, ao qual ele atribuiu um código postal, digamos, pela proximidade com outro elemento, pode levar dias para ter o seu código postal atualizado. Curiosamente, isso não acontece com boundary=postal_code, cujas alterações se refletem quase imediatamente. Isso meio que sugere que a relação boundary=postal_code é o mapeamento mais desejável em todas as situações.