Renderização de parques nacionais/reservas naturais

O estilo Mapnik padrão mudou a forma como áreas do tipo leisure=nature_reserve são renderizadas. Exemplo: http://www.openstreetmap.org/way/70874158. Eu procurei mas não encontei uma explicação “oficial” de o que exatamente foi feito, e por quê. Alguém viu alguma discussão sobre o assunto?

Note que aquele hachurado com a sigla NR não aparece mais, e parece que uma área etiquetada apenas com leisure=nature_reserve, sem boundary=national_park, é renderizada exatamente como os “boundary=national_park” era renderiazados no passado; em particular, elas aparecem em níveis baixos de zoom de 7 a 12. Em geral, parece uma boa mudança, exceto pelo fato de que áreas menores ficam um pouco discretas de mais (para o meu gosto).

Em vista dessas mudanças, podemos repensar o uso da tag boundary=national_park, a qual está sendo usada, basicamente, para fins de controle da renderização (cf. http://wiki.osm.org/wiki/WikiProject_Brazil/Unidades_de_conserva%C3%A7%C3%A3o). A idéia seria remover totalmente o uso da tag boundary=national_park no Brasil, substituindo-a por boundary=protected_area (que é semanticamente mais correta mas continua não sendo renderizada), e manter a tag leisure=nature_reserve nos casos em que a área deve ser renderizada (não fica bem, em geral, exibir UCs do tipo áreas de preservação ambiental em geral no mapa: imagine Brasília inteira dentro de um polígono verde: http://www.openstreetmap.org/relation/3426617). Para terras indígenas (cf. http://wiki.osm.org/wiki/WikiProject_Brazil/Terras_ind%C3%ADgenas), a idéia seria etiquetá-las com boundary=protected_area + leisure=nature_reserve. TIs não são “reservas naturais”, e muito menos áreas de lazer, mas, como já discutimos no passado, nenhum renderizador “mainstream” mostraria essas áreas sem um pouco de intervenção direta – a vantagem é que agora isso pode ser feito com uma única tag, leisure=nature_reserve. [A propósito, ninguém se anima a importar um dos arquivos da Funai? É uma coisa interessante de se fazer uma vez ou duas, e em particular você vê com os próprios olhos a dimensão do desmatamento na Amazônia. Por outro lado, importar todos os 16 arquivos sozinho não é muito animador…]

Enfim, as mudanças de etiquetagem acima parecem razoáveis para todo mundo, ou seriam prematuras? Eu creio que funcionariam direitinho com o estilo Humanitarian também; alguém saberia confirmar?

Vamos importar…
Ps.: agora(depois de começar a importar) eu entendi o por que você disse

Outra coisa, porque os usuários costumam creio usuários específicos para importar esses dados?

A semântica de “boundary” é a de fronteira: uma linha que divide áreas com mudanças marcantes de jurisdição (ou seja, de poder político). Então, se houver alguma categoria de área protegida com muitas restrições de acesso/uso/exploração ou que esteja sob a adminitração de uma organização autônoma (e provavelmente independente da administração pública regional que controla os impostos, o registro das propriedades particulares e o planejamento dos sistemas viários), provavelmente seria bem adequada à definição de “national park” do OSM.

De qualquer forma, como a distinção não é clara no OSM, talvez genericamente faça mais sentido:

  • sempre aplicar leisure=nature_reserve ao principal objeto que representa a UC (tanto faz se esse objeto é uma relação com múltiplos membros ou se é uma área simples que não participa de relações)
  • se a UC for grande/complexa o bastante a ponto de justificar o uso de relações, aplicar boundary=national_park à relação (que é type=boundary) e também aos seus membros (tal como se aplica boundary=administrative aos membros das relações type=boundary+boundary=administrative)

Isso tudo com exceção das áreas de proteção ambiental, que conforme você mencionou são um caso à parte. Mas eu não vejo problema em colocar Brasília dentro de um polígono verde se o significado desse polígono estiver coerente com a definição no OSM (ou melhor, com o significado que adotarmos no Brasil para as tags internacionais).

A principal razão para aplicar boundary=* às linhas que são membros de relações de limite é auxiliar os renderizadores mais simples que não suportam relações. Mapear assim (leisure sempre, + national_park em relações e seus membros) também se aproximaria automaticamente da descrição no wiki em ambos os artigos (sobre nature reserve e national park), que diz: “The distinction is unclear and is under discussion, but some suggestions are: nature reserves are smaller areas than national parks. National parks are rather like administrative boundaries around large areas whereas nature reserves are more evident on-the-ground.”

Você acha que as áreas protegidas deveriam ser renderizadas mesmo quando não são uma reserva natural? Talvez seja o caso de abrir uma issue no repositório do OSM-Carto (estilo visual do site, que usa o Mapnik por baixo dos panos) e sugerir um estilo (cor, preenchimento, borda, etc., se possível comparando com outros sistemas/mapas famosos em papel). E talvez você possa solicitar também que as reservas menores fiquem mais evidentes.

Um desenvolvedor do OSM-Carto que eu vejo participando muito e bem disposto a implementar as alterações (ainda que não imediatamente) é o Matthijs. Eu me comuniquei bastante com ele através desta issue e da longa discussão sobre ela na lista tagging@ .

Alguns motivos (mas provavelmente há outros):

  • Se algo der errado na importação, é fácil descobrir quais são os changesets para reverter.
  • Um usuário à parte também facilita uma reversão no caso de se descobrir futuramente que a fonte de dados estava sob uma licença restritiva (mas o certo é verificar isso antes mesmo de começar a importar os dados).
  • Se alguém está importando dados sem criar um usuário a parte, provavelmente não leu as orientações de importação e alguém precisa chamar a sua atenção.
  • Alguém que estiver revisando alterações no mapa pode saber, ao consultar o histórico dos elementos, que a informação veio de alguma fonte oficial, ao invés de ter sido simplesmente mapeada (ou até deduzida) por alguém mapeando sobre uma imagem de satélite. Isso permite a pessoa saber mais sobre a confiabilidade da informação (há fontes pouco confiáveis e há situações em que somente uma fonte oficial é capaz de fornecer uma informação confiável, que não está marcada “no chão”, na imagem de satélite).

O ponto que eu queria discutir não é a utilização ou não de tag boundary=* (atualmente todas as UCs no Brasil vão com boundary=national_park), e sim sobre fazer a transição da tag boundary=national_park para a mais recente, e abrangente, boundary=protected_area. A única desvantagem dessa última, ao meu ver, é que os renderizadores a ignoram. Mas, como agora a tag leisure=nature_reserve é suficiente para renderizar corretamente as UCs gigantescas que temos no Brasil, eu estou propondo fazer uma transição definitiva para o novo sistema baseado na boundary=protected_area. Outas informações, como propriedade da terra e permissões de acesso podem ser deduzida das subetiquetas complementares.

Essas distinções são mais bem expressas pelas etiquetas protect_class=* e afins (que já estamos usando). Com a modificação https://github.com/gravitystorm/openstreetmap-carto/commit/c505f51a930fe00977af8ae7fc2d58a36a659ff1, deixa de haver diferença no tratamente entre national_park e nature_reserve no renderizador, o que sugere que esta distinção sutil (e de utilidade questionável) está em processo de obsolecência.

Bem, considerando tudo issso, eu concordo com a transição.

Segue para avaliação da comunidade um changeset de importação de dados que será realizada do Projeto Terras Indígenas http://wiki.osm.org/wiki/WikiProject_Brazil/Terras_ind%C3%ADgenas
Link https://www.dropbox.com/s/pjvpgxkshvsolsb/funai-amazonas-1.osm.gz
É preciso estabelecer um prazo para revisão?

Importações são assuntos importantes e devem ser tratados na lista talk-br. Pouca gente acompanha o fórum, e os mais antigos/experientes estão todos na lista. Além disso, este tópico não é sobre a sua importação e sim sobre a relação entre as tags usadas e a renderização.