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

[John Packer]

Sou só eu que penso que o caso de restrição por via pode ser feito como
deveria ser feito, mesmo que tenha a falta de suporte pelas aplicações? (ao
invés de fazer algo que necessite de correção manual no futuro)


Em 26 de março de 2014 20:02, Paulo Carvalho
<paulo.r.m.carvalho em gmail.com>escreveu:

> 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
>
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.openstreetmap.org/pipermail/talk-br/attachments/20140326/962c7f91/attachment.html>