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=-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=-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=-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=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-pt] Fotos para valores de surface=* no wiki português
Prezados colegas portugueses, Recentemente um colabor brasileiro traduziu o artigo no wiki português sobre a etiqueta surface=* [1] com enfoque no contexto brasileiro, ilustrando com fotos do sul do Brasil. Muitas delas eu removi para evitar que o conteúdo se diferenciasse demasiadamente daquele usado pelas comunidades de outros países, e, em alguns casos, para evitar um conflito com a prática mais estabelecida dentro e fora do Brasil, que sempre usou o wiki inglês como referência principal para esta etiqueta. No entanto, para evitar ressentimentos, a comunidade brasileira sugeriu (em discussão no Telegram) que as fotos que eu retirei deveriam ser reintroduzidas no artigo, o que eu fiz. Listo a seguir URLs referentes à alteração [2], ao conteúdo anterior [3] e ao novo [4]. Como o prefixo Pt no wiki é compartilhado entre as comunidades lusófonas, pergunto: concordam com a reintrodução das fotos? Cumprimentos, [1] https://wiki.openstreetmap.org/wiki/Template:Pt:Map_Features:surface [2] https://wiki.openstreetmap.org/w/index.php?title=Template%3APt%3AMap_Features%3Asurface=revision=1587552=1587392 [3] https://wiki.openstreetmap.org/w/index.php?title=Template:Pt:Map_Features:surface=1587392 [4] https://wiki.openstreetmap.org/w/index.php?title=Template:Pt:Map_Features:surface=1587552 -- Fernando Trebien +55 (51) 99962-5409 "Nullius in verba." ___ Talk-pt mailing list Talk-pt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-pt
[OSM-legal-talk] Brazilian postal code database patent application in Germany apparently rejected
Hello, In Brazil we're discussing the legality of mapping postal codes using official data sources and we've found formal communications from the Brazilian Post (EBCT) [1] saying that the organization has filed a patent on the database with German Patent Applicatations, reference number 10.346.551.0. I've found the application on DPMA's website [2], but I'm unfamiliar with the terminology, so I'd kindly like to ask you for some help interpreting what it says. Under "Procedural Data", an "Examination procedure" was started in 2010 and its "Legal/procedural status" was set to "Decision to reject has become final" in 2016. Does that mean that the application was rejected? [1] https://en.wikipedia.org/wiki/Correios [2] https://register.dpma.de/DPMAregister/pat/register?AKZ=103465510 -- Fernando Trebien +55 (51) 99962-5409 "Nullius in verba." ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
[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=revision=1543243=1450813 [2] https://wiki.openstreetmap.org/w/index.php?title=Template:Map_Features:surface=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: [OSM-talk] Highway=trunk : harmonization between countries ?
On Sat, Feb 24, 2018 at 6:00 PM, Lester Caine <les...@lsces.co.uk> wrote: > I think the main problem is that there are well established guidelines for > various areas on mapping data at both country and region level but in may > cases even those rules do not harmonize. We need the several levels of > highway that are currently accurately mapping UK roads, but other areas of > the world do not need that degree of classifications ... so they just don't > use the ones that are not appropriate ... highway=trunk is currently defined like this in the wiki: "high performance or high importance roads that don't meet the requirement for motorway. In different countries, either performance or importance is used as the defining criterion" So, is it "either" performance "or" importance, or "only one" of those two? It's hard for a local community to agree on which factors count when the definition is vague. What is missing is establishing the >> fundamental purpose << of classification of motorised ways at the global level. Suppose that "performance" is the desirable meaning. That suggests that classification should be done based on physical qualities of the road (leading to fragments of alternating class). If instead "importance" is the desirable meaning, we still need to know what makes the road important: relative or absolute traffic volume? Economics? Planning? Administrative level? Access rights of non-motorised modes? Is it the road's "function" as in "functional classification" [1][2]? Is it the road's suitability for freight [3]? Suppose that "freight" should be an important aspect for the trunk level for any country. That means that trunks must be suitable for truck traffic. That would make the following at least trunk (some might be motorway): - most US highways and interstates (it would be the National Freight Network [4]) - most national AND state highways in Brazil, except those with load restrictions and those that are unpaved and in poor condition (including main routes between several state capitals) - state highways in India (though perhaps not all of them, due to conservation problems - like in Brazil) [1] https://comparativegeometrics.wordpress.com/2013/05/16/how-many-levels-in-a-road-hierarchy/ [2] https://wiki.openstreetmap.org/wiki/User:NE2/classification_FAQ#Why_can.27t_we_use_functional_classification.3F [3] https://en.wikipedia.org/wiki/Trunk_road [4] https://ops.fhwa.dot.gov/freight/infrastructure/nfn/index.htm -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Highway=trunk : harmonization between countries ?
On Sat, Feb 24, 2018 at 2:51 PM, Martin Koppenhoefer <dieterdre...@gmail.com> wrote: > can you please point to some examples? Are you sure about the other maps? > They often don’t show many different road classes on first sight (but they > have them and you can see it as you zoom in and out that there must be more > properties or classes than you can distinguish by color or width) Sure. Let's begin with Matej's example: route 7 on Sulec, Czechia. It's not continuous in OSM, but it is in Google Maps, Here.com and Waze: - https://www.openstreetmap.org/#map=14/50.3083/13.8837 - https://www.google.com.br/maps/@50.30831134,13.88367320,14z - https://wego.here.com/?map=50.30828,13.88449,14,normal In Germany, there are many small stretches of trunk in the area between Berlin, Hamburg and Hannover. On the route Hamburg - Uelzen - Braunschweig, it happens twice along route B4: - in Uelzen: https://www.openstreetmap.org/#map=13/52.9611/10.5890 - in Gifhorn: https://www.openstreetmap.org/#map=13/52.4694/10.5244 No such changes in Google Maps, Here.com or Waze. In Openstreetmap.de, this leads to the interesting effect of knowing where the road is divided. However, that does not translate well elsewhere - for example, in England, on route A40 between Oxford and Gloucester, which is not divided: https://www.openstreetmap.de/karte.html?zoom=18=51.80304=-1.63750=B000TT In Italy, on route SS12 between Verona and Modena, it also happens twice: - in Isolda della Scala: https://www.openstreetmap.org/#map=13/45.2730/11.0218 - in Mirandola: https://www.openstreetmap.org/#map=13/44.8679/11.0485 As in the other example, no such changes in Google Maps, Here.com or Waze. -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Highway=trunk : harmonization between countries ?
gt; >>>> You are demonstrating that you can guess the road class from other data. >>>> I think it's cute, but does not match on-the-ground data in countries where >>>> road classification is well-defined. >>>> >>>> Look, I've spent a lot of time on this and I have better things to do. >>>> Fill in the info for your regions on the wiki and then we can see what we >>>> can do. Until then, bear in mind that "harmonising" European roads will >>>> likely get you banned. I don't want to sound like I'm threatening you, but >>>> I've probably spent all the time I'm willing to spend on arguing with some >>>> random person who wants to break our local road classification system >>>> "because it will look nicer". >>>> >>>> On 24 February 2018 at 07:59, djakk djakk <djakk.dj...@gmail.com> wrote: >>>>> >>>>> Yes, but this rendering does not change when a road crosses a border ^^ >>>>> >>>>> djakk >>>>> >>>>> >>>>> Le sam. 24 févr. 2018 à 05:43, JB <jb...@mailoo.org> a écrit : >>>>>> >>>>>> There is something I don't get. >>>>>> Draw primary the same color as trunk and you have no more « >>>>>> discontinuity »? >>>>>> In France, some commercial map (the most sold, I think) use a >>>>>> different >>>>>> rendering for trunk and primary, because you drive faster on trunks. I >>>>>> like it, I think they like it, because they have been using this >>>>>> rendering for decades. >>>>>> JB. >>>>>> >>>>>> Le 24/02/2018 à 04:45, Fernando Trebien a écrit : >>>>>> > As an exercise (and I'm curious about your thoughts on this), I >>>>>> > found >>>>>> > the main routes between place=city within Czechia (didn't have time >>>>>> > to >>>>>> > include cities in adjacent countries, bear that in mind). >>>>>> > >>>>>> > Here's the result [1] using the old colour scheme (motorway=blue, >>>>>> > trunk=green, primary=red; with a little mistake: secondary=yellow). >>>>>> > Top image uses the current classifications, and bottom image is the >>>>>> > result if city-city routes are classified as trunks. Looks very >>>>>> > similar to most other maps. Just by looking at it, it's quite >>>>>> > obvious >>>>>> > which is the main route between each pair of cities. As expected, >>>>>> > the >>>>>> > method also found out the best ways through and around Praha when >>>>>> > going across it. This could also be slightly improved - for example, >>>>>> > with little extra time, it is easier to recommend going through >>>>>> > route >>>>>> > 6 and then Karlovarská than through route 5 and Bucharova. >>>>>> > >>>>>> > I've checked the three small secondary segments using Street View. >>>>>> > Their physical structure is quite good. If still considered >>>>>> > undersirable, there are alternative main ways that increase the >>>>>> > total >>>>>> > time of travel very slightly. Not all routers agreed on taking them >>>>>> > anyway. >>>>>> > >>>>>> > [1] https://i.imgur.com/qFGSveX.jpg >>>>>> > >>>>>> > ___ >>>>>> > talk mailing list >>>>>> > talk@openstreetmap.org >>>>>> > https://lists.openstreetmap.org/listinfo/talk >>>>>> >>>>>> >>>>>> ___ >>>>>> talk mailing list >>>>>> talk@openstreetmap.org >>>>>> https://lists.openstreetmap.org/listinfo/talk >>>>> >>>>> >>>>> ___ >>>>> talk mailing list >>>>> talk@openstreetmap.org >>>>> https://lists.openstreetmap.org/listinfo/talk >>>>> >>>> >> >> On 24 February 2018 at 10:39, djakk djakk <djakk.dj...@gmail.com> wrote: >>> >>> Matej, you don’t have to answer
Re: [OSM-talk] Highway=trunk : harmonization between countries ?
gt; >>> I agree, our trunk roads are a little fuzzy on their definition, but >>> elevating random primary roads to trunk is a loss of data for us. Touching >>> anything else than reclassifying primary to trunk et vice versa will >>> certainly be considered as vandalism in Czechia. >>> >>> You are demonstrating that you can guess the road class from other data. >>> I think it's cute, but does not match on-the-ground data in countries where >>> road classification is well-defined. >>> >>> Look, I've spent a lot of time on this and I have better things to do. >>> Fill in the info for your regions on the wiki and then we can see what we >>> can do. Until then, bear in mind that "harmonising" European roads will >>> likely get you banned. I don't want to sound like I'm threatening you, but >>> I've probably spent all the time I'm willing to spend on arguing with some >>> random person who wants to break our local road classification system >>> "because it will look nicer". >>> >>> On 24 February 2018 at 07:59, djakk djakk <djakk.dj...@gmail.com> wrote: >>>> >>>> Yes, but this rendering does not change when a road crosses a border ^^ >>>> >>>> djakk >>>> >>>> >>>> Le sam. 24 févr. 2018 à 05:43, JB <jb...@mailoo.org> a écrit : >>>>> >>>>> There is something I don't get. >>>>> Draw primary the same color as trunk and you have no more « >>>>> discontinuity »? >>>>> In France, some commercial map (the most sold, I think) use a different >>>>> rendering for trunk and primary, because you drive faster on trunks. I >>>>> like it, I think they like it, because they have been using this >>>>> rendering for decades. >>>>> JB. >>>>> >>>>> Le 24/02/2018 à 04:45, Fernando Trebien a écrit : >>>>> > As an exercise (and I'm curious about your thoughts on this), I found >>>>> > the main routes between place=city within Czechia (didn't have time >>>>> > to >>>>> > include cities in adjacent countries, bear that in mind). >>>>> > >>>>> > Here's the result [1] using the old colour scheme (motorway=blue, >>>>> > trunk=green, primary=red; with a little mistake: secondary=yellow). >>>>> > Top image uses the current classifications, and bottom image is the >>>>> > result if city-city routes are classified as trunks. Looks very >>>>> > similar to most other maps. Just by looking at it, it's quite obvious >>>>> > which is the main route between each pair of cities. As expected, the >>>>> > method also found out the best ways through and around Praha when >>>>> > going across it. This could also be slightly improved - for example, >>>>> > with little extra time, it is easier to recommend going through route >>>>> > 6 and then Karlovarská than through route 5 and Bucharova. >>>>> > >>>>> > I've checked the three small secondary segments using Street View. >>>>> > Their physical structure is quite good. If still considered >>>>> > undersirable, there are alternative main ways that increase the total >>>>> > time of travel very slightly. Not all routers agreed on taking them >>>>> > anyway. >>>>> > >>>>> > [1] https://i.imgur.com/qFGSveX.jpg >>>>> > >>>>> > ___ >>>>> > talk mailing list >>>>> > talk@openstreetmap.org >>>>> > https://lists.openstreetmap.org/listinfo/talk >>>>> >>>>> >>>>> ___ >>>>> talk mailing list >>>>> talk@openstreetmap.org >>>>> https://lists.openstreetmap.org/listinfo/talk >>>> >>>> >>>> ___ >>>> talk mailing list >>>> talk@openstreetmap.org >>>> https://lists.openstreetmap.org/listinfo/talk >>>> >>> > > On 24 February 2018 at 10:39, djakk djakk <djakk.dj...@gmail.com> wrote: >> >> Matej, you don’t have to answer quickly, you can answer one time per week >> if you prefer, the strong arguments will still weight well :) >> >> djakk >> >
Re: [OSM-talk] Highway=trunk : harmonization between countries ?
As an exercise (and I'm curious about your thoughts on this), I found the main routes between place=city within Czechia (didn't have time to include cities in adjacent countries, bear that in mind). Here's the result [1] using the old colour scheme (motorway=blue, trunk=green, primary=red; with a little mistake: secondary=yellow). Top image uses the current classifications, and bottom image is the result if city-city routes are classified as trunks. Looks very similar to most other maps. Just by looking at it, it's quite obvious which is the main route between each pair of cities. As expected, the method also found out the best ways through and around Praha when going across it. This could also be slightly improved - for example, with little extra time, it is easier to recommend going through route 6 and then Karlovarská than through route 5 and Bucharova. I've checked the three small secondary segments using Street View. Their physical structure is quite good. If still considered undersirable, there are alternative main ways that increase the total time of travel very slightly. Not all routers agreed on taking them anyway. [1] https://i.imgur.com/qFGSveX.jpg ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Highway=trunk : harmonization between countries ?
On Fri, Feb 23, 2018 at 7:30 PM, Matej Lieskovský <lieskovsky.ma...@gmail.com> wrote: > Ok, look here: https://www.openstreetmap.org/#map=16/50.3124/13.8720 > The highway=trunk section is a bypass built to motorway specification. It is > not even a motorroad, because it is so short, but the change in the > character of the road is immense - it goes from 2 lanes to 2+2 lanes with a > median, gets wider borders, no pedestrians, cyclists or agricultural > vehicles allowed... The fact that it is drawn as a trunk road hints at all > these changes. You could also map it with lanes=4+foot=no+bicycle=no+agricultural=no and let the renderer decide whether these things are worthy of special representation or not. As a map user, I'm left with a bad impression of a map with such discontinuities, it looks messy and unprofessional. None of the commercial alternatives to OSM have such artifacts. You may also look for other maps of Czechia on Google Images and most won't show artifacts like that either. Also look at the classification of England, Australia and Russia in OSM and you won't find any similar artifacts. I doubt their roads never change structure over long distances. > On 23 February 2018 at 23:18, Fernando Trebien <fernando.treb...@gmail.com> > wrote: >> >> Wouldn't the estimate change often? We usually don't like that in OSM. [1] >> >> [1] >> https://wiki.openstreetmap.org/wiki/Good_practice#Don.27t_map_temporary_events_and_temporary_features >> >> On Fri, Feb 23, 2018 at 7:11 PM, Matej Lieskovský >> <lieskovsky.ma...@gmail.com> wrote: >> > A "traffic" tag sounds like a good idea, but I'd have two suggestions: >> > 1) Can we find a better name? >> > 2) Estimates are better than words. I can imagine what 5000 cars per day >> > look like, but what is considered heavy traffic in (for example) Brazil? >> > >> > I'm all for letting highway tag only worry about high-level stuff >> > (footway, >> > cycleway, road, path...) and have a separate class tag for official >> > classification where needed. >> > >> > I've created this page: >> > https://wiki.openstreetmap.org/wiki/Highway_classes >> > Feel free to add your region! >> > >> > PS: +1 to Michael's point about not changing classifications in >> > countries >> > with an official system. >> > >> > On 23 February 2018 at 23:06, Michael Andersen <o...@hjart.dk> wrote: >> >> >> >> On fredag den 23. februar 2018 15.31.37 CET Fernando Trebien wrote: >> >> >> >> > Assuming the map is correctly classified in Europe, I'm seeing many >> >> > fragments of motorways and trunks all over the map. Is this an >> >> > artifact of local definitions? Or is it intentional and desirable? >> >> >> >> The "fragments" of trunks you see in Denmark are intentional and >> >> desirable. We >> >> follow the official classifications. We will not be happy to see you >> >> change them. >> >> >> >> >> >> >> >> >> >> ___ >> >> talk mailing list >> >> talk@openstreetmap.org >> >> https://lists.openstreetmap.org/listinfo/talk >> > >> > >> > >> > ___ >> > talk mailing list >> > talk@openstreetmap.org >> > https://lists.openstreetmap.org/listinfo/talk >> > >> >> >> >> -- >> Fernando Trebien >> +55 (51) 9962-5409 >> >> "Nullius in verba." > > -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Highway=trunk : harmonization between countries ?
Wouldn't the estimate change often? We usually don't like that in OSM. [1] [1] https://wiki.openstreetmap.org/wiki/Good_practice#Don.27t_map_temporary_events_and_temporary_features On Fri, Feb 23, 2018 at 7:11 PM, Matej Lieskovský <lieskovsky.ma...@gmail.com> wrote: > A "traffic" tag sounds like a good idea, but I'd have two suggestions: > 1) Can we find a better name? > 2) Estimates are better than words. I can imagine what 5000 cars per day > look like, but what is considered heavy traffic in (for example) Brazil? > > I'm all for letting highway tag only worry about high-level stuff (footway, > cycleway, road, path...) and have a separate class tag for official > classification where needed. > > I've created this page: https://wiki.openstreetmap.org/wiki/Highway_classes > Feel free to add your region! > > PS: +1 to Michael's point about not changing classifications in countries > with an official system. > > On 23 February 2018 at 23:06, Michael Andersen <o...@hjart.dk> wrote: >> >> On fredag den 23. februar 2018 15.31.37 CET Fernando Trebien wrote: >> >> > Assuming the map is correctly classified in Europe, I'm seeing many >> > fragments of motorways and trunks all over the map. Is this an >> > artifact of local definitions? Or is it intentional and desirable? >> >> The "fragments" of trunks you see in Denmark are intentional and >> desirable. We >> follow the official classifications. We will not be happy to see you >> change them. >> >> >> >> >> ___ >> talk mailing list >> talk@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk > > > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Highway=trunk : harmonization between countries ?
I don't intend to. But I still wonder why they are desirable. On Fri, Feb 23, 2018 at 7:06 PM, Michael Andersen <o...@hjart.dk> wrote: > On fredag den 23. februar 2018 15.31.37 CET Fernando Trebien wrote: > >> Assuming the map is correctly classified in Europe, I'm seeing many >> fragments of motorways and trunks all over the map. Is this an >> artifact of local definitions? Or is it intentional and desirable? > > The "fragments" of trunks you see in Denmark are intentional and desirable. We > follow the official classifications. We will not be happy to see you change > them. > > > > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Highway=trunk : harmonization between countries ?
On Fri, Feb 23, 2018 at 5:25 PM, Mark Wagner <mark+...@carnildo.com> wrote: > Which one is the "best"? If it's the fast route, there's no issue: > both roads are already "highway=motorway". I think the fastest route is almost always what most people would consider the best. The exception (probably rare/non-existent in the US) would be when the fastest route has infrastructure problems - say, it is a dirt road - while there are nearby routes with fewer problems (say a paved road that takes a little extra time because it is significantly longer). That being an exception, the local community can the discuss the exception (in the forum, so that it can be linked to from the map) and vote against making it the main route. > Fargo and Rapid > City are both larger than any city within 200 miles, which would > seem to make them "large/important", but even by western American > standards, they're pretty small in an absolute sense. I propose that place=* implies importance. Fargo has 105k inhabitants (place=city), Rapid City has 67k inhabitants (place=town). One highway class would connect cities (city-city), a lower class would connect towns and above (town-town, town-city), so the class of the ways making up the route between those places would be of the second class. If cities are connected by trunk and towns by primary, then the route between them would be primary. Now, which is the best route? Google insists on going through McIntosh, whereas Here.com and Waze prefer going through Sioux Falls or Dickinson depending on which direction you're going (mostly because the roads in the area are nearly a grid, which is a characteristic of the US that is not typical of most countries - that's worthy of some discussion). Nonetheless, there are few options to choose from. Google is the dissonant view, so maybe it should be initially ignored. The route through Sioux Falls is part of other routes between pairs of towns (say Sioux City - Grand Forks), so it must be a town-town route for at least that other reason. The remaining question then is whether the route Dickinson - Rapid City should be a town-town route. Dickinson has 17k inhabitants, so it is a town, so that route should be a town-town route. Which one is the main route between Fargo and Rapid City is then not relevant because both options are town-town routes for other reasons. If the situation did not allow us to ignore the problem, the next step would be to collect data (tracklogs), or publicly agree that both routes should be considered important because they're too similar (one possible improvement for the method). It should be noted that the route between Sioux Falls and Fargo would end up being classified as a city-city route because it is part of the main route between Kansas City (place=city, 459k people) and Winnipeg (place=city, 705k people). What if going through McIntosh is really the main route, or if all three routers are wrong? In that case, the initial analysis would be incorrect and the community would need to discuss that particular case and document it. It is possible that routers in the OSM ecosystem (OSRM, GraphHopper) can be used as long as relevant properties (maxspeed=*, and in places with deficitary infrastructure, surface=*) of route alternatives are mapped in OSM so that the routers can take them into account. What if, instead of the US, one is mapping in the UK, where place=* is defined according to public ordinances. In that case, the method still works, it just will judge a place's importance using another criterion instead of population. > Trunk, primary, > or secondary? > > -- > Mark > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Highway=trunk : harmonization between countries ?
I'm glad it is not so much of a problem in Czechia and I hope it would rarely be a problem anywhere. In any case, the idea can be developed further. Matej raises some interesting points that can account for better classification. For example, we could add some bias towards regional and/or national routes, in order to avoid shortcuts (though not forbid them completely if they are significant); likewise, we could add some bias to infrastructure, such as pavement quality, signage quality, feasibility for large vehicles (such as trucks), etc. Most interesting I think is to share with the global community how the local community understands classification. Are access rights really important to the map user, or is it only important to mappers? If so, why can't the renderer parse access tags to decide how to represent the way? (I believe that was the intention when motorroad=* was proposed.) On Fri, Feb 23, 2018 at 3:29 PM, djakk djakk <djakk.dj...@gmail.com> wrote: > Don’t worry, when the official system is good, lik in Czechia, it matches > Fernando’s suggestion :) > > djakk > > > Le ven. 23 févr. 2018 à 18:32, Matej Lieskovský <lieskovsky.ma...@gmail.com> > a écrit : >> >> Don't get me wrong, this system might work well for countries without an >> official system, but what do you expect to happen in the EU? >> Will we have "highway=primary" + "class=tertiary" because some random road >> happens to be a shortcut? Or do you expect us in Czechia to use "class=II" >> while germans use "class=S" so that it actually matches the signage? Will >> the renderer parse ref numbers (and ignore the main tag) or will we receive >> hundreds of complaints about some section of the road having (what every >> local resident will consider to be) the wrong class? >> >> How do you determine "important cities" when even the line between towns >> and cities is country-dependant? Or is using administrative differences only >> not OK for roads? >> >> Even Waze actually follows local administration. >> >> >> Long story short: I am strongly against deploying this system in countries >> with a functioning official classification system. >> >> On 23 February 2018 at 18:06, Fernando Trebien >> <fernando.treb...@gmail.com> wrote: >>> >>> +1 >>> >>> Administrative classification is not strictly related everywhere to >>> signage, structure and access rights. >>> >>> On Fri, Feb 23, 2018 at 1:12 PM, djakk djakk <djakk.dj...@gmail.com> >>> wrote: >>> > I know that « trunk » is country-dependent but why not moving it to a >>> > worldwide definition ? Administrative classification could be moved to >>> > other >>> > tags :) >>> > >>> > >>> > djakk >>> > >>> > Le ven. 23 févr. 2018 à 16:06, Matej Lieskovský >>> > <lieskovsky.ma...@gmail.com> >>> > a écrit : >>> >> >>> >> Greetings >>> >> I'd like to caution against using this system globally. In Czechia, >>> >> roads >>> >> are formally classified into classes, which influence signage, ref >>> >> numbers >>> >> and so on. Deploying this system here would make the tag >>> >> confusing/useless >>> >> and would likely face enormous backlash. I have no problems with using >>> >> this >>> >> system in countries without a clearly defined road classification, but >>> >> please don't touch the countries where there is no doubt about what >>> >> class >>> >> any given road is. >>> >> Happy mapping! >>> >> >>> >> On 22 February 2018 at 16:20, djakk djakk <djakk.dj...@gmail.com> >>> >> wrote: >>> >>> >>> >>> Hello, >>> >>> >>> >>> I totally agree with you, the definition you provide, >>> >>> administrative-free, tends to the same osm map between countries. >>> >>> >>> >>> djakk >>> >>> >>> >>> Le jeu. 15 févr. 2018 à 19:18, Fernando Trebien >>> >>> <fernando.treb...@gmail.com> a écrit : >>> >>>> >>> >>>> Landing on this discussion several months late. I've just heard of >>> >>>> it >>> >>>> by reading a wiki talk page [1]. >>> >>>> >>> >>>> Since 13 February 2009, the wiki [
Re: [OSM-talk] Highway=trunk : harmonization between countries ?
On Fri, Feb 23, 2018 at 3:31 PM, Fernando Trebien <fernando.treb...@gmail.com> wrote: > Assuming the map is correctly classified in Europe, I'm seeing many > fragments of motorways and trunks all over the map. Is this an > artifact of local definitions? Or is it intentional and desirable? I should note that I don't see such artifacts in England, Australia, South Africa, Russia, Japan, among others. > On Fri, Feb 23, 2018 at 2:32 PM, Matej Lieskovský > <lieskovsky.ma...@gmail.com> wrote: >> Don't get me wrong, this system might work well for countries without an >> official system, but what do you expect to happen in the EU? >> Will we have "highway=primary" + "class=tertiary" because some random road >> happens to be a shortcut? Or do you expect us in Czechia to use "class=II" >> while germans use "class=S" so that it actually matches the signage? Will >> the renderer parse ref numbers (and ignore the main tag) or will we receive >> hundreds of complaints about some section of the road having (what every >> local resident will consider to be) the wrong class? >> >> How do you determine "important cities" when even the line between towns and >> cities is country-dependant? Or is using administrative differences only not >> OK for roads? >> >> Even Waze actually follows local administration. >> >> >> Long story short: I am strongly against deploying this system in countries >> with a functioning official classification system. >> >> On 23 February 2018 at 18:06, Fernando Trebien <fernando.treb...@gmail.com> >> wrote: >>> >>> +1 >>> >>> Administrative classification is not strictly related everywhere to >>> signage, structure and access rights. >>> >>> On Fri, Feb 23, 2018 at 1:12 PM, djakk djakk <djakk.dj...@gmail.com> >>> wrote: >>> > I know that « trunk » is country-dependent but why not moving it to a >>> > worldwide definition ? Administrative classification could be moved to >>> > other >>> > tags :) >>> > >>> > >>> > djakk >>> > >>> > Le ven. 23 févr. 2018 à 16:06, Matej Lieskovský >>> > <lieskovsky.ma...@gmail.com> >>> > a écrit : >>> >> >>> >> Greetings >>> >> I'd like to caution against using this system globally. In Czechia, >>> >> roads >>> >> are formally classified into classes, which influence signage, ref >>> >> numbers >>> >> and so on. Deploying this system here would make the tag >>> >> confusing/useless >>> >> and would likely face enormous backlash. I have no problems with using >>> >> this >>> >> system in countries without a clearly defined road classification, but >>> >> please don't touch the countries where there is no doubt about what >>> >> class >>> >> any given road is. >>> >> Happy mapping! >>> >> >>> >> On 22 February 2018 at 16:20, djakk djakk <djakk.dj...@gmail.com> >>> >> wrote: >>> >>> >>> >>> Hello, >>> >>> >>> >>> I totally agree with you, the definition you provide, >>> >>> administrative-free, tends to the same osm map between countries. >>> >>> >>> >>> djakk >>> >>> >>> >>> Le jeu. 15 févr. 2018 à 19:18, Fernando Trebien >>> >>> <fernando.treb...@gmail.com> a écrit : >>> >>>> >>> >>>> Landing on this discussion several months late. I've just heard of it >>> >>>> by reading a wiki talk page [1]. >>> >>>> >>> >>>> Since 13 February 2009, the wiki [2] criticises highway >>> >>>> classification >>> >>>> as problematic/unverifiable. This has also been subject to a lot of >>> >>>> controversy (and edit wars) in my local community (Brazil), >>> >>>> especially >>> >>>> regarding the effect of (lack of) pavement. >>> >>>> >>> >>>> In trying to achieve greater consensus some years ago, I decided to >>> >>>> seek opinions elsewhere and finally I arrived at this scheme [3] >>> >>>> which >>> >>>> I think is very useful, if not perfect yet. It can be easily >>> >>>> summar
Re: [OSM-talk] Highway=trunk : harmonization between countries ?
What do you think about changes of classification at country borders? Can this be somehow reconciled? Assuming the map is correctly classified in Europe, I'm seeing many fragments of motorways and trunks all over the map. Is this an artifact of local definitions? Or is it intentional and desirable? On Fri, Feb 23, 2018 at 2:32 PM, Matej Lieskovský <lieskovsky.ma...@gmail.com> wrote: > Don't get me wrong, this system might work well for countries without an > official system, but what do you expect to happen in the EU? > Will we have "highway=primary" + "class=tertiary" because some random road > happens to be a shortcut? Or do you expect us in Czechia to use "class=II" > while germans use "class=S" so that it actually matches the signage? Will > the renderer parse ref numbers (and ignore the main tag) or will we receive > hundreds of complaints about some section of the road having (what every > local resident will consider to be) the wrong class? > > How do you determine "important cities" when even the line between towns and > cities is country-dependant? Or is using administrative differences only not > OK for roads? > > Even Waze actually follows local administration. > > > Long story short: I am strongly against deploying this system in countries > with a functioning official classification system. > > On 23 February 2018 at 18:06, Fernando Trebien <fernando.treb...@gmail.com> > wrote: >> >> +1 >> >> Administrative classification is not strictly related everywhere to >> signage, structure and access rights. >> >> On Fri, Feb 23, 2018 at 1:12 PM, djakk djakk <djakk.dj...@gmail.com> >> wrote: >> > I know that « trunk » is country-dependent but why not moving it to a >> > worldwide definition ? Administrative classification could be moved to >> > other >> > tags :) >> > >> > >> > djakk >> > >> > Le ven. 23 févr. 2018 à 16:06, Matej Lieskovský >> > <lieskovsky.ma...@gmail.com> >> > a écrit : >> >> >> >> Greetings >> >> I'd like to caution against using this system globally. In Czechia, >> >> roads >> >> are formally classified into classes, which influence signage, ref >> >> numbers >> >> and so on. Deploying this system here would make the tag >> >> confusing/useless >> >> and would likely face enormous backlash. I have no problems with using >> >> this >> >> system in countries without a clearly defined road classification, but >> >> please don't touch the countries where there is no doubt about what >> >> class >> >> any given road is. >> >> Happy mapping! >> >> >> >> On 22 February 2018 at 16:20, djakk djakk <djakk.dj...@gmail.com> >> >> wrote: >> >>> >> >>> Hello, >> >>> >> >>> I totally agree with you, the definition you provide, >> >>> administrative-free, tends to the same osm map between countries. >> >>> >> >>> djakk >> >>> >> >>> Le jeu. 15 févr. 2018 à 19:18, Fernando Trebien >> >>> <fernando.treb...@gmail.com> a écrit : >> >>>> >> >>>> Landing on this discussion several months late. I've just heard of it >> >>>> by reading a wiki talk page [1]. >> >>>> >> >>>> Since 13 February 2009, the wiki [2] criticises highway >> >>>> classification >> >>>> as problematic/unverifiable. This has also been subject to a lot of >> >>>> controversy (and edit wars) in my local community (Brazil), >> >>>> especially >> >>>> regarding the effect of (lack of) pavement. >> >>>> >> >>>> In trying to achieve greater consensus some years ago, I decided to >> >>>> seek opinions elsewhere and finally I arrived at this scheme [3] >> >>>> which >> >>>> I think is very useful, if not perfect yet. It can be easily >> >>>> summarised like this: >> >>>> - trunk: best routes between large/important cities >> >>>> - primary: best routes between cities and above >> >>>> - secondary: best routes between towns/suburbs and above >> >>>> - tertiary: best routes between villages/neighbourhoods and above >> >>>> - unclassified: best routes between other place=* and above >> >>>> &g
Re: [OSM-talk] Highway=trunk : harmonization between countries ?
+1 Administrative classification is not strictly related everywhere to signage, structure and access rights. On Fri, Feb 23, 2018 at 1:12 PM, djakk djakk <djakk.dj...@gmail.com> wrote: > I know that « trunk » is country-dependent but why not moving it to a > worldwide definition ? Administrative classification could be moved to other > tags :) > > > djakk > > Le ven. 23 févr. 2018 à 16:06, Matej Lieskovský <lieskovsky.ma...@gmail.com> > a écrit : >> >> Greetings >> I'd like to caution against using this system globally. In Czechia, roads >> are formally classified into classes, which influence signage, ref numbers >> and so on. Deploying this system here would make the tag confusing/useless >> and would likely face enormous backlash. I have no problems with using this >> system in countries without a clearly defined road classification, but >> please don't touch the countries where there is no doubt about what class >> any given road is. >> Happy mapping! >> >> On 22 February 2018 at 16:20, djakk djakk <djakk.dj...@gmail.com> wrote: >>> >>> Hello, >>> >>> I totally agree with you, the definition you provide, >>> administrative-free, tends to the same osm map between countries. >>> >>> djakk >>> >>> Le jeu. 15 févr. 2018 à 19:18, Fernando Trebien >>> <fernando.treb...@gmail.com> a écrit : >>>> >>>> Landing on this discussion several months late. I've just heard of it >>>> by reading a wiki talk page [1]. >>>> >>>> Since 13 February 2009, the wiki [2] criticises highway classification >>>> as problematic/unverifiable. This has also been subject to a lot of >>>> controversy (and edit wars) in my local community (Brazil), especially >>>> regarding the effect of (lack of) pavement. >>>> >>>> In trying to achieve greater consensus some years ago, I decided to >>>> seek opinions elsewhere and finally I arrived at this scheme [3] which >>>> I think is very useful, if not perfect yet. It can be easily >>>> summarised like this: >>>> - trunk: best routes between large/important cities >>>> - primary: best routes between cities and above >>>> - secondary: best routes between towns/suburbs and above >>>> - tertiary: best routes between villages/neighbourhoods and above >>>> - unclassified: best routes between other place=* and above >>>> >>>> For example, the best route between two villages would be at least >>>> tertiary. So would be the best route between a village and a town or a >>>> city. Parts of this route might have a higher class in case they are >>>> part of a route between more important places. >>>> >>>> It surely raises the problem of determining optimal routes. Maybe a >>>> sensible criterion would be average travel time without traffic >>>> congestion. A number of vehicles may be selected for this average - >>>> could be motorcycle+car+bus+truck, or simply car+truck. >>>> >>>> Early results in my area [4, in Portuguese] seem promising and have >>>> produced more consensus than any previous proposals. To me, this >>>> method seems to: >>>> - resist alternations in classification along the same road >>>> - work across borders (where classification discontinuities are >>>> expected because each country is using different classification >>>> criteria) >>>> - account for road network topology >>>> - work in countries with mostly precarious/unpaved roads or >>>> without/unknown official highway classes >>>> - work between settlements as well as within settlements >>>> >>>> Borderline cases are probably inescapable in any system that does not >>>> use solely criteria that are directly verifiable - from the ground, or >>>> from the law. Maybe, in certain developed countries, the system is so >>>> well organized that merely checking signs/laws is sufficient. That >>>> does not mean it is like that everywhere on the planet. >>>> >>>> OSM has so far received a lot of input from communities in developed >>>> countries (mostly Europe, North America and Australia) and hasn't >>>> given much attention to less developed/organized countries. What comes >>>> closest to this is what the HOT Team does, but the judgment of road >>>> classification one can do from satellite images in a foreign count
Re: [Talk-br] Como mapear Polícia Rodoviária?
2018-02-15 12:56 GMT-02:00 Fidelis Assis <fidelis.as...@gmail.com>: > 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 <fidelis.as...@gmail.com>: > 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: [OSM-talk] Highway=trunk : harmonization between countries ?
://wazeopedia.waze.com/wiki/Brazil/Como_categorizar_e_nomear_vias [11] https://wazeopedia.waze.com/wiki/Germany/Kartenlegende_(Deutschland) [12] https://wazeopedia.waze.com/wiki/France/Classification_France [13] https://wazeopedia.waze.com/wiki/Italy/Tipologia_delle_strade [14] https://wazeopedia.waze.com/wiki/Indonesia/Panduan_Tipe_Jalan [15] https://wiki.waze.com/wiki/%E9%81%93%E8%B7%AF%E7%B1%BB%E5%9E%8B [16] https://wiki.waze.com/wiki/%E3%80%8C%E9%81%93%E8%B7%AF%E7%A8%AE%E5%88%A5%E3%80%8D -- Fernando Trebien +55 (51) 99962-5409 "Nullius in verba." ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
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 <fidelis.as...@gmail.com>:
>
>
> Em 11 de fevereiro de 2018 18:25, Vítor Rodrigo Dias <vitor.d...@gmail.com>
> 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] 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 <gwebe...@gmail.com>: > 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 <fernando.treb...@gmail.com>: > >> 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
2015-07-07 2:32 GMT-03:00 thunder...@gpsinfo.com.br: 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] Opinando
2015-07-07 12:34 GMT-03:00 thunder...@gpsinfo.com.br: 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 2
2015-07-07 13:54 GMT-03:00 thunder...@gpsinfo.com.br: 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 hcto...@gmail.com: 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] 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 li...@gimnechiske.org: 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 fernando.treb...@gmail.com 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 thunder...@gpsinfo.com.br: 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 thunder...@gpsinfo.com.br: 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
2015-07-07 10:53 GMT-03:00 Márcio Vinícius Pinheiro marcioviniciu...@gmail.com: 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] Opinando
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 hcto...@gmail.com: 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
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 thunder...@gpsinfo.com.br: 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 thunder...@gpsinfo.com.br: 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] 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 adriano...@gmail.com: 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 fernando.treb...@gmail.com escreveu: 2015-07-05 4:57 GMT-03:00 Marcio - Thundercel thunder...@gpsinfo.com.br: 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
Re: [Talk-br] Discussões Improdutivas
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] Discussões Improdutivas
2015-07-06 13:48 GMT-03:00 A. Carlos anorcar...@hotmail.com: 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] 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 thunder...@gpsinfo.com.br: 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] Necessidade de intermediaçã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
2015-07-04 21:43 GMT-03:00 Marcio - Thundercel thunder...@gpsinfo.com.br: 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
2015-07-05 1:40 GMT-03:00 Marcio - Thundercel thunder...@gpsinfo.com.br: 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
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
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 thunder...@gpsinfo.com.br 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 thunder...@gpsinfo.com.br: 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
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 li...@gimnechiske.org 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 fernando.treb...@gmail.com 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 thunder...@gpsinfo.com.br 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 thunder...@gpsinfo.com.br: 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
Re: [Talk-br] Necessidade de intermediação
2015-07-05 4:57 GMT-03:00 Marcio - Thundercel thunder...@gpsinfo.com.br: 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 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. -- Fernando Trebien +55 (51) 9962-5409 Nullius in verba. ___ Talk-br mailing list Talk-br
Re: [Talk-br] Necessidade de intermediação
2015-07-04 20:04 GMT-03:00 Marcio - Thundercel thunder...@gpsinfo.com.br: 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
Em tempo. 2015-07-04 20:04 GMT-03:00 Marcio - Thundercel thunder...@gpsinfo.com.br: 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] [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 fernando.treb...@gmail.com 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 spe...@gmail.com 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 o Alexandre Magno, utilizador que submeteu este assunto à lista, aludiu ao facto que na “sua terra” o centro comercial era como uma “baixa da cidade” para nós, PTs (dispenso correções a esta comparação, para o que é serve.) O *Fernando Trebien, segundo protagonista deste evento aqui na lista, refutou o ponto de vista. Opino que as suas observações me parecem, no geral e lidas na diagonal, sensatas e ponderadas. Penso que qualquer um com alguma experiência **a**s partilhará.* O Alexandre resolveu proclamar a sua renúncia de voto mas não abre mão do direito à opinião. E por isso resolveu levar o assunto à
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.07152lat=51.49283zoom=18open_sidebar=map_keyfullscreen=true 2015-07-03 9:24 GMT-03:00 Adriano Rosa adriano...@gmail.com: 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 fernando.treb...@gmail.com 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 fernando.treb...@gmail.com: 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
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 li...@gimnechiske.org: “plaza” pode ser amenity=marketplace Aun Johnsen On Jul 3, 2015, at 19:17, Rogério Plisk rogerpl...@gmail.com 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 fernando.treb...@gmail.com 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 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 fernando.treb...@gmail.com 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 spe...@gmail.com 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
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 nao...@gmail.com: 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-pt] [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 fernando.treb...@gmail.com 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 terá dúvidas relevantes aos mapeadores se não se tornar um mapeador. Vocẽ já disse que não pretende mapear, então é difícil você ter dúvidas relevantes. Isso se aplica também às traduções. Se você levantar dúvidas irrelevantes, não estará contribuindo com o OSM, estará fazendo a gente perder o foco, e com isso, perder tempo. Mesmo que não seja intencional, será um desserviço. Aceite
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 nao...@gmail.com: 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
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 nao...@gmail.com: 2015-07-02 23:41 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: 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
, 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 fernando.treb...@gmail.com 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 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
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
