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

[Fernando Trebien]

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.)

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.

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)