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.

Já tinha notado isso em outras edições que fiz com o iD. Parece que algum lixo da área de transferência acaba aparecendo sem um motivo aparente em campos aleatórios. Não sei porque acontece. Obrigado pelo alerta.

OK, eu trato ambas as formas durante a extração dos alertas.
abraço

Sim, 0-360 = all. Aquela página não menciona all mas como já encontrei essa forma em outros países, usei por achar mais clara. Se preferir mude para 0-360 :)

Olá, Naoliv.
Sim, quando é zero é porque não está sendo cobrado.
O note é para isso mesmo, ajudar outros mapeadores, no caso eu e alguns colegas de fórum que coletamos e mantemos uma tabela de tarifas atualizadas para uma UX do iGO e agora estamos passando para o OSM. Essas anotações do local do pedágio ajudam na manutenção da tabela e agora na migração para OSM. Como existem alguns casos em que outros mapeadores usam 'name' (até estranho) e 'description' sem um padrão, adotei o 'note' para nossas notas de modo a não sobrescrever o que já existe.
Assim que consolidarmos a migração das tarifas para o OSM, as notas poderão eventualmente ser removidas.
Abraços

Como usei esse plugin pela primeira vez, fiz um a um testando localmente até ganhar confiança. O script na verdade é um compilador de mapas para 7Ways que publiquei (gpsutil.com/7ways) a partir do conversor OSM=>MP do Liosha. Tenho trabalhado nesse compilador há alguns anos incluindo melhorias no endereçamento reverso para buscas e novas facilidades. A mais recente é a extração de pontos de alerta do OSM para uso em GPS. A ideia é motivar os participantes de fóruns que coletam pontos a atualizar o OSM pois a extração poderá ser feita a qualquer momento e por qualquer pessoa. Durante essa extração, faço verificações nos alertas e listo problemas encontrados (ex. aqueles que devem estar sobre uma via ou relacionado para se obter sentido e direção mas não estão, via preferencial em nó inicial/final, tags ausentes, incompatibilidade entre maxspeeds do ponto e da via, etc). Os nós não conectados são identificados nesses testes. A versão publicada não é a mais atual com todos esses testes. Devo atualizar em breve assim que estabilizar.

Reverti os 10 sensores de relação (repeti um id acima) movidos para a via. Por favor veja se está OK.

OK. Consegui identificar. Movi 46 sensores e 45 lombadas em SP e RJ. Dentre os sensores de SP, 11 são devices em relações e foram identificados pelo meu script por engano. Como é esse processo de reversão? É possível voltar todos os 11 ao que era antes ou preciso mover cada um para o lado?

IDs dos devices movidos:
3156575647
3291761093
3291759620
3291761092
3291759659
3291759619
3291746274
3077513375
3077513376
3137625969
3156575647

Antes que você reverta, dá uma olhada com calma. Parece que dos 30 sensores que movi em SP, apenas um ou outro fazia parte de relação. Vou conferir com calma depois.

OK, obrigado pelo aviso. Esses de relações passaram despercebidos. Vou melhorar meu programa de extração de pontos de alerta para identificar corretamente os casos que não fazem parte de relações.