[Talk-br] Caminhos como "via" em restrições

Quinta Março 27 00:16:10 UTC 2014

Bem, certamente temos visões diferentes sobre o que é ótimo e o que é
bom. Para mim, é bom o bastante mapear sem se preocupar em criar uma
via separada para a faixa de conversão. Pouco melhor que o bom (longe
do ótimo ainda) é poder receber um aviso sonoro um pouco antes para
que o motorista se posicione do lado certo da faixa de conversão. Esse
"pouco melhor" poderia ser pior dependendo do uso e do usuário (ex.: a
velha questão das vias separadas durante a navegação visual envolvendo
pedestres). O ótimo é a aplicação ter assistência de faixa (lane
assistance), que aliás, não tem como funcionar corretamente se a faixa
for desenhada como uma linha adicional.

Mais um detalhe: se você criar uma linha adicional pra faixa de
conversão e mapear como eu estou imaginando (uma via saindo com pouca
inclinação em relação à via principal), seu GPS vai lhe dizer "vire
ligeiramente à esquerda" ou "ligeiramente à direita", mesmo que a
conversão envolva uma curva de 90° (a qual ele não vai anunciar). Isso
pode deixar o motorista confuso.

Não concordo que mapear com tags/relações e sem separar a faixa possa
ser considerado "precisamente errado" hoje. "Precisamente errado"
seria seu GPS lhe mandar fazer um retorno ilegal porque a proibição
foi mapeada usando a restrição citada no início dessa discussão. Na
maioria das aplicações acho que estaria tudo praticamente certo,
inclusive o cálculo das rotas, e haveria um aviso sonoro (geralmente
uns 400m~500m antes) lhe dizendo o que fazer. Se existir alguma
situação em que o GPS estaria mostrando algo errado/confuso, peço que
me aponte um exemplo.

2014-03-26 20:02 GMT-03:00 Paulo Carvalho <paulo.r.m.carvalho em gmail.com>:
> Na indústria do petróleo conheço dois provérbios, para pensar, caso não
> conheças:
> "O ótimo é inimigo do bom".
> "É preferível estar vagamente correto do que precisamente errado".
>
>
> Em 26 de março de 2014 19:39, Fernando Trebien <fernando.trebien em gmail.com>
> escreveu:
>>
>> Mas você concorda que isso é algo que os desenvolvedores das
>>
>> aplicações têm que fazer, e não os mapeadores - que já fazem a sua
>> parte decidindo quais tags usar e educando as pessoas para usá-las
>> corretamente?
>>
>> E não são nem os desenvolvedors do OSM em si (que é só uma base de
>> dados) e sim os desenvolvedores do mkgmap, do OSRM, etc. que são
>> projetos independentes, e com os quais qualquer um, incluindo você e
>> eu, podemos ajudar.
>>
>> 2014-03-26 19:34 GMT-03:00 Paulo Carvalho <paulo.r.m.carvalho em gmail.com>:
>> > Eu também acho que os aspectos práticos do uso dos mapas não pode ser
>> > simplesmente ignorado.
>> >
>> >
>> > Em 26 de março de 2014 18:25, <thundercel em gpsinfo.com.br> escreveu:
>> >>
>> >> Raffaello,
>> >> quando questionado nos fóruns sobre o melhor mapa respondo que o melhor
>> >> mapa é aquele que contém menos erros na região em que se mais trafega.
>> >>
>> >> Não existe mapa sem erros, existe mapa com menos erros e para correção
>> >> desses o provedor do mapa depende de colaborações.
>> >> Sem utilizadores devido a limitações poucas colaborações surgirão.
>> >>
>> >> Em que pese que um mapa digitalizado serve para inúmeras utilidades não
>> >> podemos e não devemos deixar de prioriza-las em nosso esforço.
>> >>
>> >> Desconsiderando a navegação visual por contato, não consigo, por
>> >> enquanto,
>> >> avaliar utilidade que não empregue a navegação assistida (GNSS e outros
>> >> sistemas de georreferenciamento). Por essa razão priorizo, por
>> >> enquanto, o
>> >> esforço em edição do mapa OSM para fins de navegação pelo GNSS.
>> >>
>> >> Visando o nivelamento do conhecimento, aproveito a oportunidade para
>> >> comentar que no Garmin existem duas funções suporte: Lane Assistante
>> >> (LA) e
>> >> Junction View (JCV).
>> >>
>> >> A função  JCV, comentada incorretamente aqui na lista como LA, pode ser
>> >> vista no vídeo em http://www.youtube.com/watch?v=HElDa-D7tT8
>> >> Essa função depende de arquivo extra e não é inserida no mapa.
>> >>
>> >> A função Lane Assistante (defendida por mim) pode ser vista em
>> >> http://www.youtube.com/watch?v=eT3nyBjsuJ8
>> >> Essa função depende de TAG inserida no mapa, entretanto desconheço se o
>> >> MKGMAP reconhece essa TAG.
>> >>
>> >> []s
>> >> Marcio
>> >>
>> >>
>> >> From: Raffaello Bruno Limongi Freire
>> >> Sent: Wednesday, March 26, 2014 5:23 PM
>> >> To: OpenStreetMap no Brasil
>> >> Subject: Re: [Talk-br] Caminhos como "via" em restrições
>> >>
>> >> Márcio,
>> >>
>> >> é por essas limitações que, apesar de eu já estar contribuindo mais com
>> >> o
>> >> OSM do que com o Tracksource, não pretendo deixar de usar o TRC nem tão
>> >> cedo, porque a minha prioridade é o roteamento.
>> >>
>> >> Raffaello Bruno
>> >>
>> >> > From: thundercel em gpsinfo.com.br
>> >> > To: talk-br em openstreetmap.org
>> >> > Date: Wed, 26 Mar 2014 13:43:23 -0300
>> >> > Subject: Re: [Talk-br] Caminhos como "via" em restrições
>> >> >
>> >> > Nelson,
>> >> > esse seu ultimo parágrafo nos leva muito a refletir sobre custo x
>> >> > benefício
>> >> > de se contornar alguma limitação atual.
>> >> >
>> >> > Tem uma frase (não sei a autoria) que bem diferencia eficiência de
>> >> > eficácia:
>> >> > "um piloto faz excelentes pousos (eficiente), mas no aeródromo
>> >> > errado"
>> >> > (ineficaz).
>> >> >
>> >> > Me agreguei ao OSM não faz muito tempo e confesso que a cada dia mais
>> >> > me
>> >> > simpatizo com os objetivos dele.
>> >> >
>> >> > Administrando sites de GPS há vários anos já havia lido alguns
>> >> > comentários
>> >> > sobre o OSM, mas muito vagos e inconsistentes. Confesso que nunca
>> >> > havia
>> >> > sido
>> >> > motivado a me aprofundar, naquela época, na pesquisa sobre o OSM.
>> >> >
>> >> > Talvez esteja aí o problema que afeta o OSM de forma geral citado por
>> >> > você.
>> >> > Falta gente para fazer as coisas, para mapear, corrigir problemas
>> >> > e/ou
>> >> > implementar algumas características.
>> >> >
>> >> > Na minha opinião, um produto para ser bem aceito no mercado deve
>> >> > atender
>> >> > as
>> >> > necessidades atuais desse mercado, mesmo que tenha de ser modificado
>> >> > em
>> >> > certas características que farão com que no futuro, quando as
>> >> > aplicações
>> >> > forem aperfeiçoadas, venha gerar trabalho.
>> >> >
>> >> > Confesso que nos sites que administro venho tentando motivar o
>> >> > pessoal
>> >> > para
>> >> > ingresso no OSM, mas está sendo difícil a mim, empregando uma visão
>> >> > futurista, argumentar contra as criticas. Infelizmente o pessoal, em
>> >> > especial o brasileiro, quer ver resultado prático de emprego do mapa
>> >> > OSM.
>> >> >
>> >> > []s
>> >> > Marcio
>> >>
>> >> _______________________________________________
>> >> Talk-br mailing list
>> >> Talk-br em openstreetmap.org
>> >> https://lists.openstreetmap.org/listinfo/talk-br
>> >>
>> >
>> >
>> > _______________________________________________
>> > Talk-br mailing list
>> > Talk-br em openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-br
>> >
>>
>>
>>
>> --
>> 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
>> Talk-br em openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-br
>
>
>
> _______________________________________________
> Talk-br mailing list
> Talk-br em openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>

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