Deixe a sua opinião: o que você mudaria na forma de mapear no OSM?

O objetivo desse tópico é discutir alterações em tags e no jeito de mapear coisas (como ponto, linha ou com relações). Indique coisas que você gostaria de mapear e que não consegue atualmente porque não existem etiquetas (tags) oficiais para isso, ou coisas que você não mapeia ou mapeia com receio porque as tags não são bem adequadas.

Quando se usa um editor como o Potlatch ou iD, as tags nem sempre ficam evidentes pro mapeador. Para ver as tags no Potlatch, clique em “Advanced” no canto esquerdo inferior. Para ver as tags no iD, encontre no painel esquerdo a seção “Todas as etiquetas”.

Seja paciente. Deixe a sua opinião ou o seu pedido, mas saiba que quem desenvolve o OSM raramente está sendo remunerado, e as necessidades são muitas e mudam de uma hora para outra.

Diga o que você pensa sem medo. Se você concordar com o que outra pessoa disse, poste um “+1 @nomedapessoa”. Se ela disse muitas coisas, indique a qual delas você se refere. Vale discordar cordialmente também, desde que seja explicado e de preferência acompanhado de uma sugestão que você considere melhor.

Vou começar com uma: não existe uma tag para escolas de ensino não-regular (como escolas de arte ou cursos preparatórios para concursos), apesar de existir uma tag para escolas de condutores.

Sinto falta de uma forma simples de copiar as tags de um ponto para uma área. Via de regra as ferramentas de repetir dados do último objeto selecionado - quando existem, o que não é o caso do iD - funcionam somente de ponto para ponto ou de linha para linha.

Não conheço esta. Qual seria?
Talvez possamos sugerir um valor school_type=* ou algo assim.

s

É amenity=driving_school. Uma exceção que sempre me pareceu meio estranha.

+1

O que mais sinto falta são imagens de maior resolução no Bing. O que hoje temos é o que tínhamos no Google Maps há 10 anos atrás.

Renderizar vias não pavimentadas de forma diferente!

Deus! Como sinto falta disso.

A camada do mapa “Humanitário” faz isso.

Só pra avisar, isso não é um problema de “mapeamento” (geometria/tags a utilizar) e sim de renderização. Por isso, abri esse outro tópico: http://forum.openstreetmap.org/viewtopic.php?pid=399121

No JOSM com o utils2 plugin installado da para marcar um ponto e uma area e depois unir o ponto (com tags) com a area com CTRL+SHIFT+G

Boa, não conhecia este plugin. Obrigado!

[]s

Lendo por que o OSM não possui a noção de layers, e por que isso é bom, eu comecei a pensar que vegetação não é um aspecto que pertence ao OSM. Se se quer exibir a vegetação no mapa, essa informação deveria vir de outro lugar, da mesma forma que as curvas de nível no estilo OpenCycleMap vêm de uma fonte externa.

De fato, a vegetação é uma informação que ficaria melhor em um layer separado, porque ela raramente conversa com outros elementos do mapa (exceto pelo fato de que deveria colar na orla de corpos d’água), e geralmente não requer anotações tais como nome ou função (se um polígono de vegetação tem uma tag name, isso provavelmente quer dizer que deveria ser um parque, jardim, cemitério, reserva natural, ou coisa do tipo).

De fato, informação sobre vegetação, relevo e talvez hidrografia não é muito bem representada por gráficos vetoriais.

Mas o OSM tem a noção de layers sim, pelo menos para vias (o caso mais comum é para definir a ordem de renderização num entroncamento complicado com pistas sobrepostas). Poderia ter para áreas, é só uma questão do código do estilo no MapCSS considerar essa tag dessa forma. Não sei a fundo, mas o estilo padrão do Mapnik (o OSM-Carto) renderiza todas as áreas com uma ordem específica, talvez “layer” só tenha efeito entre áreas de mesmo tipo ou num mesmo “grupo” de áreas relacionadas, daria pra se testar.

Tem pelo menos 2 casos em que a vegetação conversa com um usuário comum: quando ela não existe (por exemplo, numa praia, ou num deserto), e quando ela atua como barreira (impedindo ou dificultando a circulação de pedestres ou de veículos). Nos demais casos, ela pode conversar também como “informação adicional” ou como “atração” (se for dentro de um jardim como o jardim botânico, por exemplo).

Fui verificar os detalhes sobre a ordem do rendering e preciso corrigir algumas coisas que eu disse.

Primeiro, o mapa no site é renderizado pelo TileMill, que usa o Mapnik por baixo dos panos. O funcionamento no TileMill é programando usando CartoCSS, e a ordem de renderização é a ordem dos layers neste arquivo (só cuidado que isso não tem relação a tag layer no mapa). Layers consecutivos são desenhados uns sobre os outros, então o último layer é o que vai aparecer por cima do resto. Os layers que interessam aos mapeadores são aqueles que têm associado a eles um “datasource” com um “table” com um “select”, é esse select que diz quais tags são renderizadas no layer e em que ordem (somente nesse layer).

Alguns desses elementos são ordenados pelo atributo “z_order” que é calculado no momento da importação para a base de dados pelo osm2pgsql. É um atributo obscuro, só achei um comentário antigo que diz que o cálculo considera as tags layer, highway, bridge, tunnel e railway e que é feito aqui (mas não achei o código, podem ter mudado de lugar). Se as tags consideradas ainda forem as mesmas, então a tag layer deve afetar tanto vias quanto as áreas que forem ordenadas pelo “z_order”.

Outros elementos (especialmente áreas) são ordenados também pelo atributo “way_area” (a área total do polígono), também calculado pelo osm2pgsql durante a importação. O resultado é desenhar primeiro as áreas maiores e depois as menores.

As áreas de vegetação são selecionadas no layer “landcover” e são ordenadas pelo “z_order” (que imagino que seja zero para todas elas, exceto para as que têm a tag layer) e depois pelo “way_area”. Então, na verdade, tudo que diz respeito a vegetação, parques, praças, etc. provavelmente é desenhado primeiro pela ordem estabelecida pela tag layer e, pra cada grupo com o mesmo nível em “layer”, primeiro as áreas maiores, depois, por cima, as menores. O layer “landcover” é um dos primeiros, então várias coisas ainda são desenhadas por cima desse layer, mesmo depois de toda essa ordenação interna.

Poderia haver wizards com imagens para a configuração de vias.

Eu acho que deveria ser possível adicionar uma ponte sem ter que dividir o caminho. Desta forma, quando você muda a classificação da via, a ponte fica diferente.
O mesmo acontece com os acessos. Você muda a classificação da via e sobra aquele monte de pontos de retorno em cor diferente. :stuck_out_tongue:

Abraços, Linhares

+1

Acho que os editores poderiam ter essa funcionalidade. O JOSM, por exemplo, poderia identificar esses casos e perguntar se você deseja propagar a alteração (mais ou menos como ele faz quando se quebra uma via que é parte de uma relação, ou quando se combina duas vias e você tem que decidir quais tags vão no caminho combinado).

Mais, o JOSM poderia ter um validador que encontra vias cuja classificação muda em trechos curtos. Talvez seja até mais fácil seguir por esse caminho (porque os validadores do JOSM são modulares, podemos nós mesmos desenvolver um sem mexer no resto do programa).