Re: [Talk-br] admin_level=9 em metrópoles são regiões administrativas ou zonas?

[Pedro Geaquinto]

Revivendo isso aqui: existem também as divisas "políticas" além de
administrativas. Acho que no Rio de Janeiro, das divisões, apenas as 8
subprefeituras e as 33 regiões administrativas (RAs) têm algum corpo
administrativo, com prédios, infraestrutura e equipe reservada para tais
áreas. O resto são divisões mais políticas mesmo como as 5 áreas de
planejamento (APs) e as 16 regiões de planejamento (RPs).

O problema das RAs é que muitas vezes, principalmente em bairros pobres
como Rocinha e Cidade de Deus, apenas um bairro as compõem. Infelizmente as
subprefeituras não seguem a mesma lógica das RAs, APs, e RPs. Muitos
bairros de uma mesma subdivisão estão em duas subprefeituras diferentes.
Por esse motivo (e por estarem mudando o tempo todo), não escolheria as
subprefeituras.

Eu escolheria o que mais reflete o caráter cultural coletivo dos bairros
que, na minha opinião, são as RPs e colocaria tags especiais para as outras
(ou não haha). Como são expressas muitas vezes como AP x.x (a RP da Penha
por exemplo é a AP 3.5), dá pra automaticamente associar cada AP como um
grupo de RPs compondo suas subdivisões. O problema mesmo é que não são
exatamente divisas administrativas, mas subdivisões organizacionais do
município. Não sei como fica na legislação, onde independente mesmo são
municípios, estados e união. Em vários locais isso é fácil de conferir, já
que há divisões de distritos e subdistritos, mas o Rio de Janeiro não têm
distritos como 6 dos outros 19 municípios da região metropolitana.

[]s

2015-09-19 14:40 GMT-03:00 Arlindo Pereira :

> O que isto significa? Não entendi.
>
> []s
>
>
> 2015-09-19 9:09 GMT-03:00 Peter Krauss :
>
>> Será que essas regiões, por questões até de estabilidade e cobertura
>> oficial da demarcação, não poderiam ser definidas como agregado de áreas
>> CNEFE?
>>
>> Em 18 de setembro de 2015 20:23, Vítor Rodrigo Dias > > escreveu:
>>
>>> Arlindo,
>>>
>>> No caso de Belo Horizonte, utilizei as regionais como distritos, Por
>>> quê? Explico.
>>>
>>> Belo Horizonte é oficialmente dividida em três distritos (sede, Barreiro
>>> e Venda Nova). As regionais, por sua vez, são nove (Barreiro, Centro-Sul,
>>> Leste, Norte, Nordeste, Noroeste, Oeste, Pampulha e Venda Nova).
>>> Oficialmente, para o IBGE, as regionais constituem subdistritos. As áreas
>>> do distrito e subdistrito do Barreiro são praticamente iguais, tendo
>>> divergências mínimas entre uma e outra. Venda Nova, por sua vez, é hoje um
>>> local muito mais reconhecido pela região que engloba o *subdistrito
>>> Venda Nova* do que o *distrito*, este muito maior em área e que inclui
>>> bairros que, ainda que façam parte oficialmente do distrito Venda Nova, não
>>> são reconhecidos pela população nem por ninguém como parte do conceito do
>>> que é "Venda Nova" como localidade.
>>>
>>> Como há apenas um nível disponível no OSM entre cidade e bairro, acabei
>>> optando por cadastrar os subdistritos no admin_level 9.
>>>
>>> Abraços!
>>>
>>> Em sex, 18 de set de 2015 às 17:14, Arlindo Pereira <
>>> openstreet...@arlindopereira.com> escreveu:
>>>
 Pessoal,

 no entendimento de vocês, o que seriam as admin_level=9 em metrópoles?

 A tag é comumente utilizada para demarcar distritos, que tipicamente
 são aglomerados fora da cidade porém dentro do município. Isto tipicamente
 não acontece em metrópoles.

 Aqui no Rio de Janeiro temos, a priori, dois candidatos: as zonas da
 cidade (zona sul, zona norte etc.) e as Regiões Administrativas, que são
 divisões da prefeitura, tendo cada qual a sua subprefeitura.

 Note que no link http://www.rio.rj.gov.br/web/cvl/ra há a
 especificação de qual região administrativa envolve quais bairros.

 Eu tenho dúvidas sobre se as RAs seriam distritos, e gostaria da
 opinião dos colegas da lista.

 []s
 Arlindo
 ___
 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
>
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Ortofoto da Cidade do Rio de Janeiro

[Pedro Geaquinto]

Excelente! O WMS da ortofoto de 2012 estava bugado na projeção WGS84 e só
ficava consideravelmente pouco desviado em uma projeção SAD69 que a
prefeitura usa (muito próximo da ortofoto de 2013). Mas ainda assim tem um
offset em relação ao Bing (e os dados do OSM).

O desafio é encontrar o offset correto para nosso uso. Para isso temos que
encontrar isso nas partes baixas da cidade, porque o Bing é todo zuado nos
morros.

2015-12-20 16:55 GMT-02:00 Márcio Vinícius Pinheiro <
marcioviniciu...@gmail.com>:

> Atualizei as instruções para utilização da Ortofoto do Rio de Janeiro,
> para mapeadores da cidade na página da wiki:
>
> https://wiki.openstreetmap.org/wiki/Rio_de_Janeiro_%28city%29/Import_IPP#Ortofotos
>
> Coloquei as instruções para o servidor WMS da Ortofoto 2013 (mais precisa
> e com resolução/escala muito maior do que a de 2012).
>
> É provável que a ortofoto de 2014 vá ser liberada em breve, assim que
> tiver notícia comunico (e peço que se alguém tiver notícia antes de mim,
> que também comunique ;-).
>
> - - - ·
> Atenciosamente,
>
> Márcio Vinícius Pinheiro
> http://about.me/Doideira
> 
>
> ___
> 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] O que houve com Fernando Trebien?

[Pedro Geaquinto]

Faz falta mesmo, parou de editar por motivos parecidos que eu reduzi muito
o ritmo. Tínhamos discussões interessantes sobre hierarquia de vias e ele
fez avançar bastante o assunto no Brasil, mas seguimos sem convenção,
principalmente em meios urbanos.

On 13 December 2015 at 12:12, Arlindo Pereira <
openstreet...@arlindopereira.com> wrote:

> Também acho uma lástima. :(
>
> []s
>
>
> 2015-12-13 11:54 GMT-02:00 Erick de Oliveira Leal <
> erickdeoliveiral...@gmail.com>:
>
>> Poxa, uma pena. Ele foi o que mais me ajudou quando entrei aqui.
>>
>> Em 13 de dezembro de 2015 11:49, Arlindo Pereira <
>> openstreet...@arlindopereira.com> escreveu:
>>
>>> Desistiu do projeto depois de discussões improdutivas na lista com outro
>>> mapeador aqui do Rio.
>>>
>>> > mailman-boun...@openstreetmap.org
>>> >
>>> > Jul 8
>>> > to talk-br-owner
>>> > fernando.treb...@gmail.com foi removido da lista Talk-br.
>>>
>>> []s
>>> Arlindo
>>>
>>> 2015-12-13 11:42 GMT-02:00 Erick de Oliveira Leal <
>>> erickdeoliveiral...@gmail.com>:
>>>
 Opa pessoal, alguém sabe o que aconteceu com o Fernando Trebien?
 Diz nessa página "retired"
 http://wiki.openstreetmap.org/wiki/User:Ftrebien

 As mensagens indicam um link
 https://www.openstreetmap.org/user/user_401472 como se o usuário dele
 não existisse mais.

 ___
 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
>
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] OSM e TrackSource

[Pedro Geaquinto]

Pessoal, percebi que aquele padrão com "Rua" para nomes de ruas apareceu em
Casimiro de Abreu - RJ.

Esse é o changeset: http://www.openstreetmap.org/browse/changeset/16303429
Desculpem-me por não ter percebido antes.


2013/8/23 Wille 

>  Não vejo o fato de o cadastro no OSM ser tão desburocratizado como um
> grande problema. É bom lembrar que a wikipédia, apesar de ter várias
> ferramentas de moderação, permite que se edite uma página sem nem fazer o
> login.
>
> Acho interessante que uma pessoa possa fazer um cadastro rápido e
> acrescentar o nome da rua onde mora ou meia dúzia de POIs que ela conheça
> ou até corrigir alguma informação errada. São pequenas colaborações, mas
> que, multiplicado por um grande número de usuários, podem fazer a diferença
> e chegar em lugares que talvez nenhum mapeador experiente chegaria. O que a
> gente precisa é que os softwares de edição sejam mais inteligentes e tenham
> uma validação mais rígida para não permitir certos erros.
>
> O ônus de poder contar com a colaboração de qualquer pessoa, é que a gente
> tenha que investir um certo tempo corrigindo os erros dos novos
> contribuidores. É assim para o OSM, para a Wikipédia, para projetos de
> software livre ou qualquer outra atividade colaborativa.
>
>
> On 23-08-2013 19:00, Vitor George wrote:
>
> Oi Gerald,
>
>  Meus comentários abaixo.
>
> 2013/8/23 Gerald Weber 
>
>>
>>
>>>  Para se abrir uma empresa no Brasil, por exemplo, são exigidos vários
>>> documentos e procedimentos, o que toma muito tempo (e dinheiro). Esta
>>> burocracia, criada na maior das boas intenções, no final das contas não
>>> garante que as empresas vão agir dentro da lei, pelo contrário, e acaba-se
>>> gerando uma ineficiência econômica.
>>>
>>>  Já em países desenvolvidos é fácil você abrir uma empresa. Em questão
>>> de dias você pode fazê-lo, mas estará em sérios problemas se sua empresa
>>> for pega cometendo uma irregularidade. Muito diferente do que em nosso país.
>>>
>>
>>  Olha, desculpa, mas não vou embarcar nesta conversa de "em países
>> desenvolvidos" tudo é mais fácil. Trabalhei por muitos anos no exterior,
>> sei que não é assim. Algumas coisas são, outras não.
>>
>
>  Eu não disse que tudo é mais fácil em países desenvolvidos. O que eu
> disse que há menos burocracia no exemplo que dei.
>
>
>>
>>
>>>  A filosofia do OpenStreetMap segue a mesma linha anti-burocrática.
>>> Qualquer um pode editar, bastando uma conta de e-mail e a concordânciacom 
>>> os Termos do Contribuidor (
>>> Contributor Terms). Mas se um usuário for pego fazendo edições nocivas,
>>> poderá sofrer sanções e até ser banido do projeto. Veja a lista dos
>>> usuários nesta situação:
>>>
>>>  http://www.openstreetmap.org/user_blocks
>>>
>>
>>  Me desculpe, mas as sanções que o usuário sofre são ridículas. É
>> bloqueado até que leia a mensagem (em inglês). Uau, que medo. Veja o caso o
>> Matheus Eduardo. E se for bloqueado? É só abrir outra conta no dia
>> seguinte. A lista: só isto de contas bloqueadas? Tem 1.3 milhões de
>> usuários no OSM!!
>>
>
>  Eu monitoro todas as edições do Matheus Eduardo e de outros
> automaticamente pelo feed da página de usuários, e até agora não percebi
> novos problemas. O banimento do projeto me parece suficiente. Se o usuário
> abrir uma conta no dia seguinte, ele vai provavelmente ser pego novamente.
> Pode ser virar um jogo de gato e rato, mas uma hora um dos dois vai cansar,
> e eu acho que vai ser o infrator. Enfim, nenhum sistema é a prova de falhas.
>
>  O OSM tem esse número que você falou de usuários registrados, mas no
> Brasil deve ter uns quatro mil colaboradores que editaram o mapa. Não é
> tanta gente assim pra monitorar.
>
>
>
>>>  Não é nada difícil identificar padrões de vandalismo, uso de dados com
>>> copyright e outras edições nocivas. Quando um usuário manda uma cidade
>>> inteira para dentro do OpenStreetMap, é bastante fácil perceber. Talvez
>>> não se perceba no mesmo momento que o usuário fez, como foi o caso do
>>> Erick, mas sempre é possível voltar atrás nas edições. Todos os casos
>>> de edições nocivas que você citou podem ser revertidas sem nenhum
>>> problema ao serem identificadas.
>>>
>>
>>
>>  Pode não ser nada difícil, mas também não é nada fácil. Se a gente
>> recebesse alertas de que dados nossos foram apagados já seria um grande
>> avanço. A gente poderia por exemplo estabelecer no perfil que sempre que
>> mais que X nós forem apagados ou alterados a gente recebesse um email. Sei
>> lá algo, do gênero. Isto é algo que tem que vir de dentro do sistema do
>> OSM, não pode ser um script maluco no whodidit ou coisas do gênero.
>>
>
>  Uma ferramenta que é bastante fácil de usar é o OSM Mapper da ITO:
>
>  http://www.itoworld.com/static/openstreetmap_tools/osm_mapper.html
>
>  Basta selecionar a região que vc quer monitorar e ele gerará um feed e
> visualizações das edições. Aí já dá para pegar bastante coisa
> inconveniente. Recomendo muito esta ferramenta.
>
>
>>
>>>
>>>  A gente reclama tanto 

Re: [Talk-br] Encontrar tags oneway reversas

[Pedro Geaquinto]

Eu não gosto muito do oneway=-1, acho supérfluo e sempre que encontro eu
troco para oneway=yes (mudando, claro, o sentido).


2013/9/4 Erick de Oliveira Leal 

> corrigindo vida=via
>
>
> Em 4 de setembro de 2013 16:37, Erick de Oliveira Leal <
> erickdeoliveiral...@gmail.com> escreveu:
>
> Eu pensei alto aqui, acho que estava querendo que o JOSM fosse Deus e
>> descobrisse uma vida traçada no sentido contrário ahahaha
>>
>>
>> Em 4 de setembro de 2013 16:33, Arlindo Pereira <
>> openstreet...@arlindopereira.com> escreveu:
>>
>> O que seria a mão oposta ao normal então? Não ficou claro pra mim. Uma
>>> via dividida em três segmentos onde dois deles sejam em um sentido e um
>>> terceiro no meio em outro? Isso pode acontecer no mundo real.
>>>  On Sep 4, 2013 4:30 PM, "Erick de Oliveira Leal" <
>>> erickdeoliveiral...@gmail.com> wrote:
>>>
 Não. oneway=yes


 Em 4 de setembro de 2013 16:27, Arlindo Pereira <
 openstreet...@arlindopereira.com> escreveu:

> Você se refere às vias com oneway=-1?
> On Sep 4, 2013 4:25 PM, "Erick de Oliveira Leal" <
> erickdeoliveiral...@gmail.com> wrote:
>
>> É possível encontrar tags highways que estejam com a tag oneway=yes,
>> mas que estejam em mão oposta ao normal?
>>
>> ___
>> Talk-br mailing list
>> Talk-br@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-br
>>
>>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-br
>
>

 ___
 Talk-br mailing list
 Talk-br@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-br


>>> ___
>>> Talk-br mailing list
>>> Talk-br@openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-br
>>>
>>>
>>
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-br
>
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Etiquetas para casos especiais

[Pedro Geaquinto]

Outro caso especial que seria legal discutir: garagens de ônibus.
Seria adequado landuse=commercial + name=Garagem da "Empresa X"?


2013/8/31 Augusto Stoffel 

> Aparentemente o valor public não está previsto para a tag access.
>
> Outras possibilidades seriam fee=no, ou operator=SUS ou seja qual for o
> orgão do governo que gere o local.
>
> On Sat, 2013-08-31 at 14:54 -0300, Arlindo Pereira wrote:
> > Gostei dessa. Tenho usado hospital por falta de opção melhor.
> >
> > On Aug 31, 2013 1:19 PM, "Fernando Trebien"
> >  wrote:
> > Postos de saude: que tal amenity=clinic + access=public?
> >
> > 2013/8/31 Fernando Trebien :
> > > Poderia ser office=company nesses casos entao, enquanto
> > ninguem faz
> > > uma proposta melhor. Que tal?
> > >
> > > 2013/8/31 Pedro Geaquinto :
> > >> Entendi. Nunca tinha visto dessa forma.
> > >>
> > >> Bom, até faz sentido em certos institutos como o que curso
> > atualmente a
> > >> língua russa, que se chama Centro de Cultura Eslava. Além
> > de línguas, há
> > >> debates e conversas mais culturais mesmo.
> > >> Mas alguns outros mais "industriais" como Wizard e Yazigi
> > (esse ultimo eu já
> > >> fiz alemão), acho que pedem uma tag nova.
> > >>
> > >> On Aug 31, 2013 9:49 AM, "Fernando Trebien"
> > 
> > >> wrote:
> > >>>
> > >>> Como que você as mapepu? Se foi só 1 não é tão grave. :P
> > Como você fez?
> > >>>
> > >>> Quando eu mapeei as escolas de línguas aqui em Porto
> > Alegre eu pesquisei a
> > >>> melhor tag a ser usada e achei uma discussão sobre isso na
> > comunidade
> > >>> internacional. O argumento era que essas escolas
> > frequentemente ensinam não
> > >>> só a língua como também a cultura de um outro país, muitas
> > vezes através de
> > >>> eventos ligados à arte (exposições, debates, exibição de
> > filmes, etc.).
> > >>> Muitas inclusive incentivam os seus alunos a exercitarem
> > outras formas de
> > >>> arte (literária, canto, cinema, teatro, etc.) desde que no
> > contexto da
> > >>> língua ensinada.
> > >>>
> > >>> Se não for arts_centre, então acho que só sobraria
> > office=company. Ou uma
> > >>> tag nova, como você sugeriu.
> > >>>
> > >>> On Aug 31, 2013 6:32 AM, "Pedro Geaquinto"
> >  wrote:
> > >>>>
> > >>>> Já houve discussão para escolas de línguas? Eu vou ter
> > que revisar um POI
> > >>>> pelo menos, usava a tag errada. :p
> > >>>> Eu acho que usar arts_centre seria muito estranho, acho
> > que isso pede uma
> > >>>> tag em específico.
> > >>>>
> > >>>> On Aug 31, 2013 3:06 AM, "Fernando Trebien"
> > 
> > >>>> wrote:
> > >>>>>
> > >>>>> Acrescentei o caso do motel. Quase coloquei o "<3" do
> > Arlindo como
> > >>>>> comentario. :P
> > >>>>>
> > >>>>> Concordo que deveriamos criar issues pro iD, mas o que
> > voce tem em
> > >>>>> mente exatamente? Criar itens no menu da esquerda que
> > soh aparecam
> > >>>>> para os brasileiros?
> > >>>>>
> > >>>>> 2013/8/30 Arlindo Pereira
> > :
> > >>>>> > Esqueci de comentar. De resto, concordo com tudo.
> > Agora seria muito
> > >>>>> > bom
> > >>>>> > criarmos issues (principalmente) no iD para
> > implementar esses casos
> > >>>>> > diretamente no editor.
> > >>>>> >
> > >>>>> > []s
> > >>>>> > 

Re: [Talk-br] Etiquetas para casos especiais

[Pedro Geaquinto]

Entendi. Nunca tinha visto dessa forma.

Bom, até faz sentido em certos institutos como o que curso atualmente a
língua russa, que se chama Centro de Cultura Eslava. Além de línguas, há
debates e conversas mais culturais mesmo.
Mas alguns outros mais "industriais" como Wizard e Yazigi (esse ultimo eu
já fiz alemão), acho que pedem uma tag nova.
On Aug 31, 2013 9:49 AM, "Fernando Trebien" 
wrote:

> Como que você as mapepu? Se foi só 1 não é tão grave. :P Como você fez?
>
> Quando eu mapeei as escolas de línguas aqui em Porto Alegre eu pesquisei a
> melhor tag a ser usada e achei uma discussão sobre isso na comunidade
> internacional. O argumento era que essas escolas frequentemente ensinam não
> só a língua como também a cultura de um outro país, muitas vezes através de
> eventos ligados à arte (exposições, debates, exibição de filmes, etc.).
> Muitas inclusive incentivam os seus alunos a exercitarem outras formas de
> arte (literária, canto, cinema, teatro, etc.) desde que no contexto da
> língua ensinada.
>
> Se não for arts_centre, então acho que só sobraria office=company. Ou uma
> tag nova, como você sugeriu.
> On Aug 31, 2013 6:32 AM, "Pedro Geaquinto"  wrote:
>
>> Já houve discussão para escolas de línguas? Eu vou ter que revisar um POI
>> pelo menos, usava a tag errada. :p
>> Eu acho que usar arts_centre seria muito estranho, acho que isso pede uma
>> tag em específico.
>> On Aug 31, 2013 3:06 AM, "Fernando Trebien" 
>> wrote:
>>
>>> Acrescentei o caso do motel. Quase coloquei o "<3" do Arlindo como
>>> comentario. :P
>>>
>>> Concordo que deveriamos criar issues pro iD, mas o que voce tem em
>>> mente exatamente? Criar itens no menu da esquerda que soh aparecam
>>> para os brasileiros?
>>>
>>> 2013/8/30 Arlindo Pereira :
>>> > Esqueci de comentar. De resto, concordo com tudo. Agora seria muito bom
>>> > criarmos issues (principalmente) no iD para implementar esses casos
>>> > diretamente no editor.
>>> >
>>> > []s
>>> > Arlindo
>>> >
>>> >
>>> > 2013/8/30 Arlindo Pereira 
>>> >>
>>> >> Eu que propus o amenity=love_hotel. Gostaria de ver um <3 renderizado
>>> no
>>> >> Mapnik um dia. :-P
>>> >>
>>> >> Por mim, usamos as duas juntas, sendo a primeira "meio que" um
>>> >> tagging-for-the-renderer (motéis (no sentido brasileiro) não deixam
>>> de ser
>>> >> um "hotel de beira de estrada", que você vai com o carro numa viagem
>>> - só
>>> >> não são na beira da "estrada" como em viagem), e a segunda para pegar
>>> os
>>> >> tipos específicos de motéis brasileiros.
>>> >>
>>> >>
>>> >> On Fri, Aug 30, 2013 at 7:47 PM, Nelson A. de Oliveira <
>>> nao...@gmail.com>
>>> >> wrote:
>>> >>>
>>> >>> E quanto a classificação do motel?
>>> >>> No Brasil faz sentido tourism=motel + amenity=love_hotel (as duas
>>> juntas)
>>> >>>
>>> >>> ___
>>> >>> Talk-br mailing list
>>> >>> Talk-br@openstreetmap.org
>>> >>> http://lists.openstreetmap.org/listinfo/talk-br
>>> >>
>>> >>
>>> >
>>> >
>>> > ___
>>> > Talk-br mailing list
>>> > Talk-br@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@openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-br
>>>
>>
>> ___
>> Talk-br mailing list
>> Talk-br@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-br
>>
>>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-br
>
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Etiquetas para casos especiais

[Pedro Geaquinto]

Já houve discussão para escolas de línguas? Eu vou ter que revisar um POI
pelo menos, usava a tag errada. :p
Eu acho que usar arts_centre seria muito estranho, acho que isso pede uma
tag em específico.
On Aug 31, 2013 3:06 AM, "Fernando Trebien" 
wrote:

> Acrescentei o caso do motel. Quase coloquei o "<3" do Arlindo como
> comentario. :P
>
> Concordo que deveriamos criar issues pro iD, mas o que voce tem em
> mente exatamente? Criar itens no menu da esquerda que soh aparecam
> para os brasileiros?
>
> 2013/8/30 Arlindo Pereira :
> > Esqueci de comentar. De resto, concordo com tudo. Agora seria muito bom
> > criarmos issues (principalmente) no iD para implementar esses casos
> > diretamente no editor.
> >
> > []s
> > Arlindo
> >
> >
> > 2013/8/30 Arlindo Pereira 
> >>
> >> Eu que propus o amenity=love_hotel. Gostaria de ver um <3 renderizado no
> >> Mapnik um dia. :-P
> >>
> >> Por mim, usamos as duas juntas, sendo a primeira "meio que" um
> >> tagging-for-the-renderer (motéis (no sentido brasileiro) não deixam de
> ser
> >> um "hotel de beira de estrada", que você vai com o carro numa viagem -
> só
> >> não são na beira da "estrada" como em viagem), e a segunda para pegar os
> >> tipos específicos de motéis brasileiros.
> >>
> >>
> >> On Fri, Aug 30, 2013 at 7:47 PM, Nelson A. de Oliveira <
> nao...@gmail.com>
> >> wrote:
> >>>
> >>> E quanto a classificação do motel?
> >>> No Brasil faz sentido tourism=motel + amenity=love_hotel (as duas
> juntas)
> >>>
> >>> ___
> >>> Talk-br mailing list
> >>> Talk-br@openstreetmap.org
> >>> http://lists.openstreetmap.org/listinfo/talk-br
> >>
> >>
> >
> >
> > ___
> > Talk-br mailing list
> > Talk-br@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@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-br
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Excesso de tertiary em Porto Alegre

[Pedro Geaquinto]

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 

> 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 :
> > 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 
> >>
> >> Olá Pessoal
> >>
> >> vou meter minha colher de pau na discussão novamente
> >>
> >>
> >> 2013/8/28 Flavio Bello Fialho 
> >>>
> >>> 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õe

Re: [Talk-br] Excesso de tertiary em Porto Alegre

[Pedro Geaquinto]

O meu maior problema é que estou sem internet! Gostaria muito de participar
da discussão, mas tudo parece conspirar contra.
Na outra "rodada" de discussões perdi boa parte porque estava epicamente
atarefado, agora acontece isso... Postem no fórum, vou cruzar os dedos para
poder acompanhar vocês.

Só acho que o assunto é muito subjetivo e sempre vai render discussões na
comunidade local, ainda mais não havendo uma notação oficial
(governamental) para nortear as coisas. Na minha opinião, o que deveria
acontecer é criar páginas na wiki só para hierarquias de vias, para cada
região metropolitana. Assim, a discussão de coisas ambíguas (como
importância de uma via, por exemplo) fica mais facilmente discutível pela
comunidade local, ou seja, que conhece sua cidade. Isso tudo após uma ampla
discussão nacional, é claro (que não poderei acompanhar bem inicialmente).
:/
On Aug 25, 2013 10:57 AM, "Fernando Trebien" 
wrote:

> Concordo plenamente.
> On Aug 25, 2013 7:59 AM, "Gerald Weber"  wrote:
>
>> Olá Pessoal
>>
>> tenho acompanhado a discussão meio à distância.
>>
>> Quando discutimos os fluxogramas de classificação de vias eu fui da
>> opinião que o esquema serviria essencialmente para uma primeira rodada de
>> classificações. Isto porque na maior parte do tempo mapeamos fora de casa e
>> carecemos de conhecimento local.
>>
>> A partir desta classificação preliminar teria de haver uma discussão com
>> mapeadores locais para fazer o ajuste fino. Eu acho que a questão de Porto
>> Alegre chegou exatamente neste ponto.
>>
>> Alterar novamente o fluxograma apenas para atender ao caso de Porto
>> Alegre certamente acarretará problemas com outras cidades, especialmente
>> nos casos onde já se iniciou a reclassificação. Cada cidade vai ter suas
>> peculiaridades que vão ser impossíveis de tratar com um algorítmo único.
>> Aqui que eu penso entra a força do OSM com o conhecimento local dos
>> mapeadores.
>>
>> Portanto eu sugiro que se abra o tópico "Porto Alegre" no forum (não aqui
>> no talk-br) e que se discuta neste forum como deve ser tratado cada caso.
>> Se for necessário discutam rua por rua. Depois que chegarem à algum
>> consenso, façam suas alterações e registem com a tag note= cada uma das
>> decisões. Quem sabe seria interessante também colocar a tag website com o
>> link do forum onde determinada rua foi discutida.
>>
>> Agora eu penso que uma cidade ter mais ou menos tertiary apenas
>> representa a permeabilidade dos bairros em relação a um tráfego mais
>> intenso. Naturalmente isto varia muito de cidade para cidade e certamente
>> de bairro para bairro.
>>
>> um grande abraço a todos
>>
>> Gerald
>>
>>
>> ___
>> Talk-br mailing list
>> Talk-br@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-br
>>
>>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-br
>
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Regiões Administrativas do Distrito Federal

[Pedro Geaquinto]

Pois é, tenho essa dúvida também.
Quando existem distritos auto-suficientes ou com fraca ligação econômica
direta com a sede, com população semelhante ou até maior do que a sede,
vale usar "livremente" a tag?

E a sede? Você desconta a população no ponto?

Vou jogar um exemplo: Itapemirim-ES vs seu distrito Itaipava (que contém o
bairro de Itaoca). A sede é muito menor em população que o distrito. O que
fazer?

1. Manter town nas duas, com população total em Itapemirim e local em
Itaipava.
2. Village em Itapemirim (se não me engano, tem 9 mil habitantes) e town em
Itaipava (tem mais de 10 mil).
3. Town em Itapemirim, com população total, e suburb em Itaipava (acho
pouquíssimo adequado, porque são bem distantes e independentes).

Eu não sei exatamente o que fazer e atualmente a opção escolhida é a 1.


2013/7/9 Fernando Trebien 

> Tem razão, o DF (que tem governo próprio) é dividido em "regiões
> administrativas" (sem governo, subordinados ao DF) e é proibido por
> lei que uma região dessas tenha governo, então parece mais com a
> definição de "distrito".
>
> http://pt.wikipedia.org/wiki/Regi%C3%A3o_Administrativa_(Distrito_Federal)
> http://pt.wikipedia.org/wiki/Distrito#Brasil
> http://pt.wikipedia.org/wiki/Distritos_do_Brasil
>
> Sendo assim, as relações das regiões teriam a tag "admin_level=9". O
> nó com o papel "admin_centre" teria a tag "place=city" para Brasília
> (além de "capital=yes"). Para as outras regiões, se você não tiver um
> critério melhor (alguma classificação oficial de diferentes tipos de
> região), pode adotar o indicado no wiki
> (http://wiki.openstreetmap.org/wiki/Key:place) que é:
> - "place=hamlet" para regiões com menos de ~mil habitantes
> - "place=village" para regiões com menos de ~10 mil habitantes
> - "place=town" para regiões com menos de ~100 mil habitantes
>
> Pode ser útil:
> http://pt.wikipedia.org/wiki/Anexo:Lista_de_regi%C3%B5es_administrativas_do_Distrito_Federal_por_popula%C3%A7%C3%A3o
>
> Pela definição no wiki do OSM, as 10 mais populosas nessa lista seriam
> tipicamente consideradas "cidades". Eu no fundo acho que não estaria
> "errado" colocar "admin_level=9" para todas as regiões e usar a tag
> "place" livremente (inclusive com o valor "city") já que antigamente
> essas regiões eram chamadas de "cidades-satélite".
>
> 2013/7/8 Ednei Ramthum do Amaral :
> > Sobre o assunto, vale lembrar que essa divisão da imagem da Wikipédia é a
> > última oficial disponível, mas já foram criadas várias outras regiões
> > administrativas (RAs) q não tiveram seus limites oficiais definidos.
> >
> > Pras RAs mais recentes, a melhor fonte q conheço é a q vem sendo usada
> pela
> > Codeplan:
> > http://www.codeplan.df.gov.br/areas-tematicas/demografia/257-pdad.html
> > (ver notas metodológicas)
> >
> > Não sei se a melhor opção é listar as RAs desatualizadas, deixando de
> > incluir as mais recentes, mas mantendo a limitação oficial; ou listar
> tds,
> > usando limitação não oficial; ou até listar todas e usar limitação
> oficial
> > pras antigas e a não oficial pras novas (o q poderia confundir, dando a
> > entender que uma nova RA fica dentro de uma antiga...)
> >
> > --
> > Sobre a classificação, eu equivaleria a distrito, por ser intermediário
> > entre cidade e bairro. Cidade no Brasil costuma ser associado a
> município, e
> > não é o caso das RAs. Brasília, considerada como todo o DF, seria o mais
> > próximo de município (assim é considerada, por exemplo, no Censo). Também
> > não é sempre q existem áreas verdes entre as RAs. Algumas, como o
> > Sudoeste/Octogonal, por exemplo, seriam perfeitamente bairros da RA I -
> > Brasília. Ceilândia e Taguatinga são, visivelmente, uma coisa só.
> > Distritos tb têm essa característica de às vezes serem conurbados
> > (normalmente em cidades grandes), e em outras serem separados da sede
> > (normalmente em municípios pequenos, qnd o distrito acaba buscando
> > emancipação, com o tempo).
> >
> > --
> > Bom, não costumo participar aqui. Então desculpem se disse algo
> contrário a
> > algum consenso já estabelecido...
> >
> >  Ednei
> >
> > Em 8 de julho de 2013 04:09, Fernando Trebien <
> fernando.treb...@gmail.com>
> > escreveu:
> >
> >> Hm será que você tem permissão pra importar isso? Está com uma licença
> >> CC 2.5 na Wikipédia, ou seja, requer que as obras derivadas sejam
> >> disponibilizadas sob a mesma licença, até onde eu sei isso é
> >> incompatível com a licença ODbL do OSM.
> >>
> >> Se for possível, talvez você possa usar o plugin ImportVec para
> >> importar o SVG. Se não funcionar, você pode converter o SVG num PNG e
> >> traçar sobre ele usando o PicLayer.
> >>
> >> Uma coisa que você tem que definir é se essas regiões são cidades
> >> (admin_level = 8) ou bairros (admin_level = 10). Se for algo
> >> intermediário, talvez possam ser tratadas como distritos (admin_level
> >> = 9)
> >> (
> http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative#admin_level
> ).
> >> Pelo que lembro, o DF não é uma área urbana co

Re: [Talk-br] Matheus Eduardo está de volta

[Pedro Geaquinto]

Esse sistema novo de notas auxilia bastante nesse problema! Além de
facilitar o to-do dos mais experientes, os novatos podem relatar problemas
sem precisar editar ou mesmo criar um username. Evita edições erradas
pontuais.

Gosto dessa ideia de haver validações para as primeiras edições, mas deve
acontecer apenas onde a comunidade é muito ativa. Não faz sentido haver
controle onde não há ninguém para controlar. Já não concordo na restrição
de deletar, seria redundante e não haveria aquele estímulo de poder deletar
por exemplo aquela padaria da esquina que faliu.

Aqui no Rio, eu (Geaquinto) agradeço muito de ter o Arlindo (Nighto)
auxiliando. Fica muito tenso além de ser um mapeador ativo, ser um
moderador de todas as edições, sozinho. Nós dois temos pouquíssimo tempo
livre, mas só de ser dois ajuda muito. Imagino que com cada vez mais
usuários ativos fica excelente moderar.


Em 14 de junho de 2013 16:34, Gerald Weber  escreveu:

> Eu penso que o OSM poderia implementar períodos de quarentena para novos
> usuários. Por exemplo, um usuário novo não deveria ser capaz de deletar
> nada inicialmente até que ele tenha feito um certo número de edições ele
> mesmo. Alternativamente, um usuário novo poderia ter todas as suas edições
> iniciais sendo validadas por usuários mais experientes. Acho que isto daria
> mais segurança a usuários novos pois eles não ficariam com medo de fazer
> besteira. Aliás, eu acho que muitos usuários novos não contribui por medo
> estarem fazendo coisas erradas, como tudo é muito técnico eles acabam
> ficando inibidos. Seria um jeito de resolver 2 problemas de uma vez só.
>
> Eu acho que do jeito que está fragiliza o sistema demasiadamente.
>
> abraço
>
> Gerald
>
>
> 2013/6/14 Fernando Trebien 
>
>> Ah, só acrescentando. Quando um projeto colaborativo cresce, não há
>> como fugir de aplicar algum tipo de moderação ativa. Já é assim no
>> OpenStreetMap em vários lugares da Europa, e na Wikipédia também é
>> assim em diversos artigos (mas não todos).
>>
>> A única solução para escapar da moderação é não fazer/usar mapas
>> colaborativos. Mas veja que tanto Google quanto Navteq já têm alguns
>> recursos colaborativos (o que quer dizer que também estão sujeitos a
>> vandalismo), então já há pouca opção disponível com garantia de
>> qualidade. A própria Apple optou por usar dados do OpenStreetMap
>> através do Maps em algumas regiões.
>>
>> 2013/6/14 Fernando Trebien :
>> > Olá José Carlos,
>> >
>> > Talvez lhe surpreenda quão fácil é monitorar a sua região. Eu uso um
>> feed
>> > RSS do WhoDidIt por ser mais fácil. Se você tiver interesse, posso
>> fornecer
>> > os detalhes. Um dos problemas desse método é que cada feed cobre uma
>> área
>> > pequena (só um pouco mais do que Porto Alegre) mas não é impossível usar
>> > mais de um feed.
>> >
>> > Eu concordo que um sistema de moderadores (tal como o da Wikipédia e,
>> de uma
>> > certa forma, também o do TrackSource) seria muito bem-vindo.
>> >
>> > On Jun 14, 2013 3:12 PM, "Jose Carlos Medeiros" > >
>> > wrote:
>> >>
>> >> O mapeamento do jeito que esta, fica um pouco complicado, e sem muita
>> >> segurança, já que, se alguem quiser corromper alguma coisa, basta
>> criar um
>> >> email e sair alterando as coisas.
>> >>
>> >> Claro, que podemos reverter, mas os itens que tem alguem olhando
>> sempre.
>> >> Eu por exemplo, mapeei o meu bairro, mas não fico monitorando isso, se
>> >> alguém alterar pode ser que eu nem veja, e o mapa fique errado.
>> >>
>> >> Deveria ser parecido com o Waze, onde existe o responsável pela área,
>> >> tipo, você se cadastra pra alterar uma região, se la não tiver
>> responsável,
>> >> então você vira um.
>> >> E caso desse algum problema de o dono da área não estar disponível ou
>> >> outros problemas, acionar uma pessoa ou grupo, responsável pela cidade
>> ou
>> >> região maior.
>> >>
>> >> Ficamos falando sempre, do ganho em ter um mapa colaborativo, que
>> podemos
>> >> utilizar pra projetos e tal, mas do jeito que ele esta não da pra
>> confiar.
>> >> Imagina se você faz um sistema de logistica ou um programa de GPS, e
>> alguem
>> >> vai e altera o mapa, a pessoa pode até corrigir, mas nem todo mundo que
>> >> ficar fazendo isso.
>> >>
>> >> Será que alguem ja propôs alguma coisa deste tipo para a OSF?
>> >>
>> >>
>> >>
>> >> []'s
>> >> José Carlos
>> >>
>> >>
>> >> Em 15 de abril de 2013 13:15, Vitor George 
>> >> escreveu:
>> >>>
>> >>> Fernando,
>> >>>
>> >>> A primeira coisa a fazer se você notar que um contribuidor está
>> fazendo
>> >>> más edições, é entrar em contato, cordialmente. Se o usuário
>> responder e
>> >>> entrar em um acordo contigo, o caso está resolvido.
>> >>>
>> >>> Caso alguma polêmica persista, o próximo passo seria postar aqui na
>> >>> lista, para que a comunidade possa debater o caso e tentar chegar a
>> uma
>> >>> solução.
>> >>>
>> >>> A maioria dos casos se resolve assim.
>> >>>
>> >>> Quando isso não funciona ou quando o usuário se recusa a discutir as
>> suas
>> >>> ediçõ

Re: [Talk-br] Comunidade brasileira no fórum do OSM

[Pedro Geaquinto]

Ótimo, as mensagens num fórum são mais dinâmicas.

On May 21, 2013 2:00 PM, "Fernando Trebien" 
wrote:

Pessoal,

Repetindo o anúncio, agora com o campo Assunto correto, acabou de ser
criada a comunidade de usuários brasileiros no fórum do OpenStreetMap:
http://forum.openstreetmap.org/viewforum.php?id=74

Para postar, basta usar o mesmo uusário e senha usado para editar o
OpenStreetMap.

A comunidade ainda está vazia. Sugiro experimentar o sistema por dois
motivos principais:
- as discussões são organizadas em threads, o que as torna mais fáceis
de acompanhar do que por e-mail
- as discussões ficam registradas para serem usadas como referência
futura pesquisável e para serem facilmente referenciadas por links

A lista de e-mail segue como canal principal de discussões e perguntas.

--
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@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-br
___
Talk-br mailing list
Talk-br@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Hierarquia das rodovias

[Pedro Geaquinto]

considered usable by motor cars.
>
> Physically, the roads which should be tagged in OSM as
> highway=unclassified can vary greatly between countries, and even
> between areas in the same country. However, within the same local
> area, physical comparisons can be made to decide the level of
> importance: use your local knowledge and judgement! One generality,
> perhaps, is that "unclassified" roads are often unpaved in larger,
> poorer or more remote/rural areas, and are typically paved in denser,
> richer or more central/urban areas."
>
> Acho que o final esclarece um dos nossos principais pontos de
> discussão: as unclassified parecem corresponder às "implantadas" do
> BIT, pelo menos nas áreas mais remotas (que é a maior parte do mapa
> fora das cidades), porque são não-pavimentadas em locais mais remotos
> (a maioria do território brasileiro). Se fizermos a correspondência
> com as "implantadas", então unclassified assume um significado
> importante: são estradas de terra com solo compactado, com pouca
> chance de atolamento. A "compactação" do solo seria um "achismo" para
> quem olha a imagem de satélite, então nesse caso a opinião de um
> morador ou de alguém fazendo survey no local deveria prevalecer, e ser
> registrada na tag "note" quando surgir.
>
> As tertiary então seriam algo entre unclassified e secondary, que
> seriam pavimentadas com alguma característica que as diferencie (pode
> ser um número de pistas menor que trunk, ou falta de acostamento).
>
> Se não chegarmos a um consenso, acho mellhor consolidar as três
> classes (primary, secondary, tertiary) numa só (primary)
> correspondente à definição de "pavimentada" do BIT. Mas, de novo, acho
> que perderíamos uma oportunidade de tornar o nosso mapa mais útil
> assim.
>
> Por fim, as de "leito natural" estão bem distantes do conceito de
> tertiary do wiki. Elas (que não têm solo compactado) me parecem estar
> abaixo do conceito de "unclassified" (mas se discordarem, aceitaria
> que fossem até "unclassified" e não mais do que isso). Por isso eu
> defendo que sejam track, para que se faça uma distinção entre rodovias
> de terra de boa qualidade e outras não tanto. Acho que o nosso
> critério (da largura) é um indicador bom e mensurável pra essas
> coisas, pois se a terra é útil para o trânsito (compactada,
> naturalmente ou não) a tendência é que a via acabe sendo alargada para
> permitir o trânsito.
>
> Acho que o nosso objetivo deve ser minimizar o número de casos em que
> uma divergência tenha que ser explicada com a tag "note" e/ou
> discutida na lista.
>
> 2013/5/21 Pedro Geaquinto :
> > Acho que os conceitos utilizados pelo Ministério dos Transportes deveriam
> > ser adaptados apenas para as rodovias nacionais (BRs) e nas demais vias
> > seriam conceitos globais.
> >
> > Poderíamos dividir entre três grupos ao invés de apenas dois: rodovias
> > nacionais, demais vias em meio não-urbano e urbano. O urbano está bem
> > estabelecido (posso dizer que não mudei nada, mas fortaleci o
> > estabelecimento com aqueles 4 conceitos acima), o não-urbano estamos
> > chegando num consenso e as nacionais mal começamos a discutir. :D
> >
> > Apenas "motorway" é um conceito global no OSM: até os seus "links" são
> > normados. Não existem referências na wiki para "shoulder", então podemos
> > dizer que acostamento não é fator decisivo, e quando disse
> > "preferencialmente" quis dizer que não é necessário esse parâmetro.
> >
> > Então vou tentar adaptar a divisão do Ministério dos Transportes,
> mostrada
> > pelo mapa do Nelson, para apenas rodovias nacionais (BR):
> >
> > Duplicadas: geralmente motorway no meio rural, só precisamos verificar
> se há
> > todas as restrições que são necesárias para classificação de motorway
> > (acessos, cruzamentos, etc), senão vai ser trunk.
> > Pavimentadas: temos que decidir entre trunk ou primary, eu prefiro trunk
> > para diferenciar das demais vias não BR (que seriam classificadas como
> > primary).
> > Implantadas: ficaria logo após o nível acima não? Logo poderiam ser
> > secondary.
> > Leito natural: concordam que apenas por hierarquia podemos tomar como
> > tertiary?
> >
> > Por último um apelo: adaptem meu fluxograma intermediário para os meios
> > não-urbanos!! Indiquem o que não concordam e façam um novo.
> >
> >
> > Em 21 de maio de 2013 00:38, Vítor Rodrigo Dias 
> > escreveu:
> >
> >> "Fiquei na dúvida em relação à aplicação do termo "leito natural".
> >> Encontrei um 

Re: [Talk-br] Hierarquia das rodovias

[Pedro Geaquinto]

Primeiro, "vamos colocar como trunk porque é o que ela deveria ser" nunca
foi meu argumento, aquilo foi um comentário a parte sobre o que acredito
sobre a infraestrutura no Brasil.

Meu argumento é "não há distinção entre vias estaduais com menos
importância que algumas vias federais que são importantes não só para o
estado, mas para o país". Mas em nome da colaboração do OSM, eu relevo a
minha opinião. Poderíamos fazer uma votação só para esse embate
trunk-primary para BRs pavimentadas.

Aí entra outra questão, se uma via é não pavimentada então ela fica
amarrada a uma definição? E ainda mais amarrado a "unclassified"? Como fica
a Transamazônica por exemplo? Acho que pode variar entre secondary (ligando
estados, ou seja, BRs), tertiary (ligando municípios) e unclassified
(pequenas ligações, ligando por exemplo um distrito isolado). Isso se
encaixaria certinho na divisão oficial para as nacionais.

Nova proposta para *rodovias nacionais* (BRs):

Duplicadas = motorway ou trunk
Pavimentadas = primary
Implantadas = secondary
Leito natural = tertiary

Para *vias em geral*, em meio rural, fiz um novo fluxograma [1]:

*Motorway:* pavimentada, 2 faixas por sentido, predomina divisória central,
é r*ecomendável* acostamento
*Trunk:* pavimentada, 2 faixas por sentido, com cruzamentos e/ou sem
divisória central
*Primary:* pavimentada, 1 faixa por sentido, predomina acostamento
*Secondary:* pavimentadas que não se encaixem no perfil acima ou sejam
alternativas àlguma primary
*Tertiary:* não pavimentadas que liguem municípios
*Unclassified:* não pavimentadas em geral
*Track:* não pavimentadas que suportam apenas um veículo por vez

Casos isolados podem ser discutidos na comunidade. Não acho que acostamento
deva servir de parâmetro além do embate primary-secondary.

[1]: http://i.imgur.com/WPlAUhG.gif


Em 21 de maio de 2013 09:58, Gerald Weber  escreveu:

> Olá Pedro e demais colegas
>
> a discussão está interessante e é necessária, mas tem hora que estamos
> andando em círculos.
>
> O grande problema da classificação é a mistura de hierarquia com o formato
> da rodovia.
>
> Eu vejo a coisa da seguinte maneira
>
>
>- Formato 1: motorway
>- Formato 2: trunk
>- Formato 3: primary, secondary, tertiary (aqui é o único lugar onde
>precisamos de uma orientação)
>- Formato 4: unclassified (começo a concordar que é uma boa colocar
>vias não pavimentadas que não sejam track aqui)
>
> Para mim, a discussão de hierarquira deveria se restringuir apenas ao
> formato 3.
>
> Não podemos transformar trunk numa super-primary, ou seja uma primary mais
> primary que a primary. E a razão principal disto é que se fizermos assim
> induzirá o usuário ao erro, possivelmente erros que geram tanstornos e
> custos.
>
> Por isto sou extremamente contra a classificação de vias simples de duas
> faixas como trunk, não importa quão importantes sejam. Por experiência
> pessoal, isto já me induziu ao erro. Felizmente nada grave, mas ainda assim
> me passou uma informação totalmente errada. Se eu fosse um usuário comum e
> não conhecesse o processo de mapeamento do OSM, eu perderia a confiança no
> mapa naquele momento.
>
> E francamente até o momento o argumento mais forte que vi vai na linha de
> dizer "vamos colocar como trunk porque é o que ela *deveria* ser",
> deveria mas não é o que para mim encerra a questão. A gente deve mapear a
> *realidade*, não desejos ou intenções.
>
> No Formato 3 temos 3 níveis possíveis, há aqui margem suficiente para
> acomodar tudo. Assim ao invés de usar trunk como super-primary, seria
> melhor aproveitar mais o nível tertiary. Então as rodovias nacionais
> importantes como primary, as demais como secondary e o que estava sendo
> tratado até agora como secondary passaria a ser tertiary.
>
> bom, tenho de ir trabalhar, a discussão continua depois,
>
> abraços
>
> Gerald
>
>
> 2013/5/21 Pedro Geaquinto 
>
>> Acho que os conceitos utilizados pelo Ministério dos Transportes deveriam
>> ser adaptados apenas para as rodovias nacionais (BRs) e nas demais vias
>> seriam conceitos globais.
>>
>> Poderíamos dividir entre três grupos ao invés de apenas dois: rodovias
>> nacionais, demais vias em meio não-urbano e urbano. O urbano está bem
>> estabelecido (posso dizer que não mudei nada, mas fortaleci o
>> estabelecimento com aqueles 4 conceitos acima), o não-urbano estamos
>> chegando num consenso e as nacionais mal começamos a discutir. :D
>>
>> Apenas "motorway" é um conceito global no OSM: até os seus "links" são
>> normados. Não existem referências na wiki para "shoulder", então podemos
>> dizer que acostamento não é fator decisivo, e quando disse
>> "preferencialmente" qu

Re: [Talk-br] Hierarquia das rodovias

[Pedro Geaquinto]

Acho que os conceitos utilizados pelo Ministério dos Transportes deveriam
ser adaptados apenas para as rodovias nacionais (BRs) e nas demais vias
seriam conceitos globais.

Poderíamos dividir entre três grupos ao invés de apenas dois: rodovias
nacionais, demais vias em meio não-urbano e urbano. O urbano está bem
estabelecido (posso dizer que não mudei nada, mas fortaleci o
estabelecimento com aqueles 4 conceitos acima), o não-urbano estamos
chegando num consenso e as nacionais mal começamos a discutir. :D

Apenas "motorway" é um conceito global no OSM: até os seus "links" são
normados. Não existem referências na wiki para "shoulder", então podemos
dizer que acostamento não é fator decisivo, e quando disse
"preferencialmente" quis dizer que não é necessário esse parâmetro.

Então vou tentar adaptar a divisão do Ministério dos Transportes, mostrada
pelo mapa do Nelson, para apenas *rodovias nacionais (BR)*:

*Duplicadas:* geralmente *motorway* no meio rural, só precisamos verificar
se há todas as restrições que são necesárias para classificação de motorway
(acessos, cruzamentos, etc), senão vai ser *trunk*.
*Pavimentadas:* temos que decidir entre trunk ou primary, eu prefiro
*trunk*para diferenciar das demais vias não BR (que seriam
classificadas como
primary).
*Implantadas:* ficaria logo após o nível acima não? Logo poderiam ser *
secondary*.
*Leito natural:* concordam que apenas por hierarquia podemos tomar como *
tertiary*?

Por último um apelo: *adaptem meu fluxograma intermediário para os meios
não-urbanos!!* Indiquem o que não concordam e façam um novo.


Em 21 de maio de 2013 00:38, Vítor Rodrigo Dias escreveu:

> "Fiquei na dúvida em relação à aplicação do termo "leito
> natural". Encontrei um TCC (
> http://www.projetos.unijui.edu.br/petegc/wp-content/uploads/2010/03/TCC-Juliano-Reis-Wallau.pdf)
>  onde
> diz que a diferença entre "leito natural" e "implantada" seria
> a estabilidade do solo da via, que teria relação com a compactação do solo.
> Isso certamente teria impacto sobre a probabilidade de atolar num dia de
> chuva. Acho difícil de medir isso por imagens de satélite, mas por fotos a
> partir do chão deve ser relativamente fácil decidir (no entanto, a opinião
> de um morador ou frequentador do local deveria prevalecer). No entanto, é
> um pouco diferente do critério de "track" com o qual havíamos concordado
> (via de terra e estreita)."
>
> Fernando, pelo menos o DER-MG, na sua listagem de rodovias, especifica
> quais rodovias não-pavimentadas estão em leito natural e quais estão
> implantadas.
>
> Abraços!
>
> Vítor Rodrigo Dias
> Revisor de textos
> Tradutor port/ing/port e port/esp/port
> Telefone: (31) 9895-3975 - TIM
>
>
> Em 20 de maio de 2013 22:56, Fernando Trebien 
> escreveu:
>
> Para comparação, tentei estabelecer uma associação entre o que eu já
>> tinha colocado no wiki (que é parecido com o que o Pedro expressou nos
>> seus fluxogramas) e a descrição que o DNIT dá para a terminologia
>> usada no BIT:
>> http://wiki.openstreetmap.org/wiki/Pt-br:How_to_map_a#M.C3.A9todo_objetivo_.282.C2.AA_proposta.29
>>
>> Fiquei na dúvida em relação à aplicação do termo "leito natural".
>> Encontrei um TCC
>> (
>> http://www.projetos.unijui.edu.br/petegc/wp-content/uploads/2010/03/TCC-Juliano-Reis-Wallau.pdf
>> )
>> onde diz que a diferença entre "leito natural" e "implantada" seria a
>> estabilidade do solo da via, que teria relação com a compactação do
>> solo. Isso certamente teria impacto sobre a probabilidade de atolar
>> num dia de chuva. Acho difícil de medir isso por imagens de satélite,
>> mas por fotos a partir do chão deve ser relativamente fácil decidir
>> (no entanto, a opinião de um morador ou frequentador do local deveria
>> prevalecer). No entanto, é um pouco diferente do critério de "track"
>> com o qual havíamos concordado (via de terra e estreita).
>>
>> Outras opções (algumas já propostas) para tentar uma aproximação com a
>> classificação do BIT seriam:
>>
>> - primary = 2 faixas sem acostamento OU 1 faixa com acostamento;
>> secondary = 1 faixa sem acostamento; tertiary = não-pavimentada com
>> terra bem compactada; unclassified = não-pavimentada larga com terra
>> insuficientemente compactada (potencial para atolamento); track =
>> não-pavimentada estreita
>>
>> - trunk = 2 faixas; primary = 1 faixa com acostamento; secondary = 1
>> faixa sem acostamento (possivelmente menos segura); tertiary =
>> não-pavimentada com terra bem compactada; etc.
>>
>> Que tal?
>>
>> 2013/5/20 Fernando Trebien :
>> > Que interessante! A classificação do Ministério dos Transportes (que
>> > não usa termos abstratos) devia ser considerada extremamente relevante
>> > na nossa forma de classificar, afinal, eles são os especialistas no
>> > assunto. Se essa é a informação publicada por eles, é porque
>> > provavelmente é a mais requisitada - ou seja, a mais útil para os
>> > usuários dessas vias.
>> >
>> > Encontrei o link principal dentro do site que leva aos links que você
>> > postou, para qu

Re: [Talk-br] Hierarquia das rodovias

[Pedro Geaquinto]

entendo e concordo que "highway" deve ser a hierarquia, mas o que
> estamos tentando decidir é como estabelecer essa hierarquia. Eu e você
> podemos discordar sobre o nível hierárquico (ou de importância) de uma
> via. Eventualmente, discutiríamos e chegaríamos a um consenso. Alguns
> meses depois, outra pessoa poderia vir e reabrir a discussão. E assim
> ficaríamos discutindo eternamente, cada vez com uma pessoa diferente,
> que tem um senso subjetivo de importância diferente, como ficou bem
> claro pela quantidade de critérios diferentes propostos nessa
> discussão até agora.
>
> Você não concorda que a hierarquia tem efeitos colaterais sobre o
> formato da via? Ou seja, que o formato "diz alguma coisa" (sem dizer
> tudo, é claro) sobre a importância da via?
>
> Quando você analisa o contexto "local", você tem que ver que "local"
> pode ser uma área muito pequena ou muito ampla, depende da pessoa que
> está considerando. Por exemplo, se eu for calcular uma rota (com GPS
> ou à olho) do Rio de Janeiro até Buenos Aires, o contexto local (a
> relação hierárquica/de importância) das vias depende de comparações
> numa área muito grande. Já se for fazer uma rota do Rio até Niterói a
> relação hierárquica pode ser bem diferente porque as vias da região
> são muito mais parecidas entre si.
>
> 2013/5/20 Pedro Geaquinto :
> > A discussão está muito interessante! Desculpem pelo fluxograma estar meio
> > mal explicado, podemos mudar juntos.
> > Tentem fazer novas versões!
> >
> > Em 20 de maio de 2013 13:08, Fernando Trebien <
> fernando.treb...@gmail.com>
> > escreveu:
> >
> >> Eu concordo com tudo que o Pedro e o Gerald disseram (com o que o
> >> Vitor disse sobre as BR-4xx eu precisaria estudar mais) e achei os
> >> fluxogramas muito bons.
> >>
> >> Mas o problema que eu tentei abordar desde o começo é a ambiguidade
> >> nas interpretações do que é comparativamente mais "importante" (qual o
> >> raio de comparação?), do que é "vicinal", do que é uma "pequena"
> >> conurbação, e até o do que é "paralela" (pois nenhuma via é
> >> absolutamente reta).
> >
> >
> > Vicinal: eu imaginei vicinal todas aquelas pequenas estradinhas que
> passam
> > entre os "lotes" de plantação (não sei o termo certo) e acessos a
> chácaras,
> > sítios e sedes de fazenda. Eu também utilizo "highway=track" para ruas de
> > terra em péssimas condições, mas posso mudar.
> >
> > Pequena conurbação: nesse caso fica meio fora do contexto apenas "pequena
> > conurbação", o termo que usei foi "acesso a pequena conurbação isolada".
> A
> > ênfase está em "isolada", ou seja, um distrito ou concentração rural que
> não
> > seja caminho para outro município.
> >
> > Paralela: imaginei uma cidade populosa com um caminho mais utilizado e um
> > caminho alternativo.
> >
> >>
> >> Foi muito bom marcar as coisas ambíguas em
> >> vermelho no fluxograma para guiar o debate, mas eu marcaria algumas
> >> coisas a mais.
> >>
> >
> > Eu marquei essas coisas a mais com preto! Leia a legenda no fluxograma
> que
> > explica minha sugestão. Em preto são características que levam um pouco
> de
> > reflexão, em cinza são características físicas (podem ganhar um
> "predomina"
> > antes de cada pergunta) e em vermelho são características que devem ser
> > discutidas por toda a comunidade.
> >
> >>
> >> Acho melhor tentarmos nos concentrar nas características mensuráveis
> >> da via para minimizar as nossas divergências. Parece que estamos nos
> >> concentrando na classificação em área não-urbana, então vou considerar
> >> apenas isso a seguir.
> >>
> >> Parece que todos concordam que uma "motorway" precisa ter 2 pistas,
> >> acostamento, canteiro central, e (eu defendo) a alta velocidade. Se
> >> faltar alguma dessas coisas, o máximo que ela poderia ser é "trunk".
> >
> >
> > Não concordo em colocar na mesma medida acostamento com falta de
> > cruzamentos! E falta de canteiros centrais em pequenos trechos não faz a
> via
> > deixar de ser motorway como um semáforo faria: isso é uma convenção
> global
> > no OSM.
> > Não seria bom senso chamar a Ponte Rio-Niterói de trunk, aquilo é
> claramente
> > uma motorway, apesar de não ter acostamento (já teve inclusive no
> passado).
> > Em "restrições?", eu pensei nisso: "semáforos, lombadas e/ou
> cruzamentos?"

Re: [Talk-br] Hierarquia das rodovias

[Pedro Geaquinto]

 pavimentar (sem ampliar) para se tornar terciária.
>
>
Excelente. A não ser quando liga dois municípios, aí é tertiary. Acho que
vocês estão levando muito em consideração as caracterísiticas físicas! Para
isso servem as tags lanes, shoulder, surface... A tag highway é
primariamente para HIERARQUIA.


> Por fim, sobrariam as trilhas (track) que seriam as de pista simples,
> não pavimentadas, onde apenas 1 veículo pode passar por vez.
>
>
Gostei da definição. :)


> O que acham? Isso poderia virar uma tabela bem simples para um
> principiante seguir sem ter dúvidas.
>
> 2013/5/20 Gerald Weber :
> > Oi Pedro
> >
> > seus fluxogramas ficaram muito legais, parabéns pelo esforço
> interpretativo.
> >
> > 2013/5/20 Pedro Geaquinto 
> >>
> >>
> >> - Um muito próximo do que está escrito na wiki, que é a interpretação
> >> livre do Gerald: http://i.imgur.com/2IAfQT7.gif
> >
> >
> > Eu notei que há várias partes na wiki descrevendo as hierarquias das
> > rodovias e que não parecem consistentes entre sí. Acho que vamos ter de
> > fazer uma busca geral.
> >
> > Sobre este fluxograma, acho que não ficou muito claro as caixas com
> > "vicinal" no caso de rodovias não-pavimentadas e "restrições"  no caso de
> > motorway. Eu trocaria "restrições"  por "tem canteiro central, acessos
> > especiais e não tem cruzamentos?" ou algo assim.
> >
> > Trocaria "vicinal" por "é de uso constante, larga e tem manutenção
> > periódica?"
> >
> >>
> >>
> >> - Um intermediário da minha sugestão. Só com alguns parâmetros a mais
> que
> >> adicionei, para padronizar por exemplo o uso de "unclassified":
> >> http://i.imgur.com/rcY2LC6.gif
> >
> >
> > Ficou interessante também.
> >
> >>
> >>
> >> - Minha sugestão. Com o conceito de "importância" que depende da
> >> interpretação da comunidade: http://i.imgur.com/MsqrZlp.gif
> >
> >
> > Não querendo puxar a sardinha para a minha brasa, mas este fluxograma é o
> > que melhor mostra a complexidade em optar por este esquema de
> classificação.
> >
> >>
> >>
> >>
> >> Ah, e quanto a essa questão (meio off) de que se houvesse infraestrutura
> >> não haveria essa indagação: foi exatamente assim que eu comecei a me
> >> questionar. Essas vias que eu sugiro serem marcadas como trunk, por
> serem
> >> mais importantes que meras primary, deveriam ter sido duplicadas há
> tempos
> >> pelo tráfego pesado que recebem. Acaba que no Brasil temos corredores
> muito
> >> importantes com um formato totalmente desproporcional. É um atraso que
> temos
> >> no país, infelizmente.
> >>
> >
> > O país é gigante e pobre, e suas prioridades tem hora são muito
> estranhas.
> > Não vejo como o resultado pudesse ser muito diferente.
> >
> > Nem por isto podemos marcar as rodovias pelo que elas deveriam ser, quer
> > dizer, não faz sentido marcar uma rodovia como trunk por que ela deveria
> ser
> > duplicada mas não é.
> >
> > mais uma vez obrigado por esta sistematização.
> >
> > abraço
> >
> > Gerald
> >
> > ___
> > Talk-br mailing list
> > Talk-br@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@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-br
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Hierarquia das rodovias

[Pedro Geaquinto]

Oi pessoal.

Como prometido, fiz os fluxogramas. Acho que ajudaria os iniciantes a se
habituarem com nossas adaptações ao sistema inglês.
Mesmo assim, vão haver muitos erros. Aqui no Rio percebo que os novatos não
se importam muito com a hierarquia e muitas vias que devem ser tipicamente
tertiary estão com a tag secondary. Só querem dizer que aquela rua é
importante.
Não é um problema muito grave, já que para quem está habituado é bem
trivial entender o sistema e corrigir toda uma região de uma vez.

Voltando aos fluxogramas, fiz 3 versões para o meio rural:

- Um muito próximo do que está escrito na wiki, que é a interpretação livre
do Gerald: http://i.imgur.com/2IAfQT7.gif
- Um intermediário da minha sugestão. Só com alguns parâmetros a mais que
adicionei, para padronizar por exemplo o uso de "unclassified":
http://i.imgur.com/rcY2LC6.gif
- Minha sugestão. Com o conceito de "importância" que depende da
interpretação da comunidade: http://i.imgur.com/MsqrZlp.gif

Ah, e quanto a essa questão (meio off) de que se houvesse infraestrutura
não haveria essa indagação: foi exatamente assim que eu comecei a me
questionar. Essas vias que eu sugiro serem marcadas como trunk, por serem
mais importantes que meras primary, deveriam ter sido duplicadas há tempos
pelo tráfego pesado que recebem. Acaba que no Brasil temos corredores muito
importantes com um formato totalmente desproporcional. É um atraso que
temos no país, infelizmente.

Um abraço!

Pedro


Em 19 de maio de 2013 01:26, Fernando Trebien
escreveu:

> Gerald, pensei mais um pouco sobre a questão, tentei refinar o texto
> que eu coloquei no wiki, e acho que concordo com você que motorways
> precisam ter acostamento e pelo menos 2 pistas, senão dirigir na
> velocidade máxima (e eventualmente ter que parar por causa de
> problemas com o veículo) seria de fato muito perigoso mesmo para um
> motorista habilidoso. Seria certamente um caso de "velocidade
> incompatível com a via", um erro grosseiro do nosso governo, e a via
> não corresponderia aos requisitos mínimos de uma autoestrada pelos
> padrões internacionais. Para as trunk, que são de 80 km/h, acho
> possível que sejam de pista simples (como na sua segunda proposta), há
> muitas rodovias nacionais assim aqui no RS e elas são relativamente
> seguras. Eu fui tentar fundamentar melhor isso procurando nos artigos
> da Wikipédia sobre esses tipos de via pelas palavras "acostamento" e
> "shoulder" e só as encontrei no artigo referente a autoestradas.
>
> Estou relendo as suas propostas anteriores e pensando como posso
> conciliá-las com o que eu escrevi no wiki, aceito sugestões. Reli
> também algumas páginas no wiki, onde notei que o texto da sua proposta
> é bem parecido com o que está lá.
>
> 2013/5/18 Fernando Trebien :
> > Concordo que é complicado para um iniciante (eu já fui um) e acho que
> > o seu guia seria ideal para vias recém mapeadas, que ainda não constam
> > no mapa. Desde o início eu senti falta de uma especificação mais clara
> > do que cada coisa é.
> >
> > O meu problema é com as vias existentes. Há várias que não são primary
> > e não têm uma tag note explicando o motivo da diferença. Como saber,
> > então, se foram classificadas desta forma por um motivo
> > suficientemente "forte"? Eu diria inclusive suficientemente
> > "coerente", compatível com as expectativas de um usuário do
> > OpenStreetMap que, digamos, vem de outro país - por exemplo, turistas.
> > Sei que a maioria deve estar com a classificação que resultou de algum
> > processo de importação de dados em massa de alguma outra base de dados
> > (cuja qualidade eu desconheço). Seria interessante que a importação
> > estivesse descrita em algum lugar para sabermos quais os critérios que
> > foram usados.
> >
> > Se você quiser, podemos, por exemplo, acrescentar à regra que todas as
> > vias "motorway" precisam de acostamento. Ao escrever a regra dessa
> > forma, eu me baseei na definição da via no artigo em inglês
> > (http://wiki.openstreetmap.org/wiki/Motorway) que começa dizendo: "Use
> > highway=motorway to identify the highest-performance roads within a
> > territory". Não entrei nos detalhes do número de pistas e da separação
> > dos sentidos para não tornar essa regra muito complexa, mas se você
> > acha fundamental isso, vamos acrescentar.
> >
> > Eu penso que os casos que você citou (motorways a 60km/h e vias sem
> > acostament a 110km/h) são as exceções da regra e claramente são erros
> > de projeto ou de administração do governo. Esses são os casos em que
> > eu acho que vale à pena discutir e anotar na tag note a justificativa.
> > Os outros (a maioria) não.
> >
> > O que eu quero saber é com o que a comunidade (brasileira) concorda e
> > discorda, especialmente para fundamentar a discussão dos casos
> > ambíguos. Eu ainda estaria mapeando várias vias como "track" onde não
> > fossem pavimentadas se não tivesse levantado a questão, e talvez daqui
> > a alguns meses (ou anos) alguém ia ter que desfazer tudo o que eu fiz
>

Re: [Talk-br] Hierarquia das rodovias

[Pedro Geaquinto]

Concordo com vocês que o conceito de importância é subjetivo, mas acho que
nisso o OSM pode contornar, já que é um projeto colaborativo. Inicialmente,
reconheço as vias BR-0xx e BR-1xx como muito importantes, mas devemos
discutir.

Já montei os dois fluxogramas, o com os conceitos atuais e o com os meus,
só falta desenhar no computador. Infelizmente tenho pouco tempo
disponível...

Tive a idéia de separar os parâmetros como: físicos (número de faixas,
pavimetação, canteiro, etc); verificáveis (paralelismo a outras vias,
acesso a cidades pequenas) e discutíveis (importância de vias). O
interessante é que no caso dos parâmetros físicos, pode-se colocar em todos
os casos um "predominante" antes da pergunta. Por exemplo, uma primary de
100km que não tem acostamento durante 500m, não precisa ter um buraco em
secondary, é interessante manter a continuidade da via.

Mais tarde faço um semelhante para meios urbanos, onde temos menos
divergências.

Quanto às velocidades máximas, acho que são bons indicadores, mas não devem
ser utilizados como parâmetros definitivos no mapeamento. Antigamente havia
essas sugestões na wiki, mas acho que foram retiradas.

Um abraço.

On May 17, 2013 1:14 PM, "Fernando Trebien" 
wrote:

Tem mais uma coisa a ser considerada: duas vias longas, duplicadas,
com boa sinalização, com bom asfalto, mas uma sendo rodovia nacional e
outra sendo rodovia estadual, devem ser classificadas da mesma forma?
Penso no que seria mais útil para alguém que estiver vendo o mapa com
a ampliação mais afastada. Já vi alguns mapas brasileiros fazendo uma
distinção visual entre os dois tipos. No OpenStreetMap, acho que a
intenção original era que as nacionais fossem "motorway" porque em
países desenvolvidos as rodovias nacionais geralmente são de alta
velocidade (100km/h ou mais) e que "primary" fosse usada para as
demais em meio rural (geralmente de administração local) ou para
arteriais em meio urbano. Primary seria igual para esses dois casos
porque uma primária rural tende a virar uma arterial urbana quando a
cidade cresce.

As "trunk" parecem ter sido introduzidas para vias "regionais" para
diferenciar das nacionais e também das arteriais urbanas ou primárias
rurais (geralmente pequenas e de administração local). Nesses países,
as "trunk" seriam normalmente de velocidade menor que as "motorway".
Mas a velocidade menor deles é praticamente a nossa velocidade padrão,
então por comparação, a maioria das nossas rodovias nacionais seriam
"trunk", exceto as que são verdadeiramente autoestradas (100km/h ou
mais). As estaduais também, e daí acho subjetivo optar por uma
diferenciação (usando primary) ou deixar a mesma classificação (porque
as vias têm as mesmas características exceto pelo responsável pela
administração).

No wiki, há um artigo listando a velocidade máxima esperada para cada
tipo de via, fazendo distinção entre a aplicação em meio urbano e
rural: http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Maxspeed

Essa distinção é feita assumindo que os bairros da cidade são
(multi-)polígonos com a tag place= e que o que é meio rural é que não
está dentro dos bairros.

Se é assim, então não teria problema em classificar as estaduais como
primárias, e as intermunicipais (de administração municipal) como
secundárias. O dispositivo de GPS (ou o pré-processamento dos mapas
para um dispositivo desses) deveria atribuir a velocidade média
seguindo o critério descrito nessa página, que é a adotada pela
comunidade. Agora se não houver essa premissa, daí eu concordaria que
estaduas e nacionais deveriam ser trunk sempre devido à alta
velocidade e à estrutura (formato e controle de acesso) que suporta
essa alta velocidade em todo o percurso da via.

2013/5/17 Fernando Trebien :

> Em concordo com você em quase tudo, Gerard. Primeiramente, acho que
> quem faz o mapa tem que pens...
___
Talk-br mailing list
Talk-br@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Hierarquia das rodovias

[Pedro Geaquinto]

Eu continuo não concordando com essa definição de trunk.

É muito simples tomar apenas como medida as faixas (2x2). Na minha
concepção, a diferenciação na tag "highway=*" é de hierarquia, independente
de sua disposição física. A wiki em inglês, fala que mesmo highway=motorway
pode ser em via simples (mesmo não sendo comum), desde que seja em pequenos
trechos, larga (2x2+), com acessos e saídas, e sem interrupções, sem perder
o número de faixas. [1]

Tudo bem que o formato físico é um ótimo parâmetro para tratar como padrão.
Tomando como analogia: imagine se todos os trechos duplicados em trechos
urbanos fossem "trunk"? Seria completamente incorreto.
Da mesma forma, existem vias em certos estados que são obviamente mais
importantes que outras vias mesmo ambas sendo simples (1x1)! E por essa
convenção que estamos estipulando o contraste seria... primary vs primary.
Tem que haver algum contraste, vocês não acham que a tag "trunk" não está
sendo subutilizada nesse caso? Em vários países da América do Sul, como
Argentina e Uruguai, já vi essa tag sendo utilizada para pista 1x1.

O que eu acho é que deveriamos fazer uma lista de vias que não são trunk só
tomando em consideração as faixas (2x2) e também são mais importantes que
uma simples primary, ou seja, tem importância interestadual.

E para mim, não vale o argumento de que uma pessoa vai olhar para o mapa e
achar que a via tem 2x2. Existe a tag "lanes=*" justamente para isso.

Portanto, minha lista para o meio rural, ficaria (mudanças em vermelho):


   - *motorway:* rodovia duplicada, com canteiro central, sem cruzamentos,
   com acessos e saídas especiais e restrições para tráfego exterior.* Exceções
   em pista simples podem acontecer, desde que sejam em pequenos trechos da
   extensão da rodovia e que não perca o número de faixas.
   *
   - *trunk:* rodovias pavimentadas de grande importâcia interestadual (ou
   nacional) *listadas* independente da sua disposição física. Em casos
   gerais, uma rodovia com mais de 4 faixas (2 por sentido), *que pode ser
   atravessada* em um ou mais pontos. Uma rodovia duplicada com faixas de
   pedestres, sinais de trânsito e lombadas seria trunk.
   - *primary: *rodovias de pista simples e *pavimentada*, de grande
   importância intermunicipal (ou estadual).
   - *secondary: **mesmo formato físico de primary*, porém como via
   alternativa a uma primary ou rodovias de acesso à cidades menores. Outro
   caso para utilização é um corredor importante para o estado, porém não
   pavimentado.
   - *tertiary: *sem pavimentação, liga municípios. Com pavimentação, liga
   distritos num mesmo município ou é alternativa a secondary.
   - *unclassified: *via menor não pavimentada.


[1]: Retirado da wiki: "*In the less usual case of a motorway where traffic
travels i both directions along the same carriageway use a single way and
tag it with oneway =no."*


Em 16 de maio de 2013 20:05, Arlindo Pereira <
openstreet...@arlindopereira.com> escreveu:

> Sim, os dados do IBGE são de domínio público, pede-se apenas a atribuição
> dos dados, o que pode ser feito com source=IBGE.
>
> []s
> Em 16/05/2013 19:46, "Vítor Rodrigo Dias"  escreveu:
>
> Uma fonte razoável de dados e que está disponível para o público, embora
>> não seja 100% confiável, são os mapas de setores censitários do IBGE,
>> disponíveis em seu FTP. É possível usar esses dados nos mapas?
>>
>>
>> Vítor Rodrigo Dias
>> Revisor de textos
>> Tradutor port/ing/port e port/esp/port
>> Telefone: (31) 9895-3975 - TIM
>>
>>
>> Em 16 de maio de 2013 19:44, Vítor Rodrigo Dias 
>> escreveu:
>>
>>> Ah sim, agora entendi! Muito obrigado pela explicação!
>>>
>>> Abraços,
>>>
>>>
>>> Vítor Rodrigo Dias
>>> Revisor de textos
>>> Tradutor port/ing/port e port/esp/port
>>> Telefone: (31) 9895-3975 - TIM
>>>
>>>
>>> Em 16 de maio de 2013 19:14, Fernando Trebien <
>>> fernando.treb...@gmail.com> escreveu:
>>>
>>> Tem uma explicação sobre o uso dos dados do Google no meio do FAQ do
 OSM:
 http://wiki.openstreetmap.org/wiki/FAQ#Why_don.27t_you_just_use_Google_Maps.2Fwhoever_for_your_data.3F

 "They [Google, NAVTEQ, TeleAtlas], in turn, have obtained some of this
 data from national mapping agencies (such as the Ordnance Survey).
 Since they've made significant financial investments to gather this
 data, these organisations are understandably protective of their
 copyright. If you collect data from Google Maps in this way, you are
 creating a "derived work". Any such data retains the copyright
 conditions of the original. In practice, this means your data is
 subject to the licensing fees, and contractual restrictions, of these
 map providers. That's exactly what OpenStreetMap is trying to avoid."

 Ou seja: legalmente, o mapa não pode ser usado para absolutamente
 nada. Talvez você possa tirar uma dúvida ou outra, mas não pode sair
 copiando o nome de todas ruas, ou a sua classificaçã

Re: [Talk-br] [Meio Off] Motorville

[Pedro Geaquinto]

Legal, isso é Los Angeles né?
Acho que o animador utilizou o Maperitive. Eu uso ele às vezes pra fazer
uma cidade fictícia, é bacana.


2013/4/2 Claudomiro Nascimento Junior 

> Bem legal... rs
>
>
> 2013/4/2 Arlindo Pereira 
>
>> Vídeo sensacional!
>>
>> http://vimeo.com/62468031
>>
>> Apesar de ter o visual parecido com o Google Maps, usa dados do
>> OpenStreetMap. =)
>>
>> []s
>>
>> ___
>> Talk-br mailing list
>> Talk-br@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-br
>>
>>
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-br
>
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Dúvidas quanto ao mapeamento de trevos

[Pedro Geaquinto]

Vou dar uma olhada sim nesse material, já que sou aficcionado no assunto e
penso em fazer uma pós em Engenharia de Transportes.

Em 31 de janeiro de 2013 18:42, Gerente de Sistemas escreveu:

> Olá, sugiro consultar o Manual de Projeto Geométrico do DNIT e um livro
> sobre Engenharia de Tráfego.
>
> Creio que seria interessante ter alguém da área junto do grupo, convidem o
> curso de engenharia de tráfego da Universidade de Minas Gerais, o Maderna
> Leite é professor lá (ou era) e o livro dele é muito bom.
>
> Em 31 de janeiro de 2013 02:57, Pedro Geaquinto 
> escreveu:
>
> Foi bom terem levantado essa discussão.
>>
>> Bom, eu já meio que "estudei" as convenções mundo afora, e em certas
>> combinações de tipos de highway isso é bem complexo mesmo, muitas vezes a
>> escolha da tag fica por critério do mapeador. Então comecei a refletir e
>> fiz um pequeno tutorial sobre links e hierarquias. [1]
>>
>> Ainda está incompleto, porque existem outras exceções à idéia de
>> "hierarquia entre caminhos" que é a doutrina que sigo quando mapeio
>> estradas e ruas. São alguns binários viários incomuns. Isso acontece
>> principalmente por falta de construção de infra-estrutura pelo governo, ou
>> às vezes por outras limitações que impossibilitam a construção (técnicas,
>> ecológicas, sociais...).
>>
>> Também gostaria de dizer que discordo da definição de vias "trunk" em
>> meio rural. Não podem ser vias não duplicadas! Imagine uma auto-estrada
>> duplicada importante que a um certo momento vai pra via simples:
>> simplesmente teria que passar de "motorway" para "primary", o que é
>> desencorajado em ferramentas como o Keep it Right (motorway só se ligaria
>> com trunk, motorway_link e service). Ou seja, estamos oficialmente fora de
>> uma das poucas convenções globais do OSM.
>>
>> Um abraço. Vejam abaixo o tutorial que fiz:
>>
>> [1]: http://i.imgur.com/xpuqmgm.gif
>>
>> Em 30 de janeiro de 2013 17:24, Gerente de Sistemas 
>> escreveu:
>>
>> Alguém da lista tem mestrado em engenharia de tráfego?
>>> A Cartografia do Exército está envolvida na lista e nos trabalhos?
>>> É possível envolver alguém com estas características?
>>>
>>>
>>> Em 30 de janeiro de 2013 14:35, Tymon Douglas 
>>> escreveu:
>>>
>>> Muito obrigado pela ajuda! Vou seguir esse padrão de hoje em diante.
>>>>
>>>> Em 30 de janeiro de 2013 14:11, Bráulio escreveu:
>>>>
>>>> (O Leandro foi mais rápido, mas como eu já tinha quase terminado de
>>>>> redigir...)
>>>>>
>>>>> Tymon,
>>>>>
>>>>> Do jeito que você fez o roteamento não funciona corretamente. Por
>>>>> exemplo, quem vem da estrada de terra e quer virar à esquerda na direção
>>>>> sudeste tem que dar essa volta toda:
>>>>>
>>>>> http://i.imgur.com/7O8iok1.jpg
>>>>>
>>>>> Então o correto seria assim:
>>>>>
>>>>> http://i.imgur.com/zDYkv3N.jpg
>>>>>
>>>>> Fica meio torto, mas não tenho uma ideia melhor de como mapear. O
>>>>> ideal seria o OSM e os roteadores terem suporte a estradas mapeadas como
>>>>> áreas, mas ainda estamos longe disso.
>>>>>
>>>>> Bráulio Bezerra
>>>>>
>>>>>
>>>>> 2013/1/30 Leandro Motta Barros 
>>>>>
>>>>>> Boa tarde, Tymon!
>>>>>>
>>>>>> Só para facilitar caso alguém mais queira participar da discussão,
>>>>>> creio que estejas falando deste trevo aqui:
>>>>>> http://osm.org/go/M42Gszri~--
>>>>>>
>>>>>> (O que eu vou dizer abaixo é  o que eu costumo fazer; não é
>>>>>> necessariamente "O Jeito Certo". Vamos conversando :-) )
>>>>>>
>>>>>> Eu teria mapeado um pouco diferente. Dá uma olhada nessa outra rótula
>>>>>> ali perto (que acho que fui eu que mapeei em detalhes há um tempo
>>>>>> atrás): http://osm.org/go/M4zeq4tIH--
>>>>>>
>>>>>> Principais diferenças:
>>>>>>
>>>>>> 1) Eu sempre penso no link como sendo algum tipo de "transição".
>>>>>> Imagine alguém andando pela 471/392 e passando pelo trevo. Ele não
>>>>>> saiu da estrada primária 471/392. Pelo teu mapeamento, alguém indo
>>>>>> pela 471/392 teria sa

Re: [Talk-br] Dúvidas quanto ao mapeamento de trevos

[Pedro Geaquinto]

Hehe, nesse caso, eu estava querendo dizer: Av. Nações Unidas (trunk) -
binário Túnel do Pasmado/Pasteur (trunk/primary) - Lauro Sodré (trunk). Mas
interessante esse caso que você atentou, não tinha percebido! :D

Em 31 de janeiro de 2013 18:01, Arlindo Pereira <
openstreet...@arlindopereira.com> escreveu:

> Apesar de não mapear tanto rodovias - prefiro, por preferência pessoal,
> focar em POIs e micromapping - dar meus 2 centavos dizendo que concordo
> plenamente com a sua opinião, Pedro. De fato, é estranho cair de trunk pra
> primary e depois voltar a trunk quando as vias são ligações naturais, como
> é o caso da Pasteur - Praia de Botafogo - Pinheiro Machado (exemplo [4]).
>
> []s
>
> 2013/1/31 Pedro Geaquinto 
>
>>
>>
>> Também gostaria de dizer que discordo da definição de vias "trunk" em
>>>> meio rural.
>>>
>>>
>>> Me perdõe, mas eu realmente não entendi o que você quis dizer aqui. Há
>>> muitas trunk e motorway em meio rural na europa, porque não poderia haver
>>> aqui?
>>>
>>>
>>>> Não podem ser vias não duplicadas! Imagine uma auto-estrada duplicada
>>>> importante que a um certo momento vai pra via simples: simplesmente teria
>>>> que passar de "motorway" para "primary", o que é desencorajado em
>>>> ferramentas como o Keep it Right (motorway só se ligaria com trunk,
>>>> motorway_link e service). Ou seja, estamos oficialmente fora de uma das
>>>> poucas convenções globais do OSM.
>>>>
>>>
>>> Então minha recomendação é esta: tem que refletir a realidade e tem que
>>> refletir a importância real da via. Se neste processo tiver de violar uma
>>> ou outra convenção, então paciência. O usuário comum dos nossos mapas não
>>> sabe nada sobre estas convenções, ele precisa olhar o mapa e saber o que
>>> fazer. Se uma rodovia é duplicada por uns 10 km que seja, para ele pode ser
>>> crucial saber disto. Por isto mapear estes 10 km como motorway e o restante
>>> como primary reflete a realidade e só assim será útil, mesmo que não siga
>>> rigorosamente algumas convenções.
>>>
>>> Legal que você esteja fazendo um tutorial, seria interessante adaptá-lo
>>> e passar para a wiki?
>>>
>>>
>> Gerald, o que discordo é a definição de trunk em meio rural: *"Rodovia
>> de trânsito rápido, pavimentada e duplicada com, no mínimo, duas pistas por
>> sentido, com cruzamentos ou obstruções (semáforos, lombadas, etc) e acesso
>> direto por ruas transversais, que podem cruzar diretamente o trânsito da
>> rodovia." **[1]*
>>
>> Isso é muito incomum em território brasileiro, o único caso que conheço é
>> a Rodovia do Sol entre Guarapari e Vitória (ES-060), e só por causa dos
>> seus retornos que cruzam a estrada *[2]*. Esses casos quase só acontecem
>> em vias locais (que geralmente já não é em um meio tão rural assim) ou
>> quando há intercalação com vias singelas, como em alguns trechos da Rodovia
>> Amaral Peixoto (RJ-106). *[3]*
>>
>> Acho que existem muitas vias de trânsito pesado, de suma importância
>> nacional, que ainda não são duplicadas. Por exemplo, a BR-101 Norte tem um
>> grande papel de ligação interestadual, e é rebaixado a mesma importância
>> que rodoviais estaduais marcadas como primary, apenas pela limitação física
>> de não haver duplicação. Poderíamos criar uma nova convenção baseada também
>> na importância de cada via, além das propriedades físicas (faixas,
>> duplicação):
>>
>> *- motorway:* duplicada sem obstruções;
>> *- trunk:* via de importância nacional/interestadual independente de ser
>> duplicada, geralmente federal (poderíamos fazer uma lista desses casos*),
>> ou uma motorway (via duplicada) com obstruções;
>> *- primary:* via de importância regional/estadual, geralmente singela,
>> federal ou estadual;
>> *- secondary:* via de importância intermunicipal/interdistrital,
>> singela, estadual ou municipal;
>> *- tertiary:* via menor de importância municipal/distrital;
>> *- unclassified: *via municipal não pavimentada;
>>
>> Isso representa um gradiente mais suave do que hoje em dia, que tem um
>> abismo entre trunk e primary. Pode-se ver que apenas contesto a definição
>> de trunk, e ainda parcialmente, já que concordo com a definição atual: é só
>> uma adição.
>>
>> Quanto às vias em meio urbano, acho perfeito do jeito que está, mas
>> poderíamos discutir essa minha doutrina de "hierarquia entre caminhos" ao
>> invés de interpretar tudo como uma mera "

Re: [Talk-br] Dúvidas quanto ao mapeamento de trevos

[Pedro Geaquinto]

Também gostaria de dizer que discordo da definição de vias "trunk" em meio
>> rural.
>
>
> Me perdõe, mas eu realmente não entendi o que você quis dizer aqui. Há
> muitas trunk e motorway em meio rural na europa, porque não poderia haver
> aqui?
>
>
>> Não podem ser vias não duplicadas! Imagine uma auto-estrada duplicada
>> importante que a um certo momento vai pra via simples: simplesmente teria
>> que passar de "motorway" para "primary", o que é desencorajado em
>> ferramentas como o Keep it Right (motorway só se ligaria com trunk,
>> motorway_link e service). Ou seja, estamos oficialmente fora de uma das
>> poucas convenções globais do OSM.
>>
>
> Então minha recomendação é esta: tem que refletir a realidade e tem que
> refletir a importância real da via. Se neste processo tiver de violar uma
> ou outra convenção, então paciência. O usuário comum dos nossos mapas não
> sabe nada sobre estas convenções, ele precisa olhar o mapa e saber o que
> fazer. Se uma rodovia é duplicada por uns 10 km que seja, para ele pode ser
> crucial saber disto. Por isto mapear estes 10 km como motorway e o restante
> como primary reflete a realidade e só assim será útil, mesmo que não siga
> rigorosamente algumas convenções.
>
> Legal que você esteja fazendo um tutorial, seria interessante adaptá-lo e
> passar para a wiki?
>
>
Gerald, o que discordo é a definição de trunk em meio rural: *"Rodovia de
trânsito rápido, pavimentada e duplicada com, no mínimo, duas pistas por
sentido, com cruzamentos ou obstruções (semáforos, lombadas, etc) e acesso
direto por ruas transversais, que podem cruzar diretamente o trânsito da
rodovia." **[1]*

Isso é muito incomum em território brasileiro, o único caso que conheço é a
Rodovia do Sol entre Guarapari e Vitória (ES-060), e só por causa dos seus
retornos que cruzam a estrada *[2]*. Esses casos quase só acontecem em vias
locais (que geralmente já não é em um meio tão rural assim) ou quando há
intercalação com vias singelas, como em alguns trechos da Rodovia Amaral
Peixoto (RJ-106). *[3]*

Acho que existem muitas vias de trânsito pesado, de suma importância
nacional, que ainda não são duplicadas. Por exemplo, a BR-101 Norte tem um
grande papel de ligação interestadual, e é rebaixado a mesma importância
que rodoviais estaduais marcadas como primary, apenas pela limitação física
de não haver duplicação. Poderíamos criar uma nova convenção baseada também
na importância de cada via, além das propriedades físicas (faixas,
duplicação):

*- motorway:* duplicada sem obstruções;
*- trunk:* via de importância nacional/interestadual independente de ser
duplicada, geralmente federal (poderíamos fazer uma lista desses casos*),
ou uma motorway (via duplicada) com obstruções;
*- primary:* via de importância regional/estadual, geralmente singela,
federal ou estadual;
*- secondary:* via de importância intermunicipal/interdistrital, singela,
estadual ou municipal;
*- tertiary:* via menor de importância municipal/distrital;
*- unclassified: *via municipal não pavimentada;

Isso representa um gradiente mais suave do que hoje em dia, que tem um
abismo entre trunk e primary. Pode-se ver que apenas contesto a definição
de trunk, e ainda parcialmente, já que concordo com a definição atual: é só
uma adição.

Quanto às vias em meio urbano, acho perfeito do jeito que está, mas
poderíamos discutir essa minha doutrina de "hierarquia entre caminhos" ao
invés de interpretar tudo como uma mera "hierarquia entre vias".
Por exemplo, podemos encontrar pequenas exceções, como por exemplo, uma via
indubitavelmente trunk por quilômetros que se divide em um binário por
alguns metros (que pela definição representaria no máximo primary) e depois
volta a ser indubitavelmente trunk, como em Botafogo *[4]* ou talvez Vila
Velha *[5]* (entre a Terceira Ponte e a Rodovia do Sol existe um binário).
É aquilo: temos que assumir o *caminho como um todo*, senão poderíamos
classificar as trunks como motorway com exceção nos trechos em que existem
obstruções.

*[1]:*
http://wiki.openstreetmap.org/wiki/Pt-br:Guia_de_Mapeamento_do_Territ%C3%B3rio_Brasileiro
*[2]: *http://osm.org/go/PA50uOgVo
*[3]: *http://osm.org/go/OVe9aNdN
*[4]:* http://osm.org/go/OVcxz6Q1
*[5]: *http://osm.org/go/PA8i3Ghh
*: Já posso adiantar as BRs 040, 101, 116 e 262 como candidatas à lista.
___
Talk-br mailing list
Talk-br@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Dúvidas quanto ao mapeamento de trevos

[Pedro Geaquinto]

Foi bom terem levantado essa discussão.

Bom, eu já meio que "estudei" as convenções mundo afora, e em certas
combinações de tipos de highway isso é bem complexo mesmo, muitas vezes a
escolha da tag fica por critério do mapeador. Então comecei a refletir e
fiz um pequeno tutorial sobre links e hierarquias. [1]

Ainda está incompleto, porque existem outras exceções à idéia de
"hierarquia entre caminhos" que é a doutrina que sigo quando mapeio
estradas e ruas. São alguns binários viários incomuns. Isso acontece
principalmente por falta de construção de infra-estrutura pelo governo, ou
às vezes por outras limitações que impossibilitam a construção (técnicas,
ecológicas, sociais...).

Também gostaria de dizer que discordo da definição de vias "trunk" em meio
rural. Não podem ser vias não duplicadas! Imagine uma auto-estrada
duplicada importante que a um certo momento vai pra via simples:
simplesmente teria que passar de "motorway" para "primary", o que é
desencorajado em ferramentas como o Keep it Right (motorway só se ligaria
com trunk, motorway_link e service). Ou seja, estamos oficialmente fora de
uma das poucas convenções globais do OSM.

Um abraço. Vejam abaixo o tutorial que fiz:

[1]: http://i.imgur.com/xpuqmgm.gif

Em 30 de janeiro de 2013 17:24, Gerente de Sistemas escreveu:

> Alguém da lista tem mestrado em engenharia de tráfego?
> A Cartografia do Exército está envolvida na lista e nos trabalhos?
> É possível envolver alguém com estas características?
>
>
> Em 30 de janeiro de 2013 14:35, Tymon Douglas 
> escreveu:
>
> Muito obrigado pela ajuda! Vou seguir esse padrão de hoje em diante.
>>
>> Em 30 de janeiro de 2013 14:11, Bráulio escreveu:
>>
>> (O Leandro foi mais rápido, mas como eu já tinha quase terminado de
>>> redigir...)
>>>
>>> Tymon,
>>>
>>> Do jeito que você fez o roteamento não funciona corretamente. Por
>>> exemplo, quem vem da estrada de terra e quer virar à esquerda na direção
>>> sudeste tem que dar essa volta toda:
>>>
>>> http://i.imgur.com/7O8iok1.jpg
>>>
>>> Então o correto seria assim:
>>>
>>> http://i.imgur.com/zDYkv3N.jpg
>>>
>>> Fica meio torto, mas não tenho uma ideia melhor de como mapear. O ideal
>>> seria o OSM e os roteadores terem suporte a estradas mapeadas como áreas,
>>> mas ainda estamos longe disso.
>>>
>>> Bráulio Bezerra
>>>
>>>
>>> 2013/1/30 Leandro Motta Barros 
>>>
 Boa tarde, Tymon!

 Só para facilitar caso alguém mais queira participar da discussão,
 creio que estejas falando deste trevo aqui:
 http://osm.org/go/M42Gszri~--

 (O que eu vou dizer abaixo é  o que eu costumo fazer; não é
 necessariamente "O Jeito Certo". Vamos conversando :-) )

 Eu teria mapeado um pouco diferente. Dá uma olhada nessa outra rótula
 ali perto (que acho que fui eu que mapeei em detalhes há um tempo
 atrás): http://osm.org/go/M4zeq4tIH--

 Principais diferenças:

 1) Eu sempre penso no link como sendo algum tipo de "transição".
 Imagine alguém andando pela 471/392 e passando pelo trevo. Ele não
 saiu da estrada primária 471/392. Pelo teu mapeamento, alguém indo
 pela 471/392 teria saído por um momento da rodovia primária, entrado
 num link, e retornado à primária. Eu não acho que seria nenhum absurdo
 considerar o trevo um link (como fizestes), mas, para mim, a ideia de
 que "a pessoa não deixou a estrada primária" é mais forte.

 2) Esse é um pouco mais grave: Imagine alguém cruzando o trevo no
 sentido indo de Canguçu-Pelotas. Ele consegue simplesmente cruzar o
 trevo sem desviar o caminho para fora da 471/392, certo? Mas vai
 seguindo cada um dos trechos de caminho, respeitando todos os
 "oneway", tais como estão mapeados ali. O cara teria que sair da
 rodovia principal, entrar na via de acesso a Morro Redondo, fazer um
 retorno e só depois retomar a 471/392. (Deu para entender? Não sei se
 a minha explicação foi clara.)  É exatamente isso que um sistema de
 roteamento faz (num GPS automotivo, por exemplo), então esse
 mapeamento como está vai causar uma certa confusão nestes casos. É
 detalhe pequeno, mas faz a diferença.

 Mas em geral, acho que o mapeando está bem bom.

 Abraço,

 LMB

 PS: Legal ver alguém mapeando a metade sul do RS! De vez em quando
 mapeio algumas coisas por aí (tenho familiares aí pela volta), mas
 acho uma região bem carente de gente trabalhando.


 2013/1/30 Tymon Douglas :
 > Olá, estou com algumas dúvidas em relação à trevos com rótulas. Fiz
 alguns
 > refinamentos ao trevo de Morro Redondo / BR-471; BR-392, e gostaria
 de saber
 > se ficaram corretas, ou se devo mapear todos os acessos por dentro da
 > rótula. E quanto aos primary_links, todos aqueles acessos, incluindo a
 > rótula, são links?
 > ___
 > Talk-br mailing list
 > Talk-br@openstreetmap.org
 > http://lists.openst

Re: [Talk-br] Usuário Matheus Eduardo apagando coisas do mapa

[Pedro Geaquinto]

Nossa, eu estou imaginando o estrago vendo esse WDYC! hahaha
Eu lembro de uma das duas edições dele aqui no Rio que dá pra ver no WDYC.
Ele colocou natural=wood para a APA da Urca (onde fica o Pão de Açúcar) [1].
E eu pensei em reverter/detalhar e mandar uma mensagem, mas nem liguei na
época e deixei pra lá.

Mas dá uma tristeza mesmo, eu mesmo gastei uns dias refinando e detalhando
a BR-101 sobretudo no ES e no RJ...

[1]: http://osm.org/go/OVcx_htt

Em 29 de janeiro de 2013 09:57, Bráulio  escreveu:

> Até um tempo atrás ele não parecia simplesmente ter má intenção. Mas
> depois de tantos avisos, não faz mais sentido ele ter mais uma chance. E
> até suspeito que ele realmente lê as mensagens, mas muda só um pouco de
> comportamento, temporariamente.
>
> Quanto às reversões, as edições dele não são todas destrutivas, então não
> podemos simplesmente reverter tudo (fora isso seria um inferno lidar com os
> conflitos). Eu estou revertendo onde eu encontro remoções, já que ele quase
> sempre deixa um rastro, pois quase nunca apaga tudo completamente. Porém, é
> bom dar uma olhada em todas as edições dele que têm muitas remoções. As
> ferramentas do OSM para fazer isso ainda não são tão fáceis de usar, mas
> acho que é o melhor a se fazer. E pelo menos as edições dele estão
> concentradas no RN, que é um estado pequeno [1]. Mas também é bom dar uma
> olhada nos outros lugares.
>
> Fora isso, falta convencer a OSMF de que o bloqueio deve ser permanente.
> Depois disso ficarei de olho, caso ele crie outro usuário.
>
> [1]
> http://yosmhm.neis-one.org/?zoom=3&lat=-18.12115&lon=-51.62256&layers=B0T&u=Matheus%20Eduardo
>
>
> 2013/1/29 George Silva 
>
>> Depois de tantas edições destrutivas, duvido que seja um simples "erro".
>>
>>
>>
>>
>> 2013/1/29 Gerald Weber 
>>
>>> Eu mandei mensagem para ele explicando o problema que ele está causando
>>> e colocando na mensagem o meu email pessoal para contato.
>>>
>>> Sugiro que mais gente faça isto. Vamos partir do pressuposto que ele
>>> esteja atuando na melhor das intenções, mas só não sabe como interagir com
>>> o sistema já que todas as mensagens são em inglês.
>>>
>>> quem sabe ele se toca
>>>
>>> abraço
>>>
>>> Gerald
>>>
>>>
>>> On 29 January 2013 08:48, Nelson A. de Oliveira wrote:
>>>
 Um novo bloqueio foi aplicado, mas igual ao anterior (ativo até que
 ele faça login): http://www.openstreetmap.org/user_blocks/308

 ___
 Talk-br mailing list
 Talk-br@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-br

>>>
>>>
>>> ___
>>> Talk-br mailing list
>>> Talk-br@openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-br
>>>
>>>
>>
>>
>> --
>> George R. C. Silva
>> SIGMA Consultoria
>> 
>> http://www.consultoriasigma.com.br/
>>
>> ___
>> Talk-br mailing list
>> Talk-br@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-br
>>
>>
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-br
>
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Usuário Matheus Eduardo apagando coisas do mapa

[Pedro Geaquinto]

Infelizmente, ele está fazendo essas coisas por todo o Brasil.
Percebi que ele apagou a ref=BR-101 de toda a rodovia no estado do RJ,
deixando apenas as outras tags.
___
Talk-br mailing list
Talk-br@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Nível administrativo 9 (distritos) no OSM

[Pedro Geaquinto]

Eu e o Arlindo (Nighto) estamos começando um projeto de importação das
fronteiras (das Regiões Administrativas "9" e Bairros "10") do Rio de
Janeiro. Ainda está bem no comecinho. :)
Veja o link:
http://wiki.openstreetmap.org/wiki/WikiProject_Brazil/RJ/Rio_de_Janeiro/Import_IPP

Em 13 de novembro de 2012 14:50, Aun Johnsen escreveu:

> Eu nao importei os dados direito mas desinei ecima dos arquivos .shp
>
> Aun Johnsen
> user Skippern
> sent from Android
> On Nov 13, 2012 2:29 PM, "Nelson A. de Oliveira"  wrote:
>
>> 2012/11/12 Aun Yngve Johnsen :
>> > Infelizmente nao, meu importasao do espirito santo fui proquentava
>> unico estado sem nenhuma fronteira importada. Agora trabalhando com
>> outrosmprojeitos, tambem meu tempo e muito limitada
>>
>> Você tem esse processo de importação dos limites disponível em algum
>> lugar?
>>
>> ___
>> Talk-br mailing list
>> Talk-br@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-br
>>
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-br
>
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Tag name=*

[Pedro Geaquinto]

Exato, Aun. A key "motorway_junction" ainda prevê a utilização da key
"name". Assim pode abranger não só a key "ref" (Saída 1, 2, 3, x), mas
também o nome (Saída para cidade/bairro X).
Um exemplo na Inglaterra: a "Merstnam Interchange" é a "saída 8" na
"rodovia M23": http://osm.org/go/eur8bnBEa--

E quanto ao nome "Escola" acho redundante quando já foi utilizado uma tag
referenciando a uma escola, é mais plausível colocar o nome popular da
escola (por exemplo, "Escola do Bairro X"), do que colocar apenas "Escola".

Outra discussão que queria levantar é sobre exatamente nomes que seriam
redundantes quando já utilizada a tag. Por exemplo, ao invés de usar
"Supermercado Pão de Açúcar" eu costumo colocar apenas "Pão de Açúcar", já
que acho redundante o primeiro nome, e em certos renders existe até um
símbolo para supermercado (como no Mapnik).
Acho válido colocar o nome do logradouro apenas quando ele é necessário
para fazer sentido, como "Bar do João", porque "do João" não faz sentido.
Já um bar com nome próprio, digamos "Bar Meia-noite", já faz sentido, não
sendo necessário o nome do logradouro, podendo ser utilizado
"name=Meia-noite".
Mas isso tudo ainda é questão de bom senso, podíamos estabelecer regras.
Algumas convenções são bem abrangentes para os membros mais antigos (como
evitar abreviações), mas ainda encontramos muitos membros novatos (e talvez
até alguns antigos) que não as seguem (encontramos muitos R., Av., Tv., Al.
pelos mapas brasileiros).

Um abraço.

Em 30 de setembro de 2012 12:01, Aun Yngve Johnsen
escreveu:

>
>
> On 30. sep. 2012, at 16:37, martin...@gmx.net wrote:
>
> > Olá Leandro,
> >
> >> Date: Sat, 29 Sep 2012 11:33:09 -0300
> >> From: Leandro Motta Barros 
> >> To: OSM talk-br 
> >> Subject: [Talk-br] Tag name=*
> >>
> >> Bom dia,
> >>
> >> Vejo muitos usos da tag name que eu considero inadequados. Por exemplo:
> >>
> >> 1) name=Acesso à Avenida XYZ
> > [...]
> >> Nenhum destes casos refere-se a um nome "oficial". Para mim, são
> >> claramente "tagging for the renderer". O segundo caso também é ruim
> >
> > pelo menos no no. 1) pode ser você quem está errado (e poderia se
> preocupar menos): Aqui em Florianópolis existem muitas ruas que tem uma
> placa oficial com nome exatamente assim. Por favor não apague esses dados.
> Não importa se existe alguma lei com esse nome ou não. Se está na placa, é
> um nome no sentido de OSM. O maior problema é que nenhum editor do OSM (e
> nem o sistema em si) exige fontes, então em muitos casos não dá para saber
> de onde o colega tirou o nome.
> >
> > Nomes como "Escola" podem ser incompletos mas não sei se isso justifica
> apagá-los. Se alguém passa de carro e só vê uma placa "Escola..." sem
> conseguir ler o nome completo, ele pode achar melhor colocar o nome
> "Escola" (com algum fixme ou note) que nenhum. Mas certo, sem fonte não dá
> para verificar esta história. Se "Retorno" é um nome, não sei. Sem dúvida é
> uma informação que não devia ser apagada mas no máximo ser colocada num
> outro tag. Às vezes tem "Saída 1" e "Saída 2", por exemplo. Esses não são
> nomes? Sem dúvida a informação é ainda mais útil que o "Retorno".
> >
> > Em cidade que não conheço só corrijo erros realmente óbvios e tento não
> apagar dados neste processo. O resto deixaria para o grupo local.
> Infelizmente poucas cidades têm um wiki ou pelo menos um contato. Correções
> regulares no país todo usando um bot, por exemplo, deviam ser documentados
> no wiki.
>
> Em caso do "Saída 1" poder usar o tag highway=motorway_junction + ref=1
>
> Eu acho melhor usar alt_name=Retorno onde nao tem placas indicando o nome
> de rua e assim (um placa verde com "Retorno" nao significando o nome de rua)
>
> Eu ja criei paginas no wiki do muitos cidades, se alguns tem informacao
> specifico do cidades voces mapeando, poder adiciona-lo no wiki
>
> Aun Y. Johnsen
> Sent from my iPad
> +55 (27) 9736-3919 (vivo)
>
> >
> > Martin
> >
> > ___
> > Talk-br mailing list
> > Talk-br@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-br
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-br
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Importação IBGE de 2009

[Pedro Geaquinto]

Aqui no RJ, dei uma refinada nas rodovias da Região dos Lagos. Inclusive
elevei a Rodovia Amaral Peixoto de primary para trunk e a Via Lagos de
trunk para motorway, porque ambas tem grande importância para o estado e a
segunda é totalmente segregada.
___
Talk-br mailing list
Talk-br@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Imobiliaria

[Pedro Geaquinto]

Mas nesse caso (key:building) seria para um edifício só, como anexos de
condomínios, edifícios-garagem e casos parecidos. O mais próximo da
garagens de cooperativas de ônibus acho que seria a tag landuse=garages (
http://wiki.openstreetmap.org/wiki/Tag:landuse=garages), que foi criada
para um tipo de uso de solo para estacionamento de uso diverso aos
estacionamentos tradicionais (públicos). Nesse caso, acho que está sendo
utilizada apenas nos países da antiga URSS para "garagens comunitárias"
(são privadas, não confundir com públicas).

Acho que seria interessante nós brasileiros agregarmos esse valor de
"garagens privadas" à tag, que está bem específica para esse uso de países
da antiga URSS até agora.
Podemos até conversar com o pessoal de lá e editar a wiki, o que acham?

Em 25 de julho de 2012 10:44, Leandro Motta Barros
escreveu:

> 2012/7/25 Tulio Magno Quites Machado Filho :
> > 2012/7/25 Pedro Geaquinto :
> >> Também surgiram umas dúvidas aqui. Qual tag utilizar para
> guaritas/quiosques
> >> policiais e para garagens de ônibus?
> >
> > [...]
> >
> > Acredito que garagens de ônibus devem ser mapeadas como amenity=parking.
> > Provavelmente vc deve ter interesse em usar também a tag
> > access=private para indicar que a garagem não é aberta ao público em
> > geral.
>
> A wiki ( http://wiki.openstreetmap.org/wiki/Key:building ) sugere usar
> building=garage em prédios usados como garagem. Em
> http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking chegam dizer
> para usar building=garage *ao invés* de amenity=parking nestes casos.
>
> LMB
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-br
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Imobiliaria

[Pedro Geaquinto]

Também surgiram umas dúvidas aqui. Qual tag utilizar para
guaritas/quiosques policiais e para garagens de ônibus?

Em 6 de junho de 2012 21:31, vitor  escreveu:

> Oi Eduardo,
>
> Segundo o Taginfo, as pessoas estão utilizando as tags *
> 'shop=estate_agent'* e *'office=estate_agent'*:
>
> http://taginfo.openstreetmap.org/search?q=estate#values
>
> No wiki ainda não existe um consenso sobre qual é a correta, mas está
> pendendo mais para *'shop=estate_agent'*. Eu usaria esta.
>
>
> Vitor George
> mapaslivres.org
> twitter.com/mapaslivres
>
>
>
>
> On Wed, Jun 6, 2012 at 2:45 PM, Eduardo Medeiros <
> eduardoamedei...@gmail.com> wrote:
>
>> Alguém já registrou uma imobiliária? Utilizou o office=estate_agent?
>>
>> []s,
>>  Eduardo Medeiros
>>
>> ___
>> Talk-br mailing list
>> Talk-br@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-br
>>
>
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-br
>
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Classificação de vias

[Pedro Geaquinto]

Essa discussão tá interessante!

Um problema em se usar as imagens aéreas (como o Aun sugeriu) para
distinguir vias asfaldas e não-asfaltadas é que muitas vezes houve uma
obra entre a data da fotografia e os dias atuais, ou então a imagem
tem saturação muito alta e não dá pra distinguir estrada de chão de
paralelepípedo, pisos intertravados, etc.
Eu desisti de colocar a tag surface=* nas ruas de Marataízes-ES [1]
por causa disso, quando vou lá pessoalmente às vezes tem muitas ruas
que estão diferentes.

Já em áreas mais metropolitanas ainda tenho minhas dúvidas. Por
exemplo, tudo bem que trunk na cartilha é para vias duplicadas, mas
não serveriam para binários de ligam duas vias duplicadas?
E ainda existem bairros com ruas que podem ter várias interpretações
e, sinceramente, não sei o que fazer. Vou dar o exemplo de onde edito,
no Rio de Janeiro, onde há muito o caso de múltiplas interpretações,
já que existem muitos "bairros de passagem" pela própria geografia:

Em Copacabana [2], existe um binário (Barata Ribeiro/Nossa Senhora de
Copabana) e uma via duplicada (Av. Atlântica) de velocidades
semelhantes (60/70). Pela cartilha, o binário pode variar de tertiary
até primary e Av. Atlântica de tertiary (por ter maior vocação
turística) até trunk. Nos bairros vizinhos de Ipanema e Leblon, a
situação é parecida por terem o mesmo dilema binário + via duplicada
turística.

Ainda em Copacabana, existem alguns dilemas tertiary-secondary como:
- Av. Henrique Dodsworth (Corte do Cantagalo) [3]: liga Copacabana à
Lagoa, mas serve até para Ipanema.
- Túnel Velho + binário Siqueira Campos - Figueiredo de Magalhães [4]:
liga Copacabana a Botafogo, mas serve para todos que tem como destino
bairros após Copacabana.

1: http://www.openstreetmap.org/?lat=-21.052&lon=-40.8272&zoom=13&layers=M
2: http://www.openstreetmap.org/?lat=-22.9712&lon=-43.1841&zoom=14&layers=M
3: http://www.openstreetmap.org/?lat=-22.976794&lon=-43.195811&zoom=18&layers=M
4: http://www.openstreetmap.org/?lat=-22.9643&lon=-43.18969&zoom=17&layers=M

Em 15/06/12, Aun Yngve Johnsen escreveu:
> Eu poder dar um luz ai,
>
> Depende do fonte o classificacão das estradas e bem dificil.
> * Ate agora eu não teve como dividir meus trilhas gpx por areas asfaltadas e
> areas não asfaltadas, mas maioria dos meus trilhas gpx e dos estradas
> asfaltadas.
> * mapeamento por Bing e outros fontes com imagens aereal e mais fazil
> identificar onde e asfaltadas e onde e não, mas e dificil identificar se e
> um estrada principal ou não
> * mapeamento com fontes importadas as vezes tem informação adicional que
> poder por exemplo identificar areas asfaltadas ou não e também poder
> identificar que e estradas principal, secundario, etc.
>
> Eu acho que, afore dos estradas principais como BR-101, cohencimento local e
> necesario para identificar as ruas  mais certo. A gente mapeando sem este
> precicar mapear por um padrao, e os locais ajuda com asertar os dados
> depois
>
> Aun Y. Johnsen
> Sent from my iPad
>
> On 15. juni 2012, at 18:13, Arlindo Pereira
>  wrote:
>
>> Pois é. Na verdade, ela é subjetiva por ser uma classificação oficial da
>> Inglaterra, onde o OpenStreetMap surgiu.
>>
>> Acho a solução de colocar a observação razoável, embora não a ideal. Não
>> deixando de colocar as tags surface=* apropriadas, não vejo porque seria
>> um problema.
>>
>> Infelizmente isso é um bocado fora da minha realidade pois vivo na cidade
>> grande, não dirijo, viajo de ônibus ou de avião etc., meu mapeamento é
>> 100% metropolitano.
>>
>> []s
>>
>> 2012/6/15 Gerald Weber 
>> Olá
>>
>> eu concordo totalmente que não se deva colocar tags incorretas apenas para
>> fazer aparecer num dado renderizado alguma coisa específica, e nem sequer
>> proponho isto. Até porque seria inútil, já que cada renderizador mostra as
>> coisas do jeito que quer.
>>
>> O que me chama a atenção no entanto é que a classificação da via
>> (tertiary, secondary etc) é subjetiva e nem sequer tão útil, mas é
>> mostrada. Por outro lado não se dá ao usuário qualquer dica de que ele
>> está olhando para uma estrada de terra e não de asfalto. Em todos os mapas
>> que eu conheço esta é a informação mais elementar que existe. No mapnik e
>> todos os outros renderizadores que vi esta informação inexiste.
>>
>> Uma maneira de contornar isto seria adicionar ao nome da estrada "terra"
>> ou "em terra". Eu vejo isto nos mapas do tracksource e acho bem efetivo
>> pois garante que a informação é transmitida independente do renderizador.
>> Tipo name="BR 123 (em terra)"  nos trechos apropriados. Não compromete
>> nada e passa a informação garantidamente.
>>
>> Afinal de que serve colocar todo o esforço em mapear e depois uma
>> informação tão crucial fica simplesmente perdida?
>>
>> Enfim, se me permite emprestar a frase: "don't tag for the renderer, map
>> for the user" ;)
>>
>> abraço e bom final de semana
>>
>> Gerald
>>
>>
>> 2012/6/15 Arlindo Pereira 
>> Me parece que isso é problema do renderizador (leia-se, do Mapnik),

Re: [Talk-br] Mapping in Rio de Janeiro

[Pedro Geaquinto]

I'd like to help you too.
What do you think about micromapping Copacabana? It's a really...
intense neighborhood.



2012/6/7, Arlindo Pereira :
> Hi Alex! I live in Rio, and I'm willing to do it. Where are you going to
> stay here? We could come up with some micromapping for the area. I could
> trace the roads before, if necessary.
>
> By the way, June 17 is sunday :P
>
> Cheers,
> Arlindo "Nighto" Pereira
>
> On Thu, Jun 7, 2012 at 2:49 PM, Alex Barth  wrote:
>
>> Hello friends -
>>
>> I'll be in Rio from June 17 to Jun 21 (partly for Rio+20 UN conference) -
>> anybody up for doing walking papers maybe June 17, Saturday afternoon?
>> Open
>> to suggestions as to where specifically, but there seems to be plenty of
>> work around :)
>>
>> Alex Barth
>> http://twitter.com/lxbarth
>> tel (+1) 202 250 3633
>>
>>
>>
>>
>>
>> ___
>> Talk-br mailing list
>> Talk-br@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-br
>>
>

___
Talk-br mailing list
Talk-br@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Importando a Floresta da Tijuca (RJ)

[Pedro Geaquinto]

Oi Eduardo,
É tudo aberto na internet, aí vão uns links interessantes:

http://portalgeo.rio.rj.gov.br/ipp_viewer/?config=cadlog.xml
http://mapas.rio.rj.gov.br/#
http://www.armazemdedados.rio.rj.gov.br/

Eu geralmente consulto e edito manualmente os dados, para a floresta
em particular eu uso o JOSM+Picture Layer. Tem o município inteiro,
infelizmente não é toda a Região Metropolitana.

Já adicionei as pedreiras da cidade e em boa parte da AP1 as elevações
e picos, muitas vezes com auxílio de mapas históricos. Se quiser eu te
passo esses mapas antigos por mail.

Quanto a importação direta das informações, não sei fazer. Acho que o
Arlindo (Nighto) sabe. Não existem muitos cariocas no OSM, então acho
que não existem tutoriais.

Poderíamos fazer uns mapping parties, o que acha? A Zona Oeste em
geral tem poucos nomes de ruas adicionados, os parques estão pouco
detalhados e poucas partes tem micro mapping. Eu moro na Tijuca.

Um abraço

Em 06/06/12, Eduardo Medeiros escreveu:
> Pedro,
>   que base é essa do IPP? Foi fácil conseguir? Tem do município
> inteiro? Aproveitando existe algum tutorial para importação dessas
> informações?
>
> []s,
>   Eduardo Medeiros
>
>
> Em 6 de junho de 2012 01:12, Pedro Geaquinto 
> escreveu:
>> Olá pessoal, estou adicionando as camadas landuse=* para a Floresta da
>> Tijuca aqui no Rio de Janeiro pelo JOSM. Estou importando manualmente
>> com auxílio do arquivo de dados da Prefeitura (Instituto Pereira
>> Passos) e das imagens do Bing.
>>
>> Para ver: http://osm.org/go/OVcbsP_
>>
>> Estou fazendo isso aos poucos porque é MUITA coisa, mas o grosso que
>> era o contorno externo da floresta eu já fiz.
>> Para melhor organização, dividi em 6 setores: Pretos Forros, Pedra da
>> Gávea, Alto da Boa Vista, Serra da Carioca, Leste e Serra da Tijuca.
>> Já terminei os dois primeiros setores e criei o setor Leste para a
>> parte do Bing mais zoada com as nuvens, mas dá pra contornar numa boa.
>>
>> Eu já fiz uma relação multipolygon para suportar os enclaves em geral
>> no meio da floresta: residências e favelas (residential), pedras das
>> montanhas (sem tag), descampados (meadow), fazendas (farm), parques
>> (leisure=park), ...
>>
>> As tags que utilizei foram landuse=forest, natural=wood,
>> tourism=attraction, name e source. Usei tanto 'wood' quanto 'forest'
>> porque não dá pra saber exatamente onde a floresta é nativa e onde é
>> reflorestada, já que o reflorestamento remete ao século XIX. Diz a
>> lenda que foram apenas 9 escravos que reflorestaram tudo!
>>
>> Um abraço!
>>
>> PS: É a primeira vez que estou postando aqui.
>>
>> ___
>> Talk-br mailing list
>> Talk-br@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-br
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-br
>

___
Talk-br mailing list
Talk-br@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Importando a Floresta da Tijuca (RJ)

[Pedro Geaquinto]

Olá pessoal, estou adicionando as camadas landuse=* para a Floresta da
Tijuca aqui no Rio de Janeiro pelo JOSM. Estou importando manualmente
com auxílio do arquivo de dados da Prefeitura (Instituto Pereira
Passos) e das imagens do Bing.

Para ver: http://osm.org/go/OVcbsP_

Estou fazendo isso aos poucos porque é MUITA coisa, mas o grosso que
era o contorno externo da floresta eu já fiz.
Para melhor organização, dividi em 6 setores: Pretos Forros, Pedra da
Gávea, Alto da Boa Vista, Serra da Carioca, Leste e Serra da Tijuca.
Já terminei os dois primeiros setores e criei o setor Leste para a
parte do Bing mais zoada com as nuvens, mas dá pra contornar numa boa.

Eu já fiz uma relação multipolygon para suportar os enclaves em geral
no meio da floresta: residências e favelas (residential), pedras das
montanhas (sem tag), descampados (meadow), fazendas (farm), parques
(leisure=park), ...

As tags que utilizei foram landuse=forest, natural=wood,
tourism=attraction, name e source. Usei tanto 'wood' quanto 'forest'
porque não dá pra saber exatamente onde a floresta é nativa e onde é
reflorestada, já que o reflorestamento remete ao século XIX. Diz a
lenda que foram apenas 9 escravos que reflorestaram tudo!

Um abraço!

PS: É a primeira vez que estou postando aqui.

___
Talk-br mailing list
Talk-br@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-br