Anderson, boa tarde. As alterações nesses radares não estão corretas. A direção não é aquela para onde a câmera aponta, mas a do fluxo de tráfego fiscalizado por ela. Nesse caso, o mapeamento anterior (radar como nó da via) estaca certo e sua alteração inverteu as direções.
Vou reverter para acertar, OK?

Esqueci de colocar, essa query mostra os locais com inconsitência entre as velocidades do trecho e do radar. Ela está configurada para busca no Estado do Rio, mas você pode editar para fazer buscas em ouras UFs, municípios ou bbox:

https://overpass-turbo.eu/s/1qNp

Abraços.

Olá, Bem Mapas, tudo bem?
Esse trecho ficou com uma inconsistência entre as velocidades máximas do radar e da via. Como o trecho onde estão os 2 radares, atuando em direções opostas, está com velocidades diferentes em cada sentido (50 em um, 80 no outro) a velocidade 80 vai sempre conflitrar com um dos dois radares já que são ambos de 50.

Minha sugestão é fazer os cortes não nos pontos dos radares mas nas 2 placas de limite de velocidade que antecedem os radares e definir 50 como velocidade única nesse trecho. Uma das placas de velocidade eu já havia mapeado, a outra identifiquei (Bing) e mapeei hoje.

Nesse link fica mais claro onde elas estão (e onde podem ser feitos os cortes, talvez um pouco antes de cada uma para que elas mesmas não fiquem em 2 trechos ao mesmo tempo, o que pode gerar confusão) :

osm.org/edit?node=6023884520#map=18/-21.65538/-42.30174

E depois colocar a velocidade máxima de 50 no trecho entre as placas e manter 80 antes e depois.

Abraços e bons mapeamentos!

Olá, Bem Mapas. Obrigado!
A questão é que tem uma lombada longa (hump) bem ali no trecho em que você recolocou a velocidade de 50 km/h num dos sentidos. Eu tinha secionado o trecho no entorno da lombada para garantir nele a velocidade máxima de 30 km/h conforme a resolução 600/2016 do CONTRAN que define as velocidades nos entornos de lombadas: 20 km/h para lombadas curtas e 30 km/h para longas. Deixar com 50, mesmo em apenas um dos sentidos, fica fora da legislação e pode causar algum dano/acidente caso o motorista confie no seu navegador e acabe passando a 50 numa lombada de 30. Eu tenho procurado fazer uma "limpeza" desses casos (infelizmente são muitos) compatibilizando as velocidades nos trechos onde há lombadas com ajuda de seguinte query overpass para identificar os conflitos:

https://overpass-turbo.eu/s/1qJW

Se quiser dar uma verificada, você pode usar a query em outras áreas de interesse escolhendo bbox (para uma área menor), um município ou uma Unidade da Federação.
Abraços!

Hi Guido,

That one in particular, r4832189, had already been fixed by someone else. I had also fixed some around that region before which, for some reason, showed up broken again... fixed now (I hope).

Hi Guido.

Fixed 7 boundaries:

1- level 5 r11074718 - Região Geográfica Intermediária de Redenção;

2- level 7 r12112257 - Região Geográfica Imediata de Aquidauana - Anastácio;

3- level 7 r12112724 - Região Geográfica Imediata de Manicoré;

4- level 7 r12115099 - Região Geográfica Imediata de Altamira;

5- level 7 r12115101 - Região Geográfica Imediata de Itaituba;

6- level 7 r12115104 - Região Geográfica Imediata de Tucumã - São Félix do Xingu;

7- level 7 r12115105 - Região Geográfica Imediata de Redenção.

Hi Guido,

Thanks for the warning. Fixed (closed) now.

Hi Guido,

Thanks for the warning. Fixed (closed) now.

A imagem mostra que estava em mar/2022: https://www.google.com/maps/@-18.1820107,-47.9415319,3a,75y,52.59h,92.58t/data=!3m6!1e1!3m4!1sOmWfgM5_YiFV2V9gr4OUxw!2e0!7i16384!8i8192

Você tem alguma informação mais recente?

Olá santamriense.

OK! Obrigado pela sugestão, vou ver se consigo. É que em geral preparo uma lista com centenas de vias muito longas (há casos de dezenas de quilômetros) e saio cortando ao meio, ao meio, etc, até ficarem com tamanho razoável. São muitas, nem sempre dá para ficar olhando cada uma no detalhe. Em outros casos, gero lista de relações de restrição de manobra, ou destination_sign, defeituosas para acertar. Também eram muitas. Em geral causadas por divisões feitas nas vias com iD por mapeadores e o iD acaba corrompendo a relação inserindo trechos divididos quando não devia.

Hi, removed extra tags accidentally sent

que conhece a região, acredita que não existam mais, já vou removê-las :). Abraços,

Olá, Adriano. Não sei dizer. tenho migrado para o OSM muitas lombadas de um arquivo do antigo GPSPoint, mais de 5 anos, da época que eu administrava os pontos de alertas lá. Como não é frequente lombadas serem removidas das vias e essas em particular aparecem nas imagens do Mapillary, eu ioncluí, Mas se vocve

Hi Guido,
thanks for pointing it out. I thought I had fixed them all but some went unnoticed. Fixed now.
Best regards,
-- Fidelis

Hi, I have no idea how it got there. Anyway, I changed them all to traffic_calming=hump. Thank you for the warning.

Olá, Adriano.
Não conheço recomendação para isso, mas comecei a dividir para melhorar o endereçamento. A questão é que uma parte fundamental no endereçamento é identificar a que município, e bairro, uma rua pertence. Eu introduzi essa identificação de endereços (das ruas) usando as linhas administrativas no compilador de mapas osm2mp.pl, do Liosha (um desenvolvedor russo que o fez para Navitel e para Navikey/7ways).

A modificação funcionou bem na maioria dos casos mas tem problemas quando a via atravessa uma linha administrativa - a via acaba sendo atribuída de forma errada em alguns casos ao outro município ou ao outro bairro, o que impede encontrar o endereço desejado no GPS.

Para corrigir isso, comecei a “dividir” as vias durante o processamento em um dos nós vizinhos à linha administrativa (o que não é ideal pois o nó vizinho pode estar bem longe da fronteira), sendo essa divisão apenas no processamento, não no OSM, o que em princípio seria uma boa opção - não modificar o OSM. Melhorou o resultado, reduzindo os erros de endereçamento, mas surgiu um novo problema: vários casos de restrição de manobra possuem um dos membros, “to” ou “from” extremamente extensos e que acabam cruzando uma linha administrativa. Então, ao quebrar um trecho de via que por acaso pertence a uma relação de restrição de manobra, essa relação fica prejudicada pois o segmento original que fazia parte da relação não existe mais - foi substituído por 2 outros. Resultado a relação de manobra fica perdida.

Fiz então uma outra modificação: atualizar, no processamento dos mapas, todas as relações de manobras afetadas pela quebra de um de seus membros na linha administrativa. Isso melhorou o resultado pois as relações de manobras não são mais perdidas. Mas o tempo de processamento aumentou bastante.

Tentei, ainda, alterar o processamento para incluir um nó fictício exatamente no cruzamento da via com a linha administrativa (sem alterar no OSM), e fazer uma quebra precisa com cada parte pertencendo ao seu município/bairro correto. A dificuldade foi muito grande, não consegui. Achei mais simples e preciso quebrar o original no OSM. Não vi consequências negativas disso - exceto alguns segmentos bem pequenos, como resultado.

Um outro problema que observei nesses casos de trechos automaticamente quebrados pelo processamento nas linhas administrativas: não é raro encontrar um dos trechos com uma extensão absurda, até 20km, o que não é legal. Os trechos não devem ultrapassar 10 a 12 km - eu até prefiro menores. Em trechos muito longos, existe a chance de alguma edição impactar uma relação de restrição de manobra (ou de fiscalização) longe do local de edição e que o mapeador nem percebe. Tenho encontrado e corrigido muitas relações com problemas causados por edições desatentas (o compílador de mapas aponta esse tipo de erro ao tentar compilar a restrição).

Bom, é isso, no final achei melhor dividir as vias no próprio OSM, para se ter um endereçamento m ais preciso e para reduzir a extensão dos trechos que pertencem a uma relação de restrição de manobra (ou mesmo a uma relação de fiscalização) e evitar esses diversos problemas. O fato de algum segmento ficar pequeno me pareceu menos problemático do que os diversos erros que venho encontrando.

Finalizando, alguém poderia argumentar que essa quebra das vias nas linhas administrativas seria algo na linha “mapear para o renderizador, ou para as aplicações”. Bom, não deixa de ser, mas como o OSM é um projeto colaborativo - colaborar é fundamental - a colaboração deve ser de mão dupla, com bom senso, seja para facilitar o mapeamento (sem introduzir detalhes específicos de renderização ou da aplicação) mas também para facilitar o desenvolvimento das aplicações (não mapear contra a renderização ou contra as aplicações) que, no fim, são o que dão utilidade aos dados mapeados. Então, creio que deve haver um meio termo aí entre “não mapear para o renderizador” e “não mapear contra o renderizador” :).

Caso você tenha alguma sugestão para esses problemas de endereçamento e de restrições de manobra, ou de fiscalização, com membros extremamente longos, gostaria muito de ouvir.

Só hoje vi seu comentário, mas acho que você se enganou. Eu não coloco código de rodovia em nome. Existe a facilidade de "Histórico de alterações" que você pode seguir para conferir se alguém fez isso, e quem.
Obrigado.

Certo, mas creio que isso não tem qualquer relação com este changeset (inclusões de lombadas e atualização de nome de rua). Você tem alguma razão para achar que sim?

Não entendi, a que alteração você se refere? Eu incluí lombadas e acertei o nome de uma rua com base no IBGE. Qual a relação disso com Inhoaíba ou Campo Grande?

Não sei dizer, não fui eu que incluí esse teste.