[Talk-br] Excesso de tertiary em Porto Alegre

Sexta Agosto 30 17:22:17 UTC 2013

Soh pensando um pouco mais a fundo, pela proposta anterior (e atual
classificacao de Porto Alegre), um ciclista trabalharia basicamente
com 3 "zonas" na cidade:

Zona 1: proximo ao centro. Quase nenhuma via aqui eh nao-pavimentada,
e todas tem trafego intenso. Mas as residenciais, por terem paradas
mais frequentes, tem um trafego mais lento. Mais interessante pro
ciclista por serem mais seguras.

Zona 2: transicao para a periferia. Aqui normalmente temos o seguinte:
- terciarias: pavimentadas, sempre mais movimentadas que as
residenciais adjacentes, mas vistas no contexto da cidade o movimento
total varia por bairro (alguns bairros sao muito congestionados,
outros nao)
- residenciais: tipicamente nao-pavimentadas, menos movimentas

Conforme a cidade evolui, as terciarias nao-pavimentadas geralmente
sao as primeiras a serem pavimentadas.

Como sou ciclista tambem, sei que ha basicamente 2 perfis: os que
andam rapido e cruzam longas distancias (ao ir pro trabalho, ao
praticar o esporte, etc.) e os que pedalam mais por lazer e andam
devagar. Acho que o primeiro perfil preferiria as terciarias nessa
zona e o outro preferiria as residenciais.

Zona 3: periferia. Aqui ambas as vias tem baixo movimento e geralmente
nao sao pavimentadas. As terciarias sao um pouco mais movimentadas que
as residenciais, mas quase nao faz diferenca pro ciclitas. A ordem de
pavimentacao ao longo do tempo segue o padrao da zona 2.

Essas zonas provavelmente se encontram em muitas cidades de medio
porte (alguem confirma ou desconfirma?). Numa megalopole como Sao
Paulo (nao conheco a fundo), eh provavel que existam algumas "zonas
1", que depois se fundiram gerando "zonas 2" entre elas. Em cidades de
pequeno porte, pode ser que soh exista "zona 2" e "zona 3".

Entao, novamente, a vantagem da classificacao se torna um pouco
relativa a escala com que sao feitas as comparacoes.

Pela nova proposta, um ciclista nao poderia fazer essas "inferencias
aproximadas", nem o motorista conheceria os melhores atalhos por
dentro dos bairros. Mas pode ser que o que eu estou tentando capturar
tambem nao seja uma "terciaria" e sim uma "residencial preferencial",
uma "quaternaria" ou algo do tipo.

2013/8/30 Fernando Trebien <fernando.trebien em gmail.com>:
> A maioria dos roteadores considera apenas a tag maxspeed, e nao
> existindo, considera uma velocidade "adivinhada" pela classificacao da
> via. Alguns consideram fatores como tempo de espera em semaforos e o
> tipo de conversoes a fazer (dobrar a esquerda geralmente demora muito
> mais do que dobrar a direita). Nada impede que algum roteador faca um
> calculo combinando maxspeed, classificacao e numero de pistas
> (inclusive eu acho que faria muito sentido), mas nao sei de nenhum que
> o faca. O meu roteador anterior (Navigon) nao usava nenhuma das duas
> metricas: eles mediram os padroes de trafego, hora a hora, e colocaram
> na base offline do GPS. Entao o roteamento era baseado na velocidade
> media de cada trecho a cada hora do dia. Seria perfeito, nao fosse o
> fato de eu nao poder atualizar as restricoes de conversao quando a
> Prefeitura decide mudar tudo. :P
>
> Para bicicleta, tambem faz diferenca o material da pista (soh 1 mapa
> da ITO renderiza isso) e as elevacoes do terreno (que o OpenCycleMap
> fornece mostrando as curvas de nivel).
>
> Se voce prefere ruas mais calmas, entao geralmente preferiria as ruas
> que o meu algoritmo anterior teria deixado como residenciais. Alem
> disso, considere tambem que eh muito frequente a associacao entre
> "pavimentada" e "preferencial" (foi o que eu observei aqui; nao eh
> sempre mais eh bem comum, e suponho que seja por causa da intensidade
> do trafego), entao, se preferisse ruas calmas, iria pelas
> residenciais, e se preferisse pavimentadas, iria pelas terciarias (mas
> geralmente nao pelas secundarias, muito menos pelas primarias). Com a
> nova proposta, talvez acabasse decidindo passar, sem saber, por ruas
> com trafego medio ao inves de poder optar.
>
> Algo que poderiamos definir tambem eh que vias urbanas nao
> pavimentadas nao podem ser terciarias. Seria util para bicicletas e
> para carros. Mas isso iria de encontro com o que jah decidimos para as
> vias nao-urbanas.
>
>
> 2013/8/30 Arlindo Pereira <openstreetmap em arlindopereira.com>:
>> O resultado da renderização nessa imagem de exemplo me parece BEM mais
>> razoável.
>>
>> Não ligo muito para o roteamento (não tenho carro, uso só bicicleta ou
>> transporte público, para mim rotas que passam por ruas mais calmas/sem
>> ladeiras são mais relevantes), mas tenho uma dúvida: dada duas ruas com a
>> mesma hierarquia (vamos supor highway residential, por exemplo), as duas
>> tagueadas (entre aspas, ok) "completamente", sendo uma com mais faixas de
>> rolamento e maxspeed maior que a outra, o roteador preferiria esta via, ou
>> ele leva em consideração /apenas/ a classificação highway?
>>
>> []s
>> Arlindo
>>
>> On Aug 30, 2013 11:38 AM, "Fernando Trebien" <fernando.trebien em gmail.com>
>> wrote:
>>>
>>> Olah Pedro,
>>>
>>> Vamos lah, ao classificar, seus objetivos sao:
>>> - reservar corredores (como?) - minha sugestao original era partir da
>>> informacao oficial sobre quais sao as arteriais
>>> - analisar a hierarquia das vias restantes em relacao aos corredores
>>> (como?) - parece subjetivo
>>> - evitar descontinuidades na classificacao - isto pode ser facil de
>>> descrever sem deixar duvidas ou interpretacoes ambiguas
>>> - evitar ilhas e culs-de-sac (imagino que sejam aneis desconectados da
>>> malha de primarias e secundarias, certo?) - parece facil descrever
>>> isso claramente tambem
>>> - evitar pontas cegas - facil de descrever tambem
>>>
>>> Voce diz que considerar unicamente a conectividade da via "entre
>>> bairros" nem sempre produz um bom resultado. Concordo, foi uma das
>>> coisas que apontei na discussao anterior com o Flavio.
>>>
>>> No meio dessa discussao, conversando com voces e com um pessoal da
>>> comunidade internacional, parece que o meu metodo original nao incluia
>>> a nocao comum de que, por exemplo, uma secundaria deve se conectar
>>> necessariamente, em ambas as pontas, a outras duas vias que sejam
>>> secundarias ou de classe superior. Eh o problema das pontas soltas,
>>> que o meu algoritmo produz. Se concordamos que deve ser assim sempre,
>>> entao o segundo metodo que eu propus no meio da discussao produz quase
>>> o mesmo resultado que o seu e nao dependeria de analisar se a via liga
>>> bairros ou nao. Ele evitaria as pontas soltas, as ilhas, os binarios
>>> curtos, etc.
>>>
>>> Copiando o metodo (e estendendo um pouco):
>>> 1. Todas as vias do mapa começam como residenciais
>>> 2. Os trechos preferenciais (ininterruptos) mais longos (com pelo
>>> menos, digamos, 3km) seriam primárias (preferencial = tem mais tempo
>>> no semáforo ou não tem placa-pare). Nas cidades que publicarem uma
>>> lista de vias arteriais, faz-se a equivalencia diretamente, sem
>>> precisar analisar a preferencia. (isso economiza muito trabalho)
>>> 3. Daí, os trechos preferenciais restantes mais longos (> 2km) que se
>>> conectam a primárias ou superiores (trunk, motorway) seriam
>>> secundárias
>>> 3.1. Repete-se o passo 3, desta vez permitindo a conexao com outras
>>> secundarias tambem.
>>> 4. Daí, os trechos preferenciais restantes mais longos (> 1km) que se
>>> conectam a secundárias ou superiores (primárias, trunk, motorway)
>>> seriam terciárias
>>> 4.1. Repete-se o passo 4, desta vez permitindo a conexao com outras
>>> terciarias tambem.
>>>
>>> Um pouquinho mais ou um pouquinho menos que esses limiares, um certo
>>> espaco eu acredito ser possivel para uma avaliacao subjetiva. Mas nao
>>> usar 2km como criterio num lugar e 500m em outro, daih o usuario final
>>> deixa de ter uma expectativa razoavel sobre o significado dessas
>>> coisas no mapa.
>>>
>>> O que sobrar eh residencial, exceto em areas nao-residenciais, onde
>>> seria nao-classificada. Sobre esse resultado, aplica-se o restante do
>>> fluxograma (living streets, service, tracks, etc.). Repare que algumas
>>> vias longas mas muito estreitas (como aconteceria dentro de certas
>>> favelas) acabam virando living street, o que me parece bem aceitavel.
>>>
>>> Exemplo do resultado: http://i.imgur.com/V82e690.png
>>> Versus o atual: http://www.openstreetmap.org/#map=16/-30.0543/-51.2207
>>>
>>> Note, no entanto, que em nenhum momento falamos sobre como identificar
>>> quais vias sao "coletoras", e isso eh um conceito fundamental na
>>> engenharia de trafego. Eu as estava tentando extrair atraves das
>>> preferencias, mas enfim. Me parece que esse novo metodo valoriza mais
>>> um criterio estetico e menos outros (como o que seria util para o
>>> roteamento para carros, ciclistas, pedestres, etc.). Eu consigo
>>> imaginar varios casos onde seria util classificar uma via paralela
>>> como terciaria, mesmo que ela nao se conecte a nenhuma das vias
>>> principais da malha urbana. Talvez esses casos devam ser tratados como
>>> excecao, anotados com a tag "note" e descritos no wiki, indicando
>>> quantas pessoas concordam ou discordam do caso excepcional.
>>>
>>> "São realidades espaciais diferentes, e naturalmente a movimentação em
>>> vias residenciais ou mesmo vias importantes vão ser diferentes."
>>>
>>> Exato. Isso sugere que a escala usada para classificacao varia para
>>> cada tipo de via. Me parece que as primarias sempre seriam analisadas
>>> no contexto da cidade toda, as secundarias num nivel mais proximo do
>>> tamanho dos bairros e as terciarias seriam mais locais.
>>>
>>> "Não é simplesmente porque não conheço a cidade, tem algum problema
>>> com a gestão de hierarquia que você fez."
>>>
>>> Qual o problema, a densidade? Se sim, precisamos definir uma densidade
>>> esperada para as terciarias, nao consta em nenhum lugar. Com os
>>> limiares que eu propus acima (e de repente precisamos ajustar), parece
>>> que daria um resultado bem parecido com os exemplos que o Flavio
>>> citou.
>>>
>>> "E Trebien, acho que você está sendo um pouco contraditório ao dizer
>>> que essa linha de pensamento de "importância" é tagging for the
>>> renderer. Utilizar apenas fatores físicos para tags de hierarquia é
>>> justamente o que caracteriza tagging for the renderer."
>>>
>>> Hm dentro dessa linha de pensamento, eu disse que usar o aspecto
>>> "visual" do mapa ao atribuir classificacoes eh tagging for the
>>> renderer. Se voce nao tiver isto em mente, entao nao eh.
>>>
>>> Enfim, lancei mais ideias. Precisamos de opinioes. :D
>>>
>>> 2013/8/30 Pedro Geaquinto <pedrodigea em gmail.com>:
>>> > Bom, aqui no Rio, eu sou mais interessado que o Arlindo para
>>> > classificação
>>> > de vias, porém sempre discuto um pouquinho com ele para ter segurança
>>> > das
>>> > minhas decisões.
>>> > Gostaria de entrar num consenso com o resto do Brasil, vou explicar o
>>> > meu
>>> > esquema:
>>> >
>>> > Primeiramente eu reservo "corredores" entre os bairros e intra-bairros
>>> > ao
>>> > invés de simplesmente vias isolados. Essa é a minha principal
>>> > característica
>>> > para organizar as vias. Depois disso analiso a hierarquia entre tais
>>> > "corredores" e estabeleci alguns padrões:
>>> >
>>> > - Evitar descontinuidades. Exemplos: [1] pequenos trechos motorway (sem
>>> > sinais) em um corredor trunk; [2] binários curtos ("primary") ligando
>>> > trechos de via rápida ("trunk");
>>> >
>>> > - Evitar "ilhas" e "cul-de-sac", principalmente em vias de hierarquia
>>> > acima
>>> > ou igual a tertiary;
>>> >
>>> > - Um complemento a esse pensamento de "evitar cul-de-sac" é também
>>> > evitar
>>> > pontas cegas. Não evito completamente, mas pelo menos tento não ligar
>>> > hierarquias muito contrastantes. Por exemplo, em ferramentas de revisão
>>> > é
>>> > depreciado ligar motorway com qualquer um outro tipo de via que não seja
>>> > trunk, motorway_link ou service;
>>> >
>>> > - Algumas vias até ligam bairros OFICIAIS, mas não são tão importantes e
>>> > criariam tais "cul-de-sac" por estar ligados a binários desiguais, e
>>> > assim
>>> > criariam corredores capengas. Como no exemplo do Corte do Cantagalo [3].
>>> >
>>> > Fiz um documento [4] para esse meu pensamento há muito tempo, também
>>> > engloba
>>> > o que penso sobre links em geral, talvez alguns se lembrem. Vale lembrar
>>> > que
>>> > o Rio de Janeiro é muito descontínuo em certas partes, então devem haver
>>> > discussões diferentes para bairros mesmo na mesma cidade. Comparem por
>>> > exemplo Cordovil [5] com Copacabana. São realidades espaciais
>>> > diferentes, e
>>> > naturalmente a movimentação em vias residenciais ou mesmo vias
>>> > importantes
>>> > vão ser diferentes.
>>> >
>>> > Peço desculpas por não ler aquela toda discussão ou ter discutido com
>>> > mais
>>> > atenção, mas não tive tempo, estive atarefado.
>>> >
>>> > E eu também achei absurdo o número de tertiary em Porto Alegre, há algo
>>> > errado e esse modelo deve ser discutido mais. Não é simplesmente porque
>>> > não
>>> > conheço a cidade, tem algum problema com a gestão de hierarquia que você
>>> > fez.
>>> > E Trebien, acho que você está sendo um pouco contraditório ao dizer que
>>> > essa
>>> > linha de pensamento de "importância" é tagging for the renderer.
>>> > Utilizar
>>> > apenas fatores físicos para tags de hierarquia é justamente o que
>>> > caracteriza tagging for the renderer.
>>> >
>>> > Eu acho que deve se haver uma pequena abertura para discussão da
>>> > comunidade
>>> > local sim. Como disse, seria muito bom uma wiki para cada região
>>> > metropolitana.
>>> >
>>> > Um abraço
>>> >
>>> > [1]: Túnel Santa Bárbara e Av. 31 de Março, são vias sem sinais, porém
>>> > ligam
>>> > a R. Prof. Pereira Reis (com sinais) e Pinheiro Machado (com sinais).
>>> > http://osm.org/go/OVc0kS3M
>>> > [2]: Binário Túnel do Pasmado e Av. Pasteur/Venceslau Brás, liga o
>>> > corredor
>>> > Av. Lauro Sodré - Aterro do Flamengo. http://osm.org/go/OVcxz7QFE-
>>> > [3]: Corte do Cantagalo ou Av. Henrique Dodsworth, liga Copacabana à
>>> > Lagoa.
>>> > http://osm.org/go/OVcxhD0m8--
>>> > [4]: http://i.imgur.com/H47HSya.gif
>>> > [5]: http://osm.org/go/OVdKZpN6
>>> >
>>> >
>>> > 2013/8/29 Fernando Trebien <fernando.trebien em gmail.com>
>>> >>
>>> >> Concordo com vocês, até entrarmos no debate de classificação (e
>>> >> durante também) eu vinha sempre mapeando coisas que não existiam ainda
>>> >> em outros mapas.
>>> >>
>>> >> Mas acho que o que sustenta essa discussão é o fato de que a
>>> >> classificação é a primeira coisa que o usuário enxerga ao acessar o
>>> >> mapa pela primeira vez. Enfim, esse parece ser o assunto mais
>>> >> capicioso e mais subjetivo de todos no OSM, todo o resto me parece
>>> >> suficientemente claro e auto-explicativo (nada que levaria mais de 3
>>> >> ou 4 frases pra explicar e ficar claro). Até explicar como se usa
>>> >> relações é milhares de vezes mais fácil do que decidir uma
>>> >> classificação (mesmo local) que agrade a maioria (ou que desagrade o
>>> >> mínimo possível).
>>> >>
>>> >> 2013/8/29 Arlindo Pereira <openstreetmap em arlindopereira.com>:
>>> >> > Aqui no Rio, eu mapeio as coisas meio no feeling. Tipo, se passam
>>> >> > várias
>>> >> > linhas de ônibus, a via deve ser pelo menos terciária; se é a ligação
>>> >> > entre
>>> >> > diversos bairros, pelo menos secundária, e por aí vai.
>>> >> >
>>> >> > Não cheguei a olhar com calma o algoritmo, pois prefiro focar no
>>> >> > micromapping e nas revisões de outros usuários, mas o Geaquinto andou
>>> >> > mudando a classificação de diversas ruas e avenidas aqui no Rio - e
>>> >> > eu
>>> >> > concordei com a maioria das mudanças.
>>> >> >
>>> >> > Como não conheço PoA (já fui ao FISL 2x, mas não cheguei a andar
>>> >> > muito
>>> >> > na
>>> >> > cidade), preferi não me meter na discussão. Mas concordo que seja
>>> >> > mais
>>> >> > interessante mapear áreas rurais/não mapeadas no Google na medida do
>>> >> > possível.
>>> >> >
>>> >> > []s
>>> >> > Arlindo Pereira
>>> >> >
>>> >> > 2013/8/29 Gerald Weber <gweberbh em gmail.com>
>>> >> >>
>>> >> >> Olá Pessoal
>>> >> >>
>>> >> >> vou meter minha colher de pau na discussão novamente
>>> >> >>
>>> >> >>
>>> >> >> 2013/8/28 Flavio Bello Fialho <bello.flavio em gmail.com>
>>> >> >>>
>>> >> >>> Porto Alegre:
>>> >> >>> http://www.openstreetmap.org/#map=14/-30.0150/-51.1361
>>> >> >>> Londres: http://www.openstreetmap.org/#map=14/51.4816/-0.0560
>>> >> >>
>>> >> >>
>>> >> >> Eu conheço um pouco de Londres. É uma cidade com muitos bolsões
>>> >> >> residenciais, somente com trânsito local, mesmo no centro. O mapa
>>> >> >> indicado
>>> >> >> representa bem o que eu conheço da cidade. Muitas vias residenciais
>>> >> >> isoladas
>>> >> >> ligadas por esparsas vias terciárias. Para morar é ótimo,
>>> >> >> super-sossegado,
>>> >> >> para se locomover é um inferno.
>>> >> >>
>>> >> >> Já Porto Alegre eu estive em Julho por uma semana. Depois de começar
>>> >> >> a
>>> >> >> interagir com o OSM é difícil não andar num lugar novo e não pensar
>>> >> >> na
>>> >> >> classificações que eu daria nas ruas, acho que esta história de
>>> >> >> mapear
>>> >> >> é uma
>>> >> >> verdadeira cachaça :) No caso, eu andei bastante à pé no entorno da
>>> >> >> Avenida
>>> >> >> Carlos Gomes e me chamou a atenção o trânsito intenso em todas as
>>> >> >> vias.
>>> >> >> Portanto quando olho o mapa atual de Porto Alegre me parece bastante
>>> >> >> coerente o número grande de vias terciárias.
>>> >> >>
>>> >> >> Naturalmente este é um olhar de forasteiro ;)
>>> >> >>
>>> >> >> Agora dito isto, eu penso que os nossos mapas tem tantas
>>> >> >> deficiências,
>>> >> >> tantas cidades médias e grandes com quase nada mapeado que nossas
>>> >> >> prioridades deveriam ser outras.
>>> >> >>
>>> >> >> Por isto hoje em dia eu quase só mapeio em áreas rurais. Iniciei
>>> >> >> mapeando
>>> >> >> meu bairro em Belo Horizonte. Foi um aprendizado muito bom. Mas
>>> >> >> existem
>>> >> >> várias alternativas de mapas para BH. Poucas pessoas entendem porque
>>> >> >> deveriam usar os mapas do OSM de BH se existem tantas alternativas.
>>> >> >> Já
>>> >> >> as
>>> >> >> áreas rurais são completamente carentes, não existem alternativas e
>>> >> >> por
>>> >> >> isto
>>> >> >> que hoje eu concentro meus esforços nestas regiões. Quando a gente
>>> >> >> mostra um
>>> >> >> mapa completo de uma região que no Google só aparece como um único
>>> >> >> pontinho,
>>> >> >> aí você captura o interesse das pessoas.
>>> >> >>
>>> >> >> Eu vi que vocês já estão acalmando um pouco na discussão. Isto é
>>> >> >> muito
>>> >> >> bom. Então aproveitem e identifiquem as verdadeiras carências de
>>> >> >> suas
>>> >> >> regiões. Eu tenho certeza que são muitas.
>>> >> >>
>>> >> >> um grande abraço
>>> >> >>
>>> >> >> Gerald
>>> >> >>
>>> >> >> _______________________________________________
>>> >> >> Talk-br mailing list
>>> >> >> Talk-br em openstreetmap.org
>>> >> >> http://lists.openstreetmap.org/listinfo/talk-br
>>> >> >>
>>> >> >
>>> >> >
>>> >> > _______________________________________________
>>> >> > Talk-br mailing list
>>> >> > Talk-br em openstreetmap.org
>>> >> > http://lists.openstreetmap.org/listinfo/talk-br
>>> >> >
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Fernando Trebien
>>> >> +55 (51) 9962-5409
>>> >>
>>> >> "The speed of computer chips doubles every 18 months." (Moore's law)
>>> >> "The speed of software halves every 18 months." (Gates' law)
>>> >>
>>> >> _______________________________________________
>>> >> Talk-br mailing list
>>> >> Talk-br em openstreetmap.org
>>> >> http://lists.openstreetmap.org/listinfo/talk-br
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > Talk-br mailing list
>>> > Talk-br em openstreetmap.org
>>> > http://lists.openstreetmap.org/listinfo/talk-br
>>> >
>>>
>>>
>>>
>>> --
>>> Fernando Trebien
>>> +55 (51) 9962-5409
>>>
>>> "The speed of computer chips doubles every 18 months." (Moore's law)
>>> "The speed of software halves every 18 months." (Gates' law)
>>>
>>> _______________________________________________
>>> Talk-br mailing list
>>> Talk-br em openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-br
>>
>>
>> _______________________________________________
>> Talk-br mailing list
>> Talk-br em openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-br
>>
>
>
>
> --
> Fernando Trebien
> +55 (51) 9962-5409
>
> "The speed of computer chips doubles every 18 months." (Moore's law)
> "The speed of software halves every 18 months." (Gates' law)

-- 
Fernando Trebien
+55 (51) 9962-5409

"The speed of computer chips doubles every 18 months." (Moore's law)
"The speed of software halves every 18 months." (Gates' law)