Re: [Talk-br] BR-020 DF
Em qua., 16 de dez. de 2020 às 17:58, Lucas Piauilino escreveu: > > Olhando para os entrecruzamentos agora só queria saber exatamente o erro no > 15 e em que lugar da imagem,(porque é meio difícil identificar só usando a > localização) Assim: https://www.openstreetmap.org/directions?engine=fossgis_osrm_car&route=-15.67540%2C-47.82382%3B-15.67578%2C-47.82366#map=19/-15.67597/-47.82428 On Wed, Dec 16, 2020 at 6:11 PM Lucas Piauilino wrote: > > Acho que os "problemas" só começam a aparecer mesmo depois(no sentido > Formosa) desse viaduto em -15.66415, -47.80505 pq a via marginal(que resolve > muitos desses problemas de interseções urbanas) da BR-020 acaba aí. Queria > que você visse se esse trecho entre -15.66415, -47.80505(o referido viaduto) > e -15.1, -47.93888(logo antes do primeiro semáforo da EPIA no sentido São > Paulo), que pega um pedaço da DF-003(BR-450), a EPIA, tem outros problemas > além do 15 já citado anteriormente. Me parece que a sua ideia seria continuar a malha de autoestradas desde a BR-070 do SIA até Sobradinho. Semáforo 35. -15.7784914 -47.9389004 Entrecruzamentos: 36. 150m -15.7415751 -47.9180892 37. 175m -15.7332144 -47.9123935 38. 175m -15.730825 -47.9109009 39. 180m -15.6942112 -47.8711022 40. 240m -15.7260719 -47.9084373 41. 260m -15.722984 -47.9060179 42. 300m -15.7473307 -47.9216726 43. 380m -15.7440289 -47.9196435 Curiosamente, a administração local parece ter resolvido um dos entrecruzamentos (-15.7492268 -47.9228233) construindo barreiras à transposição de faixas. Casos assim (só achei 1 nesse trecho) não contam como entrecruzamento porque os conflitos são eliminados pelas barreiras. >> Em qua., 16 de dez. de 2020 às 12:47, Fernando Trebien >> escreveu: >>> >>> On Wed, Dec 16, 2020 at 11:45 AM Lucas Piauilino >>> wrote: >>> > >>> > Tava falando do 4 agora >>> > >>> > Em qua., 16 de dez. de 2020 às 11:41, Lucas Piauilino >>> > escreveu: >>> >> >>> >> Acho que a estrada agrícola não pode ser acessada a partir do retorno, >>> >> pelo menos oficialmente. >>> >> >>> >> Em qua., 16 de dez. de 2020 às 11:22, Lucas Piauilino >>> >> escreveu: >>> >>> >>> >>> Acho que no 2 a distância entre as entradas que aparecem nessa imagem e >>> >>> o retorno são curtas demais para que veículos que saiam dessas vias >>> >>> possam utilizá-lo, sendo que ele possui faixa de desaceleração.Esse >>> >>> retorno não foi projetado para que os veículos dessas vias pudessem >>> >>> cruzar a rodovia(isso atrapalharia quem está na faixa de desaceleração >>> >>> do retorno). >>> >>> Então, essas situações são típicas de rodovias que não são realmente >>> autoestradas (motorway) na grande maioria dos países. Em geral, >>> autoestradas privilegiam o acesso controlado e o isolamento entre a >>> rodovia e o entorno com o objetivo de maximizar a fluidez e a >>> segurança. >>> >>> -- >>> Fernando Trebien >>> >>> ___ >>> Talk-br mailing list >>> Talk-br@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/talk-br > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] BR-020 DF
On Wed, Dec 16, 2020 at 11:45 AM Lucas Piauilino wrote: > > Tava falando do 4 agora > > Em qua., 16 de dez. de 2020 às 11:41, Lucas Piauilino > escreveu: >> >> Acho que a estrada agrícola não pode ser acessada a partir do retorno, pelo >> menos oficialmente. >> >> Em qua., 16 de dez. de 2020 às 11:22, Lucas Piauilino >> escreveu: >>> >>> Acho que no 2 a distância entre as entradas que aparecem nessa imagem e o >>> retorno são curtas demais para que veículos que saiam dessas vias possam >>> utilizá-lo, sendo que ele possui faixa de desaceleração.Esse retorno não >>> foi projetado para que os veículos dessas vias pudessem cruzar a >>> rodovia(isso atrapalharia quem está na faixa de desaceleração do retorno). Então, essas situações são típicas de rodovias que não são realmente autoestradas (motorway) na grande maioria dos países. Em geral, autoestradas privilegiam o acesso controlado e o isolamento entre a rodovia e o entorno com o objetivo de maximizar a fluidez e a segurança. -- Fernando Trebien ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] BR-020 DF
On Wed, Dec 16, 2020 at 12:15 AM Lucas Piauilino wrote: > > De qualquer forma, se vc ver essa imagem um pouco antes do retorno dá pra ver > que tem uma faixa de desaceleração > > https://www.mapillary.com/map/im/x-lNonTDdf4fpXW_21vfyA > > E tem como ver a data das imagens de satélite que o OSM usa? No iD (editor do site), você dá Ctrl+Shift+B e no pop-up Fundo você clica em Mostrar mosaico. Mas aparentemente esse recurso está quebrado, era pra funcionar. [1] No JOSM, você ativa a imagem do Bing (a mesma usada no editor iD do site) em Imagery > Bing aerial imagery, depois clica com o botão direito na quadrícula (tile) cuja data você quer saber e escolhe Bing aerial imagery > Show tile info e consulta a propriedade Metadata Capture Date. As quadrículas no ponto #1 são de 13/05/2018. No ponto #3 são de 30/05/2010. Pelo visto esse retorno foi fechado um pouco antes de 2015. [2] [1] https://github.com/openstreetmap/iD/issues/2492 [2] https://www.mapillary.com/map/im/dHfrqOwNjcCLfwuz-IALXQ > Em ter., 15 de dez. de 2020 às 22:48, Fernando Trebien > escreveu: >> >> On Tue, Dec 15, 2020 at 11:32 PM Lucas Piauilino >> wrote: >> > >> > acho que o 1 nem existe mais, deve ter sido um retorno antigo, se for esse >> > mesmo que vc tá falando... >> >> Existia 6 meses atrás. >> >> [1] https://www.mapillary.com/map/im/Y26U9uwKoo_m_oR55lCfhQ >> >> > Em ter., 15 de dez. de 2020 às 19:53, Fernando Trebien >> > escreveu: >> >> >> >> Oi Lucas. Acredito que não, mas depende em parte de uma discussão que >> >> ainda não tivemos em profundidade No Telegram, essa discussão parou >> >> ali por junho, com alguns colegas defendendo regras mais flexíveis e >> >> outros defendendo regras menos flexíveis. [1] >> >> >> >> Olhei essa via nas imagens do Bing e do ESRI e encontrei as seguintes >> >> configurações que me dizem que ela não seria auto-estrada (motorway), >> >> apenas troncal. Você pode jogar a coordenada na busca do site para >> >> examinar cada situação: >> >> >> >> Cruzamentos em nível: >> >> 1. -15.6520247 -47.7776521 >> >> 2. -15.6499124 -47.7731895 * >> >> 3. -15.5948919 -47.6574683 * >> >> 4. -15.5782214 -47.3855715 >> >> 5. -15.5806927 -47.3401845 (final) >> >> >> >> Entrecruzamentos curtos: >> >> 6. 15m -15.6020105 -47.682315 >> >> 7. 20m -15.6017609 -47.6823559 >> >> 8. 50m -15.5974405 -47.6106939 >> >> 9. 70m -15.5840436 -47.3525226 >> >> 10. 70m -15.5838163 -47.3516563 >> >> 11. 75m -15.6088899 -47.6950434 * >> >> 12. 75m -15.5953982 -47.6511008 * >> >> 13. 80m -15.6001479 -47.6790802 >> >> 14. 90m -15.624929 -47.723507 >> >> 15. 130m -15.6761155 -47.8245223 >> >> 16. 130m -15.5797005 -47.4979091 >> >> 17. 130m -15.5796592 -47.4963373 >> >> 18. 150m -15.6634353 -47.8025477 >> >> 19. 150m -15.6159835 -47.7074204 >> >> 20. 150m -15.580039 -47.4031547 >> >> 21. 150m -15.5798865 -47.4017277 >> >> 22. 140m -15.6447538 -47.7621187 >> >> 23. 180m -15.5988265 -47.6764369 >> >> 24. 180m -15.5976381 -47.6742536 >> >> 25. 180m -15.5816693 -47.541782 * >> >> 26. 180m -15.5784423 -47.387327 >> >> 27. 200m -15.5819612 -47.4307922 >> >> 28. 230m -15.6368767 -47.7452838 >> >> 29. 240m -15.611242 -47.6989353 >> >> 30. 250m -15.6546956 -47.7846587 >> >> 31. 250m -15.6535979 -47.7811262 >> >> 32. 260m -15.581708 -47.5553486 >> >> 33. 270m -15.613523 -47.7033153 >> >> 34. 350m -15.6417687 -47.7561387 >> >> >> >> * Alguma das vias envolvidas ainda não foi mapeada e só é visível na >> >> imagem de satélite >> >> >> >> Da mesma forma, está pendente uma revisão dessas situações nas vias >> >> que estão mapeadas como motorway hoje. Seria necessário fazer um >> >> levantamento de cada uma dessas situações e mostrar como ficaria o >> >> resultado completo com cada regra para que fosse mais fácil chegar a >> >> um consenso. >> >> >> >> [1] https://wiki.openstreetmap.org/wiki/Talk:Pt:Tag:highway%3Dmotorway >> >> >> >> On Tue, Dec 15, 2020 at 3:37 PM Lucas Piauilino >> >> wrote: >> >> > >> >> > Será que a BR-020, do seu início até a divisa entre o Distrito Federal >> >> > e Goiás, deve ser considerada como =motorway, já que não poss
Re: [Talk-br] BR-020 DF
On Tue, Dec 15, 2020 at 11:43 PM Lucas Piauilino wrote: > > no 3 tem um caminho que dá numa ciclovia(acho que não é usada por carros) e > um retorno que eu acho que foi eliminado(se vc olhar pelo maxar) Abre o seu editor ali pra ver a imagem de satélite do Bing. Mas o ideal seria você ir pessoalmente até ali fazer um survey (levantamento em campo) pra tirar a dúvida. > Em ter., 15 de dez. de 2020 às 22:30, Lucas Piauilino > escreveu: >> >> acho que o 1 nem existe mais, deve ter sido um retorno antigo, se for esse >> mesmo que vc tá falando... >> >> Em ter., 15 de dez. de 2020 às 19:53, Fernando Trebien >> escreveu: >>> >>> Oi Lucas. Acredito que não, mas depende em parte de uma discussão que >>> ainda não tivemos em profundidade No Telegram, essa discussão parou >>> ali por junho, com alguns colegas defendendo regras mais flexíveis e >>> outros defendendo regras menos flexíveis. [1] >>> >>> Olhei essa via nas imagens do Bing e do ESRI e encontrei as seguintes >>> configurações que me dizem que ela não seria auto-estrada (motorway), >>> apenas troncal. Você pode jogar a coordenada na busca do site para >>> examinar cada situação: >>> >>> Cruzamentos em nível: >>> 1. -15.6520247 -47.7776521 >>> 2. -15.6499124 -47.7731895 * >>> 3. -15.5948919 -47.6574683 * >>> 4. -15.5782214 -47.3855715 >>> 5. -15.5806927 -47.3401845 (final) >>> >>> Entrecruzamentos curtos: >>> 6. 15m -15.6020105 -47.682315 >>> 7. 20m -15.6017609 -47.6823559 >>> 8. 50m -15.5974405 -47.6106939 >>> 9. 70m -15.5840436 -47.3525226 >>> 10. 70m -15.5838163 -47.3516563 >>> 11. 75m -15.6088899 -47.6950434 * >>> 12. 75m -15.5953982 -47.6511008 * >>> 13. 80m -15.6001479 -47.6790802 >>> 14. 90m -15.624929 -47.723507 >>> 15. 130m -15.6761155 -47.8245223 >>> 16. 130m -15.5797005 -47.4979091 >>> 17. 130m -15.5796592 -47.4963373 >>> 18. 150m -15.6634353 -47.8025477 >>> 19. 150m -15.6159835 -47.7074204 >>> 20. 150m -15.580039 -47.4031547 >>> 21. 150m -15.5798865 -47.4017277 >>> 22. 140m -15.6447538 -47.7621187 >>> 23. 180m -15.5988265 -47.6764369 >>> 24. 180m -15.5976381 -47.6742536 >>> 25. 180m -15.5816693 -47.541782 * >>> 26. 180m -15.5784423 -47.387327 >>> 27. 200m -15.5819612 -47.4307922 >>> 28. 230m -15.6368767 -47.7452838 >>> 29. 240m -15.611242 -47.6989353 >>> 30. 250m -15.6546956 -47.7846587 >>> 31. 250m -15.6535979 -47.7811262 >>> 32. 260m -15.581708 -47.5553486 >>> 33. 270m -15.613523 -47.7033153 >>> 34. 350m -15.6417687 -47.7561387 >>> >>> * Alguma das vias envolvidas ainda não foi mapeada e só é visível na >>> imagem de satélite >>> >>> Da mesma forma, está pendente uma revisão dessas situações nas vias >>> que estão mapeadas como motorway hoje. Seria necessário fazer um >>> levantamento de cada uma dessas situações e mostrar como ficaria o >>> resultado completo com cada regra para que fosse mais fácil chegar a >>> um consenso. >>> >>> [1] https://wiki.openstreetmap.org/wiki/Talk:Pt:Tag:highway%3Dmotorway >>> >>> On Tue, Dec 15, 2020 at 3:37 PM Lucas Piauilino >>> wrote: >>> > >>> > Será que a BR-020, do seu início até a divisa entre o Distrito Federal e >>> > Goiás, deve ser considerada como =motorway, já que não possui nenhuma >>> > interseção em nível(apenas retornos), ao invés da classificação atual? >>> > ___ >>> > Talk-br mailing list >>> > Talk-br@openstreetmap.org >>> > https://lists.openstreetmap.org/listinfo/talk-br >>> >>> >>> >>> -- >>> Fernando Trebien >>> >>> ___ >>> Talk-br mailing list >>> Talk-br@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/talk-br > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] BR-020 DF
On Tue, Dec 15, 2020 at 11:32 PM Lucas Piauilino wrote: > > acho que o 1 nem existe mais, deve ter sido um retorno antigo, se for esse > mesmo que vc tá falando... Existia 6 meses atrás. [1] https://www.mapillary.com/map/im/Y26U9uwKoo_m_oR55lCfhQ > Em ter., 15 de dez. de 2020 às 19:53, Fernando Trebien > escreveu: >> >> Oi Lucas. Acredito que não, mas depende em parte de uma discussão que >> ainda não tivemos em profundidade No Telegram, essa discussão parou >> ali por junho, com alguns colegas defendendo regras mais flexíveis e >> outros defendendo regras menos flexíveis. [1] >> >> Olhei essa via nas imagens do Bing e do ESRI e encontrei as seguintes >> configurações que me dizem que ela não seria auto-estrada (motorway), >> apenas troncal. Você pode jogar a coordenada na busca do site para >> examinar cada situação: >> >> Cruzamentos em nível: >> 1. -15.6520247 -47.7776521 >> 2. -15.6499124 -47.7731895 * >> 3. -15.5948919 -47.6574683 * >> 4. -15.5782214 -47.3855715 >> 5. -15.5806927 -47.3401845 (final) >> >> Entrecruzamentos curtos: >> 6. 15m -15.6020105 -47.682315 >> 7. 20m -15.6017609 -47.6823559 >> 8. 50m -15.5974405 -47.6106939 >> 9. 70m -15.5840436 -47.3525226 >> 10. 70m -15.5838163 -47.3516563 >> 11. 75m -15.6088899 -47.6950434 * >> 12. 75m -15.5953982 -47.6511008 * >> 13. 80m -15.6001479 -47.6790802 >> 14. 90m -15.624929 -47.723507 >> 15. 130m -15.6761155 -47.8245223 >> 16. 130m -15.5797005 -47.4979091 >> 17. 130m -15.5796592 -47.4963373 >> 18. 150m -15.6634353 -47.8025477 >> 19. 150m -15.6159835 -47.7074204 >> 20. 150m -15.580039 -47.4031547 >> 21. 150m -15.5798865 -47.4017277 >> 22. 140m -15.6447538 -47.7621187 >> 23. 180m -15.5988265 -47.6764369 >> 24. 180m -15.5976381 -47.6742536 >> 25. 180m -15.5816693 -47.541782 * >> 26. 180m -15.5784423 -47.387327 >> 27. 200m -15.5819612 -47.4307922 >> 28. 230m -15.6368767 -47.7452838 >> 29. 240m -15.611242 -47.6989353 >> 30. 250m -15.6546956 -47.7846587 >> 31. 250m -15.6535979 -47.7811262 >> 32. 260m -15.581708 -47.5553486 >> 33. 270m -15.613523 -47.7033153 >> 34. 350m -15.6417687 -47.7561387 >> >> * Alguma das vias envolvidas ainda não foi mapeada e só é visível na >> imagem de satélite >> >> Da mesma forma, está pendente uma revisão dessas situações nas vias >> que estão mapeadas como motorway hoje. Seria necessário fazer um >> levantamento de cada uma dessas situações e mostrar como ficaria o >> resultado completo com cada regra para que fosse mais fácil chegar a >> um consenso. >> >> [1] https://wiki.openstreetmap.org/wiki/Talk:Pt:Tag:highway%3Dmotorway >> >> On Tue, Dec 15, 2020 at 3:37 PM Lucas Piauilino >> wrote: >> > >> > Será que a BR-020, do seu início até a divisa entre o Distrito Federal e >> > Goiás, deve ser considerada como =motorway, já que não possui nenhuma >> > interseção em nível(apenas retornos), ao invés da classificação atual? >> > ___ >> > Talk-br mailing list >> > Talk-br@openstreetmap.org >> > https://lists.openstreetmap.org/listinfo/talk-br >> >> >> >> -- >> Fernando Trebien >> >> ___ >> Talk-br mailing list >> Talk-br@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-br > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] BR-020 DF
Oi Lucas. Acredito que não, mas depende em parte de uma discussão que ainda não tivemos em profundidade No Telegram, essa discussão parou ali por junho, com alguns colegas defendendo regras mais flexíveis e outros defendendo regras menos flexíveis. [1] Olhei essa via nas imagens do Bing e do ESRI e encontrei as seguintes configurações que me dizem que ela não seria auto-estrada (motorway), apenas troncal. Você pode jogar a coordenada na busca do site para examinar cada situação: Cruzamentos em nível: 1. -15.6520247 -47.7776521 2. -15.6499124 -47.7731895 * 3. -15.5948919 -47.6574683 * 4. -15.5782214 -47.3855715 5. -15.5806927 -47.3401845 (final) Entrecruzamentos curtos: 6. 15m -15.6020105 -47.682315 7. 20m -15.6017609 -47.6823559 8. 50m -15.5974405 -47.6106939 9. 70m -15.5840436 -47.3525226 10. 70m -15.5838163 -47.3516563 11. 75m -15.6088899 -47.6950434 * 12. 75m -15.5953982 -47.6511008 * 13. 80m -15.6001479 -47.6790802 14. 90m -15.624929 -47.723507 15. 130m -15.6761155 -47.8245223 16. 130m -15.5797005 -47.4979091 17. 130m -15.5796592 -47.4963373 18. 150m -15.6634353 -47.8025477 19. 150m -15.6159835 -47.7074204 20. 150m -15.580039 -47.4031547 21. 150m -15.5798865 -47.4017277 22. 140m -15.6447538 -47.7621187 23. 180m -15.5988265 -47.6764369 24. 180m -15.5976381 -47.6742536 25. 180m -15.5816693 -47.541782 * 26. 180m -15.5784423 -47.387327 27. 200m -15.5819612 -47.4307922 28. 230m -15.6368767 -47.7452838 29. 240m -15.611242 -47.6989353 30. 250m -15.6546956 -47.7846587 31. 250m -15.6535979 -47.7811262 32. 260m -15.581708 -47.5553486 33. 270m -15.613523 -47.7033153 34. 350m -15.6417687 -47.7561387 * Alguma das vias envolvidas ainda não foi mapeada e só é visível na imagem de satélite Da mesma forma, está pendente uma revisão dessas situações nas vias que estão mapeadas como motorway hoje. Seria necessário fazer um levantamento de cada uma dessas situações e mostrar como ficaria o resultado completo com cada regra para que fosse mais fácil chegar a um consenso. [1] https://wiki.openstreetmap.org/wiki/Talk:Pt:Tag:highway%3Dmotorway On Tue, Dec 15, 2020 at 3:37 PM Lucas Piauilino wrote: > > Será que a BR-020, do seu início até a divisa entre o Distrito Federal e > Goiás, deve ser considerada como =motorway, já que não possui nenhuma > interseção em nível(apenas retornos), ao invés da classificação atual? > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
[Talk-br] Reversão da inserção em massa de bicycle e class:bicycle nas rodovias do país
Envio essa mensagem para documentar a reversão de uma edição em massa, seguindo o código de conduta. [1] Ontem nos grupos do Telegram Classificação e Avançado foi discutida a necessidade de reverter os changesets 88054258, 88055043, 88055062 e 88205409 que adicionaram a 20 mil linhas de rodovias as seguintes etiquetas: bicycle=yes + class:bicycle=-2 + class:bicycle:roadcycling=1 . A opinião geral é de que deveriam ser revertidos completamente devido aos erros encontrados no valor da etiqueta bicycle e mais de uma cidade. O valor inserido descreveu como permitidas para ciclistas rodovias em diferentes cidades com sinalização no local proibindo o acesso deles. Além disso, a etiqueta class:bicycle é descrita no wiki como disputada por questões de verificabilidade. [2] Dos 28060 usos da etiqueta class:bicycle no mundo, 19482 são no Brasil, aparentemente todas inseridas por esse usuário nesses changesets. [1] https://wiki.openstreetmap.org/wiki/Pt:Código_de_conduta_de_edições_automatizadas [2] https://wiki.openstreetmap.org/wiki/Pt:Verificabilidade -- Fernando Trebien ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Nova proposta de classificação viária - Votação encerrada
Eu gostaria de sugerir que aqueles que fizeram apontamentos nos seus votos abram discussão a respeito deles na página de discussão da proposta. [1] Lá é o lugar ideal para discutir e depois votar alterações e refinamentos na proposta. Acho que já existe um consenso substancial de que a regionalização por RGInts (parte da regra 2.2) e talvez também por RGIs (parte da regra 3.1) não seria a mais adequada. Alguns colegas propuseram e começaram a explorar os resultados de regionalizar usando as categorias das REGICs para adicionar alguns pólos ao conjunto considerado. As rotas preliminares que foram apresentadas por eles no Telegram fazem um certo sentido para mim, então, havendo interesse de outros colegas, não me oponho à substituição. As que foram apresentadas produzem um resultado melhor do que as RGInts, no sentido de identificarem melhor os eixos indutores do desenvolvimento regional. Apesar disso, o número de diferenças em relação ao resultado final das demais regras tem se mostrado relativamente pequeno, de forma que essas rotas adicionais poderiam ser tratadas na lista de exceções junto com outras exceções que possam ser levantadas, por exemplo, como já foi citado por colegas diferentes algumas vezes, os acessos a grandes portos e aeroportos. Ou seja, é necessário mais estudo e comparação dos casos particulares. [1] https://wiki.openstreetmap.org/wiki/Talk:Brazil/Classifica%C3%A7%C3%A3o_das_rodovias_do_Brasil On Sun, Jun 28, 2020 at 11:49 AM santamariense wrote: > > A proposta está recebendo novas propostas de variáveis as quais > precisarão passar por novas votações, quer pontualmente, quer em > conjuntos. Várias observações foram feitas, muitas poderão ser votadas > em breve e outras tantas poderão ser votadas com o amadurecimento da > implantação em mapa do que está sendo proposto. > > Como já foi falado em várias ocasiões, a discussão não acaba aqui, mas > sim evolui com o andar do mapeamento. Vou declarar a proposta > aprovada, uma vez que há a aprovação da maioria dos que votaram e por > respeito a quem dedicou o tempo que tinha para estudar a proposta e > dar seu voto. E para que possamos virar a página e a partir desse > momento votar casos pontuais conforme forem surgindo, bem como ajustes > no texto da proposta que se julgar necessário. > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Nova proposta de classificação viária - Votação encerrada
Nós tivemos 10 votos (sem contar as abstenções) dos quais 7 concordam, o que dá 70% de aprovação. Contando com o voto do Vítor, que foi fora do período de votação, são 8 de 11 aprovações, ou 72,7%. No mesmo artigo diz que até 2015 era aceita a maioria simples com mais de 15 votos, o que não é o caso. Esse valor de 74% é um tipo de maioria qualificada. No direito brasileiro, o limiar adotado é de 60%. [1] O nível de 74% é relativamente incomum no mundo, um dos comuns mais exigentes é o de 2/3 (67%). [2] Esse processo de votação do OSM é bastante exigente em boa parte porque se aplica ao mundo todo. No caso, estamos discutindo uma mudança aplicável apenas ao Brasil, então pode ser difícil obter um nível de participação tão alto. No artigo sobre o processo de votação também diz: "todas as sugestões devem ser levadas em consideração antes de uma proposta ser aprovada ou rejeitada, a fim de resolver quaisquer deficiências na proposta original (se houver)." Eu acho que isso que pode estar faltando nesse caso. No mesmo artigo, há uma seção para o período "pós-voto" (post-vote). O template Proposal Page, [3] usado na maioria dos artigos anglófonos de propostas, suporta o valor "Post-Vote" para o campo status. Se vocês procurarem no wiki por "Post-Vote," vão encontrar vários artigos de propostas com uma seção "Post-Vote" onde são discutidos os próximos passos, onde se discute como tratar dos apontamentos feitos por quem votou. Me parece que estamos exatamente nesta fase. [1] https://pt.wikipedia.org/wiki/Maioria_qualificada [2] https://en.wikipedia.org/wiki/Supermajority#Common_supermajorities [3] https://wiki.openstreetmap.org/wiki/Template:Proposal_Page On Fri, Jun 19, 2020 at 5:47 PM Guilherme Braga Alves wrote: > > Gostaria de compreender quais regras definem a proposta como aprovada. De > acordo com a Wiki, > > "se a proposta obteve apoio suficiente, seu status pode ser alterado para > aprovada. Uma regra geral para 'apoio suficiente' é 8 votos unânimes de > aprovação ou pelo menos 10 votos com mais de 74% de aprovação" (tradução > livre). > > Considerando que a proposta obteve 7 votos 'sim' e 3 votos 'não', o patamar > de 74% não foi atingido. > _______ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Nova proposta de classificação viária - Votação encerrada
On Thu, May 14, 2020 at 7:03 PM santamariense wrote: > Também serão atualizadas paginas relacionadas a classificação viária > que tratarem sobre o tema, na maior parte dos casos apenas com a > inclusão de uma nota no topo da página, e sempre que possível linkando > a página da atual regra de mapeamento. Paginas a serem atualizadas: > > A - > https://wiki.openstreetmap.org/wiki/Pt:How_to_map_a#Classifica.C3.A7.C3.A3o_de_vias > B - https://wiki.openstreetmap.org/wiki/Brazil/Classifica%C3%A7%C3%A3o_de_vias > C - https://wiki.openstreetmap.org/wiki/Proposta_Top_05_BR_%2B_1 > D - https://wiki.openstreetmap.org/wiki/Pt:Key:highway > E - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dmotorway > F - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dtrunk > G - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dprimary > H - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dsecondary > I - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dtertiary > J - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dunclassified > K - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dresidential > L - https://wiki.openstreetmap.org/wiki/Pt:Highway:International_equivalence > M - https://wiki.openstreetmap.org/wiki/Highway:International_equivalence Eu entendo que o melhor tratamento para os artigos de highway=*, assim como de qualquer outra tag, é traduzi-los do inglês de forma exata e explicitar as diferenças ou especificidades do Brasil e de outros países lusófonos sempre que necessário, ou, talvez ainda melhor, cada um na sua própria seção. O prefixo Pt serve para Brasil, Portugal, Angola, Moçambique, etc., não podemos escrever esses artigos como se somente o sistema de classificação brasileiro estivesse valendo para todos esses países. Isso foi combinado com essas comunidades no momento que unificamos os prefixos Pt e Pt-br no wiki. Entendo que os demais artigos podem ser alterados para refletir as definições dessa nova proposta caso seja considerada aceita (ainda tenho minhas dúvidas, conforme expus na mensagem anterior). O artigo relativo à proposta da Top 5 no máximo teria o seu status alterado. -- Fernando Trebien ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Nova proposta de classificação viária - Votação encerrada
Quando você iniciou a votação, você citou as regras do seguinte artigo em inglês como norteadoras do processo, em particular em relação ao período da votação (2 semanas): https://wiki.openstreetmap.org/wiki/Proposal_process Neste mesmo artigo, diz que a proposta deve ter no mínimo 8 votos unânimes a favor para ser considerada aprovada, ou 10 com pelo menos 74% de aprovação, e que se isso não for atingido no período de 2 semanas, o período de votação deveria ser estendido. Essas regras também vão valer? Me parece que o ideal seria estender o período de votação para tentar obter mais votos. On Thu, May 14, 2020 at 7:03 PM santamariense wrote: > > Registro aqui a finalização do período de votação da nova proposta de > classificação viária. Votaram 5 mapeadores, onde 3 concordaram, sendo > que 1 fez algumas ressalvas; 1 discordou da proposta, fazendo alguns > apontamentos, ainda dentro do conceito funcional da rodovia, os quais > podem ir sendo explorados e discutidos; E 1 se absteve na votação, > embora também concorde com o conceito funcional. Dos que votaram, > portanto, mais de 50% concorda com a proposta apresentada, sendo > considerada aprovada. > > Alguns comentários foram feitos que poderiam levar a votar casos > pontuais da proposta, e não ficou claro para mim se teria algo a ser > votado desde já. se você tiver algo pontual a ser votado, manifeste-se > a qualquer momento pois ... Não menos importante, lembro aqui que o > texto da regra pode ir sendo modificado no avançar do mapeamento > conforme algumas questões pontuais forem surgindo, sendo discutidas e > votadas como de praxe. > > Com a aprovação dessa proposta, a mesma terá seu texto ajustado para > excluir o que está tachado (foi excluido do texto original ao longo da > discussão), excluir a cor verde de parte do texto (foi incluido), e > modificar parte do texto de "proposta" para "regra", ou outra sugestão > que queiram dar. > > Também serão atualizadas paginas relacionadas a classificação viária > que tratarem sobre o tema, na maior parte dos casos apenas com a > inclusão de uma nota no topo da página, e sempre que possível linkando > a página da atual regra de mapeamento. Paginas a serem atualizadas: > > A - > https://wiki.openstreetmap.org/wiki/Pt:How_to_map_a#Classifica.C3.A7.C3.A3o_de_vias > B - https://wiki.openstreetmap.org/wiki/Brazil/Classifica%C3%A7%C3%A3o_de_vias > C - https://wiki.openstreetmap.org/wiki/Proposta_Top_05_BR_%2B_1 > D - https://wiki.openstreetmap.org/wiki/Pt:Key:highway > E - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dmotorway > F - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dtrunk > G - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dprimary > H - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dsecondary > I - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dtertiary > J - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dunclassified > K - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dresidential > L - https://wiki.openstreetmap.org/wiki/Pt:Highway:International_equivalence > M - https://wiki.openstreetmap.org/wiki/Highway:International_equivalence > > Assim que as modificações forem feitas, a diferença entre antes e > depois será apresentada num próximo e-mail, por meio de link para wiki > contendo o que foi modificado. > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Nova proposta de classificação viária - Votação encerrada
Thierry, acho que seria importante colocar o seu "Concordo" lá no wiki, para arquivamento. On Fri, May 15, 2020 at 11:15 AM Thierry Jean wrote: > > Concordo: Não votei antes por não me sentir capaz de entrar a fundo nas > considerações técnicas da proposta. Entretanto, sei por ter conversado com > Anderson (Santamariense) que esta proposta vai melhorar a navegação para > pessoas que usam os navegadores em diferentes países, deixando a navegação no > Brasil, harmonizada com a de outros países. Também, apesar de isto não ser um > objetivo em si, creio que a visualização do mapa em níveis sucessíveis de > zoom, permitindo mostrar primeiro a malha mais importante para navegação e > sucessivamente as outras estradas e ruas, é muito importante para que o mapa > seja considerado "organizado" pelos usuários. Os "concorrentes" fazem assim e > é normal que OSM se comporte da mesma maneira. > > Thierry Jean > M. +55 11 99607 1319 > > > > > De: santamariense > Enviado: quinta-feira, 14 de maio de 2020 19:03 > Para: talk-br > Assunto: [Talk-br] Nova proposta de classificação viária - Votação encerrada > > Registro aqui a finalização do período de votação da nova proposta de > classificação viária. Votaram 5 mapeadores, onde 3 concordaram, sendo > que 1 fez algumas ressalvas; 1 discordou da proposta, fazendo alguns > apontamentos, ainda dentro do conceito funcional da rodovia, os quais > podem ir sendo explorados e discutidos; E 1 se absteve na votação, > embora também concorde com o conceito funcional. Dos que votaram, > portanto, mais de 50% concorda com a proposta apresentada, sendo > considerada aprovada. > > Alguns comentários foram feitos que poderiam levar a votar casos > pontuais da proposta, e não ficou claro para mim se teria algo a ser > votado desde já. se você tiver algo pontual a ser votado, manifeste-se > a qualquer momento pois ... Não menos importante, lembro aqui que o > texto da regra pode ir sendo modificado no avançar do mapeamento > conforme algumas questões pontuais forem surgindo, sendo discutidas e > votadas como de praxe. > > Com a aprovação dessa proposta, a mesma terá seu texto ajustado para > excluir o que está tachado (foi excluido do texto original ao longo da > discussão), excluir a cor verde de parte do texto (foi incluido), e > modificar parte do texto de "proposta" para "regra", ou outra sugestão > que queiram dar. > > Também serão atualizadas paginas relacionadas a classificação viária > que tratarem sobre o tema, na maior parte dos casos apenas com a > inclusão de uma nota no topo da página, e sempre que possível linkando > a página da atual regra de mapeamento. Paginas a serem atualizadas: > > A - > https://wiki.openstreetmap.org/wiki/Pt:How_to_map_a#Classifica.C3.A7.C3.A3o_de_vias > B - https://wiki.openstreetmap.org/wiki/Brazil/Classifica%C3%A7%C3%A3o_de_vias > C - https://wiki.openstreetmap.org/wiki/Proposta_Top_05_BR_%2B_1 > D - https://wiki.openstreetmap.org/wiki/Pt:Key:highway > E - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dmotorway > F - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dtrunk > G - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dprimary > H - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dsecondary > I - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dtertiary > J - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dunclassified > K - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dresidential > L - https://wiki.openstreetmap.org/wiki/Pt:Highway:International_equivalence > M - https://wiki.openstreetmap.org/wiki/Highway:International_equivalence > > Assim que as modificações forem feitas, a diferença entre antes e > depois será apresentada num próximo e-mail, por meio de link para wiki > contendo o que foi modificado. > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Nova proposta de classificação viária
On Wed, Mar 18, 2020 at 10:07 AM Flavio Bello Fialho wrote: > Um critério fundamental para o Brasil é que todas as trunk devem ser > pavimentadas. Em outros países, pode ser aceitável uma trunk não pavimentada, > como no caso do Canadá, onde boa parte do ano a estrada está coberta de neve, > mas no Brasil a erosão das chuvas deixa várias estradas não-pavimentadas > inviáveis (às vezes até as pavimentadas). No Brasil é mais necessário flexibilizar esse critério do que no Canadá. Uma estrada de neve é bem mais perigosa do que uma estrada de terra depois da chuva. Eu concordo que deva ser pavimentada, mas acho que, no caso do critério escolhido indicar que seria trunk ignorando a pavimentação, deveria ser primary se não for pavimentada. Jogar uma conexão muito importante para o nível secundário apenas pela falta da pavimentação é rebaixar demais a importância da via. Eu a rebaixaria para secundária se for de leito natural, mas em geral as vias importantes são implantadas e suficientes para a quantidade de tráfego atual delas. Temos que lembrar que as vias importantes, mesmo antes de pavimentadas, são eixos indutores, e que o desenvolvimento econômico e urbano ocorre ao seu redor mesmo ainda nessa etapa. > Um exemplo é a rota entre Boa Vista e Georgetown, que não é pavimentada no > lado da Guyana. Faria mais sentido, ao invés dessa rota, classificar como > trunk a rota entre Boa Vista e Ciudad Guayana, na Venezuela, que é > pavimentada e imagino que tenha um fluxo de veículos bem maior. Não vejo problema em ser trunk do lado brasileiro e primary do lado guianense. Pequenas alternâncias assim nas fronteiras transnacionais poderiam ser permitidas, o ruim é ficar alternando várias vezes ao longo da via. Extrapolando o contexto da conversa, essa rota também poderia ser trunk nas proximidades de Georgetown, indo pela ideia de que malhas separadas devem estar enraizadas em cidades grandes. (Antes de fazer qualquer alteração na Guiana, teríamos que conversar com a comunidade local, que no caso creio que seja predominantemente composta por mapeadores holandeses ou estrangeiros em geral.) > Acho que o trabalho ficou bom como exemplo ilustrativo, mas as rotas devem > ser discutidas com calma Acho que sim também. Mas não qualificaria ainda como "ilustrativo," para fazer esse tipo de afirmação é necessário analisar bem os detalhes. > talvez focando em um estado de cada vez. A tendência ao fazer assim é criar ilhas de critérios diferentes. Acho melhor tentarmos encontrar uma proposta mais integradora e menos segregadora. Isso ajuda tanto a consumir os dados em aplicativos quanto a manter o mapa ao longo do tempo com menos divergências entre os mapeadores. > É importante também incluir critérios físicos, como foi feito no RS (rodovias > duplicadas com mais de 10 km de extensão são trunk). Se a rodovia foi > duplicada é porque ela tem importância. É muito caro duplicar uma rodovia. É um requisito do qual eu historicamente discordo e, ao misturar os critérios, acaba produzindo confusão para o usuário do mapa e para os novos mapeadores. Quase sempre esses casos podem ser melhor justificados de outras formas. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Nova proposta de classificação viária
Vou ver isso assim que possível. Espero que vocês compreendam que (1) a maioria está tendo que se adaptar ao surto de coronavírus e (2) no RS houve um período de 10 meses para que alguns membros podessem analisar a proposta em detalhes antes de se convencerem de que era boa. O Brasil tem 26 estados e alguns deles maiores que o RS. À primeira vista, a densidade está dentro do esperado, exceto na região Norte, onde as conexões entre as capitais dos estados adjacentes não foram incluídas na malha, mesmo quando pavimentadas. Achei especialmente interessante o tratamento dado às balsas, algo que não chegou a ser discutido a fundo pela comunidade brasileira. Já gostaria de te perguntar de antemão: 1. Como você gerou as rotas? Sua planilha tem 6 mil rotas. Você produziu elas manualmente ou de forma automatizada? Se foi de forma automatizada, qual foi o procedimento? Sabendo do procedimento, seria possível agilizar a revisão. 2. Por que há diferenças com a proposta já aprovada no RS? 3. Recentemente, eu apontei para você, em conversa particular, que a rota que está marcada como Passo Fundo - Pelotas não preenche os critérios definidos para o RS e que portanto seria um erro ou uma escolha por consenso sem justificativa adequada. O único sistema de roteamento comercial que escolhe essa rota é o Google Maps. Por outro lado, o único sistema que escolhe a rota Porto Alegre - Santiago anotada no mapa é o Here.com. On Fri, Mar 13, 2020 at 11:26 AM santamariense wrote: > > Compartilho com vocês o resultado [1] da interconexão de rotas entre > as cidades com mais de 200 mil habitantes, as quais deverão ser parte > da malha trunk do nosso país. Todos os trechos tem quais rotas passam > por ele com a tag R*. A mesma relação de rotas é possível ser > encontrada na tabela que também está contida no arquivo zip a ser > baixado. É ainda possível averiguar uma rota completa, com todos os > trechos selecionados, selecionando um dos trechos, selecionando nas > tags a rota desejada, clicando com o botão direito e selecionando a > opção 'buscar chave/valor', ou algo parecido. Em caso de divergência > entre a tabela e o mapa, a rota da última deve prevalecer. > > Conurbações foram consideradas como sendo apenas uma cidade, logo, as > cidades conurbadas devem ter sua malha urbana pensa em conjunto, e, > por conseguinte, trunks adicionais podem existir dentro dessas áreas > conurbadas. > > As conexões que passam a fronteira do Brasil são meramente > ilustrativas da rota completa entre cidades interconectáveis. Porém é > importante lembrar que a classificação fora do território brasileiro > não será modificada sem diálogo com os nossos vizinhos. > > Divergências dos resultados podem ser discutidas pontualmente de modo > a se adicionar ou excluir trechos, bem como modificar as rotas. > > [1] - > https://github.com/santamariense/ClassViarBR/raw/master/Mapa%20e%20tabela%20trunk%20v20200313.zip > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Conversão em via somente para ônibus
Se a faixa não for separada do trânsito dos demais veículos (o que não é a situação desse caso específico), bastaria adicionar à relação de restrição de conversão a etiqueta except=bus, ou except=psv se todos os veículos de transporte público puderem fazer a conversão, incluindo, por exemplo, táxis e microônibus. Neste caso específico, no bairro Santa Helena em Vila Velha, ES, a "faixa" de ônibus é separada dos carros por uma faixa zebrada, que normalmente é entendida como separador de vias no OSM no Brasil. Sendo assim, a faixa dos ônibus é considerada um pista exclusiva para ônibus e é mapeada como uma linha separada paralela com highway=service + service=driveway + access=no + bus=designated ao invés de ser representada pela etiqueta busway:left=lane na linha da via principal. Mapeando como linha separada, você pode adicionar a restrição de conversão somente na linha da via principal e não adicionar a restrição à linha da pista exclusiva para ônibus. On Fri, Mar 13, 2020 at 5:12 PM Paulo Vianna wrote: > > Olá pessoal, boa tarde. > > Estou usando o tipo de rota carro pra tentar traçar uma rota de ônibus, porém > existe uma conversão que não é permitido para carro, somente ônibus. O que > devo fazer no Open Street? Devo definir a rota do ônibus como se fosse uma > rota de carro? > > O traçado em vermelho é a rota utilizada para carro. O traçado em verde foi > um demonstração para onde deveria passar o ônibus. > > http://www.codelogic.com.br/arquivo/via_onibus_verde.png > > Obrigado. > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Nova proposta de classificação viária
On Fri, Feb 14, 2020 at 7:14 PM Gerald Weber wrote: > > Oi Fernando > > On Fri, 14 Feb 2020 at 14:34, Fernando Trebien > wrote: >> >> On Thu, Feb 13, 2020 at 10:41 PM Gerald Weber wrote: >>> >>> Enfim, se eu já achava que a proposta era uma má ideia, agora estou >>> convencido que se trata de um grande desastre. >> >> >> Para quem? > > Para quem precisa confiar que os dados são reflexo da realidade e não reflexo > de um algorítmo. Por que o algoritmo não seria um reflexo da realidade? O fluxograma de 2013 também é um algoritmo, só que mais simples. >>> Daqui a duas semanas participo de uma banca de mestrado onde se fez >>> precisamente isto, extrairam os dados do OSM e fizeram uma análise de >>> conectividade. Eu já vi que tiveram problemas com as classificações das >>> rodovias. A atual proposta vai agravar a situação e tornar o OSM inútil >>> para estudos científicos deste tipo. >> >> >> Pode dar mais detalhes? Eu acredito fortemente que a nova proposta resolverá >> problemas de classificação ao invés de prejudicar. Para poder ajudar e poder >> dizer se a nova proposta realmente prejudica alguém, gostaria de saber: que >> trabalho foi esse, o que estavam tentando fazer, que problemas tiveram, que >> estudos científicos estão sendo feitos usando o OSM, etc. > > > Eu vou terminar de ler a dissertação e te falo com mais propriedade. Penso > que o texto, após as correções deva ficar disponível on-line, quando isto > acontecer eu aviso aqui. > > Mas para ficar em exemplos de trabalhos científicos, vamos considerar este > artigo: > https://www.sciencedirect.com/science/article/pii/S2226585615000199 > > Eu não sei como os mapeadores chineses classificaram suas vias e que regras > usaram. Para alguém com uma opinião forte, soa meio preocupante. E se os chineses tiverem usado um algoritmo? E se estiverem copiando uma classificação oficial que dependeu de um algoritmo? O que consta na página chinesa do artigo key:highway [1] é uma tradução quase ipsis literis do original em inglês. Já no fórum chinês do OSM só há 44 postagens - o Brasil tem 3808. Para mim, parece que a classificação atual é resultado da importação de dados de uma fonte de dados oficial, e a qualidade da classificação portanto reflete a qualidade dessa fonte de dados. Além disso, a China está cheia de motorways e trunks, para mim seria interessante saber se a análise da qualidade da classificação contemplou todos os níveis ou se ateve ao mais altos, o que pode significar que é apenas efeito colateral da enorme população desse país. > dentre elas que o OSM se aproxima mais da realidade que mapas comerciais. Qual aspecto da realidade? > mas eu prefiro uma metodologia ancorada na verificação (survey) ou, na > impossibilidade desta, na consulta de uma autoridade que realiza este tipo de > verificação como o DEER. Veja bem, a classificação do DEER não tem uma relação 1:1 com qualquer regra definida por atributos físicos, que é exatamente o que a proposta de 2013 é. Ou você defende um "algoritmo" baseado em atributos físicos, ou defende a cópia da classificação funcional "arbitrária" do DEER. Defender as duas coisas é uma contradição. > Por exemplo, no caso de MG, o seu algoritmo considerou algumas rodovias ao > redor de Diamantina deviam ser trunk. Já pelo DEER-MG ali tem um grande > vazio, não há qualquer rodovia trunk (e eu concordo com o DEER neste caso). O > que aconteceu? É o Vale do Jequitinhonha, umas das regiões mais pobres de > Minas. Tem população que satisfaz o seu critério, mas não tem renda, não tem > PIB. Tem gente, mas não tem produtos para transportar que justifiquem uma > malha tipo trunk. O grande contraste aqui é o Triângulo Mineiro que é uma > região rica permeada por trunks. Disso eu concluo que esse algoritmo então é, pelo menos do ponto de vista social, provavelmente mais ético, por não diminuir a importância das malhas que atendem populações pobres simplesmente por serem pobres. O efeito de outros métodos é apagar essas malhas do mapa, como se nessas regiões não houvese nada importante. Essa também é uma das minhas preocupações, sobretudo nas regiões menos densas (e que também são mais pobres) do Norte e do Centro-Oeste. Não havendo vias de classificação alta lá, perde-se discernibilidade, para quem mora e transita na região, entre as vias que são melhores e as que não são no contexto regional. Eu acho importante notar que é muito raro alguém fazer uma viagem terrestre muito longa, e que a maioria das viagens terrestres está limitada àquilo que se pode fazer em 1 ou no máximo 2 dias de viagem. Quando você aplica essa janela à classificação das vias e faz a classificação de forma comparativa dentro da área correspondente a esse contexto,
Re: [Talk-br] Nova proposta de classificação viária
On Thu, Feb 13, 2020 at 10:41 PM Gerald Weber wrote: > Enfim, se eu já achava que a proposta era uma má ideia, agora estou > convencido que se trata de um grande desastre. > Para quem? > Daqui a duas semanas participo de uma banca de mestrado onde se fez > precisamente isto, extrairam os dados do OSM e fizeram uma análise de > conectividade. Eu já vi que tiveram problemas com as classificações das > rodovias. A atual proposta vai agravar a situação e tornar o OSM inútil > para estudos científicos deste tipo. > Pode dar mais detalhes? Eu acredito fortemente que a nova proposta resolverá problemas de classificação ao invés de prejudicar. Para poder ajudar e poder dizer se a nova proposta realmente prejudica alguém, gostaria de saber: que trabalho foi esse, o que estavam tentando fazer, que problemas tiveram, que estudos científicos estão sendo feitos usando o OSM, etc. Eu também entendo que o "algoritmo" proposto (que eu sempre chamei de "metodologia") não deve ser levado sempre ao pé da letra sempre, alguma dose de ponderação e interpretação deve ser permitida para tratar de casos limítrofes pelo consenso. A "metodologia" é pra ajudar a orientar o trabalho de classificação e eliminar da discussão a grande maioria dos casos principais. -- Fernando Trebien ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Nova proposta de classificação viária
On Mon, Jan 27, 2020 at 3:40 PM Linhares XT wrote: > 2. Apesar de ser grande defensor dos critérios funcionais, eu considero de > maior importância os critérios administrativos. Nesse caso de Minas Gerais é > muito mais fácil pegar a informação do DEER de quais são os principais > troncos rodoviários! Geralmente quando se falou em critérios "administrativos" anteriormente, a referência era a regras baseadas somente na jurisdição de quem administra a via (federal, estadual ou municipal). No caso, ao pegar essa informação do DEER, ainda estaríamos com um critério funcional, mas ao invés de tentar inferir a função da via usando algum método mais genérico (porém verificável), estaríamos obtendo ela da fonte oficial. Daí temos dois pontos a considerar: 1. Quase nenhum estado tem essa informação publicada oficialmente, o que torna MG uma exceção; 2. Precisamos de uma regra que funcione onde não tem a informação oficial, daí a comparação entre o resultado da regra e a classificação oficial em MG; 3. Não temos garantia nenhuma de que a classificação oficial do DEER/MG esteja 100% correta em todas as vias. Para isso, outras informações no mesmo dataset também teriam que estar 100% corretas, o que eu duvido que esteja. Se eu estiver errado e o dataset de Minas for perfeito, isso tornaria Minas novamente exceção no país. Dito isso, antes de entrar nos questionamentos propostos do ponto #3, já seria um avanço considerável simplesmente copiar a classificação oficial do DEER/MG por ora, pelo menos no nível trocal, e deixar o debate sobre o ponto #3 para depois. O interessante é que a regra mais genérica que está sendo proposta permite comparar as classificações oficiais dos estados quando estão disponíveis. Por exemplo, sabemos, pelos dados que temos e de posse desse método, que o DER/SC (o único outro estado que também tem classificação funcional publicada) não é tão exigente com a definição das troncais quanto o DEER/MG. -- Fernando Trebien ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Nova proposta de classificação viária
On Sun, Jan 26, 2020 at 6:03 PM santamariense wrote: > > 1. ... o critério é: "Considerar as cidades com distância igual > > ou menor à raiz quadrada da população da MENOR cidade". > > Apontamentos ou oposições à correção disto na proposta? Eu sempre entendi que esse critério era uma forma de reduzir o número de pares que teremos que considerar obrigatoriamente ao fazer a análise inicial, não uma limitação para eventuais casos particulares que encontremos depois, que constariam em lista à parte e que provavelmente seria bem curta (e provavelmente em muitos estados nem existiria). Ou seja, eu colocaria que isso não é uma restrição estrita e sim uma recomendação para a metodologia ser aplicada de forma mais eficiente. > > 2. A classificação no RS foi feita com base numa mistura de critérios > > físicos, funcionais e administrativos. Do ponto de vista físico, a > > classificação tem algumas propriedades: > > > > a) Todas as vias motorway, trunk e primary são pavimentadas, sem exceção. > > Não houve intenção de abrir brecha para vias não-pavimentadas serem > motorways, De fato. Eu estava entendendo o termo "duplicada" conforme a definição do DNIT, que inclui a pavimentação. Eu descreveria com uma pista por sentido e separador físico, mas sem pavimentação, como "dividida/separada e não-pavimentada", pra não causar confusão. Várias arteriais urbanas são divididas e nem por isso se enquadram na categoria "duplicada" do DNIT. Ia ficar bem estranho um monte de trunk indo pra bairros pouco populosos. > Vou adicionar as colocações feitas na seção "pontos a discutir" da > proposta, por enquanto. Imagino que conforme o pessoal for > amadurencendo a ideia, mais pessoas poderão opinar para tomar a > decisão. Vi as suas alterações lá. Acho que seria interessante termos um glossário, pra que as definições dos termos estejam bem claras. Eu acho interessante adotarmos as definições do CTB e do DNIT, que são do conhecimento de muitos, e esclarecer onde for necessário divergir delas por alguma razão específica do OSM. Se quiser, eu mesmo posso acrescentar o glossário. > vai selecionar as vias com melhores características físicas. Por outro > lado, temos regiões remotas do país, onde pode haver cidades que > tenham porte populacional para ter classificação viária maior do que > as estradas que levam até ela se fosse aplicada essa restrição, e caso > isso ocorra vai criar ilhas no sistema viário. Há de se considerar > também que, por exemplo, uma rodovia trunk no Acre de nada > interferiria no sistema viário de São Paulo. Ok, algumas cidades são > de fato isoladas da malha viária principal do país, como esta [1], e > daí não há o que ser feito. > > [1] - > http://g1.globo.com/ac/acre/noticia/2014/03/isolada-porto-walter-no-ac-e-unica-cidade-do-pais-sem-carro.html Me parece que a principal ligação dessa cidade com o sistema rodoviário é por barco. Talvez exista uma rota de balsa para carros, mas ninguém mapeou ela ainda. Se existir, pode ser mapeada com route=ferry + ferry=tertiary/secondary, já que essa cidade tem o limiar populacional de place=village. A etiqueta ferry=trunk/primary/secondary/tertiary/unclassified foi feita para permitir que GPSs que se guiam fortemente pela hierarquia possam converter as rotas de balsa em "rotas virtuais" do tipo esperado, em continuidade com o sistema viário em terra, e possam desenhar essas rotas nos mesmos níveis de ampliação/zoom. Essa rota de balsa terciária então se ligaria a vias urbanas terciárias (que essa cidade com certeza já está em condições de ter), por exemplo a Rua Dom Luiz Herbertes, que leva para alguns povoados (place=hamlet), e suas ligações com o porto (Rua Kalily Cameli e Rua Mamed Cameli). > Estou juntando informações de diversas fontes, bem como cruzando > dados, para obter como resultados quais das mais de 5500 cidades do > país não tem acesso asfáltico e poderia ser de fato afetada pelo que > está sendo discutido nesse item. São questões pontuais que deverão ser > discutidas no decorrer da proposta. Esse com certeza seria um dado muito interessante. > > b) Todas as rodovias duplicadas por mais de 10 km são trunk ou motorway. Eu andei olhando uns casos por aí e acho que 10km pode ser pouco e acabar levando à elevação artificial de algumas perimetrais e anéis viários. Sugiro que pensemos se não seria melhor 20km. > Este item não obstrui a classificação, apenas adiciona algumas > rodovias a mais às categorias mais elevadas de classificação, e que > poderiam muito bem ser usadas como alternativa às outras de igual > qualidade, então eu concordo, desde que não venha a ter "tocos" de > trunk desconexos da malha principal. No grupo de classificação, eu fiz a seguinte proposta, com a qual todos aparentemente concordaram, e acho que pode ser adaptada
Re: [Talk-br] Nova proposta de classificação viária
On Fri, Jan 24, 2020 at 12:54 PM santamariense wrote: > E penso que ao > ver a proposta em forma de mapa, você não vai achar tão ruim assim a > ideia quanto tu transparece imaginar. Acho que isso sim faz muita diferença. No RS isso foi fundamental para (1) despertar interesse, (2) verificar os impactos positivos E negativos, e (3) disseminar a compreensão sobre como o método é aplicado. Tanto é que primeiro veio o mapa, depois a proposta. Eu fiz assim no RS [1] justamente porque todas as discussões anteriores sobre classificação aqui na talk-br acabaram com pedidos para que fosse assim. Já tem alguém elaborando esse mapa? [1] https://forum.openstreetmap.org/viewtopic.php?id=62430 -- Fernando Trebien ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Nova proposta de classificação viária
On Fri, Jan 24, 2020 at 11:53 AM Fernando Trebien wrote: > O problema disso é que, em algumas situações, o resultado é um desvio > muito maior do que o percurso direto pela rota não-pavimentada. Esse > aqui em Porto Alegre [1] dobra de tempo ao aplicar essa restrição. [1] https://www.openstreetmap.org/directions?engine=graphhopper_car&route=-29.8830%2C-51.1237%3B-29.8730%2C-51.0968 -- Fernando Trebien ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Nova proposta de classificação viária
nção e há consenso de que deveria ser um pouco diferente, falta mão de obra mesmo. [2] > De uma maneira ou de outra estamos em uma encruzilhada e temos de tomar uma > decisão: se a classificação se dará pela importância abstrata de roteamento e > continuidade, ou pela estrutura física real, ou um misto dos dois. A importância "abstrata" (nem tanto) se relaciona com alguns aspectos que vão além do roteamento, como o urbanismo, a geografia, a distribuição populacional, que estariam de certa forma mais de acordo com a ideia de o OSM ser um mapa de "propósitos gerais" (portanto, não só para roteamento). Da minha parte, eu tenho deixado a estrutura física influenciar rigidamente a classificação nos casos extremos, e para o caso típico (mais de 95% das vezes) simplesmente seguir a metodologia da rota ideal, que TAMBÉM é influenciada pela estrutura física, mas de maneira menos rígida. Posso citar tantos casos com que eu já lidei e que "deram certo" (no sentido de que pararam as guerras de edição), tanto dentro quanto fora das cidades, mas acho que seria interessante fazer isso no fórum pra não poluir a lista. > "the truth is on the ground" Não há classificação no chão. [3][4] Mesmo onde está definida legalmente, como é o caso da Inglaterra e do Uruguai, a classificação depende de algum tipo de interpretação por alguém. [1] https://support.google.com/maps/thread/2292860 [2] https://github.com/gravitystorm/openstreetmap-carto/issues/110 [3] https://wiki.openstreetmap.org/wiki/Pt:Verificabilidade#Tags_problem.C3.A1ticas [4] https://wiki.openstreetmap.org/wiki/Verifiability#Problematic_tags -- Fernando Trebien ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Nova proposta de classificação viária
cruzamento e do > viaduto da avenida, ela muda de nome e torna-se uma rodovia federal, a > BR-356[3], com base no BHMap, portal de dados georreferenciados da > prefeitura. Já no plano diretor, a situação é outra e a avenida somente > torna-se uma rodovia federal após o trevo do BH Shopping[4], sendo > considerada uma via de ligação regional. A classificação não necessariamente muda só porque mudou o responsável pela via. O que acontece na altura do entroncamento com a rua prof. Rodrigues Seara é que a via passa a ter características físicas de motorway, que é a única classe viária que, pela nova proposta, ainda seria definida em termos do seu perfil físico. Então, mais uma vez, a estrutura física produzindo um resultado estranho. O mapa da prefeitura, o Waze, o Here e o Google Maps não apresentam essa variação na classificação da via. No grupo de classificação do Telegram uns dias atrás, eu propus o seguinte, muitos concordaram e ninguém discordou: a rede motorway deve ser subconjunto da rede trunk (independente de como a rede trunk esteja definida). Nesse caso, não há classe municipal que seria atribuída a trunk (as vias de ligação regionais seriam a princípio primary, e são motorway por outros motivos). Só que a rede trunk, se formos seguir a nova proposta, não incluiria o trecho da BR-356 desde o entroncamento com a BR-040. O motivo: as rotas de passagem pela cidade são todas contornando pela BR-040. Então esse trecho seria todo primary. Se isso parecer baixo demais, algo a se considerar é acompanhar o Here e o Google e elevar a trunk o anel formado pela avenida do Contorno e Andradas e (algumas/todas as) conexões (que exigira análise e discussão com a comunidade local) que levam até esse anel partindo da malha trunk (BR-040). > No caso, qual seria o certo para ser representado no mapa? Atualmente, o > que está mapeado é justamente o primeiro caso que mencionei[5]. Para mim seria mais natural (no sentido de produzir um mapa menos confuso) a solução da Prefeitura, ao olhar o sistema como um todo. Mas como as opiniões são fortes quando se fala em motorway, acho difícil que concordem comigo. Pela mesma razão, um mapeador elevou a classificação da avenida Zaida Jarros aqui em PoA [3]. Anteriormente, ela era primária, o que produzia um mapa mais enxuto, estava em acordo com o plano diretor e não afetava nem roteamento automático, nem a escolha visual das rotas. > Seguindo o plano diretor, a grande maioria das ruas do centro de Belo > Horizonte são arteriais[5], porém apenas umas três avenidas são > consideradas `primary`, as principais avenidas do centro são `secondary` > e nem todas as ruas, consideradas arteriais pelo plano diretor, são > `tertiary`[6]. Como ficaria o mapeamento neste caso, visto que o centro > é uma região de alto tráfego de veículos? Essa é a principal diferença entre o plano diretor de Belo Horizonte e os demais planos que eu vi por aí [4]. Eu trataria isso como caso excepcional e não seguiria a classificação do plano no centro de Belo Horizonte. Uma ideia seria partir dos mapas comerciais mais usados (Google Maps, Here e Waze), chegar ao que seria uma classificação de "consenso" entre eles, e daí ir ajustando onde parecer necessário, conforme se vai analisando a funcionalidade das vias nessa região. Os três concordam quase sempre sobre as vias que consideram "locais" e divergem um pouco sobre quais consideram arteriais e quais consideram coletoras em casos que me parecem ser "intermediários". Nas maiores arteriais, concordam. Muito importante ali é mapear os limites de velocidade oficias e os semáforos. Onde tem semáforo, tem pelo menos alguma coletora envolvida (lembrando que arteriais também são coletoras, o inverso é que não vale). Tô vendo ali também que tem vias divididas que só podem ser cruzadas em alguns pontos. Isso pode sugerir que é nesses pontos que passam as coletoras. Não seria o caso se forem muitos pontos (ex. na Augusto Lima), o que levaria a uma densidade alta de coletoras, mas se forem poucos (ex. na Getúlio Vargas) pode ser que sim. > O Gerald mencionou o uso dos dados do DEER, mas eles não seriam > aplicados somente para as rodovias sob sua jurisdição, que seriam as > estaduais e federais? Quais dados deveríamos usar para as vias > municipais? E no caso, qual dado usar, o portal de dados > georreferenciados da prefeitura ou o plano diretor da cidade? Na interface entre o sistema urbano e o não-urbano/intermunicipal, sempre é necessário fazer alguns ajustes. Eu me basearia nos dois e tomaria uma decisão caso a caso analisando o contexto. [1] https://wiki.openstreetmap.org/wiki/Pt:Porto_Alegre,_Rio_Grande_do_Sul/Sistema_Viário [2] https://www.openstreetmap.org/relation/3408902 [3] https://www.openstreetmap.org/#map=15/-29.9845/-51.1831 [4] https://wiki.openstreetmap.org/wiki/Category:Cidades_com_hierarquia_vi%C3%A1ria_oficial -- Fernando Trebien ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Nova proposta de classificação viária
On Thu, Jan 23, 2020 at 7:50 PM Gerald Weber wrote: > dito tudo isto, na verdade realmente tanto faz, ninguém usa o OSM para quase > nada. Depois de 15 anos a maioria das pessoas nem nunca ouviu falar, tudo é > só Google Maps. Além disto o mapa não é confiável, e da maneira como opera, > nunca vai ser. O OSM é usado por um monte de gente importante: https://wiki.openstreetmap.org/wiki/Major_OpenStreetMap_Consumers#As_a_base_map Infelizmente, o fato de os dados serem do OSM geralmente fica relegado a uma tímida nota de rodapé, que poucos lêem, e os usuários acham que tudo é obra do provedor do serviço - que também tem seu mérito, claro. No fundo, as pessoas querem uma classificação que as ajude a encontrar os seus caminhos e a entender a sua própria localização e a das coisas ao redor. A falta de adoção do OSM me sugere que deveríamos nos perguntar por que as pessoas estão preferindo os concorrentes que usam uma classificação que não seja baseada na estrutura física. Eu acredito que é porque o resultado fica simplesmente confuso. Quanto ao mascaramento dos problemas, eu não entendo bem a sua indignação (gostaria de entender melhor). Você pode mapear as características das vias em detalhe, representando assim de forma bem rica as deficiẽncias das vias, e os interessados podem produzir uma renderização para isso, ou para propósitos mais específicos sempre é possível baixar os dados usando o Overpass e aplicar uma estilização customizada no JOSM. De fato, a camada Humanitária muda a representação das vias não-pavimentadas de alta classe, aceitando então que essa combinação é possível, justamente porque o HOT trabalha nas regiões menos desenvolvidas do planeta onde essa combinação costuma ocorrer. Como exemplo, nós podemos buscar um pouco de inspiração num dos países com mais mapeadores no OSM, vastas diferenças na sua densidade populacional, e vários problemas de infraestrutura: a Rússia. Lá no finalzinho da Sibéria tem uma trunk (a rota R504) que não é pavimentada, cruzando uma distância enorme, levando até uma cidade com um pouco menos de 100 mil habitantes (Magadan). Se mudamos de país e de realidade econômica e cultural e vamos pro Canadá, na referência de classificação oficial deles há uma menção de que as trunks não precisam ser pavimentadas. [2] Então, não sei se se sustenta bem o argumento de que a importância da via está intimamente atrelada à sua estrutura física em todas as situações. Eu acho que pode estar atrelada em situações extremas, tanto no extremo mais alto (motorway) quanto no mais baixo (service=alley nas vias públicas que são muito estreitas), mas no meio do caminho o wiki do OSM e o resultado dos outros países parece sugerir uma certa flexibilidade em relação à estrutura física. Eu gostaria de discutir vários dos outros pontos que você colocou, mas acho que seria melhor quebrá-los em tópicos para não poluir a lista. O melhor pra isso seria o fórum. Em especial, sobre a sua última observação do DEER, eu entendo que eles estavam medindo demanda, que está atrelada ao VDM, que está atrelado à estrutura física, não necessariamente definindo a importância das vias. Se possível, e com tempo, eu queria que você desse uma olhada no material do DER/SC que diferencia classificação funcional, volume de tráfego e estrutura física. [1] Sobre tempo, eu também entendo que essa proposta não vai ser aprovada da noite pro dia e que precisaria de vários ajustes às realidades locais. No RS, foram alguns meses de discussão, mais muitos meses de validação, e depois mais um tempo de espera pra ver se haveria questionamentos, daí implementação. Da minha parte, não quero atropelar ninguém, e entendo que se faz proposta para para ouvir opiniões, até porque novos consensos podem levar a alterações naquilo que já foi aprovado no RS, etc. [1] https://forum.openstreetmap.org/viewtopic.php?pid=688142#p688142 [2] https://wiki.openstreetmap.org/wiki/Canadian_tagging_guidelines#Trunk -- Fernando Trebien ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Nova proposta de classificação viária
On Wed, Jan 22, 2020 at 4:41 PM Thierry Jean wrote: > sei que seria muito bom que, em função do nível de zoom possa-se, > progressivamente, ver aparecer as vias por hierarquia Essa também é uma das intenções da proposta. No RS já dá pra ver bem isso acontecendo no site do OSM ao passar do nível 5 pro 6 e do nível 7 pro 8. O efeito é bastante parecido com o que se observa, por exemplo, na França, na Alemanha, na Espanha, nos Estados Unidos nas regiões menos populosas, no Uruguai, na província de Buenos Aires na Argentina, etc. > utilizadas pelos algoritmos de navegação. Aparentemente essa classificação funciona super bem com algoritmos de navegação. A nível estadual, as rotas mais longas costumam todas seguir pelas vias de mais alta classe na maior parte do percurso, que é o esperado pelos usuários do mapa, e sair delas somente próximo da origem e do final da rota, que também é o esperado, exceto em casos mais raros. Isso acontece em boa parte porque a classificação resultante acaba encontrando uma boa subdivisão espacial, dando preferência às vias que são melhores para dirigir. Da minha parte, eu verifiquei isso mais dentro das cidades (onde apliquei essa metodologia já faz uns anos) do que no nível estadual (onde foi aplicada só recentemente). Nas cidades, o roteamento passa a aproximar bem mais aquele feito pelas ferramentas preferidas pelo mercado (ex.: Waze, Google Maps). O resultado também costuma aproximar o nível arterial que consta nos planos diretores (nesse caso, segue-se a mesma ideia, trocando place=city por place=suburb e highway=trunk por highway=secondary), e (o que acho mais interessante) é que ele consegue capturar bem aquelas situações locais em que a realidade diverge do plano. No nível estadual, parece ter esse efeito também. Por exemplo, no RS, a principal rota entre as duas maiores cidades (Porto Alegre e Caxias do Sul) é por rodovias estaduais, sendo que a rodovia federal (pavimentada e em bom estado) que liga as duas, apesar de ser federal, não é o melhor caminho. O método sugere então que essas vias estaduais sejam trunk e que essa federal não seja, o que produz um resultado que pareceu mais intuitivo à comunidade do RS. Todos ganham: as pessoas que usam o mapa para roteamento, as que estão julgando visualmente quais vias são geograficamente mais importantes, e nós, mapeadores, que finalmente obtemos consenso. -- Fernando Trebien ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Nova proposta de classificação viária
On Wed, Jan 22, 2020 at 5:44 PM santamariense wrote: > Adicionei à proposta as observações feitas ( de 1 a 4 ) > > > 4. Para os níveis secondary e tertiary, o termo "rodovia" deve ser > > trocado pelo termo "estrada" para incluir vias não-pavimentadas que > > satisfaçam a regra da rota ideal. Especialmente importante em várias > > regiões menos desenvolvidas do país que muitas vezes não têm ligações > > viárias pavimentadas. > > Caberia aqui resaltar a diferença entre os termos estrada e rodovia > como "nota" na proposta. Qual seria exatamente a diferença a que tu se > refere? Uma asfaltada e outra não? Uma implantada e outra não? Pelas definições do CTB e do DNIT, o único caso incerto é o das vias implantadas, que segundo o DNIT são rodovias e segundo o CTB talvez não sejam (pois não são pavimentadas, segundo o DNIT). Minha opinião é de que as vias implantadas são suficientemente boas pro tráfego que elas atendem, e as comunidades de outros países consideram surface=compacted igual em qualidade a surface=paved, mas no Brasil por vezes há reclamações de que essas vias sofrem com problemas de manutenção. > Não haverá também casos onde a rota ideal entre cidades médias e grandes > se dará por estradas e não por rodovias? Acho que sim em várias regiões do interior do país. Mas no RS houve forte rejeição a essa ideia para os niveis primary e trunk (e não foi rejeição da minha parte). > > 5. Acredito que as comunidades dos outros estados vão querer avaliar > > com cuidado se o limiar populacional se ajusta à sua realidade local. > > Os limiares padrões do OSM a princípio seriam a metade dos propostos: > > 100k, 10k, 1k, etc. Pode ser muito num estado denso como São Paulo ou > > pouco num pouco denso como o Amazonas. > > Acredito que em diálogos com membros de diferentes estados, poderíamos > chegar a uma melhor definição, ou, tabelar por estados. Ou ainda, > estender o conceito para as cidades principais de Regiões Geográficas > Imediatas e Intermediárias conforme [1] +1 > Na prática, em muitos casos, ocorrerá ligação ideal entre cidades > intermediárias, que levará a completar a conexão mesmo entre as > cidades mais longínquas. Casos excepcionais deverão ser documentados. > Poderíamos considerar aqui que pelo menos o admin_centre de um > admin_level exerce importância em todo o seu território. +1 -- Fernando Trebien ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Nova proposta de classificação viária
é analisar o impacto da escolha dos limiares populacionais. > Por exemplo, a BR262 entre BH e Uberaba, e a MG-050 de Juatuba e divisa MG/SP > são consideradas "troncal" pelo DEER-MG. Também seriam troncais por essa proposta. > Fazer a uma tabela de conversão OSM/DEER-MG seria algo muito simples. Penso > que adotar a classificação oficial seria menos problemático e menos polêmico. Sim, porém, há várias questões: 1. A classificação oficial produz um resultado adequado ao OSM em comparação com outros países? 2. A classificação oficial produz um resultado uniforme e coerente entre as diversas regiões do país? 3. A classificação oficial expressa a real importância da via para os cidadãos da região, ou expressa mais interesses políticos, prioridade de desenvolvimento regional, etc.? ... > Pode ser que não se consiga esta informação para todos os estados. Mas > certamente em MG acho que o resultado seria bem satisfatório. Numa rápida avaliação a partir dos dados que você me passou lá em 2018 [3], a malha troncal oficial seria aproximada pelo método proposto se fixarmos o limiar de trunk em MG em 500k ao invés de 200k. Com esse limiar, a única rota que seria adicionada à malha, divergindo da classificação oficial, seria Juiz de Fora, MG - Ribeirão Preto, SP, que pode muito bem ser tratada como exceção através de consenso pela comunidade estadual. Ou não, caso a comunidade local julgue que é uma rota importante. Daí volta-se à questão de ajustar os limiares por região. Eu concordo que, de forma geral, o ideal é seguir a classificação oficial onde estiver disponível, como é o caso de MG. Mas a disponibilidade dessa informação em MG é uma exceção no Brasil. Por outro lado, o limiar de 500k produz uma malha bem menos densa do que a que se observa em regiões com densidade similar na Europa e na América do Norte, onde estão as comunidades mais ativas no OSM. Então, em MG a discussão poderia ser dividida em duas: (1) se o método proposto aproxima a classificação oficial para o limiar de 500k (caso em que a gente poderia dizer que ela é uma boa forma de avaliar a classificação funcional das regiões que não têm essa classificação; eu acho que é) e (2) se o limiar escolhido pelo DEER-MG está adequado às expectativas do OSM (preciso analisar mais casos particulares antes de formar uma opinião sobre isso). [1] https://wiki.openstreetmap.org/wiki/Key:highway [2] https://forum.openstreetmap.org/viewtopic.php?pid=700675#p700675 [3] https://forum.openstreetmap.org/viewtopic.php?pid=687977#p687977 -- Fernando Trebien ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Nova proposta de classificação viária
Da minha parte, que sou suspeito pra falar, concordo com quase tudo, só faço as seguintes observações: 1. O termo "ligando" na regra #1 de várias classes deveria ser substituído por "é a rota ideal", do contrário há margem para incluir qualquer conjunto de vias que não seja caminho principal entre os lugares referidos. 2. Seria interessante atribuir função aos tipos unclassified e residential, mencionando que correspondem à classe "via local" do CTB. 3. Por clareza, deve estar escrito em algum lugar que "estrutural" é um nome comum nos planos diretores mas inexistente na legislação federal (no CTB), assim como "estrutural principal", e que "principal" se refere a uma classe viária municipal oficial e não apenas a uma descrição genérica. Esse nível só existe nas cidades muito grandes, como por exemplo em São Paulo com seus três níveis de vias estruturais (o N1 seria esse tipo, o N2 seria o estrutural típico de outros municípios de tamanho médio, e o N3 seria equivalente ao arterial que vira secondary no OSM). 4. Para os níveis secondary e tertiary, o termo "rodovia" deve ser trocado pelo termo "estrada" para incluir vias não-pavimentadas que satisfaçam a regra da rota ideal. Especialmente importante em várias regiões menos desenvolvidas do país que muitas vezes não têm ligações viárias pavimentadas. 5. Acredito que as comunidades dos outros estados vão querer avaliar com cuidado se o limiar populacional se ajusta à sua realidade local. Os limiares padrões do OSM a princípio seriam a metade dos propostos: 100k, 10k, 1k, etc. Pode ser muito num estado denso como São Paulo ou pouco num pouco denso como o Amazonas. 6. "Para esta finalidade, convencionou-se que uma cidade X exerce influência num raio determinado pela raiz quadrada de sua população." No caso do RS, a aplicação desse critério não mudaria em nada a classificação final que foi aprovada. Embora eu não discorde a priori, as implicações não chegaram a ser discutidas nem no fórum, nem no Telegram. Pra classificação viária, o raio de influência de uma cidade raramente vai além das suas conexões diretas com as cidades mais próximas na categoria de lugar sendo considerada (100k ou 200k para trunk, 10k ou 20k para primary). O que varia de regiões densas pras esparsas é a distância dessas cidades de mesma categoria mais próximas, e em alguns casos (especialmente onde o sistema viário é muito denso), é necessário ir para o próximo conjunto de cidades. Por esse critério, São Paulo teria um raio de influência de pouco menos de 3500km, indo até o Ushuaia e até San Jose, na Costa Rica. Ou seja, para completar o sistema trunk, teríamos que tentar encontrar a melhor rota entre São Paulo e San Jose (que não existe [1]), ou entre São Paulo e, digamos, Caracas, na Venezuela. Faz parte dessa rota o trecho Porto Velho - Manaus, que não é pavimentado. Acho difícil argumentar que São Paulo influencia o sistema viário muito além do que seria o percurso factível em 1 dia de viagem (~1320km se for a 110km/h continuamente por 12 horas) ou muito além das capitais dos estados vizinhos, sendo que pra viagens mais longas outros modais são preferíveis (trem ou barco para cargas, avião para passageiros). Por outro lado, Palmas, no Tocantins, teria um raio de apenas 546km, que por pouco não cobre todo o estado do Tocantins. O projeto das BRs com certeza inclui prioritariamente no mínimo a interligação entre as capitais estaduais. Agora, se limitarmos em 1320km, algumas cidades grandes em regiões pouco densas, como Manaus, teriam uma área de influência viária reduzida. [1] https://pt.wikipedia.org/wiki/Regi%C3%A3o_de_Dari%C3%A9n On Tue, Jan 21, 2020 at 7:02 PM santamariense wrote: > > Olá, > > Venho por meio desta apresentar uma nova proposta de classificação > viária a ser discutida e aperfeiçoada em conjunto com a comunidade. > Ela baseia-se no resultado satisfatório e menos controverso ao qual > chegamos no RS. > > Em resumo, a proposta é fundamentada principalmente na característica > funcional da via de modo a se escolher a melhor rota entre 2 cidades. > > A proposta completa está documentada em > https://wiki.openstreetmap.org/wiki/Brazil/Classifica%C3%A7%C3%A3o_das_rodovias_do_Brasil > para apreciação da comunidade. > > Creio que para fins de documentação é mais adequada a lista Talk-Br, > porém o Telegram tem proporcionado dinamicidade às discussões, por > isso, quem estiver interessado, se possível, entre no grupo > @osm_classificacao_vias para discutir essa proposta. ( > https://t.me/osm_classificacao_vias ou > https://web.telegram.org/#/im?p=@osm_classificacao_vias ) > > > santamariense > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Road network improvements in Brazil
Hi Andrew. As usual, the only questions I have are about highway classification. In GitHub this is not yet detailed, so I'm wondering if you're planning to follow a topological approach, as proposed and accepted for the southernmost state. We know that that flowchart from 2013 is not quite satisfactory. On the other hand, we know that, without discussion, local mappers may not accept the results. What worked really well for the southernmost state was to present the results before making any changes to the map, then discussion to reach consensus. Regards, Fernando Trebien On Thu, Jul 11, 2019 at 1:41 PM Andrew Wiseman por (Talk-br) wrote: > > Hi OSM Brazil, > > This is Andrew again from the Maps team at Apple, a few months ago I wrote > that we were planning to start a project improving the road network in > Brazil, things like adding missing roads, making sure roads connect properly, > fixing incorrect alignments with GPS traces, ensuring road classifications > are consistent, and other similar issues. Thank you for your feedback then, > we incorporated it into our project. > > We did some analysis and plan to start in the North and Northeast regions of > the country. I wanted to see if you had any suggestions for places that might > have errors or have missing roads, or other issues in that area. There is > more information about our project here: > https://github.com/osmlab/appledata/issues/126 > > Thank you, > > Andrew > > Apple, Inc. > > > Andrew Wiseman | Maps | andrew_wise...@apple.com > > On Nov 9, 2018, at 11:37 AM, Andrew Wiseman wrote: > > Hello OSM Brazil, > > My name is Andrew Wiseman, I work for Apple on the Maps team. My team is > interested in doing some work on the road network in Brazil on OpenStreetMap, > things like adding missing roads, making sure roads connect properly, fixing > incorrect alignments with GPS traces, ensuring road classifications are > consistent, and other similar issues. > > Are there places you know of that need improvement or types of problems you > see frequently? Also I saw these guidelines about road classifications, are > they the most recent classifications used by the community, or are there any > others we should be aware of? > https://wiki.openstreetmap.org/wiki/Pt:How_to_map_a > > We have a Github page here about the project: > https://github.com/osmlab/appledata/issues/126 > > Please let me know if you have any suggestions or feedback. > > Thank you, > Andrew > Apple, Inc. > > > Andrew Wiseman | Maps | andrew_wise...@apple.com > > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
[Talk-br] Geometria de lagos com margens muito variáveis
Olá a todos, Tenho atualizado a geometria da Lagoa dos Patos no RS, uma lagoa rasa, com margens quase planas em diversos locais. O nível da água depende das marés próximo do oceano, e dos ventos em terra [1], e com isso às vezes invade áreas com centenas de metros e às vezes mais de um quilômetro. A minha dúvida é se estou representando corretamente no OSM: 1. A área dentro da variação do nível da água - Praias de areia: natural=beach + surface=sand + tidal=yes/no ("no" na parte seca, "yes" na parte às vezes submersa) - Outras áreas periodicamente submersas: natural=wetland + wetland=tidalflat 2. Os limites da lagoa com a terra seca: no OSM as coastlines devem aproximar a média astronômica da maré alta [2], ou "mean high water spring" (MHWS) [3]. Como não temos essa informação, tenho comparado as imagens do Bing e do ESRI e escolhido a que tem a maré mais alta para atualizar essa geometria, e a de maré mais baixa para definir a área periodicamente alagada (item anterior). 3. Os limites administrativos definidos em termos dos limites da lagoa: tenho colocado junto à maré baixa, que é mais próxima da geometria do IBGE e me parece mais próxima também do que seriam a Linha do Preamar Média (LPM) e da Linha Média de Enchentes Ordinárias (LMEO) definidas em 1831, quando o nível da água era mais baixo que o atual. A LPM e a LMEO de 1831 estão sendo levantadas pelo governo federal já faz uns anos. [5] http://www.planejamento.gov.br/assuntos/gestao/patrimonio-da-uniao/plano-nacional-de-caracterizacao Escolhi uma área [4] mais complicada para avaliar a aplicação dessas definições e gostaria de ouvir opiniões sobre se parece correto ou se algo deveria ser diferente. A aplicação dessas definições parece ter sido um tanto inconsistente no exterior. [6] [1] https://acervo.popa.com.br/diversos/ventos_lpatos.htm [2] https://wiki.openstreetmap.org/wiki/Coastline [3] https://commons.wikimedia.org/wiki/File:Tide_terms.png [4] https://www.openstreetmap.org/?mlat=-31.8076&mlon=-51.8015#map=13/-31.8076/-51.8015 [5] http://www.planejamento.gov.br/assuntos/gestao/patrimonio-da-uniao/plano-nacional-de-caracterizacao [6] https://lists.openstreetmap.org/pipermail/tagging/2018-April/035654.html -- Fernando Trebien ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber
On Fri, Feb 15, 2019 at 10:42 AM Pedro vida torta wrote: > Quilômetros de distancia não entendi bem, já que o erro será apenas nas > esquinas e o usuário estará apenas a poucos metros, eu acho aceitável melhor > que não ter nenhuma outra referencia Essa projeção gera sequências de endereços ao longo de uma mesma rua assim: 1, 5, 11, 17, 2709, 25, 27, 35, 37, 41, 358, 53, 61, etc. Repare que os números 2707 e 358 estão completamente fora da sequência. Isso porque a projeção pegou erroneamente o número de outra rua numa esquina. Em Porto Alegre, a atribuição do número é a medida em metros desde o início da rua, então 2707 e 358 com certeza são erros, óbvios. 2707 está a ~2,7km dos números adjacentes, 17 e 25. Se a rua for longa o bastante, mais adiante deverão haver números como 2705 e 2709, se o usuário procurar por 2707 será levado a um ponto 2,7km distante de onde deveria estar, sem falar que pode realmente existir um número 2707 na rua, caso em que as pesquisa retornaria dois números em qualquer ordem ou, dependendo do geocodificador utilizado, retornar apenas um dos dois números sem que se tenha certeza de qual dos dois será. A via mais longa de Porto Alegre é a avenida Protásio Alves, com 13km de extensão, uma via arterial primária com serviços (amenity=*, shop=*, etc.) ao longo de quase toda a sua extensão, e portanto ampla oportunidade para erros quilométricos decorrentes dessa metodologia. Em situação similar estão as avenidas Bento Gonçalves, Assis Brasil, Ipiranga e Sertório, e com aproximadamente metade da extensão uma outra lista de avenidas principais. Também há vias locais longas, como a Vicente da Fontoura. Nesses casos o "quilométricos" não é exagero, e são lugares muito frequentados. > criticar o trabalho dos outros e fácil Vale em ambos os sentidos, também sou alvo frequente de críticas. A crítica é necessária para manter a qualidade dos dados. O importante é as pessoas não levarem a crítica pro lado pessoal. > não pode ser simplesmente chamada de lixo já que 95% dos dados serão > extremamente úteis Lixo com certeza não é, nunca foi dito nada nem perto desse nível. Mas acho que deve haver um plano para corrigir os 5% combinado com a comunidade, senão esses 5% serão esquecidos. -- Fernando Trebien ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber
On Thu, Feb 14, 2019 at 6:03 PM Peter Krauss wrote: > Resumindo o que talvez seja um posicionamento pessoal, convém conferir se > alguém concorda: > > * a métrica de erros para fazer sentido nas nossas discussões precisa ser da > metodologia assistida, não do algoritmo sozinho. Sim sim. A métrica eu levantei com o objetivo de determinar quanto trabalho manual temos pela frente, não é um critério de aceitação/rejeição. > * não se pode afirmar que "importação é coisa ruim", o que se pode afirmar é > que "a metodologia X com o algoritmo Y para os dados Z é ruim".. Até que se > prove o contrário. Com certeza, nunca afirmei que importação é algo ruim. Quanto à metodologia, eu aceito que sejam importados dados que contêm algum problema contanto que exista um plano para tratar do problema na sequência. O que não deve acontecer é importar dados sabendo do problema e simplesmente ignorar o problema depois, deixando pros outros o problema sem que os outros tenham aceito, daí acho falta de consideração com os colegas. -- Fernando Trebien ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber
É verdade, não participei desse processo e por isso nunca afirmei que foi um erro, o que não quer dizer que não é uma "bagunça" (o termo é o usado no wiki, até então eu estive chamando isso de "pendência"). É um problema que ninguém abraçou, nem eu, nem você, um exemplo do que acontece ao importar um monte de dados e deixar algo pra fazer depois sem ter um plano de quem/quando/como resolver. On Thu, Feb 14, 2019 at 6:06 PM Sérgio V. wrote: > > Bah, uma verdadeira "Bagunça". > Nossa. Espirrou perto. > > Mas de fato, se fosse feito hoje poderia ter sido muitas coisas diferente. > O cuidado com os dados é muito importante. Isso é uma parte da coisa. > Agora, com a verdade da circunstância completa, são outros quinhentos. > > Então, bom lembrar também que a proposta foi publicada na época. > Mais conversas e auxílios no telegram, por parte da "comunidade que mostrou > interesse". > Quem não opinou, não se importou com "bagunça" possível na ocasião, seria > minimamente honesto incluir no report que aceitou assim. > Mas já se conhece o funcionamento da coisa: seleção dos fatos que interessam. > E "bagunça" é coisa séria. Nossa, o mapa de Porto Alegre terminou imprestável > pra qualquer um usar. > > Publicação da proposta no Talk-br: 2016-04-25 > Início da Wiki: 2016-04-26 > Início da importação: changeset="38980822" timestamp="2016-04-29 > Encerramento da importação: changeset="40442780" timestamp="2016-07-02 > > Dois meses de processo. > Tempo para qualquer um (interessado) em se manifestar ao menos antes do fim > daquela importação. > > Os russos recentemente introduziram uma moda de andar jogando veneno. > Vou aproveitar pra tomar uma vacina, ou um antídoto, me esconder. A coisa tá > se espalhando. > > - - - - - - - - - - - - - - - - > > Sérgio - http://www.openstreetmap.org/user/smaprs > > > > > > De: Fernando Trebien > Enviado: quinta-feira, 14 de fevereiro de 2019 16:19 > Para: OpenStreetMap no Brasil > Assunto: Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em > importação de addr:housenumber > > ...Por exemplo, na importação dos edifícios em Porto Alegre, uma informação > foi colocada na etiqueta description, foi solicitado aos mapeadores > que fosse convertida em etiquetas consumíveis (geralmente amenity=*), > mas esse trabalho nunca foi feito por ninguém. A informação está lá no > OSM, parada há anos, sem usufruto pelas aplicações. Como diz o wiki > [2] num texto proveniente do original em inglês, "nunca suponha que > essas pessoas vão alegremente arrumar a bagunça que você fez."... > > > -- > Fernando Trebien > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber
On Thu, Feb 14, 2019 at 7:55 AM Peter Krauss wrote: > 2.2. Ponto oficial incompleto: pode ser importando? Essa é a discussão. As > fontes de informação na verdade existem, só que não é uma fonte única, pode > estar misturando verdade de campo, norma oficial (por exemplo leis de > nomenclatura de rua), dado oficial (ex. os pontos fornecidos pela > prefeitura), etc. O algorítomo mesmo sendo aberto é complexo e poucas pessoas > do OSM terão tempo e capacidade de avaliar. ESTÁ EM DISCUSSÃO, mas > precisamos primeiro arrumar a casa, chegar a uma descrição satisfatória no > "ponto oficial completo" (2.1 acima). Mesmo depois de discutir e chegar a um > consenso aqui precisaremos verificar com restante da comunidade OSM. > > 2.2.1. Com numeração (addr:housenumber) obtida por interpolação/proximidade. Acho que depende das características do dado original. Se o que ele tem é o endereço inicial e final de cada quadra, ou um endereço no meio de cada quadra, ele pode ser importado sem problema algum usando linhas interpoladoras, tal como se faz sem Buenos Aires e em alguns outras cidades do mundo, contanto que os pontos de endereço contenham o nome da rua. Seria indesejável interpolar o endereço gerando cada ponto intermediário. > 2.2.2. Com nome de rua (addr:street) obtido por proximidade. Entre poder/não poder eu prefiro responder isso com as consequências pro OSM de importar com ou sem um tratamento dos problemas dessa abordagem. Em Porto Alegre já constatamos que a projeção dos endereços nas ruas para obter o nome da rua produz cerca de 5% de endereços errados, ou seja, 1 erro em cada 20 endereços. Um dado com tantos erros não possui qualidade suficiente para suportar satisfatoriamente um serviço de geocodificação. Se, por exemplo, alguém quiser usar o mapa para oferecer um serviço de entregas ou de transporte individual, muitos endereços estarão a quilômetros de distância do local correto, o que obviamente seria bem ruim pra confiabilidade do serviço. Nesse caso, eu esperaria que o usuário simplesmente descartaria o OSM e adotaria um concorrente, como o Google Maps. Pior do que isso, se alguém quiser usar os endereços existentes para inserir pontos de interesse a partir de uma listagem local, os erros serão propagados e a correção exigirá mais esforço (talvez o dobro) do que se tivesse sido feita antes. Mesmo numa cidade do tamanho de Porto Alegre, a solução manual desses problemas exigiria um trabalho contínuo de ~2 semanas eu acho. Vale a pena considerando o benefício. Na maioria dos municípios (em geral pequenos) um trabalho desse tipo poderia ser feito completamente em poucas horas. Onde não houver mão-de-obra disposta a realizar a correção, acho que é fundamental no mínimo documentar (de preferência no wiki) que ficou pendente de correção, do contrário ninguém vai saber onde procurar os erros. Idealmente seria aberta também uma tarefa em algum sistema de gestão de tarefas para orientar e monitorar esse trabalho. Agora que temos o Kaart interessado em nos ajudar, podemos também tentar um contato com eles para que realizem as correções manualmente. Se este caso surgir com frequência em municípios diferentes, acho que vale a pena organizar um grupo de trabalho para fazer as correções manuais. Um grupo especializado assim estaria familiarizado com o tipo de erro desse processo e poderia trabalhar rápido e com menos erros humanos. Caso a etapa de documentar a correção não for feita, o resultado mais provável é que os erros permanecerão no mapa por um bom tempo e que serão esquecidos, prejudicando a confiabilidade dos dados. Por exemplo, na importação dos edifícios em Porto Alegre, uma informação foi colocada na etiqueta description, foi solicitado aos mapeadores que fosse convertida em etiquetas consumíveis (geralmente amenity=*), mas esse trabalho nunca foi feito por ninguém. A informação está lá no OSM, parada há anos, sem usufruto pelas aplicações. Como diz o wiki [2] num texto proveniente do original em inglês, "nunca suponha que essas pessoas vão alegremente arrumar a bagunça que você fez." Não estou dizendo que é obrigação de quem importa fazer a correção manual. O importante é traçar um plano de correção e engajar as pessoas que o executarão, e havendo interessados em fazer isso antes mesmo da importação, melhor ainda. Como você pode ver lá na discussão de Porto Alegre, há também questões relativas à limpeza de dados existentes. > O que acha? Podemos seguir com essa terminologia? importação de "ponto > invalido" (obviamente invalida), de "ponto oficial completo" e de "ponto > oficial incompleto". Eu chamaria isso de um endereço incompleto/insuficiente, não de inválido. O que realmente é inválido (em ~5% dos casos) é a heurística de projetar o endereço sobre a rua mais próxima, seja ela feita antes da importação ou feita pelo geocodificador caso a addr:street esteja faltando no endere
Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber
mport/Catalogue/Brazil_PMPA_Addresses_Import >>>>> >>>>> (esta questão é muito importante para esta e quaisquer outras importações >>>>> do tipo de "endereços") >>>>> >>>>> -Levantada a questão de que: >>>>> "para um endereço ser localizado no OSM, precisa ter ainda addr:street=*". >>>>> >>>>> -Problema: >>>>> Nos dados originais não tem registrado nome da rua. >>>>> O que pode ser obtido do original é: addr:housenumber=* + coordenadas. >>>>> >>>>> Necessidade (teórica ou real?): teria que complementar (adicionar) >>>>> addr:street=* para todos os 200.000 nós. (?!?) >>>>> >>>>> Dúvidas: Isso vale para qualquer endereço, para que possa ser localizado? >>>>> >>>>> Possibilidades de executar: >>>>> a) automatizado: gerando e adicionando valores de "nome de rua" por >>>>> análise de proximidade aos pontos: pode gerar erros; >>>>> b) manualmente: adicionando valores de "nome de rua" (preciso). >>>>> >>>>> Objeções: >>>>> >>>>> -É possível "retornar" o "nome de rua" por busca? Como com análise de >>>>> proximidade? Os aplicativos podem operar assim? Isso não pode deixar para >>>>> ser feito pelos aplicativos de localização/navegação, sob demanda? Se >>>>> isso for possível, não necessitaria adicionar valor de "nome de rua", nem >>>>> manualmente, nem automatizadamente. Simplesmente não adicionar >>>>> addr:street. >>>>> >>>>> -Se for real a "necessidade indispensável" de ter que constar ou >>>>> "adicionar" addr:street=* a cada nó importado de addr:housenumber=* >>>>> (mesmo onde não haja no original), então vai certamente inviabilizar >>>>> inúmeras possibilidades de importações de endereços. >>>>> >>>>> -Se tiver que adicionar, sobretudo "manualmente": trabalho gigantesco - >>>>> esqueça-se, eu não faço; outros se quiserem peguem os dados ali >>>>> disponibilizados e continuem. >>>>> De todo modo, certamente inviabiliza maior parte de futuras importações >>>>> em outros locais. >>>>> >>>>> - - - - - - - - - - - - - - - - >>>>> >>>>> Sérgio - http://www.openstreetmap.org/user/smaprs >>>>> >>>>> ___ >>>>> Talk-br mailing list >>>>> Talk-br@openstreetmap.org >>>>> https://lists.openstreetmap.org/listinfo/talk-br >>>> >>>> >>>> >>>> -- >>>> Pedro Esmerilho >>>> ___ >>>> Talk-br mailing list >>>> Talk-br@openstreetmap.org >>>> https://lists.openstreetmap.org/listinfo/talk-br >>> >>> ___ >>> Talk-br mailing list >>> Talk-br@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/talk-br >> >> ___ >> Talk-br mailing list >> Talk-br@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-br > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber
Só pra avisar que em Porto Alegre o Sérgio e eu estamos conversando no Telegram (no grupo Avançado do OSM). Constatamos ontem que a projeção produz cerca de 5% de endereços com nome de rua incorretos, mas fáceis de corrigir manualmente. Eu me dispus a fazer as correções manuais (e ainda estou estudando a possibilidade de automatizá-las parcialmente) onde necessário antes de submeter pro OSM, e também sugeri um cleanup nos endereços que já existem, para evitar duplicações e dados legados. As ideias ainda estão evoluindo e melhorando, um passo por vez. On Tue, 12 Feb 2019, 13:24 Peter Krauss Pedro, são mais argumentos a favor e concordo, mas a favor do que não > seria uma boa prática... A boa prática é já registrar o ponto com o nome de > rua, mas aí não seria o nome 100% certo, seria inferido por presunção de > proximidade com a rua... > > O que se comentou de saída para o dilema, que requer apoio na comunidade > geral do OSM, é estabelecer regras claras e consensuais para essa > presunção, e adicionalmente incluir uma tag de alerta "esse nome foi > inferido por computador" (tal como já fazemos com número de porta inferido > por interpolação). > > ... Quando comento "requer apoio na comunidade geral do OSM", é > fundamental, precisamos comparecer em bando, pois senão quem for atrás só > vai perder tempo e se queimar, como já ocorreu outras fazes: se a > comunidade-Brasil não começar a se portar como "autoridade do Brasil", a > OSMF e pessoal de outros países, que desconhecem nossa realidade, vão > continuar passando por cima, e nossas demandas continuarão "à margem"... > Você escreve em inglês? Alguém aqui poderia apoiar uma discussão em > inglês? > > > > On Tue, Feb 12, 2019 at 12:30 PM Pedro vida torta < > pedrovidator...@gmail.com> wrote: > >> Não vejo grandes problemas e importar sem o nome da via, teremos erros em >> esquinas que podem ser corrigidos com o tempo, a maioria dos aplicativos >> mostra a numeração no mapa e mesmo com o erro qualquer usuário pode achar >> visualmente, no caso em questão somente a numeração esta disponível e eu >> ficaria extremamente satisfeito com isso , já que colocar depois o nome da >> via depois e bem mais fácil. >> >> Em sex, 8 de fev de 2019 às 09:56, Sérgio V. >> escreveu: >> >>> Trago aqui questão levantada, >>> da necessidade (ou não) de ter addr:street: >>> >>> https://wiki.openstreetmap.org/wiki/Talk:Pt:Import/Catalogue/Brazil_PMPA_Addresses_Import >>> >>> (esta questão é muito importante para esta e quaisquer outras >>> importações do tipo de "endereços") >>> >>> -Levantada a questão de que: >>> "para um endereço ser localizado no OSM, precisa ter ainda >>> addr:street=*". >>> >>> -Problema: >>> Nos dados originais não tem registrado nome da rua. >>> O que pode ser obtido do original é: addr:housenumber=* + coordenadas. >>> >>> Necessidade (teórica ou real?): teria que complementar (adicionar) >>> addr:street=* para todos os 200.000 nós. (?!?) >>> >>> Dúvidas: Isso vale para qualquer endereço, para que possa ser localizado? >>> >>> Possibilidades de executar: >>> a) automatizado: gerando e adicionando valores de "nome de rua" por >>> análise de proximidade aos pontos: pode gerar erros; >>> b) manualmente: adicionando valores de "nome de rua" (preciso). >>> >>> Objeções: >>> >>> -É possível "retornar" o "nome de rua" por busca? Como com análise de >>> proximidade? Os aplicativos podem operar assim? Isso não pode deixar para >>> ser feito pelos aplicativos de localização/navegação, sob demanda? Se isso >>> for possível, não necessitaria adicionar valor de "nome de rua", nem >>> manualmente, nem automatizadamente. Simplesmente não adicionar >>> addr:street. >>> >>> -Se for real a "necessidade indispensável" de ter que constar ou >>> "adicionar" addr:street=* a cada nó importado de addr:housenumber=* (mesmo >>> onde não haja no original), então vai certamente inviabilizar inúmeras >>> possibilidades de importações de endereços. >>> >>> -Se tiver que adicionar, sobretudo "manualmente": trabalho gigantesco - >>> esqueça-se, eu não faço; outros se quiserem peguem os dados ali >>> disponibilizados e continuem. >>> De todo modo, certamente inviabiliza maior parte de futuras importações >>> em outros locais. >>> >>> - - - - - - - - - - - - - - - - >>> >>> Sérgio - http://www.openstreetmap.org/user/smaprs >>> ___ >>> Talk-br mailing list >>> Talk-br@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/talk-br >>> >> >> >> -- >> *Pedro Esmerilho* >> ___ >> Talk-br mailing list >> Talk-br@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-br >> > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br > ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber
On Fri, Feb 8, 2019 at 11:49 AM Sérgio V. wrote: > > De: Nelson A. de Oliveira > Enviado: sexta-feira, 8 de fevereiro de 2019 10:38 > > >É o que também indicam... > > Hum...São definições contraditórias: > -uma diz que "um programa pode" assumir o nome da rua mais próxima; > -outra que "deve" estar em "associatedStreet relation". Poder pode, mas nem sempre dá certo. Com frequência falha nas esquinas por causa da distância entre o ponto e as ruas. Como constam nas referências do Nelson, as aplicações esperam que esta seja a exceção e não a regra. > Afinal, qual diz o que efetivamente é necessário? > > Aí nestes casos surge a dúvida evidente: quem definiu assim, diferente? E por > quê? > Me parece que a definição parte mais de quem tem interesse no benefício do > uso do resultado do trabalho todo feito, > do que de quem tem que realizar o trabalho. Nesse momento nós estamos limitados pela capacidade das nossas ferramentas. Dependemos do ecossistema feito fora do Brasil. > Até agora, do que entendo, é o aplicativo, este sim, que vai se beneficiar > "sem esforço" nesta parte, > ganhar dados a mais de graça, como "mágica", para fazer a navegação de modo > mais "fácil" e "rápido"... > ...e ainda ganhar dinheiro com isso. A licença dos dados do OSM permite que qualquer consumidor ganhe dinheiro com o nosso trabalho, contanto que atribua ao OSM o crédito pelos dados. -- Fernando Trebien ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Obtida numeração predial da Prefeitura de Porto Alegre
Aproveitando o offtopic então, eu não conheço essa tecnologia, mas se você tiver a base instalada (e pelo que vi as versões mais recentes funcionam em Linux, Mac e Windows, e as mais antigas só em MS-DOS) a documentação diz que dá pra exportar os dados de duas formas: 1. Exportando a base toda para o SQL proprietário dessa base (pelo menos os dados seriam legíveis e talvez seja simples adaptar para SQL de tecnologias abertas como Postgres ou MySQL) [1] 2. Exportando o resultado de consultas diretamente para CSV [2] Talvez o caminho mais simples seja exportar o esquema das tabelas usando #1 para entender o modelo dos dados, e depois exportar os dados usando #2 fazendo um select pra cada tabela. Esse software me parece meio obscuro, acho difícil ter outro caminho senão instalando a própria ferramenta proprietária pra poder executar as exportações. [1] https://docs.raima.com/rdm/14_1/rdmexport.html [2] https://docs.raima.com/rdm/14_1/export.html On Fri, Feb 1, 2019 at 3:07 PM Vítor Rodrigo Dias wrote: > > Fernando, falando em sistemas proprietários outro dia me deparei com uma base > de dados em RAIMA, e até agora não consegui extrair nada dos arquivos... > achei isso num edital de licitação da Prefeitura de São João del Rei. > Em sex, 1 de fev de 2019 às 13:45, Fernando Trebien > escreveu: >> >> Valeu pelos links, vou ler com cuidado. O processo diz que o link não >> pode ser disponibilizado ao público ou que só é permitido o uso pelo >> requerente? Se não, não vejo razão para não compartilhar, nem que seja >> em privado. >> >> Não acho nada de pedantismo o que você disse (e também não quis dizer >> que você estava errado), as definições têm que estar tão claras quanto >> possível pra todo o mundo, e se existe esse sistema regional, valeria >> a pena escrever um guia de como configurar o QGIS e o JOSM para >> entenderem essas coordenadas. Da última vez que tive que converter >> coordenadas escritas em leis, achei informações desencontradas e >> confusas. Não quero fazer mal julgamento, mas não só na nossa >> prefeitura como nas outras eu às vezes suspeito de anti-transparência >> intencional. Povo não segue o decreto federal 8.777, onde inclusive o >> artigo 3 determina que o formato do dado disponibilizado tem que ser >> formato aberto. MDB (Microsoft Access), DWG (Corel Draw, que já vi >> muitas prefeituras usando) e XLS (Microsoft Excel, também muito usado) >> não são abertos, e pra quem possui as ferramentas proprietárias (as >> próprias prefeituras) não é difícil convertê-los para CSV/ODS/XML/JSON >> e PDF/SVG respectivamente. >> >> On Thu, Jan 31, 2019 at 8:14 PM Sérgio V. wrote: >> > >> > De: Fernando Trebien >> > Enviado: quinta-feira, 31 de janeiro de 2019 11:51 >> > Para: OpenStreetMap no Brasil >> > Assunto: Re: [Talk-br] Obtida numeração predial da Prefeitura de Porto >> > Alegre >> > >> > Legal. O DataPoa já disponibilizava o endereço inicial e final de cada >> > quadra, com o qual poderíamos importar os endereços na forma de >> > interpoladores. Com este conjunto, talvez possamos importar cada >> > endereço individual. Uma pena os dados estarem num formato >> > proprietário (MDB), mas acho que podemos contornar isso. Eu gostaria >> > de olhar esses dados para ver que qualidade têm e se têm problemas, >> > onde podem ser baixados? É interessante saber ao menos como estão >> > posicionados os endereços em relação aos lotes. Das discussões sobre a >> > importação dos endereços em Curitiba [1] me parece comum que sejam >> > colocados no centróide dos lotes, embora o consenso é de que devem ser >> > movidos para a face deles [2]. >> > >> > **O link não tá publico, foi disponibilizado ao email cadastrado no >> > processo. >> > >> > A maioria dos conjuntos de dados de endereços que vi até hoje costumam >> > ter problemas de precisão, ou de cadastro (nomes de ruas erradas ou >> > nomes antigos). No segundo caso, uma importação pelo JOSM deve >> > apresentar erros de validação. Acho que faria sentido sanar esses >> > problemas antes de inserir os dados no mapa. >> > >> > **Calma, não vai pro OSM ainda. Tou examinando, como falei. >> > Todo mundo vai poder ver antes de ir pro OSM. >> > >> > Esses sistemas de coordenadas obscuros (nacionais, que não estão >> > disponíveis nas ferramentas livres) também merecem ser melhor >> > documentados para que qualquer um possa verificar a conversão para um >> > sistema amplamente usado internacionalmente. Acho que o que você chama >> > de CRS TMPOA deve ser o mesmo que a lei
Re: [Talk-br] Obtida numeração predial da Prefeitura de Porto Alegre
Valeu pelos links, vou ler com cuidado. O processo diz que o link não pode ser disponibilizado ao público ou que só é permitido o uso pelo requerente? Se não, não vejo razão para não compartilhar, nem que seja em privado. Não acho nada de pedantismo o que você disse (e também não quis dizer que você estava errado), as definições têm que estar tão claras quanto possível pra todo o mundo, e se existe esse sistema regional, valeria a pena escrever um guia de como configurar o QGIS e o JOSM para entenderem essas coordenadas. Da última vez que tive que converter coordenadas escritas em leis, achei informações desencontradas e confusas. Não quero fazer mal julgamento, mas não só na nossa prefeitura como nas outras eu às vezes suspeito de anti-transparência intencional. Povo não segue o decreto federal 8.777, onde inclusive o artigo 3 determina que o formato do dado disponibilizado tem que ser formato aberto. MDB (Microsoft Access), DWG (Corel Draw, que já vi muitas prefeituras usando) e XLS (Microsoft Excel, também muito usado) não são abertos, e pra quem possui as ferramentas proprietárias (as próprias prefeituras) não é difícil convertê-los para CSV/ODS/XML/JSON e PDF/SVG respectivamente. On Thu, Jan 31, 2019 at 8:14 PM Sérgio V. wrote: > > De: Fernando Trebien > Enviado: quinta-feira, 31 de janeiro de 2019 11:51 > Para: OpenStreetMap no Brasil > Assunto: Re: [Talk-br] Obtida numeração predial da Prefeitura de Porto Alegre > > Legal. O DataPoa já disponibilizava o endereço inicial e final de cada > quadra, com o qual poderíamos importar os endereços na forma de > interpoladores. Com este conjunto, talvez possamos importar cada > endereço individual. Uma pena os dados estarem num formato > proprietário (MDB), mas acho que podemos contornar isso. Eu gostaria > de olhar esses dados para ver que qualidade têm e se têm problemas, > onde podem ser baixados? É interessante saber ao menos como estão > posicionados os endereços em relação aos lotes. Das discussões sobre a > importação dos endereços em Curitiba [1] me parece comum que sejam > colocados no centróide dos lotes, embora o consenso é de que devem ser > movidos para a face deles [2]. > > **O link não tá publico, foi disponibilizado ao email cadastrado no processo. > > A maioria dos conjuntos de dados de endereços que vi até hoje costumam > ter problemas de precisão, ou de cadastro (nomes de ruas erradas ou > nomes antigos). No segundo caso, uma importação pelo JOSM deve > apresentar erros de validação. Acho que faria sentido sanar esses > problemas antes de inserir os dados no mapa. > > **Calma, não vai pro OSM ainda. Tou examinando, como falei. > Todo mundo vai poder ver antes de ir pro OSM. > > Esses sistemas de coordenadas obscuros (nacionais, que não estão > disponíveis nas ferramentas livres) também merecem ser melhor > documentados para que qualquer um possa verificar a conversão para um > sistema amplamente usado internacionalmente. Acho que o que você chama > de CRS TMPOA deve ser o mesmo que a lei chama de SCR-POA [3]. > > **Isso, a lei chama assim. Mas não quer dizer que eu chamo errado, rsrs. > A prefeitura usa, englobando nisso a Projeção "Transversa de Mercator para > Porto Alegre (TM-POA)": > Ítem 4.3 em https://drive.google.com/file/d/0B_23OQou8LVVS1d6SG5tY2xiems/view > (de http://www2.portoalegre.rs.gov.br/spm/default.php?p_secao=345) > "a partir da publicação do Decreto n° 18.315 a PMPA passa a adotar o Sistema > Cartográfico de Referência definido pelo sistema geodésico de referência > SIRGAS2000 e projeção cartográfica TM-POA" > Justamente para adaptar melhor ao sistema amplamente usado > internacionalmente, como o SIRGAS2000 o é em relação a WGS84, apenas usando > um projeção TM adequada a PoA. > Também como no material em Shapefile da PMPA: EDIFICACOES_TM-POA.shp. > Já vem assim pra configurar CRS completa, como no QGIS. Por isso CRS=TMPOA. > Por praticidade. > (fecho minha sessão pedantismo, rsrs) > > [1] > https://lists.openstreetmap.org/pipermail/talk-br/2018-November/012460.html > [2] https://wiki.openstreetmap.org/wiki/Pt:Curitiba/Importa%C3%A7%C3%A3o_IPPUC > [3] > https://leismunicipais.com.br/a/rs/p/porto-alegre/decreto/2013/1831/18315/decreto-n-18315-2013-institui-o-sistema-cartografico-de-referencia-de-porto-alegre-scr-poa > > > > > - - - - - - - - - - - - - - - - > > Sérgio - http://www.openstreetmap.org/user/smaprs > > > > > > On Wed, Jan 30, 2019 at 11:47 AM Sérgio V. wrote: > > > > Prezados/as, > > > > Agradecendo inicialmente sobretudo ao Thierry Jean, que pelos contatos em > > eventos conseguiu indicar as pessoas responsáveis nos órgãos públicos, aqui > > no caso no setor de Coordenação de Geoprocessamento, da Secretaria > > Municipal da Faz
Re: [Talk-br] Obtida numeração predial da Prefeitura de Porto Alegre
Legal. O DataPoa já disponibilizava o endereço inicial e final de cada quadra, com o qual poderíamos importar os endereços na forma de interpoladores. Com este conjunto, talvez possamos importar cada endereço individual. Uma pena os dados estarem num formato proprietário (MDB), mas acho que podemos contornar isso. Eu gostaria de olhar esses dados para ver que qualidade têm e se têm problemas, onde podem ser baixados? É interessante saber ao menos como estão posicionados os endereços em relação aos lotes. Das discussões sobre a importação dos endereços em Curitiba [1] me parece comum que sejam colocados no centróide dos lotes, embora o consenso é de que devem ser movidos para a face deles [2]. A maioria dos conjuntos de dados de endereços que vi até hoje costumam ter problemas de precisão, ou de cadastro (nomes de ruas erradas ou nomes antigos). No segundo caso, uma importação pelo JOSM deve apresentar erros de validação. Acho que faria sentido sanar esses problemas antes de inserir os dados no mapa. Esses sistemas de coordenadas obscuros (nacionais, que não estão disponíveis nas ferramentas livres) também merecem ser melhor documentados para que qualquer um possa verificar a conversão para um sistema amplamente usado internacionalmente. Acho que o que você chama de CRS TMPOA deve ser o mesmo que a lei chama de SCR-POA [3]. [1] https://lists.openstreetmap.org/pipermail/talk-br/2018-November/012460.html [2] https://wiki.openstreetmap.org/wiki/Pt:Curitiba/Importa%C3%A7%C3%A3o_IPPUC [3] https://leismunicipais.com.br/a/rs/p/porto-alegre/decreto/2013/1831/18315/decreto-n-18315-2013-institui-o-sistema-cartografico-de-referencia-de-porto-alegre-scr-poa On Wed, Jan 30, 2019 at 11:47 AM Sérgio V. wrote: > > Prezados/as, > > Agradecendo inicialmente sobretudo ao Thierry Jean, que pelos contatos em > eventos conseguiu indicar as pessoas responsáveis nos órgãos públicos, aqui > no caso no setor de Coordenação de Geoprocessamento, da Secretaria Municipal > da Fazenda / Prefeitura Municipal de Porto Alegre. > Ajudam muito estes contatos para auxiliar aos respectivos organismos > conhecerem a utilidade e importância de disponibilizarem os dados ao OSM, bem > como auxiliar a nós demais membros da comunidade no caminho dos processos > para obtê-los efetivamente, nas variadas dimensões de colaboração ao OSM. > > Sendo assim, conforme indicado, protocolei em 09/01/2019 abertura de Processo > Administrativo comum, como pessoa física, na Prefeitura Municipal de Porto > Alegre. > Em despacho final hoje 30/01/2019 (20 dias ao todo), a Prefeitura autorizou o > uso do material nas condições requeridas do OSM, e liberou o material para > download com link temporário no processo. > Baixado o material. Veio compactado em .7z 88,0MB. > Descompactado, são 515 MB em 01 arquivo .mdb, contendo 16 planilhas. > Pelo que vi inicialmente, georreferenciadas em coordenadas UTM metros (deve > estar em CRS TMPOA, padrão da Prefeitura de Porto Alegre dentro do sistema > SIRGAS2000). > A examinar mais. > > Próximos passos são, a princípio: > -examinar e organizar o material, preparando em proposta de importação > segundo padrões do OSM; > -realizar os testes necessários e examinar compatibilização com o existente > no OSM; > -abrir uma página wiki própria (sugestão de nome e indexação?) contendo a > documentação com comprovação de liberação da Prefeitura, e demais descrições > técnicas do material e da proposta de importação, pubicando assim para > apreciação da comunidade OSM no Brasil; > -obter aprovação formal da comunidade OSM no Brasil; > -proceder à execução da importação; > -eventuais outras etapas que se mostrarem necessárias. > > - - - - - - - - - - - - - - - - > > Sérgio - http://www.openstreetmap.org/user/smaprs > > _______ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] BH Map como fonte de dados
Lá embaixo do mapa diz © Prodabel. Então, é necessário saber se os dados são posse da Prodabel ou não. Se sim, pode ser interessante perguntar se está tudo protegido por licença ou se alguns dados (especialmente nomes de ruas) são de domínio público. Às vezes é só a geometria que é coberta pela licença. Se for isso, não está proibido olhar pro mapa deles pra ver onde falta alguma rua e traçar no OSM usando a imagem do Bing. On Mon, Nov 12, 2018 at 3:58 PM Vitor George wrote: > > Oi Alexandre, > > Bem-vindo à comunidade do OpenStreetMap. Antes de usar os dados é preciso > esclarecer com a prefeitura se os dados estão em domínio público ou sob uma > licença compatível com a Open Database License: > > https://www.openstreetmap.org/copyright > > Pelo que consegui ver no BH Map, não há informações sobre a licença dos > dados. Desta maneira, é preciso confirmar com os responsáveis as condições de > uso e, se possível, pedir para eles incluírem esta informação no site. > > Abraços, > Vitor > > > > Em sáb, 10 de nov de 2018 às 02:36, Alexandre Oliveira > escreveu: >> >> Ei pessoal! >> >> Sou um novato, contribui algumas edições acredito que há 2 anos, e meu >> interesse pelo OSM foi despertado novamente. >> >> >> Gostaria de saber se eu poderia usar o BH Map[1] como fonte para as >> edições? Não apenas como consulta, mas, por exemplo, para estabelecer a >> área de casas, edifícios, etc. Parece que o sistema deles já tem >> delimitado as áreas construídas, o que facilitaria muito, em vez de >> ficar usando a imagem aérea fornecida pelo OSM. >> >> >> [1] http://bhmap.pbh.gov.br/v2/mapa/ >> >> Obrigado! >> Alexandre >> >> >> ___ >> Talk-br mailing list >> Talk-br@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-br > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Road network improvements in Brazil
I forgot to mention, there was another interesting forum thread regarding the classification of trunks in the entire country. While most mappers agreed we need to raise at least some primaries to the trunk level, there hasn't been consensus on the exact criteria that should be used. [1][2] Also, there is an undocumented (but openly discussed [3]) agreement that the definition of motorway should be slightly relaxed, since many highways fulfill the international criteria without fully implementing access control. [1] https://forum.openstreetmap.org/viewtopic.php?id=59392 [2] https://forum.openstreetmap.org/viewtopic.php?id=52982 [3] https://forum.osm.org/viewtopic.php?pid=700528#p700528 On Fri, Nov 9, 2018 at 2:57 PM Fernando Trebien wrote: > > Hi Andrew, > > Classification is a hotly debated topic that surely deserves more > attention, with many controversial proposals as written in the > article. The system proposed in the article dates back to 2013 and has > been heavily criticised, producing fragmentary networks in regions > with many unpaved roads (most places in Brazil except the most > developed regions along the coast). Recently there has been a very > interesting forum thread focused on rural highway classification in > the southermost state of Rio Grande do Sul [1], where mappers have > agreed to diverge from the system proposed in 2013 (what's on the wiki > right now). > > The wiki does not talk about urban street classification. The > Brazilian community has agreed to try to follow municipal plans as > closely as possible. So far, only the street classification in the > region of Porto Alegre is documented in detail [2]. We have gathered > the official street classification of many cities [3], but most have > not been reviewed yet, a few have been reviewed but not documented. In > Santa Maria [4], some classification has been done but the mappers > have stated that they did not base their work on the community's > agreement, instead following an approach more similar to that of 2013. > > [1] https://forum.openstreetmap.org/viewtopic.php?id=62430 > [2] > https://wiki.openstreetmap.org/wiki/Pt:Porto_Alegre,_Rio_Grande_do_Sul/Sistema_Vi%C3%A1rio > [3] > https://wiki.openstreetmap.org/wiki/Category:Cidades_com_hierarquia_vi%C3%A1ria_oficial > [4] > https://wiki.openstreetmap.org/wiki/Santa_Maria,_Rio_Grande_do_Sul/Sistema_Vi%C3%A1rio > On Fri, Nov 9, 2018 at 2:38 PM Andrew Wiseman > wrote: > > > > Hello OSM Brazil, > > > > My name is Andrew Wiseman, I work for Apple on the Maps team. My team is > > interested in doing some work on the road network in Brazil on > > OpenStreetMap, things like adding missing roads, making sure roads connect > > properly, fixing incorrect alignments with GPS traces, ensuring road > > classifications are consistent, and other similar issues. > > > > Are there places you know of that need improvement or types of problems you > > see frequently? Also I saw these guidelines about road classifications, are > > they the most recent classifications used by the community, or are there > > any others we should be aware of? > > https://wiki.openstreetmap.org/wiki/Pt:How_to_map_a > > > > We have a Github page here about the project: > > https://github.com/osmlab/appledata/issues/126 > > > > Please let me know if you have any suggestions or feedback. > > > > Thank you, > > Andrew > > Apple, Inc. > > > > > > Andrew Wiseman | Maps | andrew_wise...@apple.com > > ___ > > Talk-br mailing list > > Talk-br@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/talk-br > > > > -- > Fernando Trebien -- Fernando Trebien ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Road network improvements in Brazil
On Fri, 9 Nov 2018, 14:57 Fernando Trebien In > Santa Maria [4], some classification has been done but the mappers > have stated that they did not base their work on the community's > agreement, instead following an approach more similar to that of 2013. > Actually, the documentation seems a bit contradictory. It states that they classified according to the offifial types of streets, but also state they did not use the official data as basis for their work. So I'm not sure what's the actual status there. On Fri, Nov 9, 2018 at 2:38 PM Andrew Wiseman > wrote: > > > > Hello OSM Brazil, > > > > My name is Andrew Wiseman, I work for Apple on the Maps team. My team is > interested in doing some work on the road network in Brazil on > OpenStreetMap, things like adding missing roads, making sure roads connect > properly, fixing incorrect alignments with GPS traces, ensuring road > classifications are consistent, and other similar issues. > > > > Are there places you know of that need improvement or types of problems > you see frequently? Also I saw these guidelines about road classifications, > are they the most recent classifications used by the community, or are > there any others we should be aware of? > https://wiki.openstreetmap.org/wiki/Pt:How_to_map_a > > > > We have a Github page here about the project: > https://github.com/osmlab/appledata/issues/126 > > > > Please let me know if you have any suggestions or feedback. > > > > Thank you, > > Andrew > > Apple, Inc. > > > > > > Andrew Wiseman | Maps | andrew_wise...@apple.com > > _______ > > Talk-br mailing list > > Talk-br@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/talk-br > > > > -- > Fernando Trebien > ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Road network improvements in Brazil
Hi Andrew, Classification is a hotly debated topic that surely deserves more attention, with many controversial proposals as written in the article. The system proposed in the article dates back to 2013 and has been heavily criticised, producing fragmentary networks in regions with many unpaved roads (most places in Brazil except the most developed regions along the coast). Recently there has been a very interesting forum thread focused on rural highway classification in the southermost state of Rio Grande do Sul [1], where mappers have agreed to diverge from the system proposed in 2013 (what's on the wiki right now). The wiki does not talk about urban street classification. The Brazilian community has agreed to try to follow municipal plans as closely as possible. So far, only the street classification in the region of Porto Alegre is documented in detail [2]. We have gathered the official street classification of many cities [3], but most have not been reviewed yet, a few have been reviewed but not documented. In Santa Maria [4], some classification has been done but the mappers have stated that they did not base their work on the community's agreement, instead following an approach more similar to that of 2013. [1] https://forum.openstreetmap.org/viewtopic.php?id=62430 [2] https://wiki.openstreetmap.org/wiki/Pt:Porto_Alegre,_Rio_Grande_do_Sul/Sistema_Vi%C3%A1rio [3] https://wiki.openstreetmap.org/wiki/Category:Cidades_com_hierarquia_vi%C3%A1ria_oficial [4] https://wiki.openstreetmap.org/wiki/Santa_Maria,_Rio_Grande_do_Sul/Sistema_Vi%C3%A1rio On Fri, Nov 9, 2018 at 2:38 PM Andrew Wiseman wrote: > > Hello OSM Brazil, > > My name is Andrew Wiseman, I work for Apple on the Maps team. My team is > interested in doing some work on the road network in Brazil on OpenStreetMap, > things like adding missing roads, making sure roads connect properly, fixing > incorrect alignments with GPS traces, ensuring road classifications are > consistent, and other similar issues. > > Are there places you know of that need improvement or types of problems you > see frequently? Also I saw these guidelines about road classifications, are > they the most recent classifications used by the community, or are there any > others we should be aware of? > https://wiki.openstreetmap.org/wiki/Pt:How_to_map_a > > We have a Github page here about the project: > https://github.com/osmlab/appledata/issues/126 > > Please let me know if you have any suggestions or feedback. > > Thank you, > Andrew > Apple, Inc. > > > Andrew Wiseman | Maps | andrew_wise...@apple.com > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Cedência dos dados de cartografia da IPPUC de Curitiba / Importação de numeração predial
On Tue, Nov 6, 2018 at 10:52 AM santamariense wrote: > O reposicionamento do centroide > para junto dos logradouros será feito antes de se enviar ao OSM. Ah ok então. É bastante trabalho, mas de fato é o ideal. -- Fernando Trebien ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Cedência dos dados de cartografia da IPPUC de Curitiba / Importação de numeração predial
On Mon, Nov 5, 2018 at 8:36 PM santamariense wrote: > > 2. Atribuir o endereço à entrada do lote, do lado de dentro. É feito > > assim em Berlim, Amsterdã, Paris, Madri e partes de Londres e Nova > > Iorque. > > É essa que está sendo proposta. Por ora eu acho ok. Mas gostaria de desdobrar esse ponto para o longo prazo, não só em Curitiba mas também em outras cidades. O centróide do lote é diferente da entrada. Colocar o endereço na entrada reduz o número de erros de projeção do endereço na via (mais comuns nas esquinas), que é a primeira etapa do roteamento. Ainda sobram casos particulares, mas menos. A minha questão, então, é se seria preferível no OSM, no longo prazo, mover os pontos do centróide para a entrada, ou até mesmo eliminar o ponto do centróide e transferir o endereço para o edifício ou lote quando estiver mapeado. -- Fernando Trebien ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Cedência dos dados de cartografia da IPPUC de Curitiba / Importação de numeração predial
"É gerado o centroide dos lotes" Essa é a parte que acho que deveria ser discutida. Ninguém me respondeu ainda no fórum. [1] O costume tem sido um dos seguintes: 1. Atribuir o endereço ao lote todo, ou a um prédio que ocupa o lote. É feito assim em Moscou e partes de Londres e Nova Iorque. 2. Atribuir o endereço à entrada do lote, do lado de dentro. É feito assim em Berlim, Amsterdã, Paris, Madri e partes de Londres e Nova Iorque. 3. Usar linhas interpoladoras junto às entradas dos lotes, do lado de dentro. É feito assim em Toronto, e Buenos Aires. A opção 3 só é possível em lugares que adotam numeração métrica, como é o caso de Porto Alegre e como parece ser o caso de Curitiba (o incremento da numeração correspondeu ao tamanho dos segmentos no conjunto "Eixos de rua" em todos os segmentos que testei). A questão que acho relevante é, tendo a opção, se preferimos criar um ponto para cada endereço ou se preferimos criar uma linha interpoladora. A segunda opção certamente é mais fácil de manter e permite geocodificação independente de se dividir os lotes futuramente (é mais robusta), mas não permite responder à questão de se um determinado número de lote existe ou não na realidade (exceto se a numeração for sequencial e não métrica). A proposta original [2] e o texto atual no wiki parece sugerir que, tendo a opção, o preferível é ter cada número individual e não a linha interpoladora, mas a única coisa que se ganha com isso é poder responder se o número existe ou não. Digamos que a opção escolhida seja a 1 ou a 2. Ainda restaria decidir se: 1. O ponto do endereço deve conter o nome da rua, como é feito em Berlim, Amsterdã, Paris e algumas partes de Londres, e também nos números dos interpoladores em Toronto e Buenos Aires 2. O ponto do endereço não deve conter o nome da rua mas deve estar vinculado à rua por uma relação do tipo street, como proposto pelo Anderson no fórum noutra discussão [3] [1] https://forum.openstreetmap.org/viewtopic.php?pid=723264#p723264 [2] https://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Karlsruhe_Schema [3] https://forum.openstreetmap.org/viewtopic.php?pid=688853#p688853 On Thu, Nov 1, 2018 at 10:49 PM santamariense wrote: > > Então pessoal, dando sequência apresento um detalhamento de qual > arquivo será usado, quais campos ("tags") ele tem, e quais desses > campos parecem ser úteis. O detalhamento está documentado em > https://wiki.openstreetmap.org/w/index.php?title=Curitiba/Importa%C3%A7%C3%A3o_IPPUC&oldid=1688307 > > Caso alguém tenha alguma sugestão de mudança de metodologia apresente > o mais breve possível, para que a comunidade possa analisar e de comum > acordo implementar. > > []'s > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
[Talk-br] Atualização da definição de surface=cobblestone:flattened
Prezados, O artigo sobre surface=* foi traduzido pela primeira vez no início desse ano [1], e nele foi colocada uma definição para surface=cobblestone:flattened que não corresponde a nenhuma das definições que existiram no wiki inglês (ou em qualquer outro). Na mesma data, o artigo em inglês [2] definia este valor assim: "One of three tags used to describe sett surface. This is neither a correct name, like sett (cobblestone is by definition not shaped into any form), nor a colloquially used name, like cobblestone." De todo o período em que cobblestone:flattened esteve no wiki inglês, metade foi com esta definição, um pouco foi recomendando "usar sett no lugar de cobblestone:flattened", e o resto do tempo foi sem qualquer definição. [3] Não houve discussão a respeito até a que se deu no início desse ano que resultou num novo consenso [4] considerando o uso real que foi feito para esta e outras etiquetas similares. Além disso, pensando na referência do texto traduzido à "calçada portuguesa", o valor ainda é muito raro em calçadas [5] e pode haver formas mais interessantes de identificar esse tipo de pavimento e outros similares [6]. Eu gostaria de atualizar o artigo em português, sem que ninguém se sentisse ofendido, então gostaria de saber se há alguma objeção. O início do artigo traduzido justifica a tradução com uma discussão feita no Telegram. O texto da discussão só está disponível para quem tem Telegram para poder ingressar no grupo, tornando a discussão menos transparente do que teria sido usando os canais tradicionais da comunidade (lista de e-mail, fórum, página de discussão no wiki). Ainda assim, lendo a discussão que transcorreu no Telegram, não foi proposta a definição que consta hoje no wiki português, e também não foram considerados os usos feitos em outros países e o suporte das ferramentas do ecossistema do OSM. [1] https://wiki.openstreetmap.org/w/index.php?title=Template%3APt%3AMap_Features%3Asurface&type=revision&diff=1543243&oldid=1450813 [2] https://wiki.openstreetmap.org/w/index.php?title=Template:Map_Features:surface&oldid=1539260 [3] https://forum.openstreetmap.org/viewtopic.php?pid=681775#p681775 [4] https://forum.openstreetmap.org/viewtopic.php?id=61042 [5] https://taginfo.openstreetmap.org/keys/sidewalk%3Asurface#values [6] https://www.openstreetmap.org/user/Pieter%20Vander%20Vennet/diary/43120#comment40787 -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Como mapear Polícia Rodoviária?
2018-02-15 12:56 GMT-02:00 Fidelis Assis : > Verdade, dificulta encontrar o nome e mesmo confirmar se é polícia > rodoviária. Não seria melhor deixar em branco quando não se sabe? O problema é quando o mapeador acredita que sabe porque é isso o que ele está vendo lá no local. Nesse caso não temos como escapar de fazer uma revisão geral de tempos em tempos pra uniformizar os cadastros. Mas não havendo nome no local, de fato, é melhor deixar em branco. > Um pouco antes tem uma placa informando "Polícia Militar Rodoviária", o que > permite acrescentar police=traffic_police, já adotando a especialização: Perfeito. Se o posto for mapeado como área, também pode-se adicionar landuse=military no caso das polícias militares. > Pesquisando-se um pouco mais poderíamos completar com nome, endereço, > telefone e sigla: > > Base de São CarlosOPM:3º BPRv - 1ª Cia > Endereço:SP 310/3 Rodovia Washington Luís, 233,6 > Telefone:(16) 3371-3478 > > http://www.policiamilitar.sp.gov.br/unidades/cprv/quarteis_e_bases_pmrv.asp?pagina=3 +1 Sempre faço isso quando posso, não só com polícias. > Em SP, pelo que entendi, há mais de um batalhão de policia rodoviária (1º, > 2º, etc), coordenados pelo "Comando de Policiamento Rodoviário". Na minha > interpretação/sugestão, "3º Batalhão de Polícia Rodoviária" ou talvez > "Comando de Policiamento Rodoviário", aplicável para todos os postos em SP, > seria o valor para operator. > > http://www.policiamilitar.sp.gov.br/unidades/cprv/historico.asp Se o posto de polícia e o local das operações do batalhão forem a mesma coisa, então "3º Batalhão de Polícia Rodoviária" seria a identificação do posto (vai em name=* ou official_name=*) e "Comando de Policiamento Rodoviário" poderia ir em operator=*. -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Como mapear Polícia Rodoviária?
2018-02-15 11:32 GMT-02:00 Fidelis Assis : > Perfeito, apenas prefiro para name o nome por extenso, deixando sigla > possivelmente para ref. No OSM, existem várias etiquetas para nome [1] e código de referência [2], mas as etiquetas name=* e ref=* são de certa forma especiais porque precisam ser verificáveis a partir do que é observável no local [3]. O que vai nelas é particularmente importante para a renderização no site principal do OSM. Entendo que isso cria um pequeno problema no Brasil porque muitas vezes as pessoas se referem a certo lugar mais pelo acrônimo do que pelo nome completo (em boa parte porque muitos nomes completos são longos demais para serem práticos), ao ponto de o acrônimo ser adotado como identificação principal no local. Nessa situação, para a extração de dados, sugiro que seja implementada uma lógica relativamente simples: - se você preferir o acrônimo, procurar a etiqueta short_name, e caso não exista, procurar a etiqueta name - se você preferir o nome completo, procurar a etiqueta official_name, e caso não exista, procurar a etiqueta name Não é um problema simples, eu mesmo já alternei a minha visão a respeito várias vezes. Mas como o OSM é também uma rede social e a verificabilidade [4] é importante para os colegas realizando inspeção em campo, esse sistema é o que causa menos confusão. [1] https://wiki.openstreetmap.org/wiki/Key:name [2] https://wiki.openstreetmap.org/wiki/Key:ref [3] https://wiki.openstreetmap.org/wiki/Good_practice#Map_what.27s_on_the_ground [4] https://wiki.openstreetmap.org/wiki/Verifiability -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Como mapear Polícia Rodoviária?
Prezados, No caso das polícias rodoviárias federais, algumas etiquetas que podem vir sempre, além de amenity=police, são: 1. police=traffic_police ou police=road_police A etiqueta não-oficial police=* [1] segue a ideia geral usada em vários outros casos no OSM de definir novas etiquetas para especializar etiquetas mais genéricas. Como não é oficial, estaríamos adiantados, mas nada impede de usar se acharmos útil. Melhor ainda seria iniciar a discussão com a comunidade internacional para tentar definir ela bem. 2. operator=DPRF A etiqueta operator é uma anotação sem valores fixos. DPRF significa Departamento de Polícia Rodoviária Federal, e é o nome do órgão que administra todas as polícias rodoviárias federais do país. Mapeadores diferentes podem acabar optando por grafar de uma ou de outra forma. 3. description=Polícia Rodoviária Federal A etiqueta description também é uma anotação É feita para mapas clicáveis, como o OpenStreetBrowser. Em name=* deve ir a identificação do lugar conforme o que é observável no local. Pesquisei um pouco ("posto de polícia rodoviária" no Google Images) e há uma certa variabilidade na forma de esses postos policiais se identificarem visualmente, então acho que podemos tentar padronizar. Alguns exemplos: [2-14] Algo que sempre aparece é o texto "Polícia Rodoviária Federal" bem grande. Quase sempre também aparece o acrônimo respectivo, "PRF". Acho que quase sempre só há um posto por município, então muitos também se identificam como "Posto de [nome do município]". Isso, a princípio, está implícito pela geometria (pelo fato de o posto estar situado dentro da área do município). Muitos também identificam a superintendência regional a que pertencem, geralmente no formato "[número]ª SRPRF/[sigla do estado]", por exemplo, 12ª SRPRF/ES. SRPRF significa "Superintendência Regional de Polícia Rodoviária Federal". Assim como no município, o código do estado está implícito pela geometria e porque os estados têm a etiqueta short_name=* definida. Isso tudo sugere que esses postos poderiam ser identificados assim: 1. Se a sigla for mais saliente pra quem observa diretamente: - name="12ª SRPRF" - alt_name="12a SRPRF" - official_name="Décima Segunda Superintendência Regional de Polícia Rodoviária Federal do Espírito Santo" 2. Se o nome completo for mais saliente pra quem observa diretamente: - name="Décima Segunda Superintendência Regional de Polícia Rodoviária Federal do Espírito Santo" - short_name="12ª SRPRF" - alt_name="12a SRPRF" Ambos os casos são pesquisáveis no ecossistema do OSM (Nominatim) das seguintes formas (partes entre colchetes são opcionais): - "[número+ª/número+a/número por extenso] SRPRF, [estado/município]" : "12ª SRPRF, ES", "12a SRPRF, ES", "Décima Segunda SRPRF, Linhares" - "Polícia Rodoviária Federal, [município]" : "Polícia Rodoviária Federal, Linhares" Acho (mas não tenho certeza) que, nos casos em que a superintendência não está escrita bem grande, deve haver uma placa mais próxima da entrada com essa informação. Talvez precisemos de mais alguns exemplos. [1] https://taginfo.openstreetmap.org/keys/police [2] http://www.sitedelinhares.com.br/public/noticias/posto-da-policia-rodoviaria-federal-ainda-em-reformas.jpg [3] http://www.noca.com.br/fotos/novaprf1.jpg [4] http://www.portal25horas.com.br/wp-content/uploads/policia-rodoviaria-federal.jpg [5] http://www.gazetadopovo.com.br/ra/mega/Pub/GP/p2/2009/05/16/VidaCidadania/Imagens/policia_estradas_160509.jpg [6] http://www.guaranoticias.com.br/conteudo/9b643f6d2ea3556279c7a0d41a37d901.JPG [7] http://g1.globo.com/Noticias/Brasil/foto/0,,14798259,00.jpg [8] http://www.alagoas24horas.com.br/wp-content/uploads/2008/02/f061c05a994b41a7b0e89d36536463fc_prf.1.jpg [9] http://marcelolopes.jor.br/upload/noticias/20140407132025_755.jpg [10] http://3.bp.blogspot.com/-G092WrGAtAI/VJ2lNeAxUfI/PEY/FJudTI-rMQg/s1600/Foto_Posto_2014.jpg [11] http://4.bp.blogspot.com/-EGRP8W7X2rE/VkQREE7bKGI/ZNw/8SzZYnVfdjw/s1600/posto-prf-sobral.JPG [12] https://s03.video.glbimg.com/x720/5813374.jpg [13] http://www.girodegravatai.com.br/wp-content/uploads/2016/11/fd.png [14] https://cidadeportal.com.br/arquivos/f4bd37ee5aac47264fe6e1e361e76069/noticias/C09062017175920f01.jpg 2018-02-13 10:46 GMT-02:00 Fidelis Assis : > > > Em 11 de fevereiro de 2018 18:25, Vítor Rodrigo Dias > escreveu: >> >> Existe tag pra “highway patrol”? Como se diferencia nos eua? > > > Tentei ver se existe uma forma de se abrir "police" em categorias combinando > duas etiquetas, ex: > > amenity=police > police=highway_patrol > > mas não achei. > > Abraços, > -- Fidelis > > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br > -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
[Talk-br] Transporte público v2 e highway=bus_stop
Eu entendo que: - *public_transport=stop_position* representa o ponto de parada do ônibus [1] e deve ser um ponto na linha de uma via que é membro da rota do ônibus - *public_transport=platform* representa a área de espera dos passageiros [2], que pode ser ponto, linha ou área e deve ficar ao lado da via, separada dela - *highway=bus_stop* representa o ponto de embarque dos passageiros [3], e que deve ficar na plataforma; se a plataforma for uma área, deve ficar dentro dela ou no máximo na sua borda; se for uma linha deve ser um ponto ao longo da linha ou em um dos seus extremos; se for um ponto, deve se combinar com a tag public_transport=platform no mesmo ponto Também entendo que, ao migrar para a versão 2, não se deve remover highway=bus_stop, ou pelo menos não ainda [4]. Vocês concordam/discordam? [1] https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_position : *to identify the place where a vehicle stops along a public transport route* [2] https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dplatform : *to identify the places where passengers wait for public transport of any type* [3] https://wiki.openstreetmap.org/wiki/Tag:highway%3Dbus_stop : *is a place where passengers can board or alight from a bus* [4] https://github.com/gravitystorm/openstreetmap-carto/issues/311#issuecomment-221728439 -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Classificação viária (de novo)
Legal, avisei lá também! :D 2017-12-03 8:07 GMT-02:00 Gerald Weber : > Oi Fernando > > muito bom ver você na ativa de novo :) > > você deve estar estranhando a falta de reação à sua mensagem, ocorre que o > pessoal está levando as discussões para os grupos do telegram em especial > este daqui: https://telegram.me/OSMBrasil_Comunidade, o talk-br acabou > esvaziado em função disto. > > um grande abraço > > Gerald > > > > 2017-11-25 15:14 GMT-02:00 Fernando Trebien : > >> Gostaria de convidá-los a darem uma olhada neste post do fórum, sem >> pressa, e seguirem a discussão lá caso se interessem (por favor não inundem >> a lista de e-mails): >> >> https://forum.openstreetmap.org/viewtopic.php?pid=674296#p674296 >> >> Sei que chegar a um conseno quanto à classificação é difícil e que foi >> muito desgastante em 2013, só quero saber se há alguma forte objeção a essa >> proposta. Se houver, descarto a ideia direto ao invés de investir tempo >> (que não será pouco) para elaborá-la em nível nacional/continental. >> >> -- >> Fernando Trebien >> +55 (51) 99962-5409 <(51)%2099962-5409> >> >> "Nullius in verba." >> >> ___ >> Talk-br mailing list >> Talk-br@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-br >> >> > > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br > > -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
[Talk-br] Classificação viária (de novo)
Gostaria de convidá-los a darem uma olhada neste post do fórum, sem pressa, e seguirem a discussão lá caso se interessem (por favor não inundem a lista de e-mails): https://forum.openstreetmap.org/viewtopic.php?pid=674296#p674296 Sei que chegar a um conseno quanto à classificação é difícil e que foi muito desgastante em 2013, só quero saber se há alguma forte objeção a essa proposta. Se houver, descarto a ideia direto ao invés de investir tempo (que não será pouco) para elaborá-la em nível nacional/continental. -- Fernando Trebien +55 (51) 99962-5409 "Nullius in verba." ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Necessidade de intermediação
Muito interessante o Strava, adicionei ao wiki como ferramenta de apoio a QA. Bom saber que tem bastante gente usando os traçados que fiz no interior dos parques aqui. :D 2015-07-07 14:10 GMT-03:00 Aun Johnsen : > So para finalizar do meu lado > > Anexado [0] e um screenshot da mapa do trevo como era quando deu meu > 1º comentário no changeset do Marcio, com overlay do Strava. Quando > comentei o changeset não tinha motivo editar nada nesse trevo, so > queria ver se roteamento realmente era complicado e como Marcio tinha > editado trevo algum meses antes perguntei a ele. O overlay do Strava > claramente mostrando que a forma da trevo ainda era errado, e por caso > dos comentários que recebi decidi a editar o trevo adicionar dados > faltando por provas da Strava. > > Eu so mostrando aqui os dados eu tinha para adicionar os links que > adicionei. O Marcio ja queria coloque em duvida se esses fui dados > certos. Eu não mais vai comentar a isso, e para vocês, o comunidade do > OSM Brasil analizar e formar sue opinião. > > Eu nao vai responder esse assunto mais. Terminando aqui. Não quer mais > saber quem era certo ou errado, ou que dados no local e confiável ou > não. > > [0] http://i.imgur.com/Zkc16fn.png > > On 7/7/15, Fernando Trebien wrote: >> Recapitulando. >> >> Eu disse que conhecia suas credenciais. >> >> Você disse que não. Citou uma conversa para comprovar sem fornecer >> link para ela. >> >> Voltei ao tópico mostrando que conhecia e mostrando links. >> >> Agora você foge de novo puxando a conversa para uma lista que boa >> parte da talk-br não assina (e vice-versa: boa parte dos membros da >> CocarDL não assinam a talk-br) e à qual portanto não têm acesso. Sim, >> você citou isso lá, além de citar as mesmas credenciais que eu >> reproduzi acima. Qual a relevância disso aqui, me pergunto ainda. >> >> Seu novo argumento também não faz sentido porque você citou suas >> credenciais com GNSS aqui na talk-br também, 8° parágrafo: >> https://lists.openstreetmap.org/pipermail/talk-br/2014-January/004901.html >> >> 2015-07-07 9:43 GMT-03:00 : >>> Não é esse debate que me referi e sim o que travamos na lista CocarDL no >>> ano >>> passado >>> >>> -Mensagem Original- From: Fernando Trebien >>> Sent: Tuesday, July 7, 2015 3:17 AM >>> To: OpenStreetMap no Brasil >>> Subject: Re: [Talk-br] Necessidade de intermediação >>> >>> 2015-07-07 2:32 GMT-03:00 : >>>> >>>> Não conhece! >>>> As que conhece foram as apresentadas por mim e ligadas tão somente a >>>> navegação GNSS em réplica a você por ter apresentado as suas e querendo >>>> se >>>> prevalecer delas no debate. >>>> Esqueceu? >>>> Se necessário reproduzo aqui copia do debate. >>> >>> >>> Respondo apenas para o leitor casual tirar suas próprias conclusões. >>> Prefiro reproduzir links para discussões completas, não extratos >>> descontextualizados. >>> >>> 10º parágrafo: >>> https://lists.openstreetmap.org/pipermail/talk-br/2014-January/005052.html >>> 1ª parágrafo de resposta: >>> https://lists.openstreetmap.org/pipermail/talk-br/2015-July/010307.html >>> 14º comentário do changeset (8º do usuário Thundercel): >>> http://www.openstreetmap.org/changeset/30210630 >>> >>> >>> ___ >>> Talk-br mailing list >>> Talk-br@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/talk-br >> >> >> >> -- >> Fernando Trebien >> +55 (51) 9962-5409 >> >> "Nullius in verba." >> >> ___ >> Talk-br mailing list >> Talk-br@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-br >> > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Opinando 2
2015-07-07 13:54 GMT-03:00 : > Segundo a mídia esse acesso foi > aberto ao tráfego no ano passado. Veja em > http://newsrondonia.com.br/noticias/transito+der+abre+passagens+sob+a+br+364+na+regiao+do+trevo+do+roque/42394 > > Desenhei esse acesso de forma improvisada porque dele não tenho tracklog e > tampouco imagem atualizada para referência. Quando retirado da etiqueta em > construção é bem provável que requeira alinhamento.e por isso é bem provável > que requeira alinhamento. Isto vale como fonte da informação. Mas é a primeira vez que é citada na discussão toda. Idealmente teria sido incluída na etiqueta source do changeset, mas pode ser incluída também como resposta na discussão do changeset [1]. O que discutíamos não era a precisão do traçado e sim a permissão legal de copiar a informação sobre as conexões (qual entrada se conecta a qual saída) das fontes citadas (Here.com, Waze, e uma comunicação particular informal com um terceiro). > Segundo notícias na mídia ele já se encontra aberto ao tráfego, mas decidi > mante-lo com a etiqueta em construção para confirmar se está mesmo > operacional e seu real traçado. Notícias às vezes contêm erros, mas valem como fonte. Se tiver links para elas, por favor compartilhe, ajudará a concluir o debate. > Interessante que a fonte ilícita (Google Maps) já estampa esse acesso. > > Incrível a velocidade de atualização do Google nesse trevo. > Veja em > https://www.google.com.br/maps/place/Porto+Velho+-+RO/@-8.7714573,-63.8826919,19z/data=!4m2!3m1!1s0x92325b665998520b:0x75d0f25ad2c5198b Bem, aqui em Porto Alegre, metade da cidade sofreu vandalismo no Google Maps, mais de uma vez. Não dá pra confiar na correção dos dados, nem é legal a cópia. Não é um caso isolado, é um fenômeno mundial e atual: http://www.abc.es/tecnologia/redes/20150513/abci-google-maps-maker-vandalismo-201505131425.html [1] http://www.openstreetmap.org/changeset/30210630 -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Opinando 2
Iniciativa louvável, Helio. Sem dúvida precisamos de uma fonte adicional de informação pra resolver o problema. Contatei um mapeador local também. 2015-07-07 13:15 GMT-03:00 Helio Cesar Tomio : > Concordo com os comentários do Márcio Vinicius Pinheiro. > Como resolver todo este debate e por um fim nestas discussões pouco > produtivas? > Tomei a liberdade de enviar email para a Polícia Rodoviária, com print da > tela com o trevo. > Se responderem, ponto final para o debate. > Quem tiver interesse, pode fazer o mesmo enviando para a prefeitura, > departamento municipal de transportes, bombeiro, ... > Faço isto não por que duvide do mapeador, muito pelo contrário, porque > sempre foi uma pessoa empenhada no OSM, assim como todos que participam > desta comunidade. > Faço em defesa deste Fórum e da harmonia entre seus pares. > Debates, diferenças, são sempre bem vindos. Mas que sejam positivos e que > resultem em campo fértil para que o OSM cresça e frutifique no nosso país. > > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br > -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Opinando
2015-07-07 12:34 GMT-03:00 : > Quando você erra a culpa é do outro que lhe induziu ao erro. Nesse caso específico, foi sim. Mas essa generalização é sua tentativa de me desmoralizar. > Você aqui defendeu o mapeador local e naquela ocasião distorceu a edição > feita pelo mapeador local mesmo estando em contato com ele na lista Cocar se > valendo de imagens satélite desatualizadas e não confiando na informação do > editor que reside no local (eu). Vocẽ era novo aqui e certamente não conhecia um décimo das etiquetas que conhece hoje, eu usei as informações que você me passou para mostrar o que eu acreditava ser o certo, sabendo que era possível reverter a edição. Nossa conversa vinha em bom tom até esse momento. Antes que você me deixasse reverter, você saiu revertendo, e desde então retorna a esse assunto. Isso o qualifica como troll. Você não entende a fluidez do modelo do OSM. Acho que vou ter que escrever uma tese a respeito para defender meu argumento. Não que alguém vá ler. > Já citei que não vou repassar a mensagem de colaboração que recebi sobre o > Trevo de Porto Velho e tampouco o tracklog porque não gostei das mensagens > iniciais questionando minha palavra. Ok, direito seu. Direito meu não acreditar em você então. > Como informei fui questionado no changeset sobre a alteração e respondi a > fonte LÍCITA que me fez editar. Mesmo tendo informado a fonte me solicitaram > provas e isso, pelo menos para mim, é duvidar da minha integridade o que não > aceito em qualquer fórum. Direito seu. Não quer dizer que convença seus interlocutores. > Se você aceita duvidarem da sua palavra é outra estória e não entro no > mérito de caráter de quem quer que seja. Você construiu e tem o seu, eu o > meu. Ok. Mas as pessoas vão duvidar aceite você ou não. > Como já tivemos, você e eu, sérios desentendimentos na lista Cocar agora > quem vai se calar aqui serei eu e só responderei sobre qualquer fato > relacionado com este assunto aqueles que respeitam os demais que > voluntariamente contribuem com o OSM. Ótimo, não aguentava mais! Não esqueça que também contribuo voluntariamente né. > Não comentarei mais suas colocações e todos sabem que recentemente outro > importante colaborador adotou também aqui essa postura com você. Que conveniente citar isso sem referenciar as circunstâncias. Deixo com vocês as impressões do colega Pedro Santos, da lista talk-pt, sobre o ocorrido com o importante colaborador defendido pelo Márcio. São imensamente mais lúcidas do que a atual discussão. https://lists.openstreetmap.org/pipermail/talk-pt/2015-July/001179.html https://lists.openstreetmap.org/pipermail/talk-br/2015-July/010289.html > From: Fernando Trebien > Sent: Tuesday, July 7, 2015 11:33 AM > To: OSM talk-br > Subject: Re: [Talk-br] Opinando > > > Com respostas desse tamanho não pode reclamar de TL;DR. > > Naquela ocasião você me induziu ao erro com imagens que não representavam > adequadamente o local. Com informação errada, eu só podia deduzir que você > tinha se confundido. Você me informou corretamente muito depois da minha > alteração, e eu então aceitei o que você fez, mas você não entendeu que me > confundiu e desde então tenta dar a entender que estraguei o mapa > intencionalmente, distorcendo completamente a situação. Deve ser a décima > vez que você traz essa história à tona e que eu tenho que explicar > exatamente a mesma coisa. > > Na ocasião atual, uma edição num local onde você não esteve recentemente, só > falta você copiar a mensagem do seu informante para resolver o impasse. Você > diz que tem, mas nega compartilhá-la devido a questões morais pessoais. Se é > assim posso inventar questões morais a torto e direito para defender > qualquer coisa que eu faça também. > > > _______ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br > -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Opinando
2015-07-07 10:53 GMT-03:00 Márcio Vinícius Pinheiro : > Eu acho muito louco que dêem preferência a uma verificação a distância e > pelo Bing(!) em detrimento do que foi alegadamente mapeado in loco. Não houve mapeamento in loco porque o mapeador que fez o changeset nunca esteve no local. A alegação feita por um terceiro não foi apresentada, apesar de o mapeador dizer que detém cópia dela. > Estamos aqui falando em comprovar o óbvio, a coisa está lá, é só ir lá ver. Quem? Nem nós, nem o mapeador se dispôs a fazer isso. Não há mapeadores locais envolvidos que tenham se disposto também. Contatei um, mas não obtive resposta ainda. > Entendo a necessidade de se questionar o mapeador em caso de dúvida (e > entendo que o questionado não deve tomar isso como uma ofensa e tem a > obrigação de responder, por mais cansativo que seja), mas entendo também que > a palavra do mapeador pode ter muito mais valor do que qualquer dessas > fontes desatualizadas da Internet. Claro. Contanto que ninguém do Waze leia essa conversa, que, aliás, é pública. Até o momento, só sei ao certo que foram consultadas fontes ilícitas. A parte da alegação do terceiro eu acreditava ser verdade até que se negaram a apresentá-la mesmo dizendo que a tinham. > Talvez devêssemos usar o princípio de que o ônus da prova seja do > "acusador". Nós sempre preferimos a rota mais segura porque o ônus da prova é grande e somos poucos e não detemos a informação final para produzir esse ônus. Mas uma acusação formal vindo de uma das grandes empresas pode ser catastrófica para o OSM no Brasil, especialmente se se estabelecer a prática de copiar informações desses sistemas. > Fotos do Bing (desatualizadas), mapas do IBGE (imprecisos) entre > outros não podem ser provas irrefutáveis. Ninguém disse isso. > Não acho que mapear apenas o que > já está mapeado em outras fontes seja o objetivo do OSM. O objetivo do OSM é ter um mapa do mundo todo. Isso inclui as informações dessas fontes. Quão importante é se igualar a uma fonte ou outra depende da preferência do mapedor. Menu "Sobre" na página principal: https://www.openstreetmap.org/about > Uma coisa é reverter algo devido à suspeita de terem sido utilizadas fontes > ilegais (paga-se pouco nesse caso, quando a suspeita é forte - tipo, se > questionado, o mapeador não responde nada, ou cita as fontes ilegais), outra > coisa é "corrigir" o mapeamento de uma área com base em informações antigas > sem ter como comprovar que não houve mudanças mais recentes. O problema é que até o momento a única comprovação é uma informação que diz-se que circulou no boca-a-boca e que diz-se que foi corroborada por fontes ilícitas. > Acho saudável discutir o primeiro caso: até que ponto paga-se pouco por uma > suspeita? Se houvesse um mapeador no local, pouquíssimo. Mas não há, então paga-se mais - mas também engaja-se novos colaboradores no local. > No segundo caso, a resposta é simples: não mexa naquilo que não conhece. O que leva à seguinte recomendação (mesma que fiz ontem): mapeie apenas o local onde mora, ou se mapear fora, acumule registros para mostrar que conhece o local. Dizer que conhece qualquer um pode dizer sobre qualquer local, daí vira uma festa. > Temos que confiar até o momento em que virmos com nossos próprios olhos (não > fotos aéreas de 2009, ou relatos imprecisos) o que está errado. Sem dúvida não se pode mapear com base em suposições. Por isso, registros valem mais do que alegações que ainda não foram apresentadas. > Mapear remotamente é útil para as áreas ainda não mapeadas. Mas há limites legais sobre o que se pode fazer remotamente. Senão seria muito fácil plagiar outros mapas e dizer que foi tudo trabalho seu. > Para correções, > apenas com dados atualizados (e preferência para dados obtidos in loco). E > reversão, apenas em casos claros de vandalismo ou utilização de fontes > ilegais ou ilegítimas. Não sei por quê tanto mimimi. Também não sei. É a via mais discutida na história do OSM Brasil. Já recomendei que não se apeguem tanto ao próprio trabalho. Vários trabalhos meus já foram "desfeitos" (foram alterados, nem sempre do jeito certo, mas cada um interpreta como quer), se eu abrisse uma discussão sobre cada um deles, ninguém mais mapeava no Brasil. > Atenciosamente, > Márcio Vinícius Pinheiro. > http://about.me/Doideira -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Necessidade de intermediação
Recapitulando. Eu disse que conhecia suas credenciais. Você disse que não. Citou uma conversa para comprovar sem fornecer link para ela. Voltei ao tópico mostrando que conhecia e mostrando links. Agora você foge de novo puxando a conversa para uma lista que boa parte da talk-br não assina (e vice-versa: boa parte dos membros da CocarDL não assinam a talk-br) e à qual portanto não têm acesso. Sim, você citou isso lá, além de citar as mesmas credenciais que eu reproduzi acima. Qual a relevância disso aqui, me pergunto ainda. Seu novo argumento também não faz sentido porque você citou suas credenciais com GNSS aqui na talk-br também, 8° parágrafo: https://lists.openstreetmap.org/pipermail/talk-br/2014-January/004901.html 2015-07-07 9:43 GMT-03:00 : > Não é esse debate que me referi e sim o que travamos na lista CocarDL no ano > passado > > -Mensagem Original- From: Fernando Trebien > Sent: Tuesday, July 7, 2015 3:17 AM > To: OpenStreetMap no Brasil > Subject: Re: [Talk-br] Necessidade de intermediação > > 2015-07-07 2:32 GMT-03:00 : >> >> Não conhece! >> As que conhece foram as apresentadas por mim e ligadas tão somente a >> navegação GNSS em réplica a você por ter apresentado as suas e querendo se >> prevalecer delas no debate. >> Esqueceu? >> Se necessário reproduzo aqui copia do debate. > > > Respondo apenas para o leitor casual tirar suas próprias conclusões. > Prefiro reproduzir links para discussões completas, não extratos > descontextualizados. > > 10º parágrafo: > https://lists.openstreetmap.org/pipermail/talk-br/2014-January/005052.html > 1ª parágrafo de resposta: > https://lists.openstreetmap.org/pipermail/talk-br/2015-July/010307.html > 14º comentário do changeset (8º do usuário Thundercel): > http://www.openstreetmap.org/changeset/30210630 > > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Opinando
ET sobre esse Trevo do Roque em Porto Velho. > > Uma das vias desenhadas por mim no novo Trevo teve como referencia um > tracklog já constante da base OSM e as demais as fiz de forma aproximada > conforme me foi passado verbalmente. > > Em paralelo decidi também pesquisar como esse trevo estava retratado nas > fontes ilícitas e nelas identifiquei que o Waze e o Here já retratam o novo > Trevo. > > []s > Marcio > > > > []s > Marcio > > -Mensagem Original- > From: Fernando Trebien > Sent: Monday, July 6, 2015 11:52 PM > To: OpenStreetMap no Brasil > Subject: Re: [Talk-br] Opinando > > 2015-07-06 17:22 GMT-03:00 Helio Cesar Tomio : > > Assim, entendo que a atitude correta é aceitar e manter a verdade do > > mapeador. > > Isso vale amplamente para o mapeador local (só não vale se for pego no > ato plagiando uma fonte de dados), mas as coisas mudam de figura para > o mapeador remoto. Nesse caso, isso vale se não houver risco quanto à > legalidade do método pelo qual a informação foi obtida. Eu não quero > citar nomes (porque o tratamento seria igual independente da pessoa), > mas no debate recente o problema é que, não havendo registro da > comunicação boca-a-boca, sobraram só imagens de fontes cuja > legitimidade legal não foi demonstrada. Eu não tenho dúvidas de que o > autor agiu de boa fé, mas a verdade do mapeador >> remoto << precisa > ser sustentável legalmente, essa é uma pressão externa que nós temos. > Talvez haja resistência porque alguns estão vindo de projetos que não > tinham preocupação com os pormenores legais. Mandei um e-mail há pouco > sugerindo formas que eu conheço de garantir isso com o mínimo possível > de trabalho adicional. > > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br > > ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Necessidade de intermediação
2015-07-07 2:32 GMT-03:00 : > Não conhece! > As que conhece foram as apresentadas por mim e ligadas tão somente a > navegação GNSS em réplica a você por ter apresentado as suas e querendo se > prevalecer delas no debate. > Esqueceu? > Se necessário reproduzo aqui copia do debate. Respondo apenas para o leitor casual tirar suas próprias conclusões. Prefiro reproduzir links para discussões completas, não extratos descontextualizados. 10º parágrafo: https://lists.openstreetmap.org/pipermail/talk-br/2014-January/005052.html 1ª parágrafo de resposta: https://lists.openstreetmap.org/pipermail/talk-br/2015-July/010307.html 14º comentário do changeset (8º do usuário Thundercel): http://www.openstreetmap.org/changeset/30210630 -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Necessidade de intermediação
2015-07-07 1:08 GMT-03:00 : > Não sou programador e por isso não emprego, como você, termos técnicos. > Não considero que minha interpretação do algoritmo esteja errada. Interpreto > o algoritmo de acordo com as observações que fazemos nos testes em campo. Mas estava errada. Seus testes lhe apresentam um comportamento observável, não verdades matemáticas. Você quer ter o direito de dizer que estou errado, mas nunca aceita o direito dos outros dizerem que você está errado quando foge à esfera do seu conhecimento. > Credenciais? > Você nem conhece as minhas para falar isso. Talvez se surpreenda ao > conhecer. Conheço, você fez questão de apresentá-las logo que entrou no OSM. E as repetiu diversas vezes desde então, inclusive nesta discussão. Não demora a apresentá-las quando duvidam de algo que diz. Não me importavam muito antes, e me importam cada vez menos, assim como o resto que diz, devido ao tom com que se dirige aos demais e em particular a mim desde o início. Tal é o tom que ninguém mais se interessou em participar até o fim. Detesto arrogância, só recebi ingratidão sua por participar desta intermediação que convocou (o contrário só viria se eu tivesse apoiado você, tão egocêntrica é a sua intenção), e agora voltarei a lhe dar o que já lhe dava de melhor: minha surdez. Estou convencido de que ao não dividir meu conhecimento e opinião com você e ao direcionar minhas energias para outras tarefas estarei contribuindo mais com essa comunidade. Com o mesmo tempo que perdi nisso, eu mapeei todos os limites dos bairros da 10ª maior capital do Brasil e junto todo o seu sistema de BRTs. Ah, e participei de diversas discussões interessantes nas comunidades internacionais do OSM. Além de meus compromissos particulares, é claro. Melhor aproveitarmos melhor nosso tempo né. ;-) -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Necessidade de intermediação
Bem, não há interlocutor melhor nessa discussão, o que fazer? Tem que me aturar. :-) Quanto ao comentário dramático/sarcástico (nada produtivo) "Também pudera se o interlocutor não le o que voce escreve." Como disse, essa conversa é longa demais (TL;DR). É um esforço incomum alguém TENTAR lê-la e intermediá-la. Em boa parte porque os participantes não são concisos na forma de se expressar. Se perdi algum pedaço, sou humano, nunca disse o contrário. Agora, não omita informação para parecer mais correto do que é. Li que esse tracklog disponível estava desatualizado e que era considerado pouco útil devido às alterações recentes no local. Em momento algum questionei sua habilidade com testes de roteamento. Mas sua interpretação do algoritmo estava claramente errada. De qualquer forma, ambos os assuntos fogem ao foco principal do OSM. Quanto ao comentário sobre expertise - como se sentiu com uma pessoa argumentando com base em credenciais? Reflita. Acho que não gostou. Não faça aos outros o que não querem que façam com você. Não aceito alfinetadas gratuitas. Estou pensando em tirar outras férias ou em ir contribuir com as comunidades mais amigáveis de outros países. Ainda bem que filtro os trolls no meu inbox. 2015-07-06 22:10 GMT-03:00 : > Adriano, > > A existência de tracvklog na base oSM já foi citado por mim antes, mas o > Fernando só le o que interessa a ele devido a sua “expertise”. > > Depois eu que levo a exaustão. Também pudera se o interlocutor não le o que > voce escreve. > > From: Adriano Rosa > Sent: Monday, July 6, 2015 12:14 PM > To: OpenStreetMap no Brasil > Subject: Re: [Talk-br] Necessidade de intermediação > > uma ressalva quanto ao último parágrafo da mensagem do fernando: > "Outra saída para essa situação toda é aceitar que o que foi feito por > você é indefensável e portanto é mais seguro que seja revertido, pelo > bem da comunidade. Alguém com melhores condições de demonstrar a > licitude do método vai corrigir quando chegar a hora." > mesmo que o marcio não mostre o tracklog que ele recebeu, acho que não > precisa reverter a edição, pois há tracklogs já incluídos que, ao menos, > parcialmente demonstram o percurso atual no trevo. > > > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br > -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Opinando
2015-07-06 17:22 GMT-03:00 Helio Cesar Tomio : > Assim, entendo que a atitude correta é aceitar e manter a verdade do > mapeador. Isso vale amplamente para o mapeador local (só não vale se for pego no ato plagiando uma fonte de dados), mas as coisas mudam de figura para o mapeador remoto. Nesse caso, isso vale se não houver risco quanto à legalidade do método pelo qual a informação foi obtida. Eu não quero citar nomes (porque o tratamento seria igual independente da pessoa), mas no debate recente o problema é que, não havendo registro da comunicação boca-a-boca, sobraram só imagens de fontes cuja legitimidade legal não foi demonstrada. Eu não tenho dúvidas de que o autor agiu de boa fé, mas a verdade do mapeador >> remoto << precisa ser sustentável legalmente, essa é uma pressão externa que nós temos. Talvez haja resistência porque alguns estão vindo de projetos que não tinham preocupação com os pormenores legais. Mandei um e-mail há pouco sugerindo formas que eu conheço de garantir isso com o mínimo possível de trabalho adicional. > Todos aqui são pessoas que acreditam no OSM. Não tenho dúvida. :D > Cordialmente, hctomio. > > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br > -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Discussões Improdutivas
2015-07-06 13:48 GMT-03:00 A. Carlos : > > Vou dar uma petekada aqui. > > 1. O Zezinho mora no local, manda uma contribuição, dizendo que tal Rua esta > errada, Fato. > 2 O Márcio na boa fé analisando o que recebeu, vai lá e faz o acerto. E por que Zezinho não fez a alteração ele mesmo, já que mora no local? É super fácil, só clicar em Editar. Ele também poderia ter adicionado uma nota ao mapa. Não precisava depender do Márcio pra nenhuma dessas duas coisas. Adicionar numa nota é apontar e escrever da mesma forma que escreveu para o Márcio, nada mais. Dá pra pedir pro Zezinho fazer isso, não dá? Imagina quanta discussão teria nos poupado. > 3. O Aun baseando se em documentos,provas antigas, tracks, vai lá e > reverte... > > Se eu sou Zezinho, e vejo que voltou tudo de volta, e sei, tenho certeza > moro ali, e vi que está errado. > Primeiro eu mando o Márcio " pra aquele lugar..." Ué, mas por que uma reação tão forte? Manda ele tomar um cházinho pra se acalmar. O Màrcio não é nenhum escravo do Zezinho pra fazer todas as suas vontades. Não é saudável confundir voluntarismo com submissão. ;-) > Segundo, não mando mais contribuição alguma pra ajudar, porque pra mim o > projeto já perdeu a credibilidade, Bem, Zezinho não sabe nada sobre o projeto do OSM e sobre as pressões que sofremos, natural que tire conclusões precipitadas. A Wikipédia é vítima de preconceitos similares. > se EU que moro ali, tenho certeza, e não sou atendido, meto a viola no saco > e vou embora.. O OSM incentiva as pessoas a serem pró-sumidoras, não apenas consumidoras. Quer colher um benefício que está faltando? Contribua fazendo. > Outro ponto..mês passado andei repassado todo a Região sul, colocando os > admi_centre nas relação. > Neste trabalho que eu anotei, por cima, superficial, mais de 70 cidades sem > uma única rua qualquer, isso > só região Sul, mas tem muito mais ali.. > Então. > Se estão sobrando tempo pra criarem robôs pra ficar farejando alterações > feitas, vamos farejar cidades sem ruas, > vias sem nomes, etc... Ambos os trabalhos são importantes, mapear e conferir o mapeamento dos outros. Faltam mãos para ambos. Sei que é chato quando reclamam do que você fez, sofro desse mal também. Por isso que não é bom se apegar tanto ao próprio trabalho, não transformá-lo em propriedade. > Eu estou achando que aqui é uma Comunidade que tem mais Generais que > soldados e...na frente > de batalha que vai??? Sua percepção está distorcida. Tem uns 15 mais participativos na lista (acho que uns 400 observadores), e uns 5~10 que já executaram reversões. Só na minha cidade (que nem de perto tem tanta gente editando quanto o Rio) já tem mais de 200 usuários registrados. A maioria faz contribuições eventuais, poucas demais para conhecer os pormenores do OSM. Só uns 5 fazem contribuições mais regulares e que se pode dizer que têm conhecimento aprofundado. Se não tiver nenhum fiscal, o mapa vira um aglomerado bagunçado de "coisas". Imagina em outras regiões então. > Anor C. A. de Souza -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Discussões Improdutivas
lificado como tal (julgamento meu, mas acho que a comunidade concorda) porque qualquer um pode pegar o trem, parar em todas estações, e ter a informação levantada em pouco tempo. Isso já seria diferente de ter todas as rotas de ônibus de uma cidade grande. O ideal é a empresa dizer que a informação é pública. Você também pode avaliar da seguinte forma: a empresa perde dinheiro se você copiar a informação do site? Talvez até ganhe porque economizaria o número total de acessos ao serviço. Também é uma avaliação subjetiva, mas é uma boa bússola pra esses casos mais incertos. Some a isso a quantidade de informação que o OSM poderia perder caso a empresa exigisse que a informação fosse retirada. Nesse caso, muito pouco. Se alguém na comunidade insistir numa comprovação mais contundente de que você realmente esteve lá, também seria pouco a ser perdido. Na prática, cada cidade tem uns poucos casos desses, que podem ser esclarecidos com uma dúzia de e-mails e/ou visitas a órgãos públicos (no caso, a Trensurb é uma empresa de economia mista, portanto faz parte da administração pública). Se você é morador local, a gente presume que você já andou de Trensurb e teve acesso à informação no local. Nenhuma lei protege informações expostas em local público que qualquer pessoa possa ler. Agora, isso também sugere um método de trabalho melhor: você poderia ter tirado foto das tabelas que viu nas estações. Daria menos trabalho do que transcrevê-las à mão, e serviria para sanar quaisquer questionamentos feitos pelos colegas. E, como antes, você não precisa guardar as fotos por muito tempo. Um exemplo mais interessante seria se vocẽ tivesse copiado os horários em que os trens param em cada estação. Isso sim pertence a um mercado disputado por grandes empresas (Google e Moovit). Copiar um arquivo GTFS de uma fonte oficial exigiria uma licença permissiva, mas você pode tirar fotos das tabelas horárias, e então esse dado, por estar exposto em espaço público, pode ser publicado em qualquer meio. O arquivo GTFS é a princípio protegido por lei por ser trabalhoso de confeccionar, e por isso seria considerado um "banco de dados". -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Necessidade de intermediação
Perfeito. Só fazer o OSM corresponder a esses tracklogs que temos então. Nem precisa usar scripts de reversão ou usuário especial pra isso. Para aliviar os ânimos: do ponto de vista da API do OSM, uma reversão nada mais é que uma edição comum que faz as operações de edição ao contrário (se moveu, move de volta; se colocou, remove; se removeu, recoloca), sem marcá-las de forma especial. O único indício de que foi uma "reversão" seriam os comentários no changeset. Ter um changeset seu revertido não é como se tivesse sujado a ficha no OSM, eu até já reverti formalmente changesets meus. Não existe sistema de "apontamento de culpados", tanto é que nem lembro de cor o último changeset que eu reverti, menos ainda quem foi o seu autor. Mal lembro de alguns autores que abusaram da leniência desse sistema e exigiram múltiplas reversões em sequência. Uma vez começamos a coletar os changesets de reversão no wiki, não para difamar seus autores, mas para lembrar da justificativa para a reversão, justamente para buscar a compreensão mútua com o autor, o que me parece justo, e também para irmos criando consenso sobre coisas que antes estavam implícitas (e, por isso, causando confusão). Pensem então na reversão como um simples "desfazer" mais formal. Muitos autores já se dispuseram a executar a reversão eles mesmos, e certamente teriam permissão para isso, mas como é tecnicamente complicado (especialmente quando os dados já sofreram alteração desde a edição questionada), só uns poucos acabam realmente executando. Por essas e outras, reversões também podem ser questionadas. E se podem ser questionadas, podem ser abusivas, por isso é bom que sejam feitas só depois de surgir um consenso na comunidade. E isso só é possível depois de uma comunicação exaustiva. O lugar ideal seria o fórum (já convidei várias vezes), mas o pessoal gosta de lotar a caixa dos outros. :P O que se pode fazer pra evitar poluir a lista com esses tópicos controversos é abrir o tópico lá no fórum e mandar um e-mail pra cá pedindo para os interessados participarem lá. 2015-07-06 12:14 GMT-03:00 Adriano Rosa : > uma ressalva quanto ao último parágrafo da mensagem do fernando: > "Outra saída para essa situação toda é aceitar que o que foi feito por > você é indefensável e portanto é mais seguro que seja revertido, pelo > bem da comunidade. Alguém com melhores condições de demonstrar a > licitude do método vai corrigir quando chegar a hora." > mesmo que o marcio não mostre o tracklog que ele recebeu, acho que não > precisa reverter a edição, pois há tracklogs já incluídos que, ao menos, > parcialmente demonstram o percurso atual no trevo. > > Em dom, 5 de jul de 2015 às 12:00, Fernando Trebien > escreveu: >> >> 2015-07-05 4:57 GMT-03:00 Marcio - Thundercel : >> > A partir do momento que um mapeador declara em sua edição GPS;survey >> > acredito nele e nunca pedirei comprovação do que ele editou. Quem ganha >> > é o >> > OSM porquemais um colaborador, voluntariamente, atuou no mapa. >> >> Só porque é voluntário não quer dizer que qualquer coisa que faça deve >> ser aceita. Como você disse, "assim age você, mas não pretendo agir >> assim". >> >> >> Da mesma forma, se sua informação viesse de uma prefeitura, você >> >> colocaria a prefeitura na etiqueta source. Isso informaria os outros >> >> mapeadores onde procurar a informação para confirmar: >> >> - sua veracidade; e >> >> - sua correção >> > >> > >> > Dados obtidos em prefeituras, IBGE, Bing, mapbox, não pode ser comparado >> > com >> > survey. >> >> Em diversos aspectos podem sim. >> >> >> Esse é o mesmo princípio pelo qual funciona a Wikipédia: nenhuma >> >> informação fica lá sem que uma fonte seja citada para verificação. Se >> >> a fonte não for fornecida, a informação pode ser removida por falta de >> >> neutralidade. O OSM é a Wikipédia dos mapas - inclusive é assim que se >> >> apresenta aos novos usuários. Tudo deve ser verificável, não somente >> >> sob o ponto de vista da idoneidade, mas também do ponto de vista da >> >> correção. >> > >> > >> > Não tem relação com survey. >> >> Tem tudo a ver com survey. O equivalente para Wikipédia é uma pessoa >> colocar nela uma informação que "simplesmente conhece", que "viu por >> aí", mas que não tem fonte. Isso tende a ser removido depois de um >> tempo, quando finalmente os olhos de um "fiscal" passam pela >> informação. Assim como no OSM, faltam fiscais na Wikipédia pra >> quantidade de dados nela colocados. >> >> > Entendo. Poderia nos copiar a mensagem que ele lhe envio
Re: [Talk-br] Discussões Improdutivas
Que algumas discussões andam improdutivas, isso é verdade. Agora que não há necessidade de questionamento, discordo. Tudo que existe no OSM deve ser verificável por outros. O questionamento, então, é válido caso a pessoa cometa erros. O que temos que cuidar é para questionar cordialmente, e a pessoa não pode se apegar demais ao seu trabalho. É difícil porque temos a tendência de ver o nosso trabalho como nossa "propriedade". Discussões devem ser primeiro diretas, e escalonar para a comunidade apenas caso não se chegue a um consenso. Daí a comunidade intervém e gera precedente, que ajuda a resolver outras discussões futuras. Se um mesmo problema é recorrente, a comunidade então tem que agir para evitá-lo. Percebo que tem sido assim nas outras comunidades há quase 1 década já. Haverá discussões (e naturalmente desentendimentos) até que se chegue a um consenso sobre todos os parâmetros do OSM. No Brasil, o projeto está ainda engatinhando, então esse tipo de coisa é esperada. 2015-07-04 18:55 GMT-03:00 Blademir Andrade de Lima : > Amigos Mapeadores, boa noite! > > Perceberam o quanto as discussões ultimamente estão improdutivas, e não > estão contribuindo em nada nossa comunidade? > > Não entrarei em méritos sobre quem fez isso ou aquilo, se fez errado ou não. > > Mas estamos tendo discussões sobre bobagens e coisas mínimas. > > Considero que toda pessoa que mapea age de boa fé, sem necessidade de > questionamento, exceto em casos explícitos de vandalismo. > > Desejo a todos um excelente trabalho! > > Atenciosamente, > Blademir Andrade - BladeTC > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br > -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Necessidade de intermediação
Eu não trabalho com isso mas já estudei o assunto a fundo. Mudei de área quando vi que essa já estava muito avançada. O que geralmente se faz é calcular o grafo dual do mapa geográfico: linhas viram nós e pontos de conexão entre elas viram linhas entre esses nós. Uma restrição de conversão se torna a exclusão de uma ou mais das linhas resultantes de um cruzamento. Os nós contém os pesos (tempo, ou velocidade e distância) de trafegar pela linha. O algoritmo então simplesmente explora essa estrutura de dados até chegar no destino. Conforme explora, vai somando os tempos. Quando encontrar a sequência que minimiza o tempo total, termina. Como o grafo geralmente é imenso, usam-se heurísticas para desconsiderar alguns caminhos. É aí que os algoritmos começam a dar resultados diferentes para os mesmos dados. Eu dei uma olhada por altos no projeto do mkgmap pra ver se poderia ajudar, mas achei confusa a sua organização. O projeto não tem um líder e "evolui" com contribuições eventuais. Também acho seu escopo limitado aos usuários de Garmin (eu não tenho um Garmin), e o meu interesse são sistemas open source que cheguem ao grande público. O OSRM é o contrário de tudo isso: algoritmo estado-da-arte, código muito bem escrito, comunidade organizada e responsiva, e utilizável pelo mundo todo sem precisar de ferramentas pagas. As dificuldades relatadas até aqui me fazem supor que o Mapfactor Navigator usa um algoritmo similar ao Garmin. É grátis e tem pra celular. E a comunidade do Mapfactor, embora pequena, me parece maior e mais organizada que a do mkgmap. Talvez o pessoal queira dar uma olhada no aplicativo. On 5 Jul 2015 11:17, "Aun Johnsen" wrote: > Fernando, > > Se eu entendo esse certa o graf de roteamento, alias o produto do > algoritmo, não ha informação geográfico mas tem linhas que representa > tempo e distancia entre nos que representando locações fisico, um no > pode ser um ponto onde 2 vias cruzam, mas pode também ser a rotatório > completo, ou ate um trevo complicado como um ponto so. Um ponto pode > ser um referencia da rota (vira a esquerda no BR-101), ou um ponto do > penalidade (espera 2 segundos no semáforo). Esses linhas e pontos e > abstratos, e não direitamente retirado do mapa física. > > Se voce trabalho com isso, talvez voce posso ajudar identificar os > objetos que pode/deve dar penalidade de roteamento? > > On 7/5/15, Fernando Trebien wrote: > > Aí você que entra na minha área de expertise como se soubesse mais. Sou > > mestre em computação, li várias versões desses algoritmos. > > > > O nó a que me refiro é o do grafo de roteamento. Não é o nó do mapa (com > > coordenadas e tal). O nó do grafo de roteamento sequer tem coordenadas, > > possui apenas propriedades abstratas como o tempo para atravessar uma > linha > > de uma ponta à outra, e a referência a essa linha daí sim no mapa > > geográfico. > > On 5 Jul 2015 05:44, "Marcio - Thundercel" > > wrote: > > > >> Uma coisa é o esperado de acordo com a teoria e outra o observado na > >> pratica em exaustivos testes. > >> > >> A criação do nó em si não interfere, a princípio, com o algoritmo. > >>> Será um nó a mais a ser visitado enquanto o grafo é explorado pelo > >>> algoritmo de roteamento. > >>> > >> > >> O algoritmo, dentre outros, trata os nós e é por eles que ele traça a > >> rota. > >> > >> Já fizemos inúmeros testes de roteamento e identificamos que o > >> roteamento, > >> entre duas vias iguais, ele opta pela que tem menos nós. > >> > >> Faça o teste chegando em um nó onde se abrem duas vias e que se fecham > lá > >> na frente, como um losango. > >> Divida um segmento de reta de uma das vias inserindo um nó nela. > >> Identificará que o roteamento se dá pela via que não tem o nó inserido. > >> Foi assim que nos testes constatamos a influência de partições de via em > >> um roteamento. > >> > >> -Mensagem Original- From: Fernando Trebien > >> Sent: Sunday, July 5, 2015 4:52 AM > >> To: OpenStreetMap no Brasil > >> Subject: Re: [Talk-br] Necessidade de intermediação > >> > >> 2015-07-05 1:40 GMT-03:00 Marcio - Thundercel > >> : > >> > >>> Por outro lado lembro que classificação de vias e de velocidades > >>> interferem > >>> no roteamento e, infelizmente, não dominamos ainda o algoritmo garmin. > O > >>> que > >>> sabemos sobre ele advém de exaustivos testes realizados. > >>> Não estamos debatendo tempo e sim roteamento e tudo que interfere nele. > >>> Como bem deve saber você o roteamento leva em consideração, além
Re: [Talk-br] Necessidade de intermediação
2015-07-05 4:57 GMT-03:00 Marcio - Thundercel : > A partir do momento que um mapeador declara em sua edição GPS;survey > acredito nele e nunca pedirei comprovação do que ele editou. Quem ganha é o > OSM porquemais um colaborador, voluntariamente, atuou no mapa. Só porque é voluntário não quer dizer que qualquer coisa que faça deve ser aceita. Como você disse, "assim age você, mas não pretendo agir assim". >> Da mesma forma, se sua informação viesse de uma prefeitura, você >> colocaria a prefeitura na etiqueta source. Isso informaria os outros >> mapeadores onde procurar a informação para confirmar: >> - sua veracidade; e >> - sua correção > > > Dados obtidos em prefeituras, IBGE, Bing, mapbox, não pode ser comparado com > survey. Em diversos aspectos podem sim. >> Esse é o mesmo princípio pelo qual funciona a Wikipédia: nenhuma >> informação fica lá sem que uma fonte seja citada para verificação. Se >> a fonte não for fornecida, a informação pode ser removida por falta de >> neutralidade. O OSM é a Wikipédia dos mapas - inclusive é assim que se >> apresenta aos novos usuários. Tudo deve ser verificável, não somente >> sob o ponto de vista da idoneidade, mas também do ponto de vista da >> correção. > > > Não tem relação com survey. Tem tudo a ver com survey. O equivalente para Wikipédia é uma pessoa colocar nela uma informação que "simplesmente conhece", que "viu por aí", mas que não tem fonte. Isso tende a ser removido depois de um tempo, quando finalmente os olhos de um "fiscal" passam pela informação. Assim como no OSM, faltam fiscais na Wikipédia pra quantidade de dados nela colocados. > Entendo. Poderia nos copiar a mensagem que ele lhe enviou, mesmo que > seja uma declaração dizendo "tá igual à [fonte X]"? Acho que basta. > > Não. > Minha palavra nesse caso basta. Se você tem a informação solicitada e não quer compartilhar, começo a dar mais razão para a desconfiança do Aun. Talvez você não tenha a informação e quer apenas que acreditemos. As imagens que você apresentou a ele são de uma fonte que não conhecemos, e queremos saber se é lícita (agora me juntei ao coro, quero saber também). É um questionamento válido e importante. Você pode ter feito 4000 contribuições válidas no passado, nada impede que esta seja inválida. Nada impede que a minha próxima contribuição seja inválida também. Às vezes pode ser inválida sem que a própria pessoa perceba que foi inválida. Pode ser inclusive ilícita sem a pessoa perceber. E se pode, pode acometer os experientes também. Você leva isso para o lado da moral (frequentemente), mas eu tenho uma abordagem unicamente pragmática: se tem e é fácil mostrar, mostre, e está solucionado. Fim de papo. Se é fácil mostrar e não mostra, é porque provavelmente há algo a ser escondido. Seria tão fácil dar um Forward nesse e-mail do residente, e no entanto você prefere estender a discussão. Além disso, tracklogs são arquivos pequenos, não seria difícil guardá-los num diretório no seu computador, no Dropbox, ou em qualquer outro meio. Eu tenho praticamente todos os meus tracklogs guardados desde 2012, são centenas. >> Daí o que eu faria é acrescentar uma etiqueta "note" na linha contendo >> o link para a mensagem dele que você encaminhou pra cá. Dessa forma, >> outros mapeadores podem verificar a informação. Note que eu colocaria >> isso em "note" (um comentário informal) e não em "source" (a fonte >> usada para verificar com certeza os dados). É uma diferença sutil, mas >> desse jeito mapeadores locais podem duvidar da correção da informação >> (e têm esse direito) e confirmá-la eles mesmos mais adiante. > > Assim age voce, mas não pretendo agir assim. Gostaria de saber por que foi uma sugestão ruim. Teria sido mais "educado" da sua parte propor colocar essa informação em outra etiqueta. Se a falta dessa informação gera dúvidas, obviamente é necessária no mapa. A etiqueta "note" existe para esclarecer dúvidas em elementos disputados. Ao dizer "não pretendo agir assim" após "minha palavra nesse caso basta", você se coloca em uma posição de superioridade. Ninguém aqui é superior a ninguém. Se quiser exercer essa postura, recomendo que procure outra comunidade que a aceite melhor. Jamais a aceitarei. Não é à toa que minha assinatura em todos os e-mails é "Nullius in verba" - lema da Sociedade Real de Londres, que significa "[não acredite cegamente] nas palavras de ninguém". Confiar cegamente em alguém é colocar-se sob o poder dessa pessoa. As consequẽncias normalmente são ruins, às vezes catastróficas, a história está cheia de exemplos. Não confio cegamente nem em mim mesmo, e penso que o contrário seria prepotente e arrogante. Outra saída p
Re: [Talk-br] Necessidade de intermediação
Aí você que entra na minha área de expertise como se soubesse mais. Sou mestre em computação, li várias versões desses algoritmos. O nó a que me refiro é o do grafo de roteamento. Não é o nó do mapa (com coordenadas e tal). O nó do grafo de roteamento sequer tem coordenadas, possui apenas propriedades abstratas como o tempo para atravessar uma linha de uma ponta à outra, e a referência a essa linha daí sim no mapa geográfico. On 5 Jul 2015 05:44, "Marcio - Thundercel" wrote: > Uma coisa é o esperado de acordo com a teoria e outra o observado na > pratica em exaustivos testes. > > A criação do nó em si não interfere, a princípio, com o algoritmo. >> Será um nó a mais a ser visitado enquanto o grafo é explorado pelo >> algoritmo de roteamento. >> > > O algoritmo, dentre outros, trata os nós e é por eles que ele traça a rota. > > Já fizemos inúmeros testes de roteamento e identificamos que o roteamento, > entre duas vias iguais, ele opta pela que tem menos nós. > > Faça o teste chegando em um nó onde se abrem duas vias e que se fecham lá > na frente, como um losango. > Divida um segmento de reta de uma das vias inserindo um nó nela. > Identificará que o roteamento se dá pela via que não tem o nó inserido. > Foi assim que nos testes constatamos a influência de partições de via em > um roteamento. > > -Mensagem Original- From: Fernando Trebien > Sent: Sunday, July 5, 2015 4:52 AM > To: OpenStreetMap no Brasil > Subject: Re: [Talk-br] Necessidade de intermediação > > 2015-07-05 1:40 GMT-03:00 Marcio - Thundercel : > >> Por outro lado lembro que classificação de vias e de velocidades >> interferem >> no roteamento e, infelizmente, não dominamos ainda o algoritmo garmin. O >> que >> sabemos sobre ele advém de exaustivos testes realizados. >> Não estamos debatendo tempo e sim roteamento e tudo que interfere nele. >> Como bem deve saber você o roteamento leva em consideração, além de >> outros, >> a quantidade de nós empregados para unir os segmentos de reta na >> retratação >> da via. >> Ao se reduzir a velocidade de um trecho de via o editor é obrigado a >> dividir >> a via de forma a poder no trecho dividido estabelecer a velocidade. Isso >> por >> si só já afeta o calculo de rota por aquele trecho. >> > > Afeta, mas muito pouco, pelo menos na minha compreensão de algoritmos > de roteamento. > > O que acontece é que ele cria um novo nó no grafo de roteamento para > representar o trecho. O nó contem o tempo total para percorrer o > trecho, calculado dividindo distância por velocidade. (há variações em > que o nó contem ambas velocidade e distância e o cálculo do tempo é > feito durante o processamento, mas elas são matematicamente > equivalentes) > > A criação do nó em si não interfere, a princípio, com o algoritmo. > Será um nó a mais a ser visitado enquanto o grafo é explorado pelo > algoritmo de roteamento. > > O que acontece é que algoritmos diferentes usam heurísticas > diferentes. Algumas dessas heurísticas decidem "descartar" alguns nós > que eles "acham" que têm pouca chance de conduzir à melhor rota. > "Heurística" é um método matematicamente impreciso para chegar a uma > solução sub-ótima mais rapidamente. Se é impreciso, há heurísticas > melhores e piores. Uma heurística comum é visitar primeiro os nós > relativos às vias de maior classificação. Nesse caso, como a > classificação não foi alterada, o nó seria visitado mesmo tendo uma > velocidade mais baixa. Mas o Garmin pode usar alguma outra heurística > que eu desconheço. > > Outro insight: explorar o gráfico requer somar esses tempos, trecho > por trecho. São milhares de operação de soma. Se o programa não for > bem construído, ele pode acumular erros numéricos ao somar milhares de > números. O OSRM me parece particularmente sensível a esses erros. O > Garmin geralmente opera num hardware limitado e talvez também seja > sensível (tratar desses erros numéricos requer usar mais memória). > > Mais um insight: classificação interfere com esses algoritmos "mais > simples" que usam "heurísticas". A classificação das vias não > interfere em nada com o algoritmo A* (a-estrela) puro, nem com o > algoritmo do OSRM. Por isso, classificações não devem ser alteradas > com vistas ao roteamento. No entanto, um bom método de classificação > serve bem a praticamente qualquer algoritmo de roteamento, não por ser > o objetivo da classificação, mas por ser efeito colateral dela. > > Se, numa rota com vários quilômetros, a escolha de uma alternativa ou > outra depender de um trecho tão curto quanto o mencionado, é bem > provável que alguma dessas características esteja inteferin
Re: [Talk-br] Necessidade de intermediação
2015-07-05 1:40 GMT-03:00 Marcio - Thundercel : > Por outro lado lembro que classificação de vias e de velocidades interferem > no roteamento e, infelizmente, não dominamos ainda o algoritmo garmin. O que > sabemos sobre ele advém de exaustivos testes realizados. > Não estamos debatendo tempo e sim roteamento e tudo que interfere nele. > Como bem deve saber você o roteamento leva em consideração, além de outros, > a quantidade de nós empregados para unir os segmentos de reta na retratação > da via. > Ao se reduzir a velocidade de um trecho de via o editor é obrigado a dividir > a via de forma a poder no trecho dividido estabelecer a velocidade. Isso por > si só já afeta o calculo de rota por aquele trecho. Afeta, mas muito pouco, pelo menos na minha compreensão de algoritmos de roteamento. O que acontece é que ele cria um novo nó no grafo de roteamento para representar o trecho. O nó contem o tempo total para percorrer o trecho, calculado dividindo distância por velocidade. (há variações em que o nó contem ambas velocidade e distância e o cálculo do tempo é feito durante o processamento, mas elas são matematicamente equivalentes) A criação do nó em si não interfere, a princípio, com o algoritmo. Será um nó a mais a ser visitado enquanto o grafo é explorado pelo algoritmo de roteamento. O que acontece é que algoritmos diferentes usam heurísticas diferentes. Algumas dessas heurísticas decidem "descartar" alguns nós que eles "acham" que têm pouca chance de conduzir à melhor rota. "Heurística" é um método matematicamente impreciso para chegar a uma solução sub-ótima mais rapidamente. Se é impreciso, há heurísticas melhores e piores. Uma heurística comum é visitar primeiro os nós relativos às vias de maior classificação. Nesse caso, como a classificação não foi alterada, o nó seria visitado mesmo tendo uma velocidade mais baixa. Mas o Garmin pode usar alguma outra heurística que eu desconheço. Outro insight: explorar o gráfico requer somar esses tempos, trecho por trecho. São milhares de operação de soma. Se o programa não for bem construído, ele pode acumular erros numéricos ao somar milhares de números. O OSRM me parece particularmente sensível a esses erros. O Garmin geralmente opera num hardware limitado e talvez também seja sensível (tratar desses erros numéricos requer usar mais memória). Mais um insight: classificação interfere com esses algoritmos "mais simples" que usam "heurísticas". A classificação das vias não interfere em nada com o algoritmo A* (a-estrela) puro, nem com o algoritmo do OSRM. Por isso, classificações não devem ser alteradas com vistas ao roteamento. No entanto, um bom método de classificação serve bem a praticamente qualquer algoritmo de roteamento, não por ser o objetivo da classificação, mas por ser efeito colateral dela. Se, numa rota com vários quilômetros, a escolha de uma alternativa ou outra depender de um trecho tão curto quanto o mencionado, é bem provável que alguma dessas características esteja inteferindo no resultado. Mas os mapeadores do OSM não podem fazer nada, e talvez nem os desenvolvedores da aplicação sem ter que reescrevê-la por completo para resolver algum problema mais profundo. O que os roteadores prometem não é encontrar a melhor rota, mas uma rota sub-ótima. Quanto mais longa a distância, maior o efeito desses dois fatores (erro numérico e qualidade da heurística). Até mesmo o Waze às vezes faz bobagem na tentativa de encontrar a melhor rota. -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Necessidade de intermediação
desenha o mapa na tela. Um conversor traduz dados de um formato para outro, por exemplo, de OSM para Garmin. O mkgmap é um conversor. Quando esse processo de conversão é muito complexo, às vezes também é chamado de compilador (compilar significa "juntar/fundir partes distintas"; no caso, o compilador cria uma estrutura de dados otimizada para o roteamento e vinculada com os gráficos que o Garmin então exibe na tela). Pode haver um pré-processador antes do compilador, acho que é nisso que vocês estão trabalhando. Ele modificaria informações já baixadas do OSM antes de mandar para o mkgmap. > Essa inclusão não está errada, entretanto o algoritmo garmin interpreta esse > trecho com velocidade elevada como melhor caminho para cruzamento de Vitória > abandonando a BR-101. Ele não analisa que o roteamento prossegue pelas vias > urbanas. Esse é um problema bem comum com algoritmos que só têm a informação da etiqueta maxspeed à disposição. > Lógico e não é necessário se repetir que o OSM serve para multi aplicações e > que não se deve ele ser editado de acordo com as necessidades de roteamento > de uma única aplicação (roteamento gps). Por essa razão que resolvemos o > problema dropando a nível renderizador (não no OSM)a velocidade de 110 km/h > desse trecho da ES-080. Perfeito, é esse o caminho. Melhor mesmo seria ter um serviço parecido com o Waze que coletasse esses dados em campo. Houve um projeto assim ligado ao OSM, mas morreu antes de crescer. Podem surgir outros no futuro. Justamente pela questão da conferência dos dados do OSM (todos os mapeadores devem poder conferir se os dados estão corretos), nunca se criou uma etiqueta para julgar o grau de congestionamento de uma via. Essa informação é bastante transitória e seria difícil os mapeadores chegarem a um consenso sobre ela. Só por comparação, no TrackSource existem "donos" locais do mapa que decidem essa informação. De certa forma, o mapa realmente é uma opinião deles, com a qual as pessoas concordam sem questionar (e se questionarem, precisam convencê-los a mudar esse julgamento). No OSM isso não funcionaria porque não há um dono local do mapa. Mas lhe digo que mapear o maxspeed já resolve boa parte do problema. Não todo, é claro. Esse problema também "tende" a ser transitório (esse "tende" varia muito no tempo). Uma estrada muito congestionada "tende" a ser expandida, ou ter seus semáforos regulados, para aliviar o tráfego. Obviamente, sem garantias. -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Necessidade de intermediação
2015-07-04 21:43 GMT-03:00 Marcio - Thundercel : > Apresentei fotos do local, legislação e tudo mais para poder lhe provar que > o certo era eu. Me lembro que as fotos que você apresentou não estavam atualizadas, e isso é verificável no arquivo do debate. Mas vamos deixar isso de lado. Tenho certeza que ninguém leu aquela nossa discussão, e não farão agora, então não vai levar a nada. De qualquer forma, não tira o mérito de que foi agindo de boa fé. Boa fé não significa que o resultado será correto, apenas que eventuais erros não são mal intencionados. > O caso do Aun é bem semelhante e esse "questiona até a exaustão" e o pior, > põe em duvida a palavra do editor, o que para mim é inaceitável quando, não > tendo eu mais o tracklog recebido, aponto fontes "ilícitas" de consulta. > Ilícitas, ou não, não deixam de ser fontes de consulta que comprovam a > veracidade dos fatos. Na verdade, a gente trabalha sob a premissa de que tudo é questionável. Deixa de ser questionável quando surge consenso. Geralmente, quando está tudo certo (não só o dado como também a sua legalidade), ninguém questiona nada, ou se questiona, se convence rapidamente que não tinha motivo para questionar. > Por fim lembro que estamos aqui para colaborar voluntariamente com o OSM > editando os erros existentes no mapa (que não são poucos) e ninguém gosta de > ficar sendo questionado insistentemente por edições. Ser questionado é > aceitável, mas duvidarem da palavra e das justificativas, não aceito. A justifica tem que ser suficiente para o consenso. Claro, é complicado obter consenso quando são apenas 2 pessoas. Em uma comunidade maior, 3 ou 5 pessoas estariam discutindo e o consenso emergiria democraticamente mais rápido. Eu, por exemplo, não tenho como confirmar a correção de nenhum dos dois lados. Só posso concordar ou discordar com o método usado. > Como tenho realizado muitas edições devido aos inúmeros reportes que recebo > nos sites que administro e também por email, não são poucas as interpelações > que recebo de edições feitas. Me parece até que o OSM Brasil tem mais > fiscais do que editores. Será? Na verdade, mais de 50% das colaborações vêm de mapeadores casuais que acabam nunca se envolvendo com a comunidade, nem têm ideia que a lista talk-br e o wiki existem, muito menos da forma correta de se fazer um tracklog. Numa situação dessas, é bom que o OSM tenha fiscais, já que não existe um mecanismo de moderação. Por exemplo, o residente que lhe passou a informação informalmente poderia estar omitindo algo, mesmo sem perceber. Seria de boa fé, e estaria incorreto. Acredito que o Aun apenas queira ter certeza que estão sendo observados os limites legais. O questionamento feito por ele poderia ser feito, digamos, por quem gerencia uma das fontes ilícitas citadas, alegando (mesmo que falsamente) plágio, apenas para prejudicar o OSM (que é seu competidor de mercado). Se não pudéssemos provar, teríamos que reverter a edição, e com isso perderíamos todas as edições futuras que, juntas, podem representar um trabalho muito maior e mais valiosa do que a informação sendo atualmente questionada. Também acho que o debate esteja escalonando porque falta o material cujo uso foi declarado no changeset. Entendo as condições que levaram à falta, mas espero que vocẽ também entenda por que a falta é problemática para nós. -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Necessidade de intermediação
uma comunidade muito participativa em Porto Velho ainda. Nesse caso, se as coisas estão mudando muito rápido, nem sempre vale a pena investir tanto em discussões sobre os elementos mutáveis (isso não quer dizer que a discussão é inválida, somente que pode estar custando demais para o benefício desejado). O ideal seria ter alguém de Porto Velho mesmo mantendo o mapa dessa região. Numa situação dessas, a pessoa simplesmente iria até o local e extrairia um segundo tracklog caso o primeiro não estivesse mais acessível. > Pela analise e testes que fizemos isso está ocorrendo pela max_speed > inserida na ES-080, muito superior a da BR-101. > Como não chegamos a uma solução aceitável a nível OSM decidimos corrigir o > problema a nível renderizador (Mkgmap) inserindo nele drop para a max_speed > da BR-060 nos dados OSM. > Assim, não retiramos a informação do mapa OSM, simplesmente as > desconsideramos a nível Mkgmap. Perfeito. Então o maxspeed no OSM está todo correto, mas o roteamento dá uma rota inadequada. Curiosidade minha: é realmente inadequada, se segue por um caminho mais rápido? (teoricamente, desconsiderando o tráfego) > Isso desejaria eu, mas infelizmente o brasileiro é acomodado e todos sabem > aqui que preferem criticar do que colaborar. Ainda bem que esse residente em > Porto Velho colaborou me informando o erro no trevo e me enviando, por > solicitação minha, o tracklog do local. Entendo. Poderia nos copiar a mensagem que ele lhe enviou, mesmo que seja uma declaração dizendo "tá igual à [fonte X]"? Acho que basta. Daí o que eu faria é acrescentar uma etiqueta "note" na linha contendo o link para a mensagem dele que você encaminhou pra cá. Dessa forma, outros mapeadores podem verificar a informação. Note que eu colocaria isso em "note" (um comentário informal) e não em "source" (a fonte usada para verificar com certeza os dados). É uma diferença sutil, mas desse jeito mapeadores locais podem duvidar da correção da informação (e têm esse direito) e confirmá-la eles mesmos mais adiante. > Desconheço a experiência de vocês em extração de tracklogs, mas para os que > não sabem existem técnicas de extração de tracklogs para fins de mapeamento. > Nem todos os colaboradores conhecem essas técnicas e muitos me enviam > “registros de viagem” que na verdade não são adequados a mapeamento até > porque não gravam os segmentos com espaçamento de 1 seg. Acho que a maioria sabe desses problemas, nunca exigimos tracklogs perfeitos. Só recomendamos que sejam interpretados levando em consideração as limitações (e eventuais erros) do aparelho usado para coletar a trilha. Na verdade, não exigimos muito. Só damos recomendações. Em geral, a gente joga a barra lá em cima por acreditar que isso faz o projeto progredir mais rápido, e então desce até que o pedido se torne "factível", e é então que avaliamos se o factível é satisfatório, ou se há uma alternativa melhor. É um terreno incerto, e às vezes é na incerteza que surgem as desavenças e a má compreensão mútua. Sem ser condescendente, mas é natural e esperado, só temos que ter consciência pra não atrapalhar a colaboração. -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Necessidade de intermediação
Em tempo. 2015-07-04 20:04 GMT-03:00 Marcio - Thundercel : > Se o HERE, WAZE, YAHOO e outras fontes de analise não podem ser empregadas > por mim como consulta não sei o que estou fazendo aqui e porque estou > debatendo esse assunto. Não podem ser usadas para: - copiar geometria (com a imagem superposta à sua área de desenho) - copiar etiquetas (ex.: o nome das ruas, sua classificação/caracterização, seu código de referência (BR, SP, RS, etc.), seu limite de velocidade, etc.) Podem ser usadas para você "se dar conta" que falta algo no OSM e investigar se aquela coisa existe - presencialmente, ou pela imagem de satélite do Bing. Obviamente, apenas presencialmente (ou por fonte oficial) você pode descobrir o nome, então nomes não podem ser copiados em hipótese alguma. No entanto, tudo isso pode se copiado do mapa do IBGE ou de mapas com licenças explicitamente permissivas (tem que colar aqui pra ajudarmos a conferir se todos os termos estão de acordo com a ODbL) - nem todas as prefeituras oferecem essa declação explicitamente, então é necessário fazer contato. -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Necessidade de intermediação
2015-07-04 20:04 GMT-03:00 Marcio - Thundercel : > Paciência tem limite. Verdade. > Finalizo plagiando o dito pelo Blad em sua ultima postagem e que reflete > também meu pensar: > > "Considero que toda pessoa que mapea age de boa fé, sem necessidade de > questionamento, exceto em casos explícitos de vandalismo. > Atenciosamente, > Blademir Andrade - BladeTC" Lembro que no passado eu desfiz um trabalho seu, agindo de boa fé, e você me questionou até a exaustão. O Aun desfez um trabalho seu, também agindo de boa fé, e você está fazendo o mesmo com ele. Me parece conveniente essa interpretação seletiva dessa filosofia. Sejamos colegas. Questionamentos são sempre bem-vindos, a quem quer que seja. Precisamos ter o material para defender nossos mapeamentos quando não está claro o que estamos fazendo (por exemplo, quando diverge da imagem de satélite). Todos nós, sem exceção. Títulos e honrarias não conferem autorização automática a todas as ações. Isso é trabalhar em comunidade, sem hierarquias. O questionamento só não faz sentido depois que o material já foi apresentado. -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Necessidade de intermediação
ta. 2015-07-04 19:35 GMT-03:00 Aun Johnsen : > On 7/4/15, Marcio - Thundercel wrote: >> Conforme já citei a você anteriormente e somente a titulo de ilustração >> porque as fontes não podem ser empregadas no OSM: >> >> Tracklogs atualizados no trevo: >> >> http://gpsinfo.com.br/images/portovelho2.jpg >> > Vejo que spread e muito grande nesses tracklogs, mas pode ser por > ferramenta do visualização, esses tracklogs pode ser compartilhadas > para o OSM? do onde eles são disponíveis? >> Mapa Waze atualizado segundo informação do residente local: >> >> http://gpsinfo.com.br/images/portovelho.jpg >> > Nao conheco esse feramenta do visualisazao, os dados não e do OSM, > isso e do TrackSource? Acho que e do um projeto ou outro de mapas > crowdsource com licença não compatível com OSM, não confia muito isso > porque pode ha mesmo erros de falta do levantamento. Que a link não > existe no TS ou outros fontes similares não significa que não existe. >> Mapa Here atualizado no trevo também segundo informação desse mesmo >> residente: >> >> https://www.here.com/?map=-8.77122,-63.88256,18,normal&x=ep > Mapas Here também tem mesmo problema, mapas crowdsource sobre licença > não compativel mesmo não confiável >> >> Compreenda que esse Trevo vem sofrendo inúmeras alterações devido as obras e >> um histórico que se arrasta por anos. O DNIT assumiu as obras desse trevo >> depois que a Prefeitura não foi capaz de conduzi-las. Veja histórico disso >> em >> http://blogdocarloscaldeira.blogspot.com.br/2015/01/conheca-toda-historia-dos-viadutos-de.html >> > Isso e informação novo para mim, porque voce não divulgou isso > primeira vez? Blog do um politico aparentemente do Porto Velho, que > quer usar o problemas de terminar obras nesse trevo para fim deles, > esse pode dar mais luz sobre situação admito. >> Compreenda também que estamos tratando de vias automotivas e não vias para >> bicicletas e tampouco tracklogs desatualizados extraídos por bicicletas >> podem valer de referência para se desenhar vias ou links automotivos. >> >> O desenho que havia eu feito refletia as informações recebidas por mim de um >> residente local e você as está alterando por deduções e não vejo isso como >> correto. >> >> Agora mesmo solicitei ao colaborador que lá reside o tracklog do acesso >> passando por baixo do viaduto que foi aberto ao tráfego na semana passada. >> Estou aguardando ele me retornar. >> > Espero retorna dele, e se for posivel compartilhar os tracklogs dele > com o comunidade, vai ser muito util em disputas como esse, e talvez > podemos descobrir mais problemas do roteamento com isso? >> Se você cita que faço edições que não concorda também não concordo com >> muitas que você faz e nem por isso vou a você questionar a fonte de >> referencia empregada e mesmo informando eu replicar que não é verdade. >> >> Creio que essas discussões também não levam a nada e como você citou, se >> pararmos para ficar debatendo essas pequenas situações deixaremos de >> corrigir os inúmeros erros ainda existentes no mapa. Como você também não >> vou questionar seus erros, vou corrigi-los diretamente, mas continuo >> aguardando a correção do roteamento incorreto pela ES-060 que você se >> prontificou a corrigir. Creio que pelo visto serei obrigado a corrigir as >> velocidades incorretamente incluídas em trecho da rodovia. >> > Pelo roteamento do ES-060 e BR-101 entre Guarapari e Vitoria eu ja > coletei horas de trilhas, compartilhadas no OSM-GPS e no Mapillary, > voce pode entra e ver cada placa de velocidade, para, de a > preferencia, semaforo e mais nesses trechos, e voce pode ver que se a > mapa nao e 100% certo e bem proximo. Eu ainda esperando ferramentas > para JOSM que vai me ajudar editar isso, que e previsto melhorar os > proximo meses, e tempo a anilisar esses dados. Eu ainda tem algum > ligares ao ir gravar mesmos dados para Mapillary, para identificar > porque voce fui roteado ao sair BR-101 onde o GPS falou. Ja entrei > muitos maxspeed nesse região para melhorar o roteamento, mandei uns > 5-6 issues para OSRM para melhorar o penalidade por roteamento urbana, > e procurei para entender que tipo tags pode dar penalidade similar no > GPS como Garmin. > > Voce dize no um comentario que ha muitos radares do 60km/h nesse > trecho ES-060, se voce olhando meu Mapillary e a mapa voce pode ver > que quase tudo deles ja e no mapa e que o velocidade desses radares > não e 60km/h mas e 80km/h > > Espero se voce começar editar esses trechos que voce mesmo procurando > que tem nesses imagens Mapillary, se voce não quer esperar ate eu > terminar meu levantam
Re: [Talk-br] [Talk-pt] Declaração de renúncia de voto para decidir traduções de etiquetação (RESUMO + OPINIÃO)
E dependendo do contexto também pode ser highway=pedestrian+area=yes. É uma palavra bem genérica. https://en.wikipedia.org/wiki/Plaza Geralmente um mercado (marketplace) é uma atividade que se desenvolve num plaza. Às vezes é fixo, outras vezes é itinerante/intermitente (caso mais normal aqui no Brasil). 2015-07-03 19:21 GMT-03:00 Lists : > “plaza” pode ser amenity=marketplace > > Aun Johnsen > > On Jul 3, 2015, at 19:17, Rogério Plisk wrote: > > > Shopping Center é meu voto (termo em pt-br para o inglês mall) > > Para os centrinhos comerciais de bairro (igual ao da foto do Centro Alecrim) > na California/Eua me lembro que eram chamados de "Plaza". > > Temos o "plaza" etiquetado em inglês? > > Sds, > Rogério. > > Le 3 juil. 2015 à 14:29, Fernando Trebien a > écrit : > > Cara, tu tá brigando com pessoas nas DUAS listas, AINDA? Essa prepotência > (que já não é opinião só minha) de querer ser ouvido a todo custo, sem > querer ter experiência, não contribui em nada com o OSM, só nos faz perder > tempo. Reavalie. > > On 3 Jul 2015 09:49, "Alexandre Magno Brito de Medeiros" > wrote: >> >> Esta resposta está endereçada (no cabeçalho) à talk-br, ao Pedro Santos >> (Portugal) e ao Fernando Trebien; apesar de que infelizmente este último, >> muito provavelmente, não exercerá seu direito de conhecê-la, já que resolveu >> me filtrar em sua Caixa de Entrada. Ainda vai para a talk-br porque é do meu >> interesse deixar lá, ao menos no histórico, um conhecimento mais completo >> dos fatos. Só não a envio à talk-pt porque, após pedir desculpas à talk-pt, >> e sabendo que Fernando não retornaria, eu disse "o tópico finda aqui". >> >> É possível que o tópico não devesse nunca ter estado na talk-pt. Mas com >> certeza a talk-br era lugar para ele. Não na expectativa de interessar a >> cada participante, mas na expectativa de fazer uma renúncia pública que >> realmente tivesse valor. >> >> Não abro mão do direito à opinião. Mas, como declarado posteriormente, nem >> tenho tanta vontade de exercê-lo no que diz respeito a etiquetação. Aquilo a >> que eu me agarro mesmo é o direito de relatar sobre o nome e a existência >> das coisas que conheço a partir de minhas vivências. >> >> Pedro Santos envolveu-se e a talk-pt é pública. >> >> Pedro dá a entender, em sua interpretação, que minha renúncia é como um >> brado inconsequente de um opinativo qualquer que ficou insatisfeito porque >> não teve seus pitacos de momento considerados, quando na verdade o problema >> que tento resolver e existe entre eu e Fernando (com consequências para a >> comunidade) já era público e datava de alguns meses. >> >> PT-PT e PT-BR são variantes linguísticas, tratadas idealmente no OSM (não >> sei no iD) como idiomas diferentes. Na realidade, há misturas e as traduções >> realizadas em um país afetam as traduções usadas no outro. Sabendo disso, eu >> julguei que publicaria a renúncia na talk-pt sem abusar do âmbito de >> comunicação desse meio. E assim permanece meu juízo. Eu apenas reconheço >> que, de forma complicadora para mim, o tópico se estendeu para além da >> renúncia. >> >> Você leitor, se fala português, de um ou de outro lado do oceano, saiba >> que pode me reclamar a renúncia. Ela não é algo que dou somente ao Fernando. >> >> Eu disse "o tópico finda aqui" e por isso não o estou reabrindo na >> talk-pt. O Pedro Santos deixar sua interpretação de mim após isso, deveria >> obrigar a consciência dele a exibir na talk-pt esta minha defesa. Não é >> correto opinar publicamente sobre "uma pessoa" quando esta já se comprometeu >> publicamente a ausentar-se. Então Pedro, você tenha a pachorra de ao menos >> exibir integralmente esse meu e-mail presente de defesa, lá na talk-pt. >> Minha sugestão é que você me responda, se o for fazer, pela talk-br com >> cópia (esta vez) para a talk-pt. Eu vou me abster de voltar à talk-pt. >> >> Alexandre Magno >> >> Em 3 de julho de 2015 03:37, Fernando Trebien >> escreveu: >>> >>> Da minha parte, peço inclusive desculpas, no princípio nem me dei conta >>> que a lista talk-pt estava incluída na nossa discussão, que certamente >>> deveria ter se limitado à lista talk-br. Ou melhor, deveria ter ocorrido em >>> particular. >>> >>> Faço parte da talk-pt apenas como observador, em boa parte para obter >>> inspiração para os trabalhos de tradução do OSM. >>> >>> On 3 Jul 2015 03:20, "Pedro Santos" wrote: >>>> >>>> Bom dia! >>>>
Re: [Talk-br] [Talk-pt] Declaração de renúncia de voto para decidir traduções de etiquetação (RESUMO + OPINIÃO)
Cara, tu tá brigando com pessoas nas DUAS listas, AINDA? Essa prepotência (que já não é opinião só minha) de querer ser ouvido a todo custo, sem querer ter experiência, não contribui em nada com o OSM, só nos faz perder tempo. Reavalie. On 3 Jul 2015 09:49, "Alexandre Magno Brito de Medeiros" < alexandre@gmail.com> wrote: > Esta resposta está endereçada (no cabeçalho) à talk-br, ao Pedro Santos > (Portugal) e ao Fernando Trebien; apesar de que infelizmente este último, > muito provavelmente, não exercerá seu direito de conhecê-la, já que > resolveu me filtrar em sua Caixa de Entrada. Ainda vai para a talk-br > porque é do meu interesse deixar lá, ao menos no histórico, um conhecimento > mais completo dos fatos. Só não a envio à talk-pt porque, após pedir > desculpas à talk-pt, e sabendo que Fernando não retornaria, eu disse "o > tópico finda aqui". > > É possível que o tópico não devesse nunca ter estado na talk-pt. Mas com > certeza a talk-br era lugar para ele. Não na expectativa de interessar a > cada participante, mas na expectativa de fazer uma renúncia pública que > realmente tivesse valor. > > Não abro mão do direito à opinião. Mas, como declarado posteriormente, nem > tenho tanta vontade de exercê-lo no que diz respeito a etiquetação. Aquilo > a que eu me agarro mesmo é o direito de relatar sobre o nome e a existência > das coisas que conheço a partir de minhas vivências. > > Pedro Santos envolveu-se e a talk-pt é pública. > > Pedro dá a entender, em sua interpretação, que minha renúncia é como um > brado inconsequente de um opinativo qualquer que ficou insatisfeito porque > não teve seus pitacos de momento considerados, quando na verdade o problema > que tento resolver e existe entre eu e Fernando (com consequências para a > comunidade) já era público e datava de alguns meses. > > PT-PT e PT-BR são variantes linguísticas, tratadas idealmente no OSM (não > sei no iD) como idiomas diferentes. Na realidade, há misturas e as > traduções realizadas em um país afetam as traduções usadas no outro. > Sabendo disso, eu julguei que publicaria a renúncia na talk-pt sem abusar > do âmbito de comunicação desse meio. E assim permanece meu juízo. Eu apenas > reconheço que, de forma complicadora para mim, o tópico se estendeu para > além da renúncia. > > Você leitor, se fala português, de um ou de outro lado do oceano, saiba > que pode me reclamar a renúncia. Ela não é algo que dou somente ao Fernando. > > Eu disse "o tópico finda aqui" e por isso não o estou reabrindo na > talk-pt. O Pedro Santos deixar sua interpretação de mim após isso, deveria > obrigar a consciência dele a exibir na talk-pt esta minha defesa. Não é > correto opinar publicamente sobre "uma pessoa" quando esta já se > comprometeu publicamente a ausentar-se. Então Pedro, você tenha a pachorra > de ao menos exibir integralmente esse meu e-mail presente de defesa, lá na > talk-pt. Minha sugestão é que você me responda, se o for fazer, pela > talk-br com cópia (esta vez) para a talk-pt. Eu vou me abster de voltar à > talk-pt. > > Alexandre Magno > > Em 3 de julho de 2015 03:37, Fernando Trebien > escreveu: > >> Da minha parte, peço inclusive desculpas, no princípio nem me dei conta >> que a lista talk-pt estava incluída na nossa discussão, que certamente >> deveria ter se limitado à lista talk-br. Ou melhor, deveria ter ocorrido em >> particular. >> >> Faço parte da talk-pt apenas como observador, em boa parte para obter >> inspiração para os trabalhos de tradução do OSM. >> On 3 Jul 2015 03:20, "Pedro Santos" wrote: >> >>> Bom dia! >>> >>> Agora que foram despejadas 4 páginas de texto (A4, 12pt, parágrafo >>> simples), + de 2.400 palavras ou então + de 14.000 caracteres nesta lista, >>> achei que devia tentar fazer um apanhado para aqueles que não têm a minha >>> pachorra, acrescentando mais uma página. Por acréscimo segue a minha >>> opinião, bem distinguível do relato. >>> >>> Devo salientar que faço uma análise o mais isenta de preconceitos >>> xenófobos que consigo. Se isto se transformar numa picardia >>> Portugal/Brasil, não vou perder tempo. Simplesmente ignorarei este tópico. >>> >>> A tradução da tag shop=mall foi posta a discussão no fórum users: >>> Brazil <http://forum.openstreetmap.org/viewforum.php?id=74>: >>> >>> http://forum.openstreetmap.org/viewtopic.php?pid=513600#p513600 >>> >>> ontem às 14:26:31 (hora PT penso eu) >>> >>> >>> Ao 3º post: >>> >>> http://forum.openstreetmap.org/viewtopic.php?pid=513621#p513621 >>> >>>
Re: [Talk-br] Ciclovias na calçada
Quanto mais exemplos eu procuro fora, mais inconsistências de interpretação eu acho. Bem, vamos ao mea culpa antes. Está mais "certo" (por convenção) como descrito no fórum (por não haver segregação entre calçada e ciclovia), mas a princípio nenhuma das duas está inteiramente "errada" e há alguns prós e contras discutíveis [1]. As discussões no wiki inclusive apontam para uma 3ª possibilidade [2]. A convenção é mais parecida com o que você apontou (highway=path+footway=designated+bicycle=designated+segregated=no) por não haver segregação entre a calçada e a ciclovia. Vou alterar aqui em PoA na próxima revisão das ciclovias. O pessoal costuma fazer como eu fiz aqui (colocando a calçada na via principal, não na ciclovia) em alguns lugares na Inglaterra (e a principal visualização de calçadas que existe é a da ITO Map, que é um serviço inglês), mas é inconsistente, varia de um lugar pro outro. Faltam duas coisas no que diz no fórum: acrescentar a etiqueta footway=sidewalk à ciclovia+calçada combinada, e negar a calçada na via principal definindo a etiqueta sidewalk=left/right/no. Do contrário, a calçada fica representada duas vezes, uma delas implicitamente. As demais tags estão ok e são necessárias. É um pouco discutível se o certo é usar path ou footway para representar essa via. Afinal, nos pontos de estreitamento, quem prevalece é o pedestre, então há uma função dominante para a via (ela ser "calçada"). Usa-se path somente quando não há uma função dominante clara - no caso das calçadas+ciclovias bem projetadas - ou quando essa função não corresponde aos tipos básicos do OSM (footway, cycleway, bridleway, track, pedestrian, etc.). Estaria semanticamente mais certo mapear com highway=footway+bicycle=designated(+demais etiquetas). Na prática, faz pouca diferença fazer de um jeito ou de outro. Alguns renderizadores podem não reconhecer a combinação highway=footway+bicycle=designated, apesar de correta. Filosofia/prática: Na Alemanha e na Holanda, o costume é não declarar a etiqueta sidewalk=* na via quando a calçada é mapeada separadamente, com ou sem combinação com ciclovia. Isso faz com que os aplicativos de roteamento pensem que é possível pro pedestre andar tanto pela via principal quanto pela calçada ao lado. Na Inglaterra, eles invetaram uma etiqueta informal sidewalk=separate para dizer que a calçada correspondente à via principal foi mapeada separadamente. Isso foi em 2011, o ITO Map [4] suporta a etiqueta desde então, mas ela nunca foi formalizada/aprovada por voto. Ela também não permite expressar qual das duas calçadas foi mapeada separadamente, o que é um problema. Essa situação sugere que as pessoas não estão dando muita importância prum roteamento 100% correto pra bicicleta e pedestre. Um dos problemas (sem solução atualmente) de mapear ciclovias e calçadas separadas da via principal é que não tem como as aplicações saberem que elas fazem parte da via principal e, portanto, têm o mesmo nome. Então a instrução do roteador [3] nunca vai apresentar o nome da via principal (como seria esperado) ao calcular a rota por essa calçada/ciclovia. Isso se resolveria com a relação "street" (pouco usada) ou "associatedStreet" (pouco necessária no Brasil), ambas pouco suportadas pelas aplicações e complexas de mapear. Também se resolveria mapeando com as etiquetas cycleway=track e sidewalk=* na via principal nos casos em que há segregação física. Mas é discutível se isso realmente é preferível (em geral se prefere separar quando há segregação física entre os fluxos). Também se resolveria dando à calçada+ciclovia o nome da via principal, mas ninguém faz isso na prática, provavelmente para evitar replicação de dados. [1] http://wiki.openstreetmap.org/wiki/Consolidation_footway_cycleway_path [2] http://wiki.openstreetmap.org/wiki/Talk:Sidewalks#Sidewalks_in_roads_with_cycleways [3] http://open.mapquest.com/ [4] http://www.itoworld.com/map/126?lon=-0.07152&lat=51.49283&zoom=18&open_sidebar=map_key&fullscreen=true 2015-07-03 9:24 GMT-03:00 Adriano Rosa : > para um caso parecido, foi adotada uma solução diferente, como está no > fórum: http://forum.openstreetmap.org/viewtopic.php?pid=504510#p504510 > > tiago, imagino que seja a mesma situação: calçada de uso compartilhado entre > pedestres e ciclistas, com áreas designadas para eles, mas não exclusivas. > > Em sex, 3 de jul de 2015 às 02:11, Fernando Trebien > escreveu: >> >> E só pra confirmar, a etiqueta roundtrip tem um uso diferente do que >> eu disse. Deveria ser roundtrip=no no caso que eu mostrei. De qualquer >> forma, ela é pouco usada e útil só quando o valor dela é yes. >> >> 2015-07-03 1:54 GMT-03:00 Fernando Trebien : >> > "Se você vai olhar o mapa de tempos em tempos e se dispõe a consertar >> > esses probleminhas, seria o ideal." Quis dizer, seria o ideal mapear >> > com et
Re: [Talk-br] Ciclovias na calçada
E só pra confirmar, a etiqueta roundtrip tem um uso diferente do que eu disse. Deveria ser roundtrip=no no caso que eu mostrei. De qualquer forma, ela é pouco usada e útil só quando o valor dela é yes. 2015-07-03 1:54 GMT-03:00 Fernando Trebien : > "Se você vai olhar o mapa de tempos em tempos e se dispõe a consertar > esses probleminhas, seria o ideal." Quis dizer, seria o ideal mapear > com etiquetas, não como linha separada. :P (Reescrevi tentando ser > mais sucinto, esqueci um pedaço importante.) > > 2015-07-03 1:50 GMT-03:00 Fernando Trebien : >> Ah, e mais um detalhe legai: se por acaso o ciclista puder passar por >> um semáforo sem ter que parar, pode acrescentar bicycle=yes ao >> semáforo. >> >> Exemplo (nota que fica verde ao invés de amarelo na camada de >> bicileta): http://www.openstreetmap.org/node/1277685174 >> >> 2015-07-03 1:40 GMT-03:00 Fernando Trebien : >>> 1. Ciclovia (trajeto separado da pista dos automóveis, inclusive se a >>> separação for o meio-fio da calçada) >>> >>> É uma linha com a etiqueta highway=cycleway. Exemplo praticamente >>> igual ao seu: http://www.openstreetmap.org/way/356686653 >>> >>> Uma alternativa seria usar a etiqueta cycleway:[lado]=track, mas tem >>> alguns efeitos colaterais indesejáveis. Faz sentido fazer isso apenas >>> se tiver pressa e se a ciclovia segue a via principal por um longo >>> trecho, sem alternar o lado muitas vezes (que produziria quebras na >>> via principal). >>> >>> 2. Ciclofaixa >>> >>> O ideal/certo: acrescenta-se a etiqueta cycleway:[lado]=lane à via >>> principal. [lado] pode ser :left ou :right e se refere à direção da >>> "linha" (então cuidado: se a linha tiver oneway=-1, ela aponta no >>> sentido oposto ao do tráfego). Também é bom acrescentar >>> oneway:bicycle=yes/no, dependendo se a ciclofaixa é bi- ou >>> unidirecional em relação à via. Se tiver uma ciclofaixa de cada lado, >>> cada uma num sentido, é oneway:bicycle=no. Exemplo de via principal >>> com etiquetas de ciclofaixa: >>> http://www.openstreetmap.org/way/112410788 >>> >>> O factível nesse momento: há quem prefira mapear ciclofaixas como uma >>> linha separada (pessoal do RJ gosta), mas não está 100% de acordo com >>> as convenções do OSM (onde só se separa linhas quando há separação >>> física). Os efeitos colaterais são pequenos, e certamente elimina o >>> problema de alguém excluir a via principal e redesenhar esquecendo da >>> ciclovia, então há vantagens. Outra vantagem de separar é ganhar >>> destaque no mapa cicloviário sem precisar criar uma relação pra isso - >>> e relações ainda são facilmente quebráveis por usuários inexperientes. >>> Se você vai olhar o mapa de tempos em tempos e se dispõe a consertar >>> esses probleminhas, seria o ideal. >>> >>> Sugiro que as ciclofaixas mapeadas como ciclovias (linhas separadas) >>> tenham uma etiqueta fixme="Converter em ciclofaixa assim que editores >>> não quebrarem relações." pra que as pessoas não se esqueçam de fazer >>> essa mudança quando der. >>> >>> Se você procura por algo simples, pare de ler aqui e faça apenas o >>> factível. Se quiser algo completo e legal pra mostrar pros outros, >>> continue. >>> >>> 3. Rota ciclística (pra ambos os casos) >>> >>> Não é obrigatória, mas é uma sugestão interessante. >>> >>> Pra que tanto ciclovia quanto ciclofaixa tenham destaque na camada pra >>> bicicleta, tem que criar uma relação >>> type=route+route=bicycle+network=[icn/ncn/rcn/lcn]+roundtrip=yes/no. >>> Esses valores [icn/ncn/rcn/lcn] são, respectivamente, para redes >>> cicloviárias internacionais, nacionais, regionais e locais. Redes >>> municipais são mapeadas com lcn (local cycle network). A etiqueta >>> roundtrip indica se a relação é um ciclo fechado; pode ser tanto uma >>> rota circular que volta ao ponto de partida quando uma relação onde os >>> membros incluem ambos os sentidos, ida e vinda. Exemplo combinando >>> ciclovia e ciclofaixa numa rota só que é roundtrip porque combina ida >>> e vinda, que são separadas apesar de serem na mesma avenida: >>> http://www.openstreetmap.org/relation/5322653 >>> >>> Alterna pra camada de bicicletas e aproxima no exemplo pra ver que o >>> mapa mostra inclusive que a ciclofaixa é unidirecional em cada lado da >>> via (no trecho da ciclovia a renderização mostra como se fosse >>> unidirecional, tinha um
Re: [Talk-br] Ciclovias na calçada
"Se você vai olhar o mapa de tempos em tempos e se dispõe a consertar esses probleminhas, seria o ideal." Quis dizer, seria o ideal mapear com etiquetas, não como linha separada. :P (Reescrevi tentando ser mais sucinto, esqueci um pedaço importante.) 2015-07-03 1:50 GMT-03:00 Fernando Trebien : > Ah, e mais um detalhe legai: se por acaso o ciclista puder passar por > um semáforo sem ter que parar, pode acrescentar bicycle=yes ao > semáforo. > > Exemplo (nota que fica verde ao invés de amarelo na camada de > bicileta): http://www.openstreetmap.org/node/1277685174 > > 2015-07-03 1:40 GMT-03:00 Fernando Trebien : >> 1. Ciclovia (trajeto separado da pista dos automóveis, inclusive se a >> separação for o meio-fio da calçada) >> >> É uma linha com a etiqueta highway=cycleway. Exemplo praticamente >> igual ao seu: http://www.openstreetmap.org/way/356686653 >> >> Uma alternativa seria usar a etiqueta cycleway:[lado]=track, mas tem >> alguns efeitos colaterais indesejáveis. Faz sentido fazer isso apenas >> se tiver pressa e se a ciclovia segue a via principal por um longo >> trecho, sem alternar o lado muitas vezes (que produziria quebras na >> via principal). >> >> 2. Ciclofaixa >> >> O ideal/certo: acrescenta-se a etiqueta cycleway:[lado]=lane à via >> principal. [lado] pode ser :left ou :right e se refere à direção da >> "linha" (então cuidado: se a linha tiver oneway=-1, ela aponta no >> sentido oposto ao do tráfego). Também é bom acrescentar >> oneway:bicycle=yes/no, dependendo se a ciclofaixa é bi- ou >> unidirecional em relação à via. Se tiver uma ciclofaixa de cada lado, >> cada uma num sentido, é oneway:bicycle=no. Exemplo de via principal >> com etiquetas de ciclofaixa: >> http://www.openstreetmap.org/way/112410788 >> >> O factível nesse momento: há quem prefira mapear ciclofaixas como uma >> linha separada (pessoal do RJ gosta), mas não está 100% de acordo com >> as convenções do OSM (onde só se separa linhas quando há separação >> física). Os efeitos colaterais são pequenos, e certamente elimina o >> problema de alguém excluir a via principal e redesenhar esquecendo da >> ciclovia, então há vantagens. Outra vantagem de separar é ganhar >> destaque no mapa cicloviário sem precisar criar uma relação pra isso - >> e relações ainda são facilmente quebráveis por usuários inexperientes. >> Se você vai olhar o mapa de tempos em tempos e se dispõe a consertar >> esses probleminhas, seria o ideal. >> >> Sugiro que as ciclofaixas mapeadas como ciclovias (linhas separadas) >> tenham uma etiqueta fixme="Converter em ciclofaixa assim que editores >> não quebrarem relações." pra que as pessoas não se esqueçam de fazer >> essa mudança quando der. >> >> Se você procura por algo simples, pare de ler aqui e faça apenas o >> factível. Se quiser algo completo e legal pra mostrar pros outros, >> continue. >> >> 3. Rota ciclística (pra ambos os casos) >> >> Não é obrigatória, mas é uma sugestão interessante. >> >> Pra que tanto ciclovia quanto ciclofaixa tenham destaque na camada pra >> bicicleta, tem que criar uma relação >> type=route+route=bicycle+network=[icn/ncn/rcn/lcn]+roundtrip=yes/no. >> Esses valores [icn/ncn/rcn/lcn] são, respectivamente, para redes >> cicloviárias internacionais, nacionais, regionais e locais. Redes >> municipais são mapeadas com lcn (local cycle network). A etiqueta >> roundtrip indica se a relação é um ciclo fechado; pode ser tanto uma >> rota circular que volta ao ponto de partida quando uma relação onde os >> membros incluem ambos os sentidos, ida e vinda. Exemplo combinando >> ciclovia e ciclofaixa numa rota só que é roundtrip porque combina ida >> e vinda, que são separadas apesar de serem na mesma avenida: >> http://www.openstreetmap.org/relation/5322653 >> >> Alterna pra camada de bicicletas e aproxima no exemplo pra ver que o >> mapa mostra inclusive que a ciclofaixa é unidirecional em cada lado da >> via (no trecho da ciclovia a renderização mostra como se fosse >> unidirecional, tinha um erro na relação, deve atualizar daqui a uns >> dias). Posso ajudar a compor a relação de rota se você quiser. >> >> Se a rota tiver uma numeração ou código próprio, esse código vai na >> etiqueta ref da relação. Se por acaso o sistema for como o Holandês, o >> não são as rotas que têm identificação e sim os pontos de conexão >> entre as rotas, o esquema é um pouco diferente. Como não conheço o >> sistema em São Paulo, me avise se for esse o caso. Exemplo desse caso: >> http://www.opencyclemap.org/?zoom=12&a
Re: [Talk-br] Ciclovias na calçada
Ah, e mais um detalhe legai: se por acaso o ciclista puder passar por um semáforo sem ter que parar, pode acrescentar bicycle=yes ao semáforo. Exemplo (nota que fica verde ao invés de amarelo na camada de bicileta): http://www.openstreetmap.org/node/1277685174 2015-07-03 1:40 GMT-03:00 Fernando Trebien : > 1. Ciclovia (trajeto separado da pista dos automóveis, inclusive se a > separação for o meio-fio da calçada) > > É uma linha com a etiqueta highway=cycleway. Exemplo praticamente > igual ao seu: http://www.openstreetmap.org/way/356686653 > > Uma alternativa seria usar a etiqueta cycleway:[lado]=track, mas tem > alguns efeitos colaterais indesejáveis. Faz sentido fazer isso apenas > se tiver pressa e se a ciclovia segue a via principal por um longo > trecho, sem alternar o lado muitas vezes (que produziria quebras na > via principal). > > 2. Ciclofaixa > > O ideal/certo: acrescenta-se a etiqueta cycleway:[lado]=lane à via > principal. [lado] pode ser :left ou :right e se refere à direção da > "linha" (então cuidado: se a linha tiver oneway=-1, ela aponta no > sentido oposto ao do tráfego). Também é bom acrescentar > oneway:bicycle=yes/no, dependendo se a ciclofaixa é bi- ou > unidirecional em relação à via. Se tiver uma ciclofaixa de cada lado, > cada uma num sentido, é oneway:bicycle=no. Exemplo de via principal > com etiquetas de ciclofaixa: > http://www.openstreetmap.org/way/112410788 > > O factível nesse momento: há quem prefira mapear ciclofaixas como uma > linha separada (pessoal do RJ gosta), mas não está 100% de acordo com > as convenções do OSM (onde só se separa linhas quando há separação > física). Os efeitos colaterais são pequenos, e certamente elimina o > problema de alguém excluir a via principal e redesenhar esquecendo da > ciclovia, então há vantagens. Outra vantagem de separar é ganhar > destaque no mapa cicloviário sem precisar criar uma relação pra isso - > e relações ainda são facilmente quebráveis por usuários inexperientes. > Se você vai olhar o mapa de tempos em tempos e se dispõe a consertar > esses probleminhas, seria o ideal. > > Sugiro que as ciclofaixas mapeadas como ciclovias (linhas separadas) > tenham uma etiqueta fixme="Converter em ciclofaixa assim que editores > não quebrarem relações." pra que as pessoas não se esqueçam de fazer > essa mudança quando der. > > Se você procura por algo simples, pare de ler aqui e faça apenas o > factível. Se quiser algo completo e legal pra mostrar pros outros, > continue. > > 3. Rota ciclística (pra ambos os casos) > > Não é obrigatória, mas é uma sugestão interessante. > > Pra que tanto ciclovia quanto ciclofaixa tenham destaque na camada pra > bicicleta, tem que criar uma relação > type=route+route=bicycle+network=[icn/ncn/rcn/lcn]+roundtrip=yes/no. > Esses valores [icn/ncn/rcn/lcn] são, respectivamente, para redes > cicloviárias internacionais, nacionais, regionais e locais. Redes > municipais são mapeadas com lcn (local cycle network). A etiqueta > roundtrip indica se a relação é um ciclo fechado; pode ser tanto uma > rota circular que volta ao ponto de partida quando uma relação onde os > membros incluem ambos os sentidos, ida e vinda. Exemplo combinando > ciclovia e ciclofaixa numa rota só que é roundtrip porque combina ida > e vinda, que são separadas apesar de serem na mesma avenida: > http://www.openstreetmap.org/relation/5322653 > > Alterna pra camada de bicicletas e aproxima no exemplo pra ver que o > mapa mostra inclusive que a ciclofaixa é unidirecional em cada lado da > via (no trecho da ciclovia a renderização mostra como se fosse > unidirecional, tinha um erro na relação, deve atualizar daqui a uns > dias). Posso ajudar a compor a relação de rota se você quiser. > > Se a rota tiver uma numeração ou código próprio, esse código vai na > etiqueta ref da relação. Se por acaso o sistema for como o Holandês, o > não são as rotas que têm identificação e sim os pontos de conexão > entre as rotas, o esquema é um pouco diferente. Como não conheço o > sistema em São Paulo, me avise se for esse o caso. Exemplo desse caso: > http://www.opencyclemap.org/?zoom=12&lat=52.6709261141&lon=5.18794326937 > > Não é obrigatório, mas é possível também criar uma relação pra agrupar > todas as rotas ciclísticas locais. Exemplo: > http://www.openstreetmap.org/relation/3492114 > > Daí você pode colocar essas relações no wiki e olhar de vez ver se > alguém quebrou algo no mapa por acidente (acontece com frequência, > torço pra que o pessoal do iD resovla isso logo). Uma forma (chata) de > contornar esse problema dos acidentes de mapeamento é diminuir a > atração dos mapeadores à via que tem a ciclofaixa - mapeando-a em > detalhe total. Mas não posso pedir isso, só sugeri
Re: [Talk-br] Ciclovias na calçada
1. Ciclovia (trajeto separado da pista dos automóveis, inclusive se a separação for o meio-fio da calçada) É uma linha com a etiqueta highway=cycleway. Exemplo praticamente igual ao seu: http://www.openstreetmap.org/way/356686653 Uma alternativa seria usar a etiqueta cycleway:[lado]=track, mas tem alguns efeitos colaterais indesejáveis. Faz sentido fazer isso apenas se tiver pressa e se a ciclovia segue a via principal por um longo trecho, sem alternar o lado muitas vezes (que produziria quebras na via principal). 2. Ciclofaixa O ideal/certo: acrescenta-se a etiqueta cycleway:[lado]=lane à via principal. [lado] pode ser :left ou :right e se refere à direção da "linha" (então cuidado: se a linha tiver oneway=-1, ela aponta no sentido oposto ao do tráfego). Também é bom acrescentar oneway:bicycle=yes/no, dependendo se a ciclofaixa é bi- ou unidirecional em relação à via. Se tiver uma ciclofaixa de cada lado, cada uma num sentido, é oneway:bicycle=no. Exemplo de via principal com etiquetas de ciclofaixa: http://www.openstreetmap.org/way/112410788 O factível nesse momento: há quem prefira mapear ciclofaixas como uma linha separada (pessoal do RJ gosta), mas não está 100% de acordo com as convenções do OSM (onde só se separa linhas quando há separação física). Os efeitos colaterais são pequenos, e certamente elimina o problema de alguém excluir a via principal e redesenhar esquecendo da ciclovia, então há vantagens. Outra vantagem de separar é ganhar destaque no mapa cicloviário sem precisar criar uma relação pra isso - e relações ainda são facilmente quebráveis por usuários inexperientes. Se você vai olhar o mapa de tempos em tempos e se dispõe a consertar esses probleminhas, seria o ideal. Sugiro que as ciclofaixas mapeadas como ciclovias (linhas separadas) tenham uma etiqueta fixme="Converter em ciclofaixa assim que editores não quebrarem relações." pra que as pessoas não se esqueçam de fazer essa mudança quando der. Se você procura por algo simples, pare de ler aqui e faça apenas o factível. Se quiser algo completo e legal pra mostrar pros outros, continue. 3. Rota ciclística (pra ambos os casos) Não é obrigatória, mas é uma sugestão interessante. Pra que tanto ciclovia quanto ciclofaixa tenham destaque na camada pra bicicleta, tem que criar uma relação type=route+route=bicycle+network=[icn/ncn/rcn/lcn]+roundtrip=yes/no. Esses valores [icn/ncn/rcn/lcn] são, respectivamente, para redes cicloviárias internacionais, nacionais, regionais e locais. Redes municipais são mapeadas com lcn (local cycle network). A etiqueta roundtrip indica se a relação é um ciclo fechado; pode ser tanto uma rota circular que volta ao ponto de partida quando uma relação onde os membros incluem ambos os sentidos, ida e vinda. Exemplo combinando ciclovia e ciclofaixa numa rota só que é roundtrip porque combina ida e vinda, que são separadas apesar de serem na mesma avenida: http://www.openstreetmap.org/relation/5322653 Alterna pra camada de bicicletas e aproxima no exemplo pra ver que o mapa mostra inclusive que a ciclofaixa é unidirecional em cada lado da via (no trecho da ciclovia a renderização mostra como se fosse unidirecional, tinha um erro na relação, deve atualizar daqui a uns dias). Posso ajudar a compor a relação de rota se você quiser. Se a rota tiver uma numeração ou código próprio, esse código vai na etiqueta ref da relação. Se por acaso o sistema for como o Holandês, o não são as rotas que têm identificação e sim os pontos de conexão entre as rotas, o esquema é um pouco diferente. Como não conheço o sistema em São Paulo, me avise se for esse o caso. Exemplo desse caso: http://www.opencyclemap.org/?zoom=12&lat=52.6709261141&lon=5.18794326937 Não é obrigatório, mas é possível também criar uma relação pra agrupar todas as rotas ciclísticas locais. Exemplo: http://www.openstreetmap.org/relation/3492114 Daí você pode colocar essas relações no wiki e olhar de vez ver se alguém quebrou algo no mapa por acidente (acontece com frequência, torço pra que o pessoal do iD resovla isso logo). Uma forma (chata) de contornar esse problema dos acidentes de mapeamento é diminuir a atração dos mapeadores à via que tem a ciclofaixa - mapeando-a em detalhe total. Mas não posso pedir isso, só sugerir. 2015-07-03 0:38 GMT-03:00 Tiago Fassoni A. A. Leite : > Outra questão para os experts da lista: Como trato ciclovias que foram > simplesmente pintadas na calçada? > > (ah sim, a orientação do mapillary tá zoada porque uso uma sony action cam > que não dá orientação de GPS. Mal ae). > > Trago alguns exemplos: > > http://www.mapillary.com/map/im/O5WRV1NzKiOY1VfMQpgiDA > > http://www.mapillary.com/map/im/jtSjl465K78QD3oi5msoJg > > Alguma ideia de como trato essas coisas no OSM? A wiki de bicicleta não é > muito clara sobre isso. > > Vida Longa e Próspera, > Tiago > > ___ > Talk-br mailing list > Tal
Re: [Talk-br] Declaração de renúncia de voto para decidir traduções de etiquetação
Também acho nada dessa discussão seja de interesse da talk-pt. Mas como todas as respostas nela mencionam o meu nome... Tudo começou aqui, e depois partiu pro lado pessoal e pra questões retóricas e filosóficas que fugiam ao tópico: http://forum.openstreetmap.org/viewtopic.php?pid=513643#p513643 O primeiro e-mail dessa discussão aqui na talk-br (que é do Alexandre falando sobre si) é basicamente uma cópia da mesma mensagem postada lá um pouco mais abaixo. A minha primeira resposta foi curta e dissuasiva, mas a coisa continuou com uma segunda mensagem duplicando outra postagem lá no fórum. Estou tentando fazer o uso adequado de ambos os meios. 2015-07-02 23:46 GMT-03:00 Nelson A. de Oliveira : > 2015-07-02 23:41 GMT-03:00 Fernando Trebien : >> Também não sei, afinal a discussão começou no fórum - e inclusive continuou >> lá. > > É que em algumas mensagens nessa discussão o Alexandre (e você, dando > reply to all, talvez) estão mandando mensagem para a talk-pt também. > Eu não acho que seja de interesse deles essa discussão. > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Declaração de renúncia de voto para decidir traduções de etiquetação
2015-07-02 23:32 GMT-03:00 Alexandre Magno Brito de Medeiros < alexandre@gmail.com>: > E por isso você está querendo, de uma maneira educada, que eu simplesmente > cale a boca sobre qualquer coisa que se refira a mapeamento. > Mas se você não mapeia, o que você tem a dizer de relevante sobre mapeamento? Não quero que se cale, quero que seja relevante. Mas pra ser relevante, tem que mapear. -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Declaração de renúncia de voto para decidir traduções de etiquetação
Também não sei, afinal a discussão começou no fórum - e inclusive continuou lá. 2015-07-02 23:38 GMT-03:00 Nelson A. de Oliveira : > Pessoas... se eu fosse português eu estaria pensando agora "Que raios é isso?" > Sinceramente não creio que precisa mandar nada com cópia para a talk-pt... > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Declaração de renúncia de voto para decidir traduções de etiquetação
Como dizer isso sem ser ofensivo... talvez não tenham usado o código porque não viram utilidade para ele. Porque você, não sabendo do que precisamos porque não mapeia junto com a gente, supôs que seria útil. Se você mapeasse, saberia quais são as nossas reais necessidades, porque seria um mapeador como nós. Seu tempo e foco estariam na direção certa, não perdidos no nada. Se você pode escrever código, pode fazer mapas também. Não são limitações, são objeções/desejos. Estou dizendo que sim, és capaz, só precisas pôr a mão na massa. Mas não queres. 2015-07-02 23:32 GMT-03:00 Alexandre Magno Brito de Medeiros < alexandre@gmail.com>: > Fernando, eu ainda "duvido", sob alguns aspectos, mas eles, os seus > métodos, constituem a sua metodologia, que é o que temos de melhor na > comunidade. Reconheço isso. E com esse "é o que temos" eu não estou dizendo > que são pouca coisa. > > A discussão presente, que você acaba de alimentar, é sim sobre mim. > > Eu não pretendo mapear com toda a abrangência que você(s) mapeia(m). E por > isso você está querendo, de uma maneira educada, que eu simplesmente cale a > boca sobre qualquer coisa que se refira a mapeamento. Com a renúncia ao > voto, eu atendo o que existe de razoável nesse seu desejo implícito. > > OK, eu vou me esforçar para lembrar de sempre consultar a Referência antes > de articular frases opinativas sobre etiquetação. Mas nem se preocupe tanto > com isso... porque eu vou evitar ao máximo estar opinando diretamente sobre > etiquetação. Meu desejo íntimo é que nunca mais eu construa uma frase do > tipo "eu acho que etiqueta=X deveria ser tal coisa", apesar de que eu não > renunciei a isso. > > O assunto etiquetação está pra mim como um livro está para o leitor. Por > ventura o leitor pode interpelar o(s) autor(es) do livro. > > Obviamente eu não estou reclamando um direito de ser o cara que tira o > foco. > > Aceitar crítica técnica deve ser muito mais fácil, especialmente quando se > pode verificar que a técnica realmente está falha, ou que o suposto > conhecimento técnico está quebrado, inconsistente. Aceitar crítica à > personalidade nem sempre é o caso. > > Por vezes, eu não sou capaz — porque nessa atividade de tradução de > etiquetas eu não me empenho (como já declarado várias vezes) — de > determinar se o que relato é um regionalismo. Então é melhor também para > vocês que eu não "chute" ser um regionalismo, propondo-o como tal. Como > você mesmo afirma, o foco também não está nos regionalismos. > > O e-mails que tenho chamado de "registro", e este seguindo eles, não são > principalmente um esclarecimento, são principalmente como um recibo, como > um atestado, como um documento, como um firmamento de palavra, que estou > dando a quem interessar. Suponho que o segundo maior interessado nesse meu > proceder seja você, pois o primeiro sou eu mesmo. Por que? Porque eu quero > continuar por aqui, dentro das minhas limitações. > > Concordo que a crítica evidenciada no último parágrafo foi construtiva. > Mas discordo* dela. Com um leque tão amplo de coisa que pode ser feita na > comunidade, eu não tenho de esperar de mim que obrigatoriamente minha > atividade de contribuição seja em mapeamento, sempre em mapeamento, ou mais > em mapeamento. Eu tenho deixado algum código, algum *know how*, no > GitHub. Coisas relevantes? Não sei. Pra quem? Não sei. Importaram pra mim, > achei que podem importar pra mais alguém. Quando aparentemente nem a mim > importaram, porque não as usei, mas as fiz, as fiz por pensar que a um > mapeador ativo — ou à comunidade tida com um todo — poderiam importar. > Estou de consciência tranquila quanto a isso, pois fiz o que pude e o que > soube, e com boa intenção, e assim pretendo continuar, se a comunidade não > rejeitar, ou até o nível a comunidade não rejeitar. > > * Discordar de uma crítica é não aceitá-la no todo ou em parte. A crítica > construtiva é aquela que o criticado aceita ao menos em parte, seja essa > parte grande ou pequena. Assim eu entendo. > > Alexandre Magno > > > > Em 2 de julho de 2015 21:24, Fernando Trebien > escreveu: > >> Obrigado pelos elogios, depois de duvidar dos meus métodos. Só quero que >> entenda que a discussão não é sobre você (nunca será) e sim sobre o OSM. >> >> Antes de propor uma tradução, considere o que diz na referência. Não >> fazer isso é menosprezar as semanas de suor que foram investidas nela. >> Traduções ruins têm consequẽncias que nos custam muito trabalho para >> consertar. Traduções literais (que você defendeu hoje) frequentemente são >> ruins, isso já tinha sido bem estabelecido há bastante tempo, não tinha por >> que questionar. >> >> Tenha foco: você nunca
Re: [Talk-br] Declaração de renúncia de voto para decidir traduções de etiquetação
a "para a comunidade", ainda que o agente >> sempre colha, querendo ou não, algo daquilo que concretiza para os outros. >> >> Como eu posso dizer aqui neste tópico, depois do que já escrevi, que "o >> seu método está bem"? É porque você não se deu conta: as minhas >> argumentações que podem golpeado o seu método são basicamente defesas do >> direito de eu fazer meus relatos. >> >> Você é muito capaz. Pode dar muito a esta comunidade, como já dava desde >> antes de eu chegar aqui e trocarmos as primeiras mensagens. A dois ou três >> dias atrás, quando percebi que você voltara a interagir através de nossos >> canais de comunicação públicos (especialmente a talk-br), inclusive >> dirigindo-se a mim, eu dei Graças a Deus (dê-me licença se você for ateu). >> Todos sentiram sua falta! EU TAMBÉM SENTI. Evidentemente eu não senti nem >> um pouco a falta de nossas dificuldades de relacionamento. Digamos que "a >> culpa seja minha e só minha", peço-lhe encarecidamente: não compartilhe seu >> conhecimento como se fosse apenas "compartilhar com Alexandre". Por favor, >> não faça isso. Se eu lhe pergunto, e a pergunta for digna, você pode >> respondê-la À COMUNIDADE. Obviamente, eu serei beneficiado. Se você notar >> que a comunidade não ganha, ou que não vale a pena o esforço, simplesmente >> não me responda. Isso não significará que estejamos sem falar um com outro. >> Eu espero que não. >> >> Eu lhe digo que na minha terra várias pessoas chamam sinal. Com esse >> relato eu já estou defendendo com unhas e dentes que esse deveria ser o >> termo no OpenStreetMap? Não! Só você me leva tão a sério. Eu podia ficar >> calado e nunca mencionar que por aqui é sinal. Eu vou fazer isso? Não! Está >> em mim a necessidade de compartilhar uma informação tão simples como essa. >> Se eu sei que a chave está na gaveta e não é para o mal que a estão >> procurando, eu digo onde a chave está. >> >> Sim, as pessoas não lêem tudo o que eu escrevo. Mas o importante é que a >> tal renúncia está gravada no fórum e no histórico da talk-br (e da >> talk-pt), incluindo imagem de tela. A quem interessar, eu sugiro que guarde >> cópias locais, começando por você, Fernando. Se necessário vier a se >> tornar, a qualquer tempo poderão esfregar a renúncia na minha cara. Simples >> assim. Mas não o façam antes de poderar se estou realmente desonrando-a; >> porque de outro modo eu me defenderei e será um novo desgaste. Eu não posso >> fazer introduções à minha renúncia toda vez que eu for submeter à >> comunidade relatos daquele tipo. E o comportamento de sinalizar com uma >> breve expressão pode dar a entender, quando negligenciado, que não estou >> renunciando ao voto naquele momento. Mas eu acato a sugestão de — pelo >> tentar — usar sempre um "aqui em Natal se usa [expressão X]". Tentar! E >> mesmo que eu proceda assim, isso nunca vai real e infalivelmente comunicar >> que eu sou renunciante do voto ali. >> >> Agora, você e demais interessados em traduzir etiquetação, lembrem que >> assim permanenço agindo: eu não estarei, de nenhum modo, nunquinha, >> participando com opiniões (os achismos) em tópicos que não sejam >> desenvolvidos em nosso idioma. >> >> Digamos que eu faça ou tenha feito uma tradução errada ou errônea, de >> software ou texto discursivo, em qualquer material que afete OpenStreetMap, >> por gentileza passem a renúncia na minha cara e eu ficarei feliz em ser >> lembrado dela e em efetuar ou deixar que efetuem, naquelas traduções, as >> correções cabíveis. >> >> Eu me comprometo a TENTAR evidenciar ao máximo que meus eventuais >> achismos são achismos. Por exemplo, usar pelo menos a palavra "acho". Se eu >> estiver falando de algo não definido como se fosse já definido, peço que, >> por favor, apontem o erro: "Ei Alexandre, isso não está definido". >> >> E lembremos que tudo aqui eu estou de "etiquetação". >> > Print screen: http://imgur.com/WSHMwy3 > > > > Alexandre Magno > > > Em 2 de julho de 2015 14:51, Fernando Trebien > escreveu: > >> Nem todos vão ler essa mensagem. Ninguém é obrigado a ler tudo. >> On 2 Jul 2015 14:04, "Alexandre Magno Brito de Medeiros" < >> alexandre@gmail.com> wrote: >> >>> Contexto: >>> http://forum.openstreetmap.org/viewtopic.php?pid=513657#p513657 >>> >>> >>> >>> *Declaro explicitamente aqui (e na talk-br, o que farei nos próximos >>> minutos) que renuncio, nesta comunidade, a votar (ter voto) em qualquer >>> di
Re: [Talk-br] Declaração de renúncia de voto para decidir traduções de etiquetação
Nem todos vão ler essa mensagem. Ninguém é obrigado a ler tudo. On 2 Jul 2015 14:04, "Alexandre Magno Brito de Medeiros" < alexandre@gmail.com> wrote: > Contexto: http://forum.openstreetmap.org/viewtopic.php?pid=513657#p513657 > > > > *Declaro explicitamente aqui (e na talk-br, o que farei nos próximos > minutos) que renuncio, nesta comunidade, a votar (ter voto) em qualquer > disputa sobre tradução de etiquetas de mapeamento. Não obstante, eu não me > insentarei de expor minhas vivências pessoais que estejam diretamente > relacionadas a possíveis significados da etiqueta. Quero fazer assim porque > não quero renunciar à oportunidade de contribuir mediante relato. Os > votantes na disputa de tradução tratem de desconsiderar SEMPRE minha > opinião como um voto. Se algum dia, na minha vida, eu quiser retroceder a > respeito dessa posição, comprometo-me a fazer declaração que anule a > presente com visibilidade igual ou superior à que esta ganhará por ficar > registrada no histórico da talk-br e do fórum.* > Print Screen: http://imgur.com/WIflZJi > > > > Eu não tinha lembrado da talk-pt, mas obviamente ela também importa. Então > agora a estou incluindo no endereçamento. > > Alexandre Magno > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br > > ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Traduções em português do iD e JOSM
Tem discussões sobre tradução no fórum [1][2][3] e no wiki [4]. Na verdade, tem mais discussões (por número) sobre tradução no wiki do que no fórum. Pro pessoal que tá interessado no assunto "tradução", faz sentido discutir no wiki. Basta se inscrever nas páginas da referência e de discussão da mesma pra receber notificações por e-mail quando algo muda ou alguém contesta algo. [1] http://forum.openstreetmap.org/viewtopic.php?id=22084 [2] http://forum.openstreetmap.org/viewtopic.php?id=23048 [3] http://forum.openstreetmap.org/viewtopic.php?id=24498 [4] http://wiki.openstreetmap.org/wiki/Talk:WikiProject_Brazil/Refer%C3%AAncia 2015-07-02 10:04 GMT-03:00 Nelson A. de Oliveira : > Bom, o Lambertus (que cuida do forum) disse que por enquanto não é > possível criar sub-forums. > A sugestão dele foi a de usar um prefixo para diferenciar as > discussões sobre tradução. > > Então para tentar organizar melhor as discussões sobre tradução, vamos > utilizar o seguinte formato de assunto no forum: > > [Tradução] Assunto a ser discutido > > Assim como o wille já fez aqui: > http://forum.openstreetmap.org/viewtopic.php?pid=513600 > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Track = via agro-florestal
Duna tracktype4: http://www.praiasecia.com.br/images/stories/rj_1024/rj-cabo-frio-praia-das-dunas-030.jpg Duna tracktype5: http://2.bp.blogspot.com/-Vj7CvAA_cdE/UCQPkC3zS6I/AKI/QdFdzrGJW-E/s1600/dunas.jpg Mas nenhuma dessas tem rastros que indiquem que são usadas regularmente. Eu só mapearia uma algo ali (path ou track ou footway) se tivesse rastros visíveis OU se fosse uma rota publicada (agência de turismo). Dá pra imaginar que a praia é caminhável de uma ponta a outra, embora não intencionalmente (é natural), então dá pra mapear um path (cuja tradução estou sugerindo ser "caminho informal") acompanhando a praia com foot=yes, bicycle=yes, etc., desde que informe também que a superfície não é lá aquelas coisas (surface=sand). Um caminho por "dentro" de uma duna talvez seja algo assim: https://aventuresedotcom.files.wordpress.com/2013/04/trilha-pelas-dunas-florianopolis.jpg Ele é relativamente bem mantido, seria surpreendente a natureza espontaneamente criar algo tão retilíneo com um contraste tão forte com as plantas. Provavelmente tiraram as plantas e jogaram areia por cima, mais de uma vez. Nesse sentido, poderia ser considerado highway=footway: um caminho intencionalmente projetado para pedestres. Para que o usuário saiba o que lhe espera, deve-se acrescentar no mínimo surface=sand a essa via. A mesma lógica se aplicaria à distinção entre track e unclassified: tracks (que estou sugerindo traduzir como "estrada informal") seriam os caminhos acessíveis a carros não oficiais/intencionais, como este: http://www.triptur.com.br/blog/wp-content/uploads/2012/02/dsc03186.jpg E unclassified/terciárias/etc. seriam os intencionais/oficiais, como este: http://www.dimasdecampos.com/wp-content/uploads/2012/12/1-22.jpg Caminhos construídos dentro de fazendas e florestas às vezes se parecem mais com o segundo, mas seriam classificados como tracks quando não construídos pelo governo (aos olhos do grande público, ainda é algo extra-oficial e de uso restrito a quem trabalha no local). Nos poucos casos em que a iniciativa pública abriu esses caminhos para acesso geral, não seriam mais tracks e sim unclassified. Mesmo que em condições ruins, como no segundo exemplo. O fato de tracks em fazendas não serem "service" é porque elas servem para circulação interna, não para chegar ou sair da fazenda, que é o propósito típico das vias service. Nesse sentido, as service são formais/oficiais/intencionais. Por isso colocar a palavra "informal" nas traduções de track e path pode ajudar as pessoas a escolher a classificação correta mais vezes, penso eu. 2015-06-30 17:30 GMT-03:00 Alexandre Magno Brito de Medeiros : > Quando perguntei sobre "trilha dentro de uma duna", não tinha em mente um > caminho com mais de 2 metros de largura. Pelo contrário, tinha em mente um > caminho aberto a facão; mas é claro, um caminho já tão usado que o chão é > areia fofa amarela. Eu não sei o que é uma duna; pra mim não é floresta. Mas > é como eu disse, "a guarda florestal está lá". > > Em 30 de junho de 2015 14:56, Fernando Trebien > escreveu: >> >> Só pra desdizer o que eu acabei de dizer, é track sim nas dunas. Diz no >> artigo sobre tracks: >> >> "If a path is wide enough for 4-wheel-vehicles (width > 2 m), and it is >> not legally signposted or otherwise only allowed for pedestrians, cyclists >> or horseriders, it is often better tagged as a highway=track." >> >> O ideal é acrescentar detalhes como tracktype, smoothness, surface, >> mtb:scale, e as tags de acesso legal (access, motorcar, bicycle, foot, >> wheelchair, etc.). >> >> Via agro-florestal não seria adequada pra esse caso, assim como estrada >> rústica não seria (não é bem uma "estrada" construída). Mas também vale >> notar que esse texto é quase uma nota de rotapé no artigo original. >> >> Que tal "estrada informal" então? >> >> Também acho que, para contrastar com esse caso (como sugere o wiki), >> "path" poderia ser traduzido como "caminho informal". Ambos os casos não são >> projetados pela adminsitração pública, os que são projetados seria >> unclassified (estradas) ou footway (calçadas, caminhos internos em parques, >> calçadas no interior de condomínios, etc.). Footway ficaria (como já está no >> iD) como "caminho de pedestre", cycleway como "ciclovia", e daí eu acho que >> todo o mundo consegue se entender. > > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br > -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Track = via agro-florestal
Só pra desdizer o que eu acabei de dizer, é track sim nas dunas. Diz no artigo sobre tracks: "If a path is wide enough for 4-wheel-vehicles (width > 2 m), and it is not legally signposted or otherwise only allowed for pedestrians, cyclists or horseriders, it is often better tagged as a highway=track." O ideal é acrescentar detalhes como tracktype, smoothness, surface, mtb:scale, e as tags de acesso legal (access, motorcar, bicycle, foot, wheelchair, etc.). Via agro-florestal não seria adequada pra esse caso, assim como estrada rústica não seria (não é bem uma "estrada" construída). Mas também vale notar que esse texto é quase uma nota de rotapé no artigo original. Que tal "estrada informal" então? Também acho que, para contrastar com esse caso (como sugere o wiki), "path" poderia ser traduzido como "caminho informal". Ambos os casos não são projetados pela adminsitração pública, os que são projetados seria unclassified (estradas) ou footway (calçadas, caminhos internos em parques, calçadas no interior de condomínios, etc.). Footway ficaria (como já está no iD) como "caminho de pedestre", cycleway como "ciclovia", e daí eu acho que todo o mundo consegue se entender. 2015-06-30 13:49 GMT-03:00 Fernando Trebien : > Bem, a classificação deve ser feita com base na idéia de "para que serve" a > via. Tracks servem principalmente para dar acesso motorizado ao interior de > fazendas e florestas. Geralmente esse acesso é restrito ao público externo, > mas às vezes é liberado. Em parte ele se contrasta com service, que é para > dar acesso a propriedades e estacionamentos, geralmente apenas acesso local > (access=destination), às vezes público (access=yes). Footways são caminhos > construídos (com ou sem pavimento) para trânsito sobretudo de pedestres > (ex.: calçadas, principais caminhos no interior de parques). Como no Brasil > esses caminhos podem, por lei, ser usados por ciclistas, dá pra adicionar > bicycle=yes a eles. Uma distinção entre track e footway é a sua intenção: > algumas footways comportariam veículos, mas não foram feitas para que esse > seja o tráfego predominante. Vice-versa para track. Pela mesma razão, uma > trilha de caminhada aberta intencionalmente para o turismo seria > highway=footway. Em contraste, um caminho irregular (no sentido de não ter > registros oficiais) por um morro seria path. Cycleways são o equivalente > para ciclistas (também com ou sem pavimento) e geralmente são chamados de > ciclovias. Bridleways são o equivalente para equitação. Tracks, por exemplo, > comportam o trânsito de cavalos, mas não foram feitas com esse objetivo > principal. Paths servem para caminhos difíceis de classificar, como esse > caminho pelas dunas. Outro caso para path seriam caminhos não intencionais > que foram se formando como tempo (ex.: rastros na grama fora dos caminhos > principais em um parque). Nesses casos, o ideal é complementar informação > pra descrever o caminho: quem pode passar por ele (bicycle, foot, > wheelchair, horse, motorcar, motor_vehicle)? Qual o estado da sua superfície > (surface, smoothness, tracktype, mtb:scale, sac_scale)? Se por acaso fosse > um caminho pela praia, contanto que a areia fosse relativamente firme, daria > pra adicionar motorcar=yes e bicycle=yes por exemplo. Muito provavelmente dá > pra adicionar foot=yes e wheelchair=no. > > A confusão toda é porque as pessoas tendem a pensar no mapa concretamente, > no desenho. Tracks são marrons para combinar com o fundo das fazendas e > florestas, não para representar que não são pavimentadas. A questão da > representação da pavimentação no mapa se arrasta, mas tá andando. > > Por essas e outras, faria sentido marcar track como via agro-florestal. Isso > ajudaria os mapeadores a se afastarem do aspecto visual e a se concentrarem > na intenção da via. > > Não sei para discordar. Mas tenho uma pergunta: uma trilha dentro de uma > duna seria etiquetada o que? Podemos considerar o ambiente como "florestal"? > Talvez sim, pois a "guarda florestal" atua lá. > > Em 30 de junho de 2015 02:42, Fernando Trebien > escreveu: >> >> Alguém discorda dessa tradução? > > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br > -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Track = via agro-florestal
Bem, a classificação deve ser feita com base na idéia de "para que serve" a via. Tracks servem principalmente para dar acesso motorizado ao interior de fazendas e florestas. Geralmente esse acesso é restrito ao público externo, mas às vezes é liberado. Em parte ele se contrasta com service, que é para dar acesso a propriedades e estacionamentos, geralmente apenas acesso local (access=destination), às vezes público (access=yes). Footways são caminhos construídos (com ou sem pavimento) para trânsito sobretudo de pedestres (ex.: calçadas, principais caminhos no interior de parques). Como no Brasil esses caminhos podem, por lei, ser usados por ciclistas, dá pra adicionar bicycle=yes a eles. Uma distinção entre track e footway é a sua intenção: algumas footways comportariam veículos, mas não foram feitas para que esse seja o tráfego predominante. Vice-versa para track. Pela mesma razão, uma trilha de caminhada aberta intencionalmente para o turismo seria highway=footway. Em contraste, um caminho irregular (no sentido de não ter registros oficiais) por um morro seria path. Cycleways são o equivalente para ciclistas (também com ou sem pavimento) e geralmente são chamados de ciclovias. Bridleways são o equivalente para equitação. Tracks, por exemplo, comportam o trânsito de cavalos, mas não foram feitas com esse objetivo principal. Paths servem para caminhos difíceis de classificar, como esse caminho pelas dunas. Outro caso para path seriam caminhos não intencionais que foram se formando como tempo (ex.: rastros na grama fora dos caminhos principais em um parque). Nesses casos, o ideal é complementar informação pra descrever o caminho: quem pode passar por ele (bicycle, foot, wheelchair, horse, motorcar, motor_vehicle)? Qual o estado da sua superfície (surface, smoothness, tracktype, mtb:scale, sac_scale)? Se por acaso fosse um caminho pela praia, contanto que a areia fosse relativamente firme, daria pra adicionar motorcar=yes e bicycle=yes por exemplo. Muito provavelmente dá pra adicionar foot=yes e wheelchair=no. A confusão toda é porque as pessoas tendem a pensar no mapa concretamente, no desenho. Tracks são marrons para combinar com o fundo das fazendas e florestas, não para representar que não são pavimentadas. A questão da representação da pavimentação no mapa se arrasta, mas tá andando. Por essas e outras, faria sentido marcar track como via agro-florestal. Isso ajudaria os mapeadores a se afastarem do aspecto visual e a se concentrarem na intenção da via. Não sei para discordar. Mas tenho uma pergunta: uma trilha dentro de uma duna seria etiquetada o que? Podemos considerar o ambiente como "florestal"? Talvez sim, pois a "guarda florestal" atua lá. Em 30 de junho de 2015 02:42, Fernando Trebien escreveu: > Alguém discorda dessa tradução? > ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
[Talk-br] Track = via agro-florestal
Alguém discorda dessa tradução? -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Traduções em português do iD e JOSM
Sim. Mas lembrando que é para a busca no site (atendida pelo Nominatim), não para a página do Nominatim (que não foi incluída no mesmo banco de tradução). 2015-06-29 18:38 GMT-03:00 Alexandre Magno Brito de Medeiros : > Eu entendi isso. Mas digamos que exista uma tradução ruim sendo entregue > pelo Nominatim ao openstreetmap.org, não sei onde ajustá-la. Seria naquele > TranslateWiki? > > Em 29 de junho de 2015 18:26, Fernando Trebien > escreveu: >> >> Hm assim: o Nominatim fornece nomes para a busca no site principal, >> mas a interface do Nominatim não é traduzível ainda porque é voltada >> para desenvolvedores (que afinal não sobrevivem sem inglês). Mas é >> legal que alguém sugira a possibilidade de tradução, talvez >> implementem uma interface pra isso em breve. >> >> 2015-06-29 17:49 GMT-03:00 Alexandre Magno Brito de Medeiros >> : >> > twain47/Nominatim ‒ How to translate nominatim.openstreetmap.org? #292 >> > >> > Tentei colher a informação lá mas estou com dificuldade de me fazer >> > entender. > > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br > -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Traduções em português do iD e JOSM
Hm assim: o Nominatim fornece nomes para a busca no site principal, mas a interface do Nominatim não é traduzível ainda porque é voltada para desenvolvedores (que afinal não sobrevivem sem inglês). Mas é legal que alguém sugira a possibilidade de tradução, talvez implementem uma interface pra isso em breve. 2015-06-29 17:49 GMT-03:00 Alexandre Magno Brito de Medeiros : > twain47/Nominatim ‒ How to translate nominatim.openstreetmap.org? #292 > > Tentei colher a informação lá mas estou com dificuldade de me fazer > entender. > > Em 28 de junho de 2015 22:51, Fernando Trebien > escreveu: >> >> Talvez ninguém tenha olhado porque o site é um projeto, o Nominatim é >> outro, e o que aparece no site são traduções que vêm das duas fontes. Em >> particular, os termos que aparecem na lista de resultados de uma pesquisa >> vêm do Nominatim. >> >> On Sun, Jun 28, 2015 at 10:48 PM, Fernando Trebien >> wrote: >>> >>> Links para todas as traduções: >>> >>> https://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Tradu%C3%A7%C3%B5es >>> >>> 2015-06-28 22:43 GMT-03:00 Alexandre Magno Brito de Medeiros >>> : >>>> >>>> http://wiki.openstreetmap.org/wiki/Nominatim/Special_Phrases >>>> >>>> Em 28 de junho de 2015 22:40, Alexandre Magno Brito de Medeiros >>>> escreveu: >>>>> >>>>> Onde são gerenciadas as traduções do Nominatim? >>>>> >>>>> Em 28 de junho de 2015 22:26, Fernando Trebien >>>>> escreveu: >>>>>> >>>>>> No caso do Nominatim, tinha MUITA coisa pra consertar. Basicamente só >>>>>> 1 tradutor se preocupou e ele pelo visto nem é mapeador. Vai levar um >>>>>> tempo, >>>>>> talvez meses, pra que os consertos passem pro site. > > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br > -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Traduções em português do iD e JOSM
Talvez ninguém tenha olhado porque o site é um projeto, o Nominatim é outro, e o que aparece no site são traduções que vêm das duas fontes. Em particular, os termos que aparecem na lista de resultados de uma pesquisa vêm do Nominatim. On Sun, Jun 28, 2015 at 10:48 PM, Fernando Trebien wrote: > Links para todas as traduções: > https://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Tradu%C3%A7%C3%B5es > > 2015-06-28 22:43 GMT-03:00 Alexandre Magno Brito de Medeiros > : >> http://wiki.openstreetmap.org/wiki/Nominatim/Special_Phrases >> >> Em 28 de junho de 2015 22:40, Alexandre Magno Brito de Medeiros >> escreveu: >>> >>> Onde são gerenciadas as traduções do Nominatim? >>> >>> Em 28 de junho de 2015 22:26, Fernando Trebien >>> escreveu: >>>> >>>> No caso do Nominatim, tinha MUITA coisa pra consertar. Basicamente só 1 >>>> tradutor se preocupou e ele pelo visto nem é mapeador. Vai levar um tempo, >>>> talvez meses, pra que os consertos passem pro site. >>> >>> >> >> >> _______ >> Talk-br mailing list >> Talk-br@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-br >> > > > > -- > Fernando Trebien > +55 (51) 9962-5409 > > "Nullius in verba." -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br