[Talk-br] [Cocar] Contribuintes para cidades do RJ no OSM

Quarta Dezembro 18 13:41:53 UTC 2013

"mas na minha opinião o OSM se dedica a fornecer mapa para Garmin como o
Tracksource e a Multispectral"

Na verdade, OSM não se dedica a nenhum GPS em particular. Na verdade mesmo,
o OSM não se dedica GPSs, ele é usado para isso, assim como para várias
outras coisas (para roteamento e navegação visual de pedestres, ciclistas,
cadeirantes, para transporte público, e até para mapeamento humanitário:
http://ambientesgeograficos.blogspot.com.br/2010/01/hoje-venho-escrever-sobre-partilha-de.html).
Existe um subprojeto dedicado ao mapeamento para navegação (
http://wiki.openstreetmap.org/wiki/OpenSeaMap) e eles têm tags próprias
(escolhidas por votação) e plugins que eles mesmos fizeram para o JOSM. Em
outros países (notavelmente a França), comunidades de ecologistas até se
dedicam até a mapear árvore por árvore, classificando-as por espécie, e não
estão nem aí pros carros (se pudessem talvez até excluiriam as rodovias do
mapa :P). Tem gente trabalhando no OSM com propósitos ligados ao turismo,
outros que o usam para simulações, para planejamento urbano, e por aí vai.

Um princípio fundamental da comunidade é fazer o máximo para não mapear
pensando nas aplicações (renderizador, navegadores, etc.). São as
aplicações que devem se adaptar ao nosso estilo, idealmente. Claro, nem
sempre dá pra seguir isso à risca (tem certas práticas "idealistas" que
quebram o funcionamento de praticamente todas as aplicações), mas ainda
assim há defensores do ideal e de que as aplicações se virem pra funcionar
corretamente. Eu sou um pouco menos rígido, pois do contrário isso não
levaria o projeto a atingir a difusão a que se propõe.

"a diferença apontada sobre criação de pista dupla onde exista canteiro
central fictício (faixa continua) não foi ainda identificada nos manuais
OSM"

O OSM não possui "manuais" (não há alguém "ditando" regras), pois é um
projeto aberto e em constante evolução. O que existe é o wiki (contendo
propostas de tags aprovadas e recomendações gerais de mapeamento), os
fóruns, as discussões nas listas de e-mail, e quando há um conflito muito
grande, às vezes há uma votação. As pessoas moderam umas às outras. O
sistema do OSM encoraja um pouco de "experimentação" e soluções "criativas"
para certos problemas (dentro de certos limites, claro). Ao lhe indicar que
uma separação é desejável quando há faixa contínua, eu estou lhe dando a
minha opinião e a de mais algumas pessoas e motivos que eu acho
pertinentes. Meu objetivo aqui é influenciar a sua opinião num sentido que
eu considero positivo, inclusive para os propósitos que você me apontou até
agora e que acho que me parecem importantes pra você. Alguém disse uma vez
(e concordo) que no OSM a gente mapeia da forma que é melhor para os
outros, não para si.

Quando você se deparar com uma via com faixa contínua, pense no valor
utilidade de cada tipo de mapeamento (como linha simples ou como duas
linhas separadas) e o impacto que isso tem no roteamento, especialmente
para chegar a um destino. Eu lhe apontei alguns exemplos, mas talvez o
ideal seja você mesmo testar a idéia. Pelo que percebi, essa questão se
torna mais importante em grandes centros urbanos movimentados e menos
importante ao se afastar da cidade (ex.: em rodovias).

Os argumentos "contra" esse estilo geralmente giram em torno de 2 fatores:
o aspecto estético do mapa (vão aparecer 2 linhas ao invés de 1 só) e a
quantidade de trabalho total (pouco mais de 2x, já que é necessário fazer
mais conexões e acrescentar mais restrições de conversão). Como lhe
apontei, o primeiro não me parece ser um problema, e o segundo me parece
valer à pena pelo benefício de ter um roteamento correto.

"Ainda não encontrei no OSM explicação de inserção de restrição de manobra
utilizando-se o JOSM"

http://wiki.openstreetmap.org/wiki/JOSM_Relations_and_Turn_Based_Restrictions

"Esse retorno na Av Chuí não está nomeado no OSM. Nenhum deles."

Está sem nome porque são vias do tipo "secondary_link", que geralmente são
vias sem nome.

"Ora, na minha opinião não se deve descaracterizar o traçado da via
formatada como secundária para se desenhar uma terciária que é o retorno. O
desenho da Av Chuí sentido leste deveria continuar refletindo a reta."

Analisando o seu desenho, vejo que é muito similar ao que está no OSM (que
foi feito por mim), com as seguintes diferenças:

- nomeação dos retornos, acessos e saídas: essa é uma prática abominada no
OSM porque a idéia de "retorno" (assim como a de "acesso") já está expressa
pelo tipo de via (que aqui é secondary_link; atenção a esta última parte,
pois não são do tipo secondary); "Retorno" seria o nome desse segmento caso
houvesse uma placa (daquelas de nome de rua) no local dizendo que aquilo
ali se chama (notavelmente) "retorno", e ainda assim você teria talvez
milhares de elementos com esse nome pela cidade, o que tornaria essa
informação pouco útil, prejudicaria a busca por nomes de ruas, poluiria o
mapa e não acrescenta muito à navegação com auxílio de voz; há pouco tempo
a comunidade brasileira fez um mutirão pra tirar as ocorrências de nomes
como "retorno", "acesso" e "saída" de todas as principais cidades
brasileiras, e aqui em Porto Alegre eu também removi as ocorrências do nome
"rótula" (exceto onde a rótula tem um nome mais notável) porque isso já
está expresso pela tag junction=roundabout

- linhas retas para as vias principais: é uma diferença de cerca de menos
de 2 metros, que por mim tanto faz, eu fiz assim porque dessa forma a
distância média entre o fluxo real e o eixo (representado no mapa) é
minimizada; você vai encontrar gente bem menos cuidadosa e menos criteriosa
editando o OSM todos os dias

Vi que você colocou um retorno também para o sentido oposto da avenida
Chuí. Não está errado, mas na minha opinião, não seria necessário nesse
caso porque:
- a faixa contínua é curta e ocorre num lugar comum (antes de um semáforo)
- não faz diferença para o roteamento

E isso reflete que sim, separar quando ocorre faixa contínua é algo meio
chato de se fazer e produz alguns resultados menos "naturais", e que a
preferência tem sido evitar isso onde não for necessário. Mas isso não quer
dizer que não seja necessário em alguns casos.

2013/12/18 ThUnDeRCeL <thundercel em gpsinfo.com.br>

>   Fernando,
> quando citei minha qualificação em navegação visual isso veio da minha
> formação. Fui educado, sempre quando da defesa uma tese, expor antes a
> qualificação para poder defende-la. Em momento algum imaginei que você
> desconfiava das minhas qualidades e se sei transmiti essa interpretação me
> perdoe.
>
> Sim, venho de um cenário GNSS uma vez que acompanhei o seu nascimento e
> bem conheço o sistema quando ainda defendia seu emprego na navegação aérea
> em reuniões na ICAO.
>
> Na minha opinião Garmin/iGO/PolNav/Destinator/TomTom/ são simplesmente
> softwares de navegação que interpretam dados cartográficos. Cada um deles
> tem determinada peculiaridade e sem duvida é importante saber as
> características de cada um para se poder refletir na base de dados (mapa)
> dados que eles reconhecem, entretanto no tocante a dados de arruamento
> todos eles reconhecem de mesma forma, sem distinção.
>
> Os provedores de mapa como a Navteq, Multispectral, TomTom, Tracksource,
> Mapear, OSM, etc se preocupam em fornecer mapas para serem reconhecidos
> pelos softwares de navegadores citados. Alguns se dedicam a fornecer o mapa
> para inúmeros navegadores e outros para determinado navegador. Nesse
> aspecto, posso estar enganado, mas na minha opinião o OSM se dedica a
> fornecer mapa para Garmin como o Tracksource e a Multispectral. Aqueles que
> desenvolvem mapas para Garmin devem conhecer profundamente as
> características do algoritmo Garmin de forma que possam bem refletir no
> mapa situações que serão bem interpretadas pelo navegador.
>
> Agradeço a você pelo apontamento de diferenças do OSM, isso em muito tem
> ajudado a todos que participam desta lista a aperfeiçoarem seus
> conhecimentos, entretanto a diferença apontada sobre criação de pista dupla
> onde exista canteiro central fictício (faixa continua) não foi ainda
> identificada nos manuais OSM. Foi identificado defesa dessa por alguns em
> fóruns não decisórios.
>
> Mesmo um GPS devidamente configurado produziria o problema que eu descrevi
> pra você anteriormente de não calcular a rota corretamente (onde correto =
> possível fisicamente + permitido legalmente) na chegada/saída de um destino
> numa via com faixa contínua.
> Com palavras não me fiz entender e assim tentarei expor com imagem o
> emprego de restrição de manobra. Importante frisar que essa situação que
> ora apresentarei ocorreu inúmeras vezes comigo em desenvolvimento de mapa
> para o Tracksource.
>
> Suponhamos que existe uma rodovia de pista simples, mão dupla e a essa
> rodovia chega uma rua residencial que se enquadra na sua ponderação.
>
> [image: RESTRICAO]
>
> Observe o sentido aplicado de restrição de manobra.
>
> Assim o condutor que se desloca em sentido Norte pela Rua nunca terá
> roteamento para virar a esquerda (oeste) em chegando na Rodovia porque o
> desenvolvedor impôs nessa manobra uma restrição. O navegador não roteia
> onde exista restrição de manobra.
>
> Ainda não encontrei no OSM explicação de inserção de restrição de manobra
> utilizando-se o JOSM, mas utilizando-se o  Potlach 2 essa explicação está
> em http://wiki.openstreetmap.org/wiki/Potlatch_2/restrictions
>
> Pesquisei no Google o que significa "back track" e não achei a definição.
> Pode esclarecer?
> desculpe pela separação das palavras. É backtrack que significa “voltar
> atrás”
>
> Voltando a situação do shopping no RS decidi observar pelo Street View o
> local.
>
> [image: RS]
>
> Assim esse local se encontra desenhado no OSM
>
> [image: RS1]
>
> Pela analise com mais calma identifico que aí não cabe uma restrição de
> manobra, cabe sim uma revisão do desenho.
>
> Primeiramente cabe lembrar que  a tecnologia avançou e hoje existe a voz
> em TTS no GPS. Assim o desenvolvedor deve sempre evitar deixar via sem
> nome, porque o voz de manobra no GPS não terá nome de via para ler e falar.
> Esse retorno na Av Chuí não está nomeado no OSM. Nenhum deles.
>
> O traçado da Avenida Chuí foi descaracterizado para a criação de outra
> pista possibilitando o retorno. Ora, na minha opinião não se deve
> descaracterizar o traçado da via formatada como secundária para se desenhar
> uma terciária que é o retorno. O desenho da Av Chuí sentido leste deveria
> continuar refletindo a reta.
>
> Vamos a um exemplo real que ocorre aqui no Rio de Janeiro, só que em
> sentido contrário.
>
> [image: RS2]
>
> Nesse exemplo existe a Av Vieira Souto que tem um retorno. Atente para a
> manutenção da reta da Avenida e a rotulação de retorno para quem irá
> retornar pela Av.
> Atente para a hierarquia inferior do retorno em relação a via.
>
> Diferente desse no desenho do RS existe a possibilidade do condutor que
> ingressa no retorno voltar a Av. Ora em ocorrendo isso basta colocar um
> pequeno acesso  de volta a Av, mas em hierarquia inferior da AV e nomeado
> como Acesso à Av Chuí.
>
> Assim eu desenharia esse local assim:
>
> [image: RS3]
>
> Esse arruamento se encontra em arquivo GPX anexado a esta mensagem.
>
> Vou parar por aqui para não ficar muito extensa esta mensagem. Depois
> comento sobre a navegação visual e a interferência nessa navegação de
> abertura de uma via de pista simples para dupla, mesmo que pequena. Só
> lembro que essa abertura se constitui para o navegador um waypoint
> significativo e como tal seria ponto de referencia para ele navegar. Em não
> existindo no terreno essa abertura isso o confundirá quando do planejamento
> antecipado da navegação como no momento da mesma.
>
> []s
> Marcio
>
> -----Mensagem Original-----
> From: Fernando Trebien
> Sent: Wednesday, December 18, 2013 12:51 AM
> To: Cooperativa de Cartografia Digital Livre
> Subject: Re: [Cocar] Contribuintes para cidades do RJ no OSM
>
> Em momento algum eu desconfiei das suas qualificações e habilidades,
> Márcio. Mas é que como você está vindo de um mundo Garmin/iGO/TRC para
> o mundo OSM, sinto a necessidade de lhe apontar algumas diferenças, as
> quais foram questionamentos que eu mesmo fiz quando comecei a
> trabalhar com o OSM. Eu vim de um mundo parecido (usava Navigon).
>
> "Assim um gps devidamente configurado nunca roteará de volta na mesma
> via  de pista simples duplo sentido fazendo uma curva em U."
>
> Mesmo um GPS devidamente configurado produziria o problema que eu
> descrevi pra você anteriormente de não calcular a rota corretamente
> (onde correto = possível fisicamente + permitido legalmente) na
> chegada/saída de um destino numa via com faixa contínua.
>
> Pesquisei no Google o que significa "back track" e não achei a
> definição. Pode esclarecer?
>
> "Em vez de criar a pista dupla inexistente não seria mais fácil se
> criar ali uma restrição de manobra, impedindo na saída do shopping se
> tomar o outro lado da Chuí?"
>
> Seria impossível fazer isso sem conectar a saída do shopping
> diretamente ao cruzamento (os dois pontos a seguir).
>
> http://www.openstreetmap.org/node/634173863
> http://www.openstreetmap.org/node/2000053446
>
> E fazendo isso, estaríamos estendendo a saída por mais de 30 metros -
> e como nosso erro máximo é pra ser de uns 3 metros...
>
> "Nesse aspecto tenho inúmeros outros argumentos técnicos que não
> recomendam o emprego de pista dupla quando essa é de um único
> pavimento asfáltico, sem canteiro real entre faixas de pista. Deixarei
> para um futuro se necessário."
>
> Eu na verdade tenho curiosidade em conhecer esses argumentos, é um
> assunto que me interessa não só pra aprimorar a minha forma de mapear
> como também pra poder influenciar a comunidade na melhor direção
> possível.
>
> "Ora, imagine um utilizador em navegação visual saber que tem uma
> pista simples de mão dupla a frente quando da passagem de um waypoint
> e essa pista nunca chega, o que ele observa no mapa é uma pista dupla.
> Isso gera confusão na navegação visual."
>
> Acho que eu preciso de um exemplo pra entender o que você quer dizer
> exatamente. Pelo que consigo imaginar, se você está fazendo navegação
> visual, acredito que você está olhando para o mapa e para o que está
> ao seu redor à medida que se desloca. Como as linhas separadas são
> muito próximas entre si, você só veria a separação no GPS se estivesse
> fisicamente bem próximo delas - e nessa situação, você entenderia o
> que pode fazer com a via - se pode atravessá-la, de que lado está o
> waypoint, etc.
>
> Já se você estiver procurando uma rota visualmente usando um GPS (mas
> sem o sistema de cálculo de rotas) ou uma versão impressa do mapa,
> você ainda assim não precisaria pensar que uma via separada é
> intransponível, há outras características que você tem que considerar:
> - a classificação da via: vias secundárias, terciárias, residenciais,
> etc., mesmo que separadas, geralmente são transponíveis; primárias às
> vezes são (exceto em horários de pico e na região central das
> cidades); trunk e motorway raramente são transponíveis a pé
> - a presença de obstáculos: no OSM você pode mapear obstáculos
> explicitamente, eis uma lista:
>
> http://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Refer%C3%AAncia#N.C3.A3o_motorizadas
>
> 2013/12/17 ThUnDeRCeL <thundercel em gpsinfo.com.br>:
> > Fernando,
> > andei lendo algumas opiniões nos links apontados e com algumas concordo e
> > com outras não.
> >
> > Existem dois tipos de navegação: assistida e visual
> >
> > Na navegação assistida o utilizador não presta atenção a tela do gps mas
> sim
> > nas instruções recebidas do roteamento.
> >
> > Na visual o utilizador não está com o gps roteado. Ele observa a tela do
> GPS
> > e acompanha o deslocamento por ela.
> >
> > Na navegação assistida li lá um comentário defendendo a criação de pista
> > dupla quando canteiro fictício para se evitar o back track. Acredito que
> > aquele que comentou não deve empregar adequadamente o gps porque esse
> tem a
> > opção de “a evitar” e dentre as lá apontadas existe a do back track.
> Assim
> > um gps devidamente configurado nunca roteará de volta na mesma via  de
> pista
> > simples duplo sentido fazendo uma curva em U.
> >
> > Nesse aspecto tenho inúmeros outros argumentos técnicos que não
> recomendam o
> > emprego de pista dupla quando essa é de um único pavimento asfáltico, sem
> > canteiro real entre faixas de pista. Deixarei para um futuro se
> necessário.
> >
> > Fui instrutor de vôo e no conjunto de missões existia a instrução de
> > navegação visual, portanto me sinto qualificado a descrever princípios
> > básicos da navegação visual, mesmo sendo essa terrestre já que os
> princípios
> > são semelhantes para navegação aérea, terrestre, marítima costeira e
> > fluvial.
> >
> > Quando da navegação visual deve o navegador identificar na rota Waypoints
> > marcantes no terreno. Nesse aspecto surge a necessidade  de se estampar
> no
> > mapa características importantes da topografia.
> >
> > Ora, imagine um utilizador em navegação visual saber que tem uma pista
> > simples de mão dupla a frente quando da passagem de um waypoint e essa
> pista
> > nunca chega, o que ele observa no mapa é uma pista dupla dupla. Isso gera
> > confusão na navegação visual.
> >
> > Vamos aos exemplos:
> >
> > (1)
> http://www.openstreetmap.org/way/244692909#map=19/-30.08240/-51.24333
> > Aqui uma pessoa que estiver saindo do shopping não podia (legalmente) ir
> > diretamente para o outro lado da avenida Chuí porque havia uma faixa
> > contínua branca separando as pistas. Hoje, não pode mesmo porque
> construiram
> > uma barreira física (tachões).
> > Me perdoe, mas essa prática de criação de pista dupla para impedir uma
> > manobra é condenável. A restrição de manobra existe para ser empregada
> > deixando o mapa mais fiel possível a realidade.
> > Em vez de criar a pista dupla inexistente não seria mais fácil se criar
> ali
> > uma restrição de manobra, impedindo na saída do shopping se tomar o outro
> > lado da Chuí?
> >
> > Nem vou comentar os demais porque já observei que em todos optou-se pelo
> > emprego de pista dupla para se restringir manobra. Me perdoe, mas sou
> > totalmente contra essa técnica desconfigurando a característica da via.
> >
> > Sempre busquei empregar restrição de manobra onde necessário e nunca
> > descaracterizei uma via para obter o resultado esperado de roteamento.
> >
> > []s
> > Marcio
> >
> > -----Mensagem Original-----
> > From: Fernando Trebien
> > Sent: Tuesday, December 17, 2013 9:30 PM
> > To: Cooperativa de Cartografia Digital Livre ; OSM talk-br
> > Subject: Re: [Cocar] Contribuintes para cidades do RJ no OSM
> >
> > Vou copiar essa discussão pro talk-br porque já tive e ela antes e não
> > tinha acumulado argumentos suficientes.
> >
> > Se você quiser se inteirar, a minha opinião coincide com a do Markus
> > Lindholm nesta outra discussão:
> > http://gis.19327.n5.nabble.com/Carriageway-divider-td5721108.html
> >
> > Citando alguns trechos:
> > - "That guideline says that a physical separation requires two highway
> > objects, it doesn't say that one shouldn't do the same with legal
> > separation." [em referência ao guideline oficial da comunidade
> > internacional:
> >
> http://wiki.openstreetmap.org/wiki/Editing_Standards_and_Conventions#Divided_highways
> ]
> >
> > - "One other aspect: it would not be possible to create correct routes
> > from an address that's in a middle of a block where the the street has
> > lanes in both direction but that are legally separated. Now if the
> > shortest route would be to turn left (in a country with right hand
> > traffic) but the legal route would require to start the trip by going
> > right, there's no way to express that without having to separate
> > highways, one in each direction. "
> >
> > - "Turn restrictions restrict from which highway object to which highway
> > object one can traverse, they can't tell whether you're allowed to
> > make a left or right turn at the start of your route. " [sobre usar
> > restrições de conversão para definir a direção de saída/chegada]
> >
> > - "As I said earlier physical separation doesn't necessary mean "cannot
> > pass", because physical obstacles come in all kind of different shape
> > and form. Where I live there are plenty of cases of physical
> > separation that any ordinary SUV could easily cross. And then there's
> > the kind that would require a tank. I think that it would be a more
> > pressing objective to be able to
> > provide a legal route from A to B than to cater for all the shortcuts
> > that are possible but not legal."
> >
> > - "Also, no one has offered any other solution to the routing issue. The
> > divider tag has been proposed, but I think it has been demonstrated
> > not to work, as routing decision are made on the node and not on the
> > line."
> >
> > Depois de solicitado um esclarecimento, outro mapeador acrescenta:
> >
> > - "Without two ways you would be routed directly to the end point, but
> > with two ways you will be routed with the needed detour. (...) I don't
> > like mapping like this, but I'm pragmatic and it does solve a real
> > problem (...)"
> >
> > Essa discussão foi feita há 1 ano atrás. Desde então, as tags
> > propostas para marcar a divisão entre as duas mãos foram todas
> > rejeitadas ou abandonadas, e obviamente nenhum GPS as suporta. Então,
> > a única forma de fazer o sistema se comportar corretamente é mapear
> > separadamente quando há separação legal. Isso está de acordo com a
> > idéia básica de que a separação de fluxos é representada por vias
> > separadas, que as vias representam os "fluxos" e não as "ruas" em si.
> >
> > Alguns exemplos:
> >
> > (1)
> http://www.openstreetmap.org/way/244692909#map=19/-30.08240/-51.24333
> >
> > Aqui uma pessoa que estiver saindo do shopping não podia (legalmente)
> > ir diretamente para o outro lado da avenida Chuí porque havia uma
> > faixa contínua branca separando as pistas. Hoje, não pode mesmo porque
> > construiram uma barreira física (tachões).
> >
> > (2)
> http://www.openstreetmap.org/way/189129832#map=18/-30.10236/-51.23257
> >
> > E veja:
> >
> https://maps.google.com/maps?q=-30.10610+-51.24229&hl=en&ll=-30.102551,-51.232595&spn=0.00698,0.018282&sll=37.0625,-95.677068&sspn=57.030354,74.882813&t=h&layer=c&cbll=-30.102556,-51.232589&panoid=Y0i5rQKpmKRoQZ2YBVR65Q&cbp=11,234.4,,0,7.08&z=16
> >
> > Esta grande via (avenida Otto Niemeyer) tem seus sentidos separados
> > apenas por faixa contínua. Não é permitido, chegando ou saindo de um
> > destino, cruzar para o outro lado, em qualquer dos pontos da via. É
> > fisicamente possível? Claro. É seguro? Não durante os horários mais
> > movimentados do dia, e certamente perturbaria o tráfego. Não separar
> > os sentidos levaria a uma rota que precisa ser ajustada no final,
> > causando um grande inconveniente ao motorista já que as quadras aqui
> > são grandes e os cruzamentos cheios de restrições de conversão
> > incomuns.
> >
> > Note que a idéia de "deixa o motorista chegar até o destino, errar a
> > chegada e deixar o GPS encontrar o retorno correto" funciona muito mal
> > aqui. Por exemplo, se a via fosse simples e não separada, e assumindo
> > que o GPS continuasse indicando o caminho, ele recalcularia esse
> > retorno para o motorista:
> >
> > http://osrm.at/5SS
> >
> > E estaria errado, caso o destino estivesse do outro lado da via. Ao
> > confiar no seu GPS, o motorista ficaria dando voltas. O retorno certo
> > seria esse:
> >
> > http://osrm.at/5ST
> >
> > Mas esse cálculo só é possível porque as duas mãos estão mapeadas
> > separadamente.
> >
> > (3)
> http://www.openstreetmap.org/way/189129832#map=18/-30.09951/-51.24809
> >
> > E veja:
> >
> https://maps.google.com/maps?q=-30.10610+-51.24229&hl=en&ll=-30.099744,-51.24849&spn=0.002468,0.00457&sll=37.0625,-95.677068&sspn=57.030354,74.882813&t=h&layer=c&cbll=-30.099742,-51.248491&panoid=UmlOMl-N8ZBGhZ5NoZ4KHg&cbp=12,194.92,,0,10.46&z=18
> >
> > A situação aqui é igual à anterior,  mas a via é ainda mais
> > movimentada, por ser uma arterial.
> >
> > (4)
> http://www.openstreetmap.org/way/189129832#map=19/-30.05666/-51.21515
> >
> > E veja:
> >
> https://maps.google.com/maps?q=-30.10610+-51.24229&hl=en&ll=-30.056625,-51.215247&spn=0.002469,0.00457&sll=37.0625,-95.677068&sspn=57.030354,74.882813&t=h&layer=c&cbll=-30.056625,-51.215248&panoid=r1R5WFPiRM7Tk_ubJGAJPw&cbp=11,42.92,,0,14.15&z=18
> >
> > Esse exemplo é interessante porque ocorre exatamente no momento em que
> > a via passa a ter separação legal. É uma via extremamente movimentada,
> > fazer algo contra a lei aqui lhe daria muitos problemas e, ao errar a
> > direção certa para chegar no destino, fica bem complicado encontrar o
> > retorno certo.
> >
> > Enfim, Márcio, sendo esse um assunto que ainda não foi devidamente
> > contemplado pela comunidade, você pode mapear como via simples, mas
> > apenas cuidado para não desfazer o trabalho dos outros que já
> > aplicaram a separação por estes motivos.
> >
> > Abraços,
> >
> > Fernando
> >
>
>
>
> --
> 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)
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.openstreetmap.org/pipermail/talk-br/attachments/20131218/b812d8de/attachment-0001.html>
-------------- Próxima Parte ----------
Um anexo não-texto foi limpo...
Nome: RS3[1].png
Tipo: image/png
Tamanho: 38587 bytes
Descrição: não disponível
URL: <http://lists.openstreetmap.org/pipermail/talk-br/attachments/20131218/b812d8de/attachment-0001.png>
-------------- Próxima Parte ----------
Um anexo não-texto foi limpo...
Nome: RS2[1].jpg
Tipo: image/jpeg
Tamanho: 27417 bytes
Descrição: não disponível
URL: <http://lists.openstreetmap.org/pipermail/talk-br/attachments/20131218/b812d8de/attachment-0004.jpg>
-------------- Próxima Parte ----------
Um anexo não-texto foi limpo...
Nome: RS1[1].jpg
Tipo: image/jpeg
Tamanho: 20700 bytes
Descrição: não disponível
URL: <http://lists.openstreetmap.org/pipermail/talk-br/attachments/20131218/b812d8de/attachment-0005.jpg>
-------------- Próxima Parte ----------
Um anexo não-texto foi limpo...
Nome: RS[1].jpg
Tipo: image/jpeg
Tamanho: 61875 bytes
Descrição: não disponível
URL: <http://lists.openstreetmap.org/pipermail/talk-br/attachments/20131218/b812d8de/attachment-0006.jpg>
-------------- Próxima Parte ----------
Um anexo não-texto foi limpo...
Nome: RESTRICAO[1].jpg
Tipo: image/jpeg
Tamanho: 12088 bytes
Descrição: não disponível
URL: <http://lists.openstreetmap.org/pipermail/talk-br/attachments/20131218/b812d8de/attachment-0007.jpg>