A maioria dos usuários novos tem dificuldades com relações e se pudermos evitar o seu uso a chance de mapeamento incorreto diminui. Uma forma de mapear sem usar relações:
1. Marcar o ponto do controlador de velocidade com highway=speed_camera 2. Marcar a velocidade máxima com maxspeed 3. Se a via for de mão única, não precisa mais nada 4. Se a via for de mão dupla, marcar a direção do monitoramento com direction=forward, direction=backward ou direction=both. 5. Se a direção da lente da câmera não coincide com a do monitoramento e alguém quiser muito mapear isso, use um tag mais específico, como "direction:lens". Em 30 de março de 2018 14:11, Fidelis Assis <[email protected]> escreveu: > > > Em 29 de março de 2018 22:50, Nelson A. de Oliveira <[email protected]> > escreveu: > >> 2018-03-29 13:28 GMT-03:00 Fidelis Assis <[email protected]>: > > > Como está ficando longo vou só resumir o que foi dito: > > O nome é sensor de velocidade, é mapeado em nó de via (como sensor pois > não existe câmera em nó de via), a direction quando existe tem a intenção > clara na prática de indicar direção de fiscalização e não da câmera porque > esta não interessa, mas devemos continuar a dizer que é câmera porque é > assim na wiki. OK, vamos em frente. > > > >> > Um outro ponto que também achei estranho no início foi o uso de >> > forward/backward em stops com uma noção contrária a do significado >> geral de >> > direction que é para onde "olha" (faces to). Em stops é usado por >> > recomendação da wiki e na prática para indicar o sentido do >> deslocamento e >> > não para onde a placa de stop, ou a linha branca, "olha" - vi depois >> > conferindo vários casos em outros países. Mas fica estranho você indicar >> > forward e o viewfield olhar para trás. Já se você usar graus indicando a >> > mesma direção o viewfield olha para frente! >> >> highway=stop é exceção para direction. >> >> Talvez uma forma de tentar entender o rolo do stop é que a placa não >> tem como se aplicar na direção oposta (enquanto que a câmera pode, >> podendo fotografar o carro de frente ou de trás). >> > > É só um erro. Não foi devidamente pensado e ficou assim porque a prática > consagrou. > > >> > Sim, claro, o problema é justamente sua complexidade maior. Poucos >> > mapeadores conseguem usá-la corretamente. >> >> Mas muita coisa no OSM só dá para ser representada de forma complexa. >> Tem gente que foge de relação, mas em muitos casos é o único mecanismo >> que existe para mapear. >> > > Assim como tem coisas simples que uma regra inadequada torna complexa. Só > dá complexidade ao óbvio. > E nesse caso relação não é o único método, é só o mais complexo. Bem mais > simples e sem suscitar tanta reação é usar forward/backward na etiqueta > maxspeed (maxspeed:forward e maxspeed:backward). > > >> Eu posso arrumar de vez em quando as câmeras que estão em vias de mão >> dupla, se for ajudar. >> > > Legal mas não entendo que esse é o problema, você, eu e outros que > conheçam relações podem fazer isso pontualmente. O problema é a quantidade > de trabalho envolvida para frente. São muitos e, como lembrou o Pedro Vida > Torta, tem o trabalho de manutenção frequente. A questão, para mim, é > encontrarmos e adotarmos uma forma simples e consistente. > > >> > Veja, o mecanismo mais simples para se indicar direção (tag direction) >> está >> > reservado para a câmera, cuja direção pouco interessa nesse contexto. Já >> > para a direção mais significativa, que é a de fiscalização, seria >> necessário >> > usar o mais complexo do enforcement. É como estabelecer regra para >> coçar a >> > orelha direita com a mão esquerda, o pessoal acaba ignorando. >> >> O enforcement já estabelece a direção a que se aplica. >> > Isso é claro né. > > >> Se parar para pensar que direction serve para representar exatamente a >> mesma coisa, não faz muito sentido. >> > Vejo pela simplicidade. Navalha de Occam. > > >> Sinceramente nunca vi alguma propriedade que dá para ser representada >> de forma duplicada assim no OSM. >> > A própria direção do stop pode ser indicada de várias formas: direction, > proximidade, prioridade (highway=priority, stop=minor), traffic_sign: > forward/traffic_sign:backward. Aliás deu um bom trabalho tratar todos os > casos, você encontra todos mesmo no OSM. > > >> Mas supondo que direction sirva para representar a direção a que se >> aplica, e alguém queira representar a direção para onde aponta a >> câmera, representaria como? >> É outro X que fica ao usar direction dessa forma. >> > > Isso eu comentei, sugeri uma forma em mensagem anterior, você não deve ter > visto. Vamos representar um radar fixo tradicional que é composto por uma > câmera, 2 sensores (2 para poder medir a velocidade) e uma lógica associada > que monitora os sensores, mede a velocidade e dispara a câmera quando o > valor medido é superior ao limite permitido. > > Normalmente a direção da câmera não interessa, a que interessa é a de > fiscalização. Mas quero também, por qualquer razão, representar a da > câmera. Vamos então precisar de uma relação de enforcement. > > A relação é composta por 3 elementos: um nó normalmente fora da via para o > DEVICE, um nó na via para o FROM e outro na via para o TO. Podemos > associar o que a relação modela com a realidade pensando no DEVICE como a > câmera, o FROM como o primeiro sensor e o TO como o segundo. Com isso, a > direção de fiscalização sai automaticamente dos dois pontos FROM e TO. > Mas e a da câmera? Bom, nós já temos um nó que representa apenas a câmera, > logo basta colocar p.ex direction=90 no DEVICE para indicarmos que a > câmera aponta para o Leste, 270 para o Oeste, etc. > > Completando, indicamos que é uma relação de enforcement do tipo maxspeed > e adicionamos a etiqueta maxspeed com o valor da velocidade máxima. > > Isso atende? A maior complexidade foi por causa do desejo de se > representar a direção da câmera. Precisamos mesmo disso se a intenção for > representar apenas a direção de fiscalização? > > Agora um exercício simples: se não precisarmos da direção da câmera, por > que do nó DEVICE? Vamos descartá-lo. Ah isso não pode porque o DEVICE é > obrigatório, só o TO é opcional quando FROM e DEVICE estão na mesma via. > OK, é só um exercício. Beleza, com isso reduzimos um pouco a complexidade > e ainda representamos a direção de fiscalização que é o que interessa. > > Podemos simplificar mais? Sim, os dois nós dos sensores, FROM e TO, podem > ser substituídos por um único, o FROM p. ex. e considerarmos o outro como > implícito, é o seguinte na via (ou anterior se o FROM for o último e ai a > gente pensa nele como TO). No caso dos radares fixos tradicionais os > sensores FROM e TO ficam próximos. > > Já que ficamos com apenas um nó de sensor, por que precisamos da relação? > Vamos descartar a relação e colocar as etiquetas highway=speed_camera [1] > e direction=forward/backward indicando direção de fiscalização no nó que > sobrou, o FROM. Já que não temos mais câmera mesmo, essa direction não > representa direção da câmera. > > Dessa forma eliminamos a relação e sua complexidade com apenas um nó na > via - na prática é isso que tem sido feito, só não é visto assim. Claro, a > primeira reação é muita estranheza, quebra muitas regras, sai do conforto, > etc. Mas é apenas uma sugestão para pensar. > > Para evitar alongamentos nesse assunto, vamos focar então em maxspeed: > forward/maxspeed:backward como forma padrão para indicar direção de > fiscalização de radares unidirecionais em vias de mão dupla? É simples, > consistente, dispensa relação e longas discussões. > > > [1] Seria legal se tivéssemos outra etiqueta para isso, ex speed_sensor > para evitar pensar em câmera. Sim, sei que tem até recomendação sobre não > usar isso, mas entendo que o contexto lá é outro. Aqui seria bem razoável. > Ou outro nome distinto: buried_speed_sensor, etc. > > > Abraços, > -- Fidelis > > _______________________________________________ > Talk-br mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/talk-br > > -- Flávio Bello Fialho [email protected]
_______________________________________________ Talk-br mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-br
