[Talk-br] [Cocar] Tutoriais e dicas de formatação OSM

thundercel em gpsinfo.com.br thundercel em gpsinfo.com.br
Segunda Janeiro 20 15:19:45 UTC 2014


Não desejaria entrar no mérito do Estádio de Maracanã ou do Jardim Zoológico 
no Rio de janeiro porque observando o mapa OSM identifico que não foram 
desenhadas vias internas da Quinta da Boa Vista. Do estádio nem tem como 
porque não existem. As poucas que ali existem são somente para serviço e 
privadas.

Quanto ao utilizador ser de qualquer forma conduzido ao destino e em lá 
chegando se virar para identificar qual a melhor maneira de ingressar na 
área não me simpatizo com essa ideia que no meu entender visa tão somente 
justificar uma deficiência do mapa.

O OSRM calcula uma rota para o Zoológico sim, mas conduz o utilizador para 
um ponto e uma via complicada para se dirigir ao Zoológico. Depois com calma 
irei mapear as vias de serviço da Quinta da Boa Vista e seus estacionamentos 
que não estão no mapa. Acredito que depois disso essas vias chegarão mais 
perto do Zoológico e o OSRM irá fazer o roteamento por elas.

Dentro da Quinta da Boa Vista, além do Zoológico, existe o Museu Histórico 
Nacional. Esse é mais complicado porque fica exatamente no centro da grande 
área da Quinta da Boa Vista.

Em que pese que no OSM não se deve criar um ponto com o mesmo nome da área 
criada sou de opinião que em determinadas situações  e para qualquer 
utilidade, dever-se-ia criar o ponto de melhor acesso aquela área.

-----Mensagem Original----- 
From: Fernando Trebien
Sent: Monday, January 20, 2014 11:41 AM
To: Cooperativa de Cartografia Digital Livre ; OSM talk-br
Subject: Re: [Cocar] Tutoriais e dicas de formatação OSM

Notem que isso é muito específico da aplicação, o OSRM funciona já que
não tem esse limite arbitrário de 30m: http://osrm.at/6az

(O OSRM também calcula uma rota da ponte Rio-Niterói até o Jardim
Zoológico do Rio.)

Essa não é necessariamente a melhor rota (provavelmente não), mas não
dá erro, e uma vez chegando até o estádio, a pessoa pode tentar "se
virar" pra achar a entrada. Claro, isso é meio ruim, já que a
tecnologia poderia ter sido mais esperta, mas não calcular rota
nenhuma seria ainda pior. Se o OSRM suportasse a tag
entrance=main/yes, a chance de dar certo seria bem maior, mas ainda
haveria uns casos em que a mesma situação ruim aconteceria.

O que o usuário poderia fazer numa situação dessas: o motorista vai
passar pelo estádio, e daí ele poderia ir convertendo à direita,
contornando o estádio, até achar uma entrada. Se eu fosse um usuário,
de 0 a 10 eu daria uma nota 7 pra um sistema que funcionasse assim, já
que me causaria alguns inconvenientes na chegada, mas calcula boa
parte da rota corretamente.

Ninguém mapeou as vias internas para carros do estádio do Maracanã
ainda (nem do Jardim Zoológico), então eu vou comparar com o Estádio
Beira-Rio aqui em Porto Alegre. Eis uma rota da minha casa até esse
estádio: http://osrm.at/6aA

Notem a especificidade da rota: o OSRM me diz pra passar do estádio,
fazer um retorno mais adiante, passar por ele de novo, e daí dobrar à
esquerda. A entrada está certa, e a rota é a ideal. Notem também que,
se não houvesse a via interna circundando o estádio, o OSRM
provavelmente me mandaria até a avenida Padre Cacique (no lado oposto
à entrada), que seria a via transitável mais próxima do ponto central
do estádio. As vias ao redor do estádio não são "artificiais" (quer
dizer, elas de fato existem e estão liberadas para o trânsito de quem
vem ao estádio), e eu não acrescentaria via nenhuma só pra fazer o
roteamento funcionar. Se elas não existissem, daí sim, essa idéia
falharia, mas notem que seria um caso bastante específico.

Alguns outros exemplos feitos da mesma forma e com bons resultados:
- da minha casa até o Jardim Botânico de Porto Alegre: http://osrm.at/6aC
- da minha casa até o BarraShoppingSul: http://osrm.at/6aD

Alguns exemplos (difíceis de achar) em que isso não funciona:
- da minha casa até o Porto Alegre Country Club (ele me manda pela
entrada de funcionários): http://osrm.at/6aE
- da minha casa até o Parque Marinha do Brasil (ele me manda pro
centro do parque ao invés de para um dos estacionamentos):
http://osrm.at/6aF

Como esses dois últimos casos seriam resolvidos: roteando para os
estacionamentos internos de cada destino. Num GPS, ao procurar por
"Porto Alegre Country Club", devem aparecer duas entradas: uma do tipo
"parque", a outra do tipo "estacionamento". Basta escolher o
estacionamento (algo que me parece um tanto natural) e tudo
funcionaria. Idem para o Parque Marinha.

2014/1/18 Paulo Henrique <phninkets em gmail.com>:
> Usando casos concretos de 02 pontos turísticos do Rio, já viram onde ficam
> os POIs do Maracanã e do Zoológico??
>
> Não achei esses POIs no OSM do Rio então deduzo que o conversor do
> "http://mapas.alternativaslibres.es" os esteja gerando com base nos
> polígonos desenhados para esses dois lugares, e assim eles ficam no meio
> desses polígonos e BEMMM longe de qualquer via roteável.
>
> Simulando no Mapsource uma rota entre a Ponte Rio-Niterói e o POI do
> Zoológico que é gerado por esse mapa, só consigo uma rota aérea.
>
> Para o Maracanã (cujo POI também fica distante de vias roteáveis) uma rota 
> é
> gerada, mas como não conheço o local, não sei se é para o local certo onde
> um turista deveria de ser levado de carro...
>
>
> PH
>
>
>
>
>
>
> Em 18 de janeiro de 2014 16:25, <thundercel em gpsinfo.com.br> escreveu:
>
>> Aí que vem o que ainda não consegui atingir.
>> Qual seria a finalidade de se mapear uma área que não tem entradas ou
>> pontos de acesso a sua borda por meio de vias roteáveis, seja para 
>> veículos,
>> pedestres, cadeirantes, barcos, etc?
>> Nem estou me referindo a GPS. Estou me referindo a qualquer utilidade que
>> forneça roteamento.
>> Compreendo eu que para se extrair roteamento de um mapa, seja para o
>> emprego que for, terrestre, marítimo, fluvial ou aéreo, naquele mapa deve
>> existir via roteavel próxima a área desenhada, caso contrário não se 
>> roteia
>> para um waypoint existente no centro daquela área.
>> Qualquer waypoint longe de via roteavel impossibilita a função 
>> roteamento.
>> Inclusão de um ponto de entrada seria uma solução para áreas que tem
>> entrada, mas para aquelas áreas que não tem entrada essa solução não é
>> possível.
>> Não sou programador e por isso fica difícil deduzir como estabelecer uma
>> logica de posicionamento de um waypoint existente no centroide da área
>> adequando-o ao requisito de roteamento daquele utilidade.
>> Até onde sei navegadores não roteiam para polígono e sim para um ponto
>> estabelecido no polígono e próximo de uma via roteavel.
>>
>> From: Fernando Trebien
>> Sent: Saturday, January 18, 2014 3:37 PM
>> To: Cooperativa de Cartografia Digital Livre
>> Subject: Re: [Cocar] Tutoriais e dicas de formatação OSM
>>
>>
>> Certo. Assim, no OSM você mapearia apenas a área e (se estiver disposto)
>> marcaria as entradas. Os waypoints do GPS são gerados pelo conversor 
>> (cuja
>> responsabilidade é tornar dados de um sistema compatíveis com outro
>> sistema), então o conversor seria responsável por gerar waypoints 
>> próximos a
>> vias roteáveis.  Ele poderia fazer isso calculando a projeção:
>> - da entrada da área, se estiver mapeada; ou
>> - do centróide da área, caso contrário
>>
>> A projeção geométrica é que garante a proximidade do waypoint à via.
>>
>> On Jan 18, 2014 2:57 PM, <thundercel em gpsinfo.com.br> wrote:
>>>
>>> Aí que está o problema.
>>> O centroide em uma grande área pode, por vezes, ficar distante de de via
>>> roteavel para determinada utilidade.
>>> Para GPS sabemos que a tolerância é de 30m. Para outras utilidades não
>>> sabemos e vai depender das características do algoritmo de roteamento 
>>> delas.
>>>
>>> From: Fernando Trebien
>>> Sent: Saturday, January 18, 2014 1:03 PM
>>> To: Cooperativa de Cartografia Digital Livre
>>> Subject: Re: [Cocar] Tutoriais e dicas de formatação OSM
>>>
>>>
>>> Daí daria pra projetar o centróide. É menos confiável que o uso da
>>> entrada mas pelo menos se obteria "algum roteamento" ao invés de um erro 
>>> do
>>> tipo "rota não encontrada".
>>>
>>> On Jan 18, 2014 11:30 AM, <thundercel em gpsinfo.com.br> wrote:
>>>>
>>>> Fernando,
>>>> não é um limite arbitrário de 30m do navegador GPS. É uma situação de
>>>> definição de um waypoint para navegação, qualquer tipo de navegação e 
>>>> para
>>>> qualquer utilidade.
>>>>
>>>> No OSM, quando o waypoint é representado por área e não ponto, o
>>>> renderizador vai extrair um waypoint para aquela área nos eu centro
>>>> geométrico e esse ponto nem sempre estará próximo a uma via empregada 
>>>> para
>>>> navegação, seja de pedestre, cadeirante, gps, etc.
>>>>
>>>> Projetar o nó da entrada principal, quando houver (bem citado por você)
>>>> resolveria o problema, mas quando não houver entrada principal?
>>>>
>>>>
>>>>
>>>> From: Fernando Trebien
>>>> Sent: Saturday, January 18, 2014 10:13 AM
>>>> To: Cooperativa de Cartografia Digital Livre
>>>> Subject: Re: [Cocar] Tutoriais e dicas de formatação OSM
>>>>
>>>>
>>>> Uma projeção talvez resolveria. É algo que o seu GPS poderia fazer se
>>>> não tivesse o limite arbitrário de 30m, mas que pode então ser feita 
>>>> pelo
>>>> conversor.
>>>>
>>>> Melhor do que projetar o centróide seria projetar o nó da entrada
>>>> principal, quando houver.
>>>>
>>>> Cálculo de centroide? Não entendi. Gerar um programa que calcule o
>>>> centro geométrico de uma área não deve ser difícil para quem domina
>>>> programação.
>>>>
>>>> Nosso problema é que o POI a ser gerado pelo polígono não deve ficar no
>>>> centro geométrico dele e sim próximo a uma via roteavel.
>>>>
>>>> Deduzo que o calculo de centroide não calcule isso.
>>>>
>>>> From: Paulo Carvalho
>>>> Sent: Friday, January 17, 2014 6:58 PM
>>>> To: Cooperativa de Cartografia Digital Livre
>>>> Subject: Re: [Cocar] Tutoriais e dicas de formatação OSM
>>>>
>>>> Cálculo do centroide.
>>>>
>>>>
>>>> Em 17 de janeiro de 2014 08:35, <thundercel em gpsinfo.com.br> escreveu:
>>>>>
>>>>> Infelizmente ainda não aprendi a compilar para lhe ajudar, mas essa
>>>>> situação foi comentada recentemente por mim ao Paulo Carvalho. Não sei 
>>>>> como
>>>>> o sistema pode gerar um POI extraindo de um polígono,
>>>>>
>>>>> []s
>>>>> Marcio
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> From: Wesley Martins
>>>>> Sent: Friday, January 17, 2014 7:57 AM
>>>>> To: Cooperativa de Cartografia Digital Livre
>>>>> Subject: Re: [Cocar] Tutoriais e dicas de formatação OSM
>>>>>
>>>>> Essa semana fiz alguns testes com o --add-pois-to-area e
>>>>> --pois-to-areas-placement e não obtive resultado satisfatório. :S
>>>>>
>>>>> Não consegui fazer o arquivo .img gerar o POIs de mercado, posto de
>>>>> gasolina, prédio... Ele gera os polígonos, mas não o POI e com isso 
>>>>> não é
>>>>> possível fazer a busca.
>>>>>
>>>>> Alguém já fez ou pode fazer um teste de compilação com essas duas
>>>>> opções?
>>>>>
>>>>> Eu usei:
>>>>>
>>>>> $ java -ea -Xmx7250M -jar mkgmap.jar entrada.osm --add-pois-to-areas
>>>>> --pois-to-areas-placement --gmapsupp --route --latin1 --index
>>>>> --preserve-element-order --remove-short-arcs --max-jobs=1 --keep-going
>>>>> Time started: Fri Jan 17 07:50:23 BRST 2014
>>>>> Time finished: Fri Jan 17 07:50:31 BRST 2014
>>>>> Total time taken: 7576ms
>>>>>
>>>>> Abraço,
>>>>>
>>>>> Wesley
>>>>>
>>>>>
>>>>> 2014/1/15 Paulo Carvalho <paulo.r.m.carvalho em gmail.com>
>>>>>>
>>>>>> Fiz mapeamento lógico no Norte Shopping (Tracksource) assim,
>>>>>> dependendo de onde você venha ou para onde você vá depois de sair do
>>>>>> shopping, o roteamento te leva à melhor saída.
>>>>>>
>>>>>>
>>>>>> Em 15 de janeiro de 2014 00:03, Fernando Trebien
>>>>>> <fernando.trebien em gmail.com> escreveu:
>>>>>>
>>>>>>> Acho que concordamos sim, e concordo que no caso específico de
>>>>>>> estacionamentos não afeta outros tipos de tráfego.
>>>>>>>
>>>>>>> Um detalhe só: se as vias internas estiverem mapeadas, acho muito
>>>>>>> difícil que o ponto central fique a mais de 30m de alguma delas. Mas 
>>>>>>> é
>>>>>>> possível, claro. Acho mais possível em estacionamentos cobertos 
>>>>>>> (onde
>>>>>>> dificilmente se mapearia o interior já que raramente se tem imagem 
>>>>>>> ou
>>>>>>> tracklog); nesses casos, eu andei fazendo (e sugiro, na falta de 
>>>>>>> opções
>>>>>>> melhores) um mapeamento "lógico" (sem exatidão geométrica) que 
>>>>>>> conecta
>>>>>>> entradas a saídas passando pelo centro da área - é menos pior do que 
>>>>>>> o
>>>>>>> roteamento falhar, e pode-se pedir pra alguém melhorar a forma das 
>>>>>>> vias
>>>>>>> colocando-se uma tag "fixme" nessas ligações "virtuais".
>>>>>>>
>>>>>>> On Jan 14, 2014 10:38 PM, "Wesley Martins" 
>>>>>>> <wesleygmartins em gmail.com>
>>>>>>> wrote:
>>>>>>> >
>>>>>>> > Fernando,
>>>>>>> >
>>>>>>> > O que eu disse era para o caso específico de áreas de
>>>>>>> > estacionamento, e o que estava me referindo era que creio ser bem 
>>>>>>> > mais
>>>>>>> > vantajoso ter controle de onde vai ficar o POI do estacionamento, 
>>>>>>> > depois de
>>>>>>> > convertido, e, para isso, usar a tag entrance=yes, do que deixar o 
>>>>>>> > mkgmap
>>>>>>> > escolher um ponto qualquer no centro do polígono (que pode ficar 
>>>>>>> > ou não a
>>>>>>> > mais de 30 metros de uma via). E por se tratar de estacionamento, 
>>>>>>> > imagino
>>>>>>> > que não vá atrapalhar cadeirantes, pessoas a pé, bicicletas, etc.
>>>>>>> >
>>>>>>> > Pelo que entendi, dissemos a mesma coisa, vc tbm concorda que o
>>>>>>> > ideal é colocar a tag entrance= em "algum" nó do polígono..
>>>>>>> >
>>>>>>> > Caso eu tenha entendido errado, por favor me corrija.
>>>>>>> >
>>>>>>> > Abraço,
>>>>>>> >
>>>>>>> > Wesley
>>>>>>> >
>>>>>>> >
>>>>>>> > 2014/1/14 Fernando Trebien <fernando.trebien em gmail.com>
>>>>>>> >>
>>>>>>> >> Wesley, um dos problemas de mapear um ponto onde seria "melhor
>>>>>>> >> para o
>>>>>>> >> carro parar" é que frequentemente esse ponto estaria num lugar
>>>>>>> >> diferente se a intenção fosse mapear para outras formas de
>>>>>>> >> transporte
>>>>>>> >> (bicicleta, pedestre, cadeirante, etc.). Talvez no futuro se crie
>>>>>>> >> uma
>>>>>>> >> relação para expressar essas coisas, mas no momento, o melhor
>>>>>>> >> mesmo é
>>>>>>> >> o nó com a tag entrance= (ainda mais se existe um conversor que
>>>>>>> >> suporta isso). São bem raros os casos em que isso leva a um
>>>>>>> >> roteamento
>>>>>>> >> errado, e caso leve, acho válido levar o caso à lista talk-br pra
>>>>>>> >> que
>>>>>>> >> as pessoas possam tentar ajudar. Levar mais pessoas a pensar 
>>>>>>> >> sobre
>>>>>>> >> isso pode levar alguém a escrever uma proposta pra comunidade
>>>>>>> >> internacional e assim finalmente abrir caminho pra mapear aquilo
>>>>>>> >> que
>>>>>>> >> vocês querem.
>>>>>>> >>
>>>>>>> >> 2014/1/14 Wesley Martins <wesleygmartins em gmail.com>:
>>>>>>> >> > Márcio,
>>>>>>> >> >
>>>>>>> >> > Mesmo nesses casos que tenham os "corredores de estacionamento"
>>>>>>> >> > mapeados,
>>>>>>> >> > penso ser interessante forçarmos o POI para o mais próximo das
>>>>>>> >> > vias mais
>>>>>>> >> > importantes. Só por excesso de zelo mesmo.
>>>>>>> >> >
>>>>>>> >> > Prefiro ter controle de aonde o POI vai ser gerado, do que
>>>>>>> >> > deixar ele ser
>>>>>>> >> > gerado automaticamente por um algoritmo que ainda tem falhas
>>>>>>> >> > quanto a
>>>>>>> >> > geração de POIs qdo o polígono for irregular.
>>>>>>> >> >
>>>>>>> >> > Pelo que lembro ter lido, ainda não existe crítica no mkgmap
>>>>>>> >> > para verificar
>>>>>>> >> > se o POI gerado está dentro do limite da área, ou não.
>>>>>>> >> >
>>>>>>> >> > Sei que é para os casos mais extremos, mas pode ocorrer, e
>>>>>>> >> > nesses, com
>>>>>>> >> > certeza vc colocaria a entrada.
>>>>>>> >> >
>>>>>>> >> > Existe uma maneira "simples" de saber se um ponto está dentro 
>>>>>>> >> > ou
>>>>>>> >> > não de um
>>>>>>> >> > polígono qualquer. É "só" traçar uma reta que parta desse ponto
>>>>>>> >> > e atravesse
>>>>>>> >> > qualquer lado. Se o número de interseções for ímpar, então ele
>>>>>>> >> > está contido
>>>>>>> >> > no polígono, mas caso contrário, for par, ele está fora.
>>>>>>> >> > Só que tem q cuidar com alguns detalhes importantes: O ponto 
>>>>>>> >> > nao
>>>>>>> >> > pode estar
>>>>>>> >> > contido na borda do polígono; A reta de verificação não pode
>>>>>>> >> > passar por
>>>>>>> >> > nenhum vértice e nem ser coincidente com os lados.
>>>>>>> >> >
>>>>>>> >> > Abraço,
>>>>>>> >> >
>>>>>>> >> > Wesley
>>>>>>> >> >
>>>>>>> >> > Sent from my iPhone
>>>>>>> >> >
>>>>>>> >> > On 14/01/2014, at 08:45, <thundercel em gpsinfo.com.br> wrote:
>>>>>>> >> >
>>>>>>> >> > Wesley,
>>>>>>> >> > também imagino dessa forma, de se colocar entrada próxima a uma
>>>>>>> >> > via roteavel
>>>>>>> >> > quando o polígono for de grande área.
>>>>>>> >> >
>>>>>>> >> > Havia eu observado essa situação de grande área quando estava
>>>>>>> >> > desenhando
>>>>>>> >> > polígonos de estacionamento, entretanto esses, se aplicado as
>>>>>>> >> > vias
>>>>>>> >> > “corredores de estacionamento”, não vejo necessidade de
>>>>>>> >> > aplicar-se a
>>>>>>> >> > entrada, a não ser que a grande área de estacionamento tenha
>>>>>>> >> > mais de uma
>>>>>>> >> > entrada.
>>>>>>> >> >
>>>>>>> >> > []s
>>>>>>> >> > Marcio
>>>>>>> >> >
>>>>>>> >> > From: Wesley Martins
>>>>>>> >> > Sent: Tuesday, January 14, 2014 8:38 AM
>>>>>>> >> > To: Cooperativa de Cartografia Digital Livre
>>>>>>> >> > Subject: Re: [Cocar] Tutoriais e dicas de formatação OSM
>>>>>>> >> >
>>>>>>> >> > Anor,
>>>>>>> >> >
>>>>>>> >> > Para essa conversão do polígono em ponto na hora de fazer a
>>>>>>> >> > compilação,
>>>>>>> >> > existe, como já comentado pelo PC, a opção --add-pois-to-areas,
>>>>>>> >> > que gera o
>>>>>>> >> > POI a partir do polígono, com duas "regras" na hora de fazer a
>>>>>>> >> > conversão.
>>>>>>> >> > Começando de trás para frente, a segunda regra na hora de fazer
>>>>>>> >> > a conversão
>>>>>>> >> > é colocar o ponto no centro do polígono. A primeira, que ainda
>>>>>>> >> > não estudei,
>>>>>>> >> > é a definição desse ponto através do 
>>>>>>> >> > "--pois-to-areas-placement"
>>>>>>> >> > que usa a
>>>>>>> >> > tag entrance= para determinar a posição do ponto.
>>>>>>> >> > Eu preciso estudar mais OSM pra entender bem essas tags. Mas é
>>>>>>> >> > mta coisa e
>>>>>>> >> > falta tempo rsrsrs mas vou verificar essa tal tag entrance pra
>>>>>>> >> > saber como se
>>>>>>> >> > comporta essa conversão.
>>>>>>> >> > Imagino que deveríamos por essa tag em todos as áreas usadas
>>>>>>> >> > para a correta
>>>>>>> >> > procura de pontos no GPS. Assim, penso eu, conseguiríamos
>>>>>>> >> > determinar a
>>>>>>> >> > localização exata do ponto. Essa semana eu testo.
>>>>>>> >> > --pois-to-areas-placement[=taglist] A semicolon separated list
>>>>>>> >> > of tag=value
>>>>>>> >> > definitions. A POI is placed at the first node of the polygon
>>>>>>> >> > tagged with
>>>>>>> >> > the first tag/value pair. If none of the nodes are tagged with
>>>>>>> >> > the first
>>>>>>> >> > tag-value pair the first node tagged with the second tag-value
>>>>>>> >> > pair is used
>>>>>>> >> > and so on. If none of the tag-value pairs matches or the 
>>>>>>> >> > taglist
>>>>>>> >> > is empty
>>>>>>> >> > the center of the polygon is used. It is possible to define
>>>>>>> >> > wildcards for
>>>>>>> >> > tag values like entrance=*. Default:
>>>>>>> >> > entrance=main;entrance=yes;building=entrance
>>>>>>> >> > Abraço,
>>>>>>> >> >
>>>>>>> >> > Wesley
>>>>>>> >>
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> --
>>>>>>> >> 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) 




Mais detalhes sobre a lista de discussão Talk-br