Summary

  • Em 17 de abril de 2009, o OpenStreetMap informou que sua API passara a somente leitura, com possíveis períodos de indisponibilidade total, durante a mudança para 0.6. Não era possível salvar edições, Potlatch saiu do ar e os demais editores precisavam de versões compatíveis.
  • A API 0.6 colocou cada alteração num changeset, passou a conferir versões dos elementos e acrescentou IDs numéricos para edições públicas. Um envio de diferenças podia ser atômico dentro de uma requisição; o changeset inteiro podia abranger várias requisições e não tinha reversão automática pela API.

O voluntário podia apontar um erro no mapa. Naquele fim de semana, não podia salvá-lo. O aviso publicado pelo OpenStreetMap em 17 de abril de 2009 dizia que a API estava em modo somente leitura durante a migração para 0.6, podendo até ficar totalmente indisponível em certos momentos. As alterações não chegariam ao banco de dados e Potlatch, o editor no navegador, foi desligado. A previsão era concluir em algum momento da segunda-feira, dia 20; quem usava outros programas deveria atualizá-los. Era a previsão de uma obra em andamento, não o horário comprovado de volta de cada serviço.

O registro de mudanças da API 0.5 para a 0.6 data a liberação da nova versão em 20 de abril. Ela exigia que toda modificação de nó, via ou relação fosse envolvida num changeset. Um grupo desses podia receber um comentário legível e se estender por várias chamadas à API. Em vez de encontrar apenas objetos alterados, a comunidade passava a ver quais alterações integravam um mesmo trabalho.

O nome do grupo não lhe dava um botão de desfazer. A documentação afirma que um changeset completo não é atômico: ele pode reunir mais de uma requisição e a API não o reverte em bloco. Um envio diferencial numa única requisição pode, sim, ser tratado atomicamente. Uma regra dá contexto à sequência de edições; a outra protege a execução de um lote enviado de uma vez. Para corrigir um erro, a diferença não era acadêmica.

Os números de versão passaram a arbitrar quando duas pessoas mudavam o mesmo trecho. O programa recebia a versão de um objeto e precisava devolvê-la junto com a alteração. Se o servidor já tivesse uma versão posterior, rejeitava a gravação baseada no estado antigo. Cabia ao editor avisar ao usuário que outra pessoa chegara primeiro e que era preciso baixar novamente a área. O mapa ganhava uma forma de recusar sobregravações atrasadas.

A identificação de quem editava também mudou. A API anterior mostrava o nome visível do usuário, que podia ser alterado sem histórico da troca. A versão 0.6 passou a incluir o ID numérico da conta para edições públicas. O próprio documento delimita o alcance: edições antigas feitas anonimamente não ganharam IDs visíveis por causa da migração. O registro futuro ficou mais consistente sem criar autores para lacunas antigas.

A página preservada dos testes de migração mostra a extensão do trabalho fora do servidor. Havia APIs de ensaio para autores de programas; era preciso verificar abertura de changesets, mensagens de conflito, Potlatch, JOSM e ferramentas de replicação. Algumas versões velhas de JOSM simplesmente não funcionariam com 0.6. A troca do centro da rede obrigou cada ferramenta de edição a provar que ainda sabia gravar.

O registro da reunião de 12 de maio da OpenStreetMap Foundation traz a parte pesada da mudança. Um servidor PostgreSQL substituiu o sistema anterior em MySQL. Etapas da migração precisaram ser refeitas, alongando o prazo; restavam correções, monitoramento e trabalho com discos adicionais. O informe posterior explica o atraso, mas não oferece um relógio completo da reabertura de cada via de escrita.

O novo histórico das edições saiu de uma pausa nas próprias edições. Os colaboradores esperaram, os programas tiveram de mudar e o servidor passou a reunir alterações, conferir versões e associar IDs mais estáveis às contas públicas. Desenhar uma rua continuou sendo o trabalho humano; salvar a rua passou a obedecer a outras regras.

Registros originais