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 <[email protected]>: > 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 > <[email protected]> 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 <[email protected]>: >> > >> > >> > >> > Em 21 de dezembro de 2013 13:38, Fernando Trebien >> > <[email protected]> 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 <[email protected]>: >> >> > >> >> > >> >> > >> >> > Em 20 de dezembro de 2013 13:28, ThUnDeRCeL >> >> > <[email protected]> >> >> > 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) _______________________________________________ Talk-br mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-br
