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 <[email protected]>:
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, <[email protected]> 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 oupontos 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 deveexistir via roteavel próxima a área desenhada, caso contrário não se roteiapara 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 (cujaresponsabilidade é tornar dados de um sistema compatíveis com outrosistema), então o conversor seria responsável por gerar waypoints próximos avias 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, <[email protected]> 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ãosabemos 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 daentrada mas pelo menos se obteria "algum roteamento" ao invés de um erro dotipo "rota não encontrada". On Jan 18, 2014 11:30 AM, <[email protected]> wrote:Fernando, não é um limite arbitrário de 30m do navegador GPS. É uma situação dedefinição de um waypoint para navegação, qualquer tipo de navegação e paraqualquer utilidade. No OSM, quando o waypoint é representado por área e não ponto, o renderizador vai extrair um waypoint para aquela área nos eu centrogeométrico e esse ponto nem sempre estará próximo a uma via empregada paranavegaçã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 senão tivesse o limite arbitrário de 30m, mas que pode então ser feita peloconversor. 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, <[email protected]> escreveu:Infelizmente ainda não aprendi a compilar para lhe ajudar, mas essasituação foi comentada recentemente por mim ao Paulo Carvalho. Não sei comoo 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 degasolina, 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 <[email protected]>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 <[email protected]> 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 muitodifí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 viascolocando-se uma tag "fixme" nessas ligações "virtuais".On Jan 14, 2014 10:38 PM, "Wesley Martins" <[email protected]>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 <[email protected]> >> >> 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 <[email protected]>: >> > 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, <[email protected]> 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)
_______________________________________________ Talk-br mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-br
