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

Flavio Bello Fialho bello.flavio em gmail.com
Domingo Abril 1 11:56:25 UTC 2018


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 <fidelis.assis em gmail.com>
escreveu:

>
>
> 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
>
> _______________________________________________
> Talk-br mailing list
> Talk-br em openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
>


-- 
Flávio Bello Fialho
bello.flavio em gmail.com
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.openstreetmap.org/pipermail/talk-br/attachments/20180401/1eb92738/attachment-0001.html>


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