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
