Dúvida sobre stop_position em terminais

Communities Brasil (Brazil)
1

Oi, pessoal!

Estou lentamente atualizando os pontos de ônibus de Florianópolis para o padrão PTv2 (Proposal:Public Transport - OpenStreetMap Wiki). Posteriormente, também quero atualizar as linhas de ônibus. Estou documentando o processo aqui: Pt:Florianópolis/Linhas de ônibus de Florianópolis - OpenStreetMap Wiki.

Tenho duas dúvidas sobre as quais gostaria de ouvir a opinião de vocês.

1. Mapeamento das stop_position em terminais

A stop_position marca o local onde o veículo para na via (é um Node na Way). Nos terminais, há diversos locais de parada, geralmente identificados por uma letra ou número (Box 1, Box 2 etc.). Em geral, uma linha de ônibus termina e inicia sua viagem na mesma localização, mas isso pode variar conforme as condições operacionais. Pensei em duas formas de mapear as stop_position nas estações:

A. Mapear todas as stop_position

Vantagens:

  • Maior precisão sobre o local onde cada linha para na estação.

Desvantagens:

  • Maior trabalho para manter atualizado.
  • Como as linhas iniciam e terminam na estação, é necessário quebrar a Way em várias partes.

B. Mapear somente uma stop_position por plataforma

Vantagens:

  • Elimina a necessidade de atualizar o local de parada de cada linha individualmente.
  • Não é necessário quebrar a Way em diversos pontos.

Desvantagens:

  • Não informa o local exato onde cada linha para.

Fiz uma imagem ilustrando as duas opções:

image
image955×657 13.3 KB

Estou tendendo a utilizar a opção B, mas queria ouvir a opinião de vocês também.

2. Tag para infraestrutura inexistente

Existem locais onde há infraestrutura (abrigo, placa etc.) somente em um lado da via. Porém, o ônibus também para para embarque e desembarque na outra direção, mesmo sem haver qualquer indicativo físico no local.

Pesquisei um pouco sobre como mapear essa situação e vi que duas tags já foram utilizadas em Florianópolis:

Quero padronizar e utilizar somente uma delas. Na opinião de vocês, qual das duas devo utilizar? Estou tendendo a utilizar physically_present=no, pois é mais utilizado em combinação com public_transport e acho mais fácil de entender.

physically_present | Chaves | OpenStreetMap Taginfo

Valeu, pessoal! :blush:

Anderson

2

Coincidentemente, atualizei ontem as 92 linhas de micro-ônibus de PoA para PTv2 e escolhi exatamente a opção B (exemplo). Eu poderia ter escolhido a opção A (é como vejo sendo feito em alguns lugares fora do Brasil), mas, para evitar os alertas dos validadores (JOSM, OSM Inspector, Osmose), seria necessário quebrar a linha (way) ao redor de cada posição de parada e incluir separadamente os pequenos segmentos nas relações de rota.

Eu escolheria a opção A se ficar claro que essa precisão faz alguma diferença para alguma aplicação específica ou se a plataforma for realmente muito longa. Também levaria em conta o trabalho adicional de manutenção: as linhas podem mudar de posição dentro da plataforma, passar para outra plataforma do mesmo terminal ou até mudar de terminal. Nesse sentido, acho a opção B um bom compromisso entre precisão e facilidade de manutenção.

Eu não usaria essas etiquetas. Elas são pouco usadas e não são citadas na documentação de highway=bus_stop nem nos demais artigos sobre transporte público e ônibus no wiki; aparecem apenas nesta discussão, onde são tratadas superficialmente.

Por isso, eu tenderia a mapear a ausência de infraestrutura combinando etiquetas amplamente usadas: name:signed=no[1] + ref:signed=no + pole=no + departures_board=no + shelter=no + bench=no etc.

  1. Não confundir com noname=*. ↩︎

1 Like
3

Eu escolheria a opção A , muito mais precisa e correta , manutenção sempre vai ter mas não acho que o órgão vai sempre estar mudando a toa o local de parada,a não ser transferir para outro corredor qdo houver mais de 1 qdo a medida se fizer necessária.

4

Uma outra possibilidade é criar uma relação public_transport=stop_area incluindo as múltiplas plataformas e pontos de um terminal, mesmo que seja um terminal linear na rua. Dessa forma, basta incluir a plataforma na relação de rota, não precisa incluir o ponto stop_position nem quebrar a linha da via em múltiplos pequenos segmentos. É como foi feito, por exemplo, aqui.

Nos exemplos de rotas-mestre, há uma relação stop_area para cada par de paradas de ônibus (uma para cada sentido), mas ainda assim tanto a plataforma quanto o ponto de parada estão incluídos nas rotas. Ao migrar pro PTv2 em PoA, eu vou criar as relações stop_area no passo seguinte. É bastante trabalhoso e não é necessário para tratar dos alertas do validadores nem para fazer as aplicações funcionarem.

5

Oi pessoal, muito obrigado pelas respostas.

@ftrebien Eu poderia ter escolhido a opção A (é como vejo sendo feito em alguns lugares fora do Brasil), mas, para evitar os alertas dos validadores (JOSM, OSM Inspector, Osmose), seria necessário quebrar a linha (way) ao redor de cada posição de parada e incluir separadamente os pequenos segmentos nas relações de rota.

Exato. Esse também é um dos problemas que quero evitar agora.

@mapafeito Eu escolheria a opção A , muito mais precisa e correta , manutenção sempre vai ter mas não acho que o órgão vai sempre estar mudando a toa o local de parada,a não ser transferir para outro corredor qdo houver mais de 1 qdo a medida se fizer necessária.

Entendo seu ponto. A opção A é mais precisa e detalhada, mas não vejo um grande benefício em fazer isso neste primeiro momento. Estou pensando em priorizar a atualização/mapeamento dos demais pontos e rotas da rede, que está bem desatualizada.

Posteriormente, posso voltar e mapear as estações com mais detalhes. Dessa forma, também consigo dividir um pouco o trabalho. Estou tendendo a utilizar a opção B, mas a opção A não será totalmente descartada.

@ftrebien Eu não usaria essas etiquetas. Elas são pouco usadas e não são citadas na documentação de highway=bus_stop nem nos demais artigos sobre transporte público e ônibus no wiki; aparecem apenas nesta discussão, onde são tratadas superficialmente.

Por isso, eu tenderia a mapear a ausência de infraestrutura combinando etiquetas amplamente usadas: name:signed=no + ref:signed=no + pole=no + departures_board=no + shelter=no + bench=no etc.

Muito boa dica! Não tinha pensado em utilizar as tags já existentes e indicar nelas a inexistência física dos elementos. Isso elimina completamente a necessidade de utilizar as novas tags que mencionei.

Vou esperar mais alguns dias para ver se mais alguém se manifesta. Mas já tive bons frutos por aqui com as respostas de vocês.

Abraços

1 Like
6

A relação stop_area serve para indicar que os elementos platform e stop_position fazem parte de um mesmo ponto de parada. Ela é utilizada para agrupar esses elementos.

Não é necessário ter uma stop_area para cada ponto de ônibus. Se dois ou mais pontos de ônibus forem próximos, é possível modelá-los utilizando uma única stop_area, contendo todos os elementos relacionados (por exemplo, duas ou mais platform e dois ou mais stop_points…). Por isso, na relação das rotas, deve-se sempre indicar especificamente qual é o stop_point e qual é a platform utilizada.

O conceito de stop_area é bastante útil para agrupar locais de transbordo. Em softwares de simulação de demanda de transportes (ex. VISUM), existe a possibilidade de importar a rede de transporte público e seus pontos de parada do OSM. Nesse contexto, pode-se utilizar a stop_area para indicar para o modelo que, dentro daquele grupo de plataformas, existe a possibilidade de realizar transbordos entre diferentes linhas.

7

Esta é a opção mais regular e segura, é que a procurei fazer ao atualizar as rotas aqui, e é a que sempre dá certo em diferentes aplicações. Ainda assim, o wiki dá a entender que apenas o membro platform é necessário:

The next step is to add each bus stop to the bus route relation in the correct order with the role “platform”. If both public_transport=platform and public_transport=stop_position as a connected relation were used for a bus stop, just add the platform node to the relation.

Minha tradução livre:

O próximo passo é adicionar cada ponto de ônibus à relação da rota de ônibus na ordem correta, com o papel “platform”. Se tanto public_transport=platform quanto public_transport=stop_position como uma relação conectada tiverem sido utilizados para um ponto de ônibus, adicione apenas o ponto da plataforma à relação.

E o validador OSM Inspector reforça essa interpretação:

This layer shows nodes tagged with public_transport=stop_position. The Public Transport version 2 schema does not require you to map them.

Minha tradução livre:

Esta camada mostra pontos marcados com public_transport=stop_position. O esquema de Transporte Público versão 2 (PTv2) não exige que você os mapeie.

Sim, são opcionais, mesmo nos pontos onde pode ocorrer transbordo. Ainda assim, são recomendados para garantia de qualidade e são amplamente usadas ao longo das rotas de exemplo dadas no wiki, mesmo em paradas simples que só tenham dois membros stop_position e platform e nada mais. Só sugeri para o caso específico dos terminais que você citou, não como obrigação nesse caso e menos ainda como obrigação geral, pelo contrário: aqui em PoA, por exemplo, seguir essa recomendação introduziria ~2500 relações stop_area para as mais de 5 mil paradas de ônibus (farei um dia, mas por enquanto estou postergando porque há outras prioridades).

1 Like