[Talk-br] Como interpretar direction em pontos de alerta?

Fidelis Assis fidelis.assis em gmail.com
Sexta Março 30 17:11:53 UTC 2018


Em 29 de março de 2018 22:50, Nelson A. de Oliveira <naoliv em gmail.com>
escreveu:

> 2018-03-29 13:28 GMT-03:00 Fidelis Assis <fidelis.assis em gmail.com>:


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
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.openstreetmap.org/pipermail/talk-br/attachments/20180330/819b5842/attachment.html>


Mais detalhes sobre a lista de discussão Talk-br