Em "Acredito que os programas de mapeamento" quis dizer "Acredito que os programas de roteamento". :P
2013/8/8 Fernando Trebien <[email protected]>: > Teoricamente, você pode mapear as áreas das ruas (só não é praticado, > provavelmente porque não há muita utilidade e porque é muito > trabalhoso). O Mapnik parece considerar essa possibilidade para as > vias "pedestrian" (que servem também para a área de "plazas" ao > combinar com a tag "area"). Um exemplo aqui em Porto Alegre, com áreas > "pedestrian" e vias "pedestrian" combinadas: > http://www.openstreetmap.org/?box=yes&bbox=-51.2281087%2C-30.0284035%2C-51.2268006%2C-30.0277769#map=18/-30.02809/-51.22745 > > Acho que o mesmo vale para as hidrovias, onde (forçando um pouco a > idéia) o contorno da água representaria o contorno da via e a linha > que passa dentro da água representa o percurso típico do barco. > > (Não cheguei a testar a combinação de "area=yes" e > "highway=residential" pra ver se o Mapnik se comportaria da mesma > forma.) > > (Acredito que os programas de mapeamento também esperam esse estilo de > mapeamento, combinando via e área, pois nenhum traça rotas dentro de > áreas supostamente navegáveis.) > > Conclusão: melhor mapear as áreas (das praças ou de qualquer outra > coisa, como edifícios) sem colá-las nas ruas. Além da dificuldade de > selecionar no editor, dá um trabalho enorme mudar a forma de > mapeamento quando outros detalhes são acrescentados (calçadas, > ciclovias, etc.). Se você estivesse mapeando a área da praça e a área > da via (além da linha do percurso, que é o que mapeamos hoje), as duas > áreas poderiam ser coladas uma na outra e isso seria exato (mas daí > talvez até seria melhor usar multipolígonos). > > 2013/8/8 Nelson A. de Oliveira <[email protected]>: >> 2013/8/8 Vitor George <[email protected]>: >>> Se a rua é o que delimita onde a praça termina, porque não mapear assim? >> >> O problema inicial é que a rua (que também é uma área na verdade) é >> representada como linha, enquanto todas as outras áreas (praças, etc) >> são de fato representadas como áreas. >> Se for ver o que está "errado", é área da rua que não está >> representada de forma correta (e não a praça). Grudando a praça na rua >> você acaba deixando a praça errada (ver abaixo). >> >>> Eu não sei se existe alguma recomendação contraria a isso, mas quando mapeei >>> de outra maneira ficou um "vácuo" entre a área e a rua, e não me pareceu >>> correto. >> >> Aí cai naquilo de mapear para o renderizador. >> A praça possui um contorno determinado. Se você grudar esse contorno >> nas ruas ao redor você vai estar representando algo que é diferente da >> realidade (vai ficar bonito no mapa, mas não vai indicar o tamanho, >> área, contorno ou posição real da praça). >> >> Não me parece certo grudar as áreas para contornar a limitação da >> representação da rua (uma linha) >> >>> Existem um recomendação fechada sobre esta questão? >> >> Vamos achar tanto quem diz que é certo quanto quem diz que é errado :-) >> >> Eu digo para não estimular a grudar as áreas por dois motivos: as >> pessoas geralmente criam vias sobrepostas (ao invés de utilizar >> multipolígonos) e também porque que dá um trabalho bem maior de >> corrigir algo que envolva esses caminhos grudados. >> >> Talvez seja o caso de apenas recomendar aos novos usuários (até que um >> dia eles tenham uma compreensão melhor das coisas) que evitem grudar >> áreas nos caminhos (e não afirmar categoricamente "nunca grudar >> áreas"). >> >> _______________________________________________ >> Talk-br mailing list >> [email protected] >> http://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) -- 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] http://lists.openstreetmap.org/listinfo/talk-br
