[Talk-br] [Cocar] Contribuintes para cidades do RJ no OSM

[Fernando Trebien]

Li bem a proposta da relação "enforcement" e acho que tem furos
(muitos deles mencionados nessa discussão:
http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Relation:enforcement)
e que provavelmente vai sofrer alterações um dia. Por isso, se
conseguirmos usar apenas o básico, é mais fácil adaptar depois, e
também é mais fácil automatizar uma conversão para um novo modelo.

Os dois exemplos (quase idênticos) que eu fiz:
http://www.openstreetmap.org/relation/3396649
http://www.openstreetmap.org/relation/3396648

Reparem nas tags da relação e nos seus membros. Para representar a
fiscalização de avanço de sinal vermelho (red light cameras), a
estrutura mais simples possível e mais compatível com "tudo" fica
assim:
* tags da relação: type=enforcement + enforcement=traffic_signals
* membros da relação: device (o nó do semáforo, parte da via) e from
(qualquer nó anterior ao semáforo ao longo da via)

O semáforo pode ser tanto o centro do cruzamento como um nó antes do
centro (como nos meus exemplos). O segundo geralmente é preferível
porque contém mais informação, mas ambos estão ok.

Se a via não for de mão única e a fiscalização de avanço de sinal
vermelho for aplicado em ambos os sentidos, você cria duas relações,
uma para cada sentido. Se estiver usando apenas um semáforo,
acrescenta-se esse mesmo semáforo a ambas as relações com o papel
(role) "device".

Não encontrei nenhum exemplo de uso em outros países (esse mapeamento
é proibido nos países germânicos e há apenas 1400 casos mapeados no
mundo todo - pouco, para uma proposta com 4 anos de idade). Encontrei
apenas este vídeo demonstrativo que ilustra como mapear algo parecido
(uma fiscalização de velocidade) usando o JOSM:
http://www.youtube.com/watch?v=2tnohs_8gFY

Aqui, o mapeador (que é autor da proposta) optou por colocar o nó
"device" fora da via e usar um nó "to". Certamente assim se consegue
representar uma informação a mais (o local exato da câmera), mas
atualmente não se ganha quase nada fazendo tanto (apenas uma
informação que normalmente fica oculta e não é usada pra nada). Por
isso, sugiro a versão mais simples do meu exemplo. No texto da
proposta original, há exemplos de várias situações mais complexas
(fiscalização de avanço somente para conversão à esquerda no
cruzamento, controle de velocidade com câmera traseira, fiscalização
de distância entre veículos, fiscalização de peso, fiscalização de
altura para túneis), algumas que fariam alguns mapeadores torcer o
nariz (vejam que a aprovação da proposta teve um número substancial de
opositores), por isso não recomendo a menos que seja necessário.

Nesse vídeo, eu ainda atribuiria a tag highway=speed_camera ao nó
"device", pra ficar bem completo. Notem que a maioria dos conversores
atualmente não suporta a relação enforcement, apenas nós com
highway=speed_camera. Se a usarmos para representar controle de
velocidade sem usar highway=speed_camera no nó, estaremos sozinhos no
mundo.

2013/12/24 Paulo Carvalho <paulo.r.m.carvalho em gmail.com>:
> Fernando, se puder mandar eu agradeço.  Preciso abrir um ticket no PFM2OSM
> para tentar gerar.  Se for algo da complexidade de uma restrição de manobra,
> é relativamente tranquilo de implementar.  Mas uma coisa é um conversor
> fazer, outra é instruir um desenvolvedor como implementar.  No Tracksource é
> muito fácil de colocar, pois é só um ponto.
>
> []s
>
> Paulo
>
>
> Em 23 de dezembro de 2013 23:38, Fernando Trebien
> <fernando.trebien em gmail.com> escreveu:
>>
>> Sim, "enforcement" representa exatamente esse caso e, por já ser uma
>> proposta aprovada há algum tempo, tem mais chance de ser suportada
>> antes de qualquer outra proposta nova. Se eu me esquecer, me lembre de
>> lhe mandar um exemplo até amanhã.
>>
>> Note que "enforcement" é uma relação e não uma tag, e que a estrutura
>> não é muito simples (nem pro mapeador). Talvez por isso não esteja
>> sendo usada amplamente.
>>
>> 2013/12/22 Paulo Carvalho <paulo.r.m.carvalho em gmail.com>:
>> >
>> >
>> >
>> > Em 21 de dezembro de 2013 13:38, Fernando Trebien
>> > <fernando.trebien em gmail.com> escreveu:
>> >
>> >> Eu ajudaria. Vamos postar sobre isso no talk-br e ver se tem mais
>> >> interessados?
>> >>
>> >> Lembro que, mesmo aprovada, levaria um tempo (meses, ou até mais de um
>> >> ano) para que as aplicações passassem a suportar o novo conjunto de
>> >> tags, tudo depende da disponibilidade e da boa vontade dos
>> >> desenvolvedores dos aplicativos de navegação e dos de conversão de
>> >> formato de mapa. Mas nada impede que façamos nossos próprios
>> >> conversores/navegadores/etc., é tudo uma questão de ter tempo e
>> >> priorizar (e é aí que geralmente quem "pede" se frustra, porque quem
>> >> pede quase nunca é quem atende o pedido).
>> >>
>> >> A proposta teria que ser bem pensada pra que a comunidade
>> >> internacional a preferisse em detrimento da relação "enforcement", que
>> >> já representa isso. Acho que, pra sermos convincentes, teríamos que
>> >> mostrar por que a relação "enforcement" não é suficiente, ou que é
>> >> difícil de se lidar e causa problemas para as aplicações. (Os
>> >> mapeadores que votam nessas propostas hoje têm um rigor quase
>> >> acadêmico às vezes.)
>> >
>> >
>> > Fernando, "enforcement" significa exatamente o caso (avanço de sinal)?
>> > Se sim não é necessário criar algo novo e eu mudo o conversor para gerar
>> > a
>> > tag certa.
>> >
>> >>
>> >>
>> >> Aliás, faz um tempo que penso que podemos começar a ser mais
>> >> participativos no nível internacional, propondo coisas de que sentimos
>> >> falta para a nossa realidade. Por exemplo, anos atrás, os alemães,
>> >> austríacos e suíços começaram a usar a tag highway=rettungspunkt para
>> >> marcar algo importante que existia por lá (pontos de resgate
>> >> emergencial: um ponto nomeado e com placas indicativas que serve para
>> >> prover serviços médicos de emergência com maior agilidade). Pouco
>> >> tempo depois, à medida que outras comunidades foram descobrindo essa
>> >> tag, viram que algo muito parecido existe em outros lugares, e a tag
>> >> virou highway=emergency_access_point, para que sirva genericamente
>> >> para todos os casos em todos os lugares.
>> >>
>> >> Como somos uma comunidade pequena (10x menos participativa do que a
>> >> argentina, que já é bem pequena se comparada às comunidades
>> >> européias), para sermos ouvidos, precisamos fazer mais pesquisa do que
>> >> eles e ver se o que estamos propondo faz sentido em outros países
>> >> também. Senão o risco é que nossas propostas acabem abandonadas.
>> >>
>> >> Obviamente, qualquer um tem permissão de votar em qualquer proposta,
>> >> inclusive nós brasileiros. Anúncios de votações são dados com alguma
>> >> frequência na lista "tagging", é interessante acompanhá-la.
>> >
>> >
>> > Obrigado pela aula. :)
>> >
>> > []s
>> >
>> > PC
>> >
>> >>
>> >>
>> >> 2013/12/21 Paulo Carvalho <paulo.r.m.carvalho em gmail.com>:
>> >> >
>> >> >
>> >> >
>> >> > Em 20 de dezembro de 2013 13:28, ThUnDeRCeL
>> >> > <thundercel em gpsinfo.com.br>
>> >> > escreveu:
>> >> >
>> >> >>
>> >> >> Até já fui lá postar sobre a duvida de POI de semáforo porque não
>> >> >> entendia
>> >> >> o porque no OSM se cadastrava qualquer tipo de semáforo e não
>> >> >> somente
>> >> >> aqueles que incorporam sensores de avanço com registro de imagens
>> >> >> que
>> >> >> vulgarmente denominamos semáforo com câmera.
>> >> >
>> >> >
>> >> > Sugiro fazer uma proposta.  É claro, para fazer os outros apoiarem,
>> >> > você
>> >> > deve explicitar os motivos.
>> >> >
>> >> >>
>> >> >>
>> >> >> Logo de imediato recebi a resposta que o OSM não mapeia tão somente
>> >> >> para
>> >> >> emprego em navegação GPS.
>> >> >>
>> >> >> Desconheço se existe algum emprego de semáforos comuns e por isso
>> >> >> não
>> >> >> ponderei.
>> >> >
>> >> >
>> >> > Semáforos causam penalidade no cálculo de rotas.  Se eles estão
>> >> > mapeados, um
>> >> > cálculo mais realista de tempo de viagem pode ser feito.  O Garmin
>> >> > não
>> >> > consideram semáforos comuns, mas outros engines de roteamento podem.
>> >> >
>> >> >>
>> >> >>
>> >> >> Outro me respondeu que existia no OSM o POI de radar e disso eu sei,
>> >> >> mas o
>> >> >> problema que semáforo com câmera não é radar. Até existe a figura
>> >> >> dos
>> >> >> semáforos radar, mas esse incorpora dois sensores, um de avanço e
>> >> >> outro
>> >> >> de
>> >> >> velocidade. São dois sensores distintos no mesmo local.
>> >> >>
>> >> >> Outro respondeu que o semáforo com câmera deveria ser considerado na
>> >> >> renderização (conversor), mas nem retruquei para não gerar ali
>> >> >> polemica.
>> >> >> Sabemos que para o conversor extrair a informação do semáforo com
>> >> >> câmera é
>> >> >> necessário que exista alguma TAG no OSM informando que aquele
>> >> >> semáforo
>> >> >> plotado tem sensor de avança. Isso não existe e por essa razão no
>> >> >> OSM
>> >> >> os
>> >> >> semáforos com câmera se misturam aos semáforos comuns.
>> >> >
>> >> >
>> >> > Proponha a criação de uma tag ou atributo expondo os motivos.  Muitos
>> >> > renderizadores poderiam usar essa informação, não só para GPSs..
>>
>> >> > Geradores
>> >> > de arquivos de alerta poderiam usar.
>> >> >
>> >> >>
>> >> >>
>> >> >> Na minha opinião, pela experiência trazida da lista Tracksource,
>> >> >> muitos
>> >> >> nada comentam em uma lista  onde participam “experts” por não terem
>> >> >> experiência no Projeto e com isso tem receio de comentarem alguma
>> >> >> besteira.
>> >> >> Não critico a esses porque essa situação é natural em qualquer
>> >> >> ambiente
>> >> >> e
>> >> >> não somente em lista de correspondência.
>> >> >>
>> >> >> Para que possamos formar um grupo de colaboradores ativo sou de
>> >> >> opinião
>> >> >> que devemos primeiro trocar informações básicas do OSM em uma lista
>> >> >> reservada (COCAR). Chamaria de alfabetização.
>> >> >>
>> >> >> Com algumas exceções acredito que todos aqui são inexperientes em
>> >> >> OSM.
>> >> >
>> >> >
>> >> > Eu inclusive.  Mas acho que pode pedir para o Fernando formatar uma
>> >> > proposta
>> >> > de nova tag ou atributo para assinalar semáforos com avanço de sinal.
>> >> > Seria
>> >> > um atributo true/false muito básico.
>> >> >
>> >> > Hoje os semáforos com registro de avanço são convertidos assim
>> >> > (exemplo):
>> >> >
>> >> > <node id="-15327" lat="-23.0054188" lon="-43.5581093"
>> >> > visible="true"
>> >> > >
>> >> >   <tag k="highway" v="speed_camera"/>
>> >> >   <tag k="amenity" v="tec_common"/>
>> >> >   <tag k="name" v="Semaforo"/>
>> >> > </node>
>> >> >
>> >> > Evidentemente está faltando informação aí.
>> >> >
>> >> > Você ou o Fernando pode fazer uma proposta para algo assim:
>> >> >
>> >> > <node id="-15327" lat="-23.0054188" lon="-43.5581093" visible="true"
>> >> > >
>> >> >   <tag k="highway" v="red_light_camera"/>
>> >> >   <tag k="amenity" v="tec_common"/>
>> >> >   <tag k="name" v="Semaforo"/>
>> >> > </node>
>> >> >
>> >> > O valor grafado em negrito seria um novo valor para o atributo.
>> >> >
>> >> > O nosso conversor poderia criar dois pontos quando encontrasse um POI
>> >> > formatado como Semaforo 60, por exemplo.
>> >> >
>> >> > []s
>> >> >
>> >> > PC
>> >>
>> >>
>> >>
>> >> --
>> >> Fernando Trebien
>> >> +55 (51) 9962-5409
>> >>
>> >> "The speed of computer chips doubles every 18 months." (Moore's law)
>> >> "The speed of software halves every 18 months." (Gates' law)
>> >>
>> >
>>
>>
>>
>> --
>> Fernando Trebien
>> +55 (51) 9962-5409
>>
>> "The speed of computer chips doubles every 18 months." (Moore's law)
>> "The speed of software halves every 18 months." (Gates' law)
>>
>



-- 
Fernando Trebien
+55 (51) 9962-5409

"The speed of computer chips doubles every 18 months." (Moore's law)
"The speed of software halves every 18 months." (Gates' law)