O maior problema seria manter o cadastro atualizado , já que radares são desativados com uma frequência grande , então qto mais simples for a inclusão mais pessoas farão parte ativamente.
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Livre de vírus. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>. <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> Em 29 de março de 2018 13:28, Fidelis Assis <fidelis.as...@gmail.com> escreveu: > > > Em 28 de março de 2018 22:24, Nelson A. de Oliveira <nao...@gmail.com> > escreveu: > >> 2018-03-28 20:35 GMT-03:00 Fidelis Assis <fidelis.as...@gmail.com>: >> > Bem, acho que não fui muito claro. O que eu sugeri antes em outras >> palavras >> > foi esquecer essa palava câmera :). E passar a interpretar o mapeamento >> de >> > sensor de velocidade em nó de via não como mapeamento de câmera e sua >> > direção mas do sensor mesmo! Aqueles sensores magnéticos ou de peso que >> > ficam sob o asfalto na grande maioria dos "radares" fixos de trânsito. >> >> Mas aí vai mudar a semântica do speed_camera. >> Da mesma forma que vai mudar se usar backward/forward como a direção a >> que ela se aplica. >> >> Vai ser outra jabuticaba no Brasil, diferente do resto do mundo :-) >> > > Nelson, o que me preocupa não é se vai mas se já não é e estamos comendo > jabuticaba achando que é maçã :-) Pelo menos para mim os sinais são claros: > > 1- A começar pelo nome, no iD a tradução de 'speed camera' é 'sensor de > velocidade'. Difícil achar que essa tradução foi feita pensando em câmera; > > 2- O mapeamento tem sido feito como um nó na via na grande maioria dos > casos. Ora, câmera não fica na via mas ao lado (maioria). Tecnica e > intuitivamente não deveria ser mapeada na via mas ao lado, aí sim sendo > necessária relação de enforcement para indicar a direção de fiscalização. > O que de fato fica na via são os sensores de velocidade para os quais a > ideia de direção concorda naturalmente com a de fiscalização; > > 3- Se a gente conferir vamos ver que nos casos em que há direction para > sensor de velocidade não há relação entre esta e a direção da câmera, para > onde ela está voltada. A impressão que passa é que a intenção dos > mapeadores, consciente ou inconscientemente, não foi retratar a direção da > câmera, mas a de fiscalização. Infelizmente, para speed camera não há uma > especificação clara na wiki indicando qual poderia ser usada. Como disse > o bhousel, "na falta usei o mesmo padrão adotado para direção em outros > casos" - em tradução livre. > > Então, a impressão que fica para mim é que a semântica já foi de fato > alterada na prática, aos poucos, sem percebermos. Estamos falando de câmera > mas inconscientemente pensando no sensor. > > E por que ele sugere explicitamente graus no template? Para mim é porque > ele estava pensando na câmera mesmo, algo naturalmente fora da via e, > portanto, sem relação tipo forward/backward com a mesma. Entretanto, na > prática o mapeamento tem sido feito na via e ele concorda com essa forma > também. > > >> No dia 31 de janeiro tinha 28 câmeras com backard/forward no Brasil. >> Hoje já tem 41. >> >> Eu tentei pedir para que isso ficasse um pouco mais explícito no iD, >> mas não consegui. >> https://github.com/openstreetmap/iD/issues/4757 > > > Isso é confuso mesmo, não há uma especificação clara na wiki e por isso > entendi as razões dele ter feito e mantido assim. > > 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! > > Perguntei sobre mas ficou por isso mesmo e aceitei que a prática > prevaleceu: https://github.com/openstreetmap/iD/pull/4602#issuecomment > -367000932 > > >> >> A relação de enforcement é mais complexa, mas já é o modelo válido >> para se definir para que sentido se aplica ou não o aviso (e existe >> desde 2009 https://wiki.openstreetmap.org/wiki/Proposed_features/Relati >> on:enforcement) >> > > Sim, claro, o problema é justamente sua complexidade maior. Poucos > mapeadores conseguem usá-la corretamente. > 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. > > Agora, resumindo, o importante no meu ponto de vista é encontrar uma forma > simples e consistente para indicar a direção de fiscalização. Concordo que > minha sugestão de interpretar como sensor é meio radical, fora da caixa, > mas me parece que é isto que já estamos fazendo há algum tempo, apenas não > chamando pelo nome. > > Uma outra possibilidade menos complexa para indicar a direção de > fiscalização para sensor de velocidade seria usar forward/backward na > etiqueta maxspeed (maxspeed:forward e maxspeed:backward), isso já é > previsto. Talvez você ache mais aceitável. > > -- > Fidelis Assis > > _______________________________________________ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br > > -- *Pedro Esmerilho*
_______________________________________________ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
