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

[Fernando Trebien]

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)