Propostas para classificação de vias

Sei como funcionam projetos open source, tenho alguma experiência com isso. Já me passou pela cabeça um fork (e seria em Lua no caso) mas é mais difícil do que parece a primeira vista, especialmente um projeto em Perl, linguagem que não gostaria de usar. E refazer tudo seria muito trabalhoso. Talvez a outra opção que ele citou, ferry=<hw_class> agrida menos, ou até nem agrida, e solucione o problema. Vou fazer uns testes.

Vou pensar mais sobre essas opções e agradeço a ajuda com o script, talvez seja mesmo a saída que perturbe menos o ambiente. Assim que amadurecer mais a ideia entro em contato.

Obrigado e um abraço,
– Fidelis

Bem, você é totalmente livre pra manipular a sua cópia local do mapa antes de aplicar o conversor, manipular o mapa principal é que seria uma questão complicada de “política”. Afinal, a comunidade não tem culpa que esse conversor específico não funcione (porque o autor não leu o wiki, ou não se envolveu com os mapeadores), e a comunidade certamente quer que as aplicações funcionem de uma forma tal que o trabalho de mapear (que é muito maior que o de programar) seja facilitado ao máximo.

Pelo que entendo, o script teria apenas que testar se uma dada entrada com a tag route=ferry tem a tag motor_vehicle=yes e, se tiver, acrescentar a ela a tag ferry=unclassified (por exemplo, pra dar um peso menor pro caminho). É provável que dê pra fazer isso até sem uma biblioteca de XML, só com processamento de texto simples, talvez até mesmo com uma única expressão regular (só tem que cuidar com os fechamentos das tags). Você podia tentar investigar isso primeiramente antes de partir pra um programa mais complexo.

Fernando,

Fiz alguns testes e na verdade é bem mais simples, basta acrescentar a tag ferry=unclassified, como o autor já havia sugerido, e o roteamento funciona. A princípio, não vejo quaisquer efeitos colaterais indesejados na adição dessa tag no OSM e é uma solução simples, rápida e sem custos adicionais de alteração no conversor.

Um esclarecimento: esse conversor e seu autor não são nada estranhos OSM, ao contrário, é o único conversor OSM->MP que encontrei no próprio site do OSM com suporte a roteamento. Possui páginas específicas no OSM com instruções detalhadas de instalação e fórum desde 2008:

Portanto, acredito que o autor tenha intimidade com os detalhes do OSM e tenha se envolvido com inúmeras questões de mapeadores, etc, ao longo do desenvolvimento. Assim, creio que a sugestão dele seja razoável.

Você, ou outras pessoas dessa lista, vê alguma contraindicação na adição dessa tag no OSM?

Abraços,
– Fidelis

Olha, eu particularmente acho que adicionar essa tag ao mapa principal seria uma redundância desnecessária, vários outros sistemas funcionam sem ela (http://wiki.openstreetmap.org/wiki/Routing/online_routers). Se você pode contornar na aplicação, e é fácil fazer isso, não vejo por que obrigar todas as outras pessoas a mudarem a sua forma de mapear (e isso incluiria mudar presets do JOSM) e ainda terem que a educar os recém-chegados sobre a forma correta de inserir tags (o que temos hoje já é complicado, e essa seria uma complicação a mais). Além disso, o artigo principal sobre route=ferry (http://wiki.openstreetmap.org/wiki/Tag:route%3Dferry) sugere que se deve usar as tags padrão de acesso, e nem sequer menciona essa tag ferry.

Mas se você discordar da minha opinião (não sou dono do mapa), fique à vontade pra sondar a opinião de mais gente mandando um e-mail pra lista talk-br.

Ah, encontrei o texto da proposta dessa tag: http://wiki.openstreetmap.org/wiki/Proposed_features/ferry#highway_ferries

Atualmente é uma proposta no estado “undefined” e “inactive”, não tem nem discussão na página Discussion, muito menos foi aberta pra votação, e é uma proposta com mais de 2 anos de idade, o que quer dizer que não está progredindo e dificilmente se tornará padrão ou amplamente aceita.

Bom, penso diferente. Talvez você esteja considerando como verdadeiras as premissas abaixo:

1- Que a tag motor_vehicle=yes (por estar listada no wiki) seja amplamente usada e que seja suficiente;
2- Se o OSRM (e outros) roteiam, então as informações estão OK e ele está fazendo a coisa certa;

Em relação à primeira, nem uma coisa nem outra. Logo que me deparei com o problema do roteamento via balsas no 7ways com mapas OSM, fui ver como elas estavam mapeadas. Peguei um trecho da Transamazônica (Humaitá/AM até Manaus) e em nenhuma delas consta a tag motor_vehicle (nem motorcar) apenas “route=ferry”. Levantei também outros pontos, no RS, para ter uma amostra maior:

=======================================
Em Humaitá/AM (id: 46900076)
Balsa BR-319

  • route=ferry
  • highway:class = primary (!)

Em Tupana?/AM -4.183,-60.807 (id: 179718338)
Balsa BR-319

  • route=ferry

Em Igapó Açu/AM (ID: 171888519)
Balsa BR-319

  • route=ferry

Em Careiro da Várzea
Balsa Careiro-Manaus (ids: 46615151, 46615217 e 46615218)
-route = ferry

Em Maquiné/RS
Balsa (id: 243071288)

  • route = ferry

Em Pinheirinho do Vale/RS
Travessia do Rio Uruguai (balsa) (id: 96491343)

  • route = ferry

Travessia do Rio Uruguai (balsa) (241502304)

  • route = ferry

Balsa (id: 241020797

  • route = ferry
    =======================================

Assim, a ideia de usar ferry=<hw_class>, no lugar de motor_vehicle=yes, me pareceu dar o mesmo trabalho que sua sugestão (motor_vehicle=yes), afinal teria de colocar uma delas mesmo. Entretanto, motor_vehicle não diz nada sobre a classe da via, informação importante para roteamento, ao passo que ferry=<hw_class> além de indicar a possibilidade de roteamento ainda acrescenta a classe. Além de dispensar qualquer preprocessamento no .osm ou alterações no conversor. Uma opção bem melhor no meu ponto de vista. Olhando por esse lado, ela não é nem redundante nem desnecessária, penso que seja mesmo indicada.

Na época, chequei também o OSRM e vi que ele roteia carros normalmente por essas balsas, mesmo sem nenhuma tag motor_vehicle ou motorcar positiva. Claramente ele não está usando isso. Essas tags positivas, quando presentes, estão sendo provavelmente ignoradas, inúteis. E como não há informação sobre a classe da via, o OSRM (e outros) está fazendo o melhor que pode para apresentar um roteamento útil, mas certamente não é o melhor possível já que não se pode comparar quando há opções. Há uma outra possibilidade que não chequei, que seria o OSRM estar examinando relações entre esses segmentos e rodovias e inferir alguma coisa daí. Acho pouco provável pela complexidade. Além de ser bem mais trabalhoso em termos de programação, se não se pode confiar na qualidade de tags simples, muito menos em relações mais complexas.

Identifiquei também alguns casos em que motor_vehicle ou motorcar são usadas:

Em São Jerônimo/RS

  • Balsa Triunfo (id: 96081681)
  • route = ferry
  • motor_vehicle = yes

Em Barra do Guarita - Balsa do Rio Uruguay

  • route = ferry
  • motorcar = yes

Em Guarujá = Balsa Bertioga-Guarujá (id:

  • route = ferry
  • motorcar = yes

Em Niterói - Barcas Niterói-Rio

  • route = ferry
  • motorcar = no

A tag motor_vehicle é menos comum, aparece apenas em um dos exemplos. De qualquer forma, não estão sendo úteis para o OSRM nem para outros roteadores. Com exceção do caso de Niterói, onde aparece na forma negativa “motorcar=no”. O OSRM de fato não roteia carros por ali. Esse dado parece indicar que o OSRM na verdade assume que route=ferry é sempre roteável, a menos que exista (motorcar|motor_vehicle|hgv)=no. Não sei se isso acarreta erros de roteamento, mas com certeza são menores do que não rotear sem tags positivas no estado atual do mapeamento. Na falta de mapeamento adequado e confiável isso é bem prático. Como é uma alteração simples no código, estou pensando em fazer uns testes e adotar se não encontrar maiores problemas. Talvez seja o caminho mais simples mesmo, ou o único com esses dados.

Nem sempre é fácil. Essa parte (aplicações) por acaso é onde tenho maior experiência, no OSM é que estou começando.

Penso que é importante olhar também os impactos da forma de se mapear sobre o desenvolvimento das aplicações. Se a forma usada for insuficiente ou se implicar em custos desnecessários, vamos ter atrasos, mais bugs, etc, nas aplicações. Afinal, tudo que obtemos de informação e de útil com os dados do OSM é através de alguma aplicação desenvolvida por programadores.

Não sei se há outras melhores, meu conhecimento de OSM ainda é pequeno, mas depois de sentir o problema de roteamento com balsas “na pele”, começo a achar que ela merece maior atenção. Provavelmente surgiu da insatisfação (insuficiência/custos extras?) com o que temos hoje e mereça maior discussão.

Abraços,
– Fidelis

Ah bom, então se o OSRM aceita rotear por balsas por padrão, você só precisa testar se a via tem motor_vehicle=no ou motorcar=no ou access=no/private, certo? (Acho que era o OsmAnd que não roteava por rotas de balsa sem motor_vehicle=yes então.)

Motorcar e motor_vehicle são diferentes, mas o que você está observando provavelmente é o efeito de uma alteração no preset do JOSM, que antigamente era motorcar para balsas e foi corrigida recentemente para usar motor_vehicle. Quem usa o JOSM geralmente atribui o tipo de acesso por veículo porque o preset leva o usuário a preencher essa informação, editores mais simples como o iD e o Potlatch não difundem essa boa prática. Infelizmente, sua aplicação precisa tratar de ambas para ser compatível com o OSM.

Eu não vejo diferenças entre uma rota de balsa que seria parte de uma via “primary” e outra que seria parte de uma via “secondary” para fins de roteamento, nem de renderização. Balsas têm uma velocidade média relativamente baixa se comparadas com veículos, e creio que não há uma grande variação, certo? Para roteamento, talvez o tempo médio de espera entre duas balsas consecutivas ou o custo por viagem seria mais importante, mas isso seria uma complexidade a mais que acho que nenhum roteador comercial suporta no momento. Você pode obter o tempo do percurso a partir da tag (padrão e aprovada) “duration” - que muitos não usam, mas acho que deveriam.

A única coisa com a qual eu não concordaria muito é em levar a comunidade brasileira a adotar práticas diferentes das já adotadas por outras comunidades muito mais participativas (Alemanha, Rússia, Argentina, etc.). Pode ser que a sua discussão pertença ao contexto internacional, daí aqui não seria o melhor lugar pra levantá-la. Nesse caso, sugeriria que você abrisse uma thread nova a respeito pra convocar interessados, e daí passar a discussão para as listas internacionais, sobretudo para a lista “tagging” e para os bugtrackers do OSRM e do OsmAnd.

Eu me referi a casos onde temos duas ou mais opções como, p. ex., a travessia entre Bela Vista (TO) e Imperatriz (MA). Há uma balsa ali e também uma ponte próxima. Enquanto o Google roteia preferencialmente pela ponte (mesmo que você marque exatamente os extremos do trecho balsa!), o OSRM, parece, considera apenas a distância. Uma forma simples de se alterar isso é acrescentar a duração no OSM.

Bom, meu primeiro objetivo é produzir mapas roteáveis que sejam úteis usando o conteúdo do OSM como for possível. Isso também estimula os usuários de GPS a participar do OSM - já temos alguns do fórum GPSPoint participando por causa do navegador. Assim, embora seja uma questão importante, não é meu foco no momento me envolver em discussões sobre formas de etiquetar, o que toma um bom tempo até se conseguir um acordo. Levantei aqui mais para chamar atenção dos mapeadores mais experientes, na esperança de uma solução já existente. Como ainda não há, optei pelo método que o OSRM está aparentemente usando (roteia a menos que haja impedimento explícito). Testei e parece que está bem legal, os novos mapas já permitem traçar rotas do Oiapoque ao Chuí! :slight_smile:

Se alguém quiser experimentar o 7ways (WinCE, Android, iPhone), gratuito, com mapas OSM, seria legal ter retorno:

https://sites.google.com/site/fidelisassis/7-ways

Abraços,
– Fidelis

Que ótimo! Vou testar agora mesmo.

Eu sempre achei muito saudável incluir a informação de duração (inclusive, vi agora que no wiki em inglês escreveram que é altamente recomendado fazer isso). Eu achava que o OSRM nem usava a informação, mas consta no wiki que usa sim. Você poderia usá-la ao converter para o 7-ways, isso seria um diferencial interessante pra esse navegador.

O mapa dessa região está meio vazio, acredito que poucos estejam mapeando por lá. Se você quiser, pode adicionar a duração você mesmo.

Vou repassar essa discussão pra lista, pra chamar a atenção do pessoal.

Uma forma de usar essa informação, que inclusive lhe daria um resultado mais preciso do que uma classificação em primary/secondary/etc., seria dividir o comprimento da rota pela duração e com isso atribuir uma tag “maxspeed”, que o roteamento consideraria como velocidade de trânsito no percurso. Assim, balsas muitos lentas (certamente há algumas em que a velocidade média é de 10km/h ou até menos) seriam mais evitadas do que qualquer via existente hoje no OSM (o OSRM, por exemplo, considera a velocidade média por residenciais em torno de 25km/h, acho que apenas “living street” é mais lenta).

Eu tentei colocar a duração nessa balsa de Bela Vista <=> Imperatriz, mas não consegui achar essa informação nem os horários. A única duração que eu vi foi a do Google, forçando a travessia pela balsa. Também não sei se o 7ways usaria essa informação, ainda está em desenvolvimento e faltam certas características, facilidades. Mas está na minha lista de testes.

Boa ideia! Certamente o navegador deve considerar a velocidade máxima dos trechos/duração total na escolha. Pode acontecer entretanto de alertar “velocidade acima do limite” dentro da balsa :slight_smile:

É, seria meio engraçado se isso acontecesse. :stuck_out_tongue:

Bem, nesse caso, você pode atribuir a categoria “primary”, “secondary”, “tertiary”, “residential” ou até “living_street” baseado na velocidade calculada para o percurso. Na ausência da informação de tempo, você pode sempre atribuir a classe mais lenta (abordagem conservadora). Acho que teria um efeito bem similar.

Eu já havia colocado o default como unclassified justamente para reduzir a prioridade do trecho. Descobri agora que, para balsas, o conversor atribui velocidade máxima = 5 km/h de secondary para baixo e 20km/h para primary e trunk. Vou alterar para 8 que é o valor sugerido para balsas na documentação do Polish Format (formato intermediário para conversão: OSM => PFM => 7w). Mas permanece o pequeno inconveniente de alarmar excesso de velocidade dentro da balsa. Vou ver com o suporte da Navikey como evitar.

Repostando uma sugestão que surgiu na lista sobre como classificar as vias trunk. A sugestão é a seguinte:

Que mais adiante foi seguida por:

Eu acho que essa idéia pode fazer algum sentido sim, por isso resolvi trazê-la para cá para ouvir as opiniões. Essa proposta tornaria o nosso mapa mais similar ao dos países vizinhos do Brasil, dando uma continuidade que talvez faça algum sentido.

Pontos a considerar:

  1. A classificação da via afeta a renderização, particularmente afeta em quais níveis de zoom ela vai ser mostrada. Em vários estilos (o padrão, o Transport, e o Humanitarian) tanto trunks quanto motorways aparecem no mesmo nível. No OpenCycleMap, as trunks aparecem 1 nível (6) depois das motorways (nível 5). No MapQuest Open, apesar de aparecerem juntas, as trunk aparecem com bem pouca evidência nos dois primeiros níveis. Em todos eles, as primárias aparecem só em níveis maiores. Dois deles (o Humanitarian e o Transport) mostram primárias e secundárias a partir do mesmo nível, e os demais mostram apenas 1 ou 2 níveis além.

1.1. As características que escolhemos para as motorways raramente são questionadas, a questão principal é sobre a diferenciação entre primárias e trunks. Atualização: parece que não é bem assim.

  1. A classificação da via afeta o roteamento somente se estiver faltando a etiqueta maxspeed. Nesse caso, a classificação é usada para “estimar” a velocidade da via. Sistemas de roteamento diferentes fazem uma estimativa diferente, e por isso mudar a classificação esperando alterar o roteamento à seu próprio gosto acaba sendo um problema pra todo o mundo (já que cada um usa seu próprio sistema de roteamento, com estimativas diferentes). Fazer isso é então considerado “mapear para a aplicação” e não é boa prática. Por fim, um mapa com a etiqueta maxspeed definida corretamente em todas as vias e com a classificação definida de forma aleatória ainda produzirá rotas coerentes.

  2. É bem possível que a classificação afete alguma outra aplicação, tal como a geração de estatísticas a partir do mapa. Eu desconheço outras aplicações, mas é possível que existam.

  3. A classificação no Brasil é especialmente problemática (comparando com outros países) devido à grande variabilidade nas condições das vias. Além disso, a noção de “importância” é meio indefinida. Uma via que atravessa uma grande distância pode ter pouco tráfego e estar em péssimas condições, enquanto que uma via curta pode estar em perfeitas condições (ou não) e ter tráfego intenso porque conecta duas grandes cidades e, por essa razão, ser mencionada com uma frequência muito maior. Uma via que passa pelo meio de uma cidade em baixa velocidade pode ser um trecho de uma via importantíssima para alguma finalidade regional (circulação de produção industrial, circulação de civis, turismo, ciclismo, atividade militar, etc. etc.) mas não ser tão importante para outra finalidade.

  4. Por causa das diferentes finalidades, pessoas diferentes frequentemente têm opiniões muito diferentes sobre a classificação adequada de uma certa via. Se não houver uma recomendação geral que expresse quais são os principais fatores ao avaliar a “importância” da via, teremos guerras de edição.

  5. Uma boa recomendação geral deve tentar acertar a maioria dos casos e tentar deixar poucas exceções incorretas a serem justificadas individualmente. Ou isso, ou teremos que discutir e votar rodovia por rodovia e estrada por estrada, caso a caso. De preferência, essa recomendação deve ser fácil de avaliar e, portanto, de exigir dos mapeadores que se aventuram a mudar classificações. É inviável escrever uma dissertação sobre cada via só para decidir a sua classificação, quase ninguém leria intermináveis discussões sobre como classificar uma via específica.

  6. Uma reclamação comum é quando a classificação se alterna ao longo da mesma via. Alternar pode até ser útil para o usuário final (caso a classificação esteja atrelada a alguma característica específica da via - como se é ou não pavimentada), mas prejudica a legibilidade do mapa. Claro, é importante também definir em quem condições a classificação pode se alternar. Uma possível situação é quando uma rodovia passa por dentro de uma cidade - ou, mais especificamente, quando vias da cidade compõem o sistema da rodovia, apesar de serem vias urbanas típicas.

  7. Outra possível reclamação é a geração de “pontas soltas”, ou seja, vias importantes/rápidas/com tráfego intenso que parecem acabar no meio do nada. Normalmente é esperado que uma via importante comece e termine em outras igualmente importantes ou mais importantes (isso é o que dá ao sistema uma noção de “hierarquia”). Mas é provável que haja exceções. E levar essa regra muito ao pé da letra também vai logo expor casos em que seriam necessários vários níveis (mais do que o que temos hoje) para expressar a hierarquia das vias.

  8. A etiqueta motorroad, geralmente associada a trunks e primaries, não faz muito sentido no Brasil. Aqui o máximo que temos é uma situação onde bicicletas não podem, à priori, circular em rodovias sem acostamento (Art. 244, § 1º do Código de Trânsito Brasileiro) e talvez algumas situações muito específicas onde veículos agrícolas e de tração animal não são permitidos também (mas é necessário ter sinalização indicativa no local).

Opiniões minhas relacionadas à opinião do Gabriel:

A. Para a classificação urbana, a preferência entre as vias sugere a sua hierarquia. Então talvez (talvez!) esse critério seja aplicável às rodovias. A maior diferença entre as vias urbanas e as intermunicipais é que as intermunicipais possuem longos trechos sem obstruções frequentes (como semáforos ou rotatórias). Eu também mudaria os 300km do Gabriel para 100km, mas isso é um detalhe que pode ser discutido depois.

B. Outra possibilidade é não usar a preferência (que só afeta a circulação em trechos curtos numa rodovia) e sim pensar na distância que a via percorre em linha reta do início ao fim. Isso pode gerar confusão em alguns casos, especialmente quando a via faz curvas (caso em que acho que faz mais sentido considerar o percurso em linha reta e não o percurso total; um caso desses seria o de rodovias circulares contornando cidades) e quando se conecta a outras vias (caso em que a via de conexão tem uma importância mais local do que global). Também pode ser difícil definir onde é o fim da via. Em alguns casos o fim depende muito de para onde o usuário do mapa quer ir.

C. Outra possibilidade é marcar todas as rodovias (vias adminstradas pelo governo federal e/ou estadual) como trunk (ou, onde tiver infraestrutura suficiente, motorway) e deixar primárias, secundárias, etc. para vias que atendem exclusivamente ao sistema urbano.

Eu sinceramente acho que a opção B faz mais sentido ao pensar “genericamente” (ou seja, sem o objetivo de mapear exclusivamente para planejar rotas). Também acho que a opção C é a mais fácil de mapear.

Os pontos 7 e 8 podem juntos produzir uma dúvida. Pelo item 8, uma via só seria trunk se puder ser trunk ao longo de todo o percurso, mas o pelo item 7 pode ser que um trecho seja rebaixado por não ser pavimentado. Nesse caso, acho que faz sentido pensar que existe uma “expectativa de pavimentação” e, com isso, classificar o trecho pavimentado como trunk, apesar de ele não ser inteiramente conectado a vias de classificação igual ou superior (o trecho não-pavimentado).

O Art. 144, § 1º do CTB é este:

“Art. 144. O trator de roda, o trator de esteira, o trator misto ou o equipamento automotor destinado à movimentação de cargas ou execução de trabalho agrícola, de terraplenagem, de construção ou de pavimentação só podem ser conduzidos na via pública por condutor habilitado nas categorias C, D ou E.
Parágrafo único. O trator de roda e os equipamentos automotores destinados a executar trabalhos agrícolas poderão ser conduzidos em via pública também por condutor habilitado na categoria B.”

s

Oops, era pra ser o 244. :stuck_out_tongue: Consertei.

Abri um tópico especificamente sobre as diferenças entre trunks e motorways.

Valeu Fernando :slight_smile:

[]s

tenho visto algumas rodovias com o uso da tag source:highway=schema_br2014. todavia, não encontrei qualquer referência (fórum, lista de discussão e wiki) sobre esse esquema, mas tão sobre o de schema_br2013.

onde posse encontrar informações sobre o schema_br2014?

Acho que deve ser erro de digitação (trocando o 3 pelo 4 ou talvez achando que deve sempre utilizar o ano atual)

valel, naoliv.

vou corrigir essa tag e conferir a classificação das vias de acordo com o schema_br2013.