Re: [Talk-br] Proposta de padronização de lombadas no Brasil
Olha, vendo essa etiqueta traffic_calming=table, eu vou segurar a minha proposta por um bom tempo até conseguir investigar melhor essa situação. A pergunta é: existe alguma lombada de 3+ metros que não seja um traffic_calming=table? (ou seja, que não tenha o topo achatado). Sinceramente, nunca vi, e olha que já vi uns 4-5 traffic_calming=table aqui na minha cidade. Estou pensando que traffic_calming=bump é menor que 1,5m, mas vou tirar umas fotos aqui pra montar melhor o meu caso (isso vai demorar umas duas semanas pelo menos). Quando às depressões, acho que teria que ser proposto uma nova etiqueta ( traffic_calming=depression ou algo assim). Alguém tem uma foto dela? Abs, João Em 25 de fevereiro de 2014 18:46, Arlindo Pereira < openstreet...@arlindopereira.com> escreveu: > Acho que as depressões poderiam ser bump/hump com depression=yes ou algo > assim, visto que é a mesma função. > > Ou propor um valor traffic_calming=depression. O que vocês acham? > > Tenho essa foto aqui, que não mostra a depressão em si mas dá uma ideia, > hehe. > > > > Isso foi em Foz do Iguaçu :P > > Procurar por "depressão na pista" no Google Imagens retorna resultados > semelhantes. :P > > []s > Arlindo > > 2014-02-25 16:54 GMT-03:00 Marcelo Pereira : > >> Considerações, minhas : >> >> - Aqui pros lados do NE tb é conhecida como quebra-molas. >> >> - Já vi muitos casos de lombadas feitas pela própria população, nota-se a >> diferença pela total falta de padrão, mas estas tendem a ser mais altas que >> as "oficiais", já vi até "triangulares" ( exemplo http://goo.gl/RC3ogE). >> Neste caso, que tag usar ? >> >> - Já vi lombadas de terra, em vias do mesmo tipo, e aí ? >> >> - Aqui perto de casa, tem uma lombada mais larga, que traz no seu corpo >> uma faixa de pedestres ( exemplo http://goo.gl/16S98g ), como se >> classificaria isso ? >> >> Aproveitando o embalo, não sei se ainda existem, mas cheguei a ver >> lombadas invertidas, ou seja, depressões na pista usadas como lombadas. >> Isso recebe tag ? >> >> Marcelo Pereira >> >> >> Em 25 de fevereiro de 2014 16:06, Fernando Trebien < >> fernando.treb...@gmail.com> escreveu: >> >> Por mim tá perfeito. >>> On Feb 25, 2014 3:38 PM, "John Packer" wrote: >>> Pessoal, em uma discussão recente aqui na lista, percebi que tem duas formas diferentes de etiquetar uma lombada: traffic_calming=bump e traffic_calming=hump. Vi que não havia uma padronização quanto a isso no Brasil, então levantei as mangas e comecei a pesquisar. Em primeiro lugar descobri que tem outros nomes para uma lombada: - lomba (que é sinônimo de lombada) - quebra-mola (que é utilizado no RS) - ondulação transversal (que é um termo mais abrangente) E descobri que existem sim dois tipos de lombada: *Tipo I* e *Tipo II*. Como podem ver no seguinte link: http://www.cliqueautomotivo.com.br/index.php?pg=sobrerodas/lombada-ou-quebra-molas O tipo 1 é menor que o tipo 2, mas é também mais curto, forçando o usuário a reduzir mais a velocidade do que no tipo 2. Nas definições de *Bump* que vi, era assim mesmo, com a única diferença sendo que *Bump* poderia ter uma altura maior do que *Hump*em alguns casos. Logo, a minha proposta de padronização é a seguinte: - em lombadas Tipo I => traffic_calming=bump - em lombadas Tipo II => traffic_calming=hump - se não se encaixar em um desses tipos, deve ser etiquetado o mais próximo, de acordo com o *comprimento* Abs, João ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br >>> ___ >>> Talk-br mailing list >>> Talk-br@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/talk-br >>> >>> >> >> >> -- >> >> ... Edileuz, eu não tem nada a ver com Creuza, >>É mentira da Ivete, não é meu esse caniveete... >> "Halley, Luiz" - Poeta, Cantor, Compsitor >> >> ___ >> 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] Problema de usabilidade do editor de endereços do iD
Atualização: O campo addr:housename foi retirado do iD, agora só pode ser incluído manualmente usando etiquetas. Um usuário (não-brasileiro) retirou o campo depois de ver que estava confundindo usuários em outros países. O *pull request* se encontra no seguinte link: https://github.com/openstreetmap/iD/pull/2127 Sugiro agora retirar a tradução de addr:housename como Complemento. Abs, João ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Nomes antigos
Isso vale para outras tags que possam ter mais de um valor, como alt_name (nomes populares pelos quais a via é conhecida), phone etc. []s 2014-02-26 21:04 GMT-03:00 Paulo Carvalho : > Valeu! > > > Em 26 de fevereiro de 2014 21:01, Arlindo Pereira < > openstreet...@arlindopereira.com> escreveu: > > Basta separar os valores por "; ". Por exemplo: >> http://www.openstreetmap.org/way/130347317#map=18/-22.90260/-43.17552 >> >> []s >> Arlindo >> >> 2014-02-26 20:57 GMT-03:00 Paulo Carvalho : >> >>> Pessoal, >>> >>> Sei que existe a tag old_name. É possível registrar nomes mais >>> antigos? Ex.: aqui no Rio a Av. Lúcio Costa já foi chamada Av. >>> Sernambetiba, que por sua vez já foi chamada Av. Litorânea, seu nome >>> original. >>>O bairro onde moro, por exemplo, já teve 3 nomes. Outros bairros do >>> Rio já tiveram mudança de nomes semelhante. >>> >>> []s >>> >>> Paulo >>> >>> ___ >>> 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] Nomes antigos
Valeu! Em 26 de fevereiro de 2014 21:01, Arlindo Pereira < openstreet...@arlindopereira.com> escreveu: > Basta separar os valores por "; ". Por exemplo: > http://www.openstreetmap.org/way/130347317#map=18/-22.90260/-43.17552 > > []s > Arlindo > > 2014-02-26 20:57 GMT-03:00 Paulo Carvalho : > >> Pessoal, >> >> Sei que existe a tag old_name. É possível registrar nomes mais >> antigos? Ex.: aqui no Rio a Av. Lúcio Costa já foi chamada Av. >> Sernambetiba, que por sua vez já foi chamada Av. Litorânea, seu nome >> original. >>O bairro onde moro, por exemplo, já teve 3 nomes. Outros bairros do >> Rio já tiveram mudança de nomes semelhante. >> >> []s >> >> Paulo >> >> ___ >> 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] Nomes antigos
Basta separar os valores por "; ". Por exemplo: http://www.openstreetmap.org/way/130347317#map=18/-22.90260/-43.17552 []s Arlindo 2014-02-26 20:57 GMT-03:00 Paulo Carvalho : > Pessoal, > > Sei que existe a tag old_name. É possível registrar nomes mais > antigos? Ex.: aqui no Rio a Av. Lúcio Costa já foi chamada Av. > Sernambetiba, que por sua vez já foi chamada Av. Litorânea, seu nome > original. >O bairro onde moro, por exemplo, já teve 3 nomes. Outros bairros do > Rio já tiveram mudança de nomes semelhante. > > []s > > Paulo > > ___ > 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] Nomes antigos
Pessoal, Sei que existe a tag old_name. É possível registrar nomes mais antigos? Ex.: aqui no Rio a Av. Lúcio Costa já foi chamada Av. Sernambetiba, que por sua vez já foi chamada Av. Litorânea, seu nome original. O bairro onde moro, por exemplo, já teve 3 nomes. Outros bairros do Rio já tiveram mudança de nomes semelhante. []s Paulo ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Plugin confaltion do JOSM
Marcelo, abra um ticket sobre esses problemas: http://josm.openstreetmap.de/newticket Erro de introspecção já é difícil de diagnosticar sendo conhecedor do código, imagine sendo de fora... não trave com isso, passa para frente. Se alguém mais vir esses erros de Java aparecendo, não percam tempo tentando adivinhar, contate os desenvolvedores. Em 26 de fevereiro de 2014 16:53, Marcelo Pereira escreveu: > Srs, > > Desculpem a demora em responder, estava enrolado em achar o Java 6 para > instalação. > > Pois bem. > > Instalei o Ubuntu do zero, com o java 6. > Usei os JOSMs 6502, 6409 e 6296 > > Sempre com o mesmo erro, consigo até listar os erros encontrados nos > mapas, mas na hora de conflacionar, erro!!! > > Aliás, na versão 6296 o conflation nem carregou, deu pau na inicialização. > > Se alguem tiver uma combinação JOSM + JAVA funcional, por favor me avise. > > Ou outra ferramenta que faça a mesma coisa. > > Agradeço às dicas recebidas, > > Att, > > Marcelo Pereira > > > > > Em 24 de fevereiro de 2014 19:13, Paulo Carvalho < > paulo.r.m.carva...@gmail.com> escreveu: > >> Pode ser mesmo biblioteca incompatível. Agora qual eu não sei. Estou >> sem condição de investigar isso. Estou com coisas mais fundamentais para >> investigar como a compilação com mkgmap. >> >> >> Em 24 de fevereiro de 2014 16:31, Fernando Trebien < >> fernando.treb...@gmail.com> escreveu: >> >> Esses erros de introspecção já foram relatados no bug tracker do >>> plugin, mas o desenvolvedor parece ter meio que abandonado o projeto, >>> ou pelo menos não o estar priorizando (afinal, se funciona com Java >>> 6...). Lembro vagamente de ter lido algum stack trace que sugeria que >>> o erro acontece numa das bibliotecas de que o plugin depende, uma das >>> usadas para calcular a semelhança topológica entre as duas malhas. >>> >>> 2014-02-22 15:22 GMT-03:00 Paulo Carvalho >> >: >>> > Faz sentido usar JOSMs mais antigos. O erro postado pelo Marcelo >>> parece ser >>> > um erro de introspecção (erro de funcionamento interno). A grosso >>> modo o >>> > plugin não está falando a mesma língua do framework (JOSM). O >>> desenvolvedor >>> > do plugin de conflação deve dar uma olhada nas APIs novas e removidas >>> do >>> > JOSM. >>> > >>> > >>> > Em 22 de fevereiro de 2014 12:40, Erick de Oliveira Leal >>> > escreveu: >>> > >>> >> Marcelo, vai testando com esses JOSMs mais antigos: >>> >> http://josm.openstreetmap.de/download/Archiv/ >>> >> >>> >> Vai tentando com intervalos de 2 em 2 meses pra ser mais rapido >>> >> >>> >> >>> >> Em 22 de fevereiro de 2014 12:35, Marcelo Pereira >>> >> escreveu: >>> >> >>> >>> Erick, >>> >>> >>> >>> Obrigado pela ajuda, segue o erro apresentado >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> ERROR: java.lang.NoSuchMethodError: >>> >>> >>> org.openstreetmap.josm.command.AddPrimitivesCommand.(Ljava/util/List;Lorg/openstreetmap/josm/gui/layer/OsmDataLayer;)V >>> >>> java.lang.NoSuchMethodError: >>> >>> >>> org.openstreetmap.josm.command.AddPrimitivesCommand.(Ljava/util/List;Lorg/openstreetmap/josm/gui/layer/OsmDataLayer;)V >>> >>> at >>> >>> >>> org.openstreetmap.josm.plugins.conflation.ConflateMatchCommand.(ConflateMatchCommand.java:42) >>> >>> at >>> >>> >>> org.openstreetmap.josm.plugins.conflation.ConflationToggleDialog$ConflateAction.conflateMatchActionPerformed(ConflationToggleDialog.java:570) >>> >>> at >>> >>> >>> org.openstreetmap.josm.plugins.conflation.ConflationToggleDialog$ConflateAction.actionPerformed(ConflationToggleDialog.java:547) >>> >>> at >>> >>> >>> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2018) >>> >>> at >>> >>> >>> javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2341) >>> >>> at >>> >>> >>> javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402) >>> >>> at >>> javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259) >>> >>> at >>> >>> >>> javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:252) >>> >>> at >>> >>> >>> java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:289) >>> >>> at java.awt.Component.processMouseEvent(Component.java:6505) >>> >>> at javax.swing.JComponent.processMouseEvent(JComponent.java:3320) >>> >>> at java.awt.Component.processEvent(Component.java:6270) >>> >>> at java.awt.Container.processEvent(Container.java:2229) >>> >>> at java.awt.Component.dispatchEventImpl(Component.java:4861) >>> >>> at java.awt.Container.dispatchEventImpl(Container.java:2287) >>> >>> at java.awt.Component.dispatchEvent(Component.java:4687) >>> >>> at >>> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4832) >>> >>> at >>> java.awt.LightweightDispatcher.processMouseEvent(Container.java:4492) >>> >>> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4422) >>> >>> at java.awt.Container.dispatchEventImpl(Container.java:2273) >>> >>> at java.awt.Window.dispatchEventImpl(Window.java:2719) >>> >>> at java.awt.Component.dispatchEvent(Compone
Re: [Talk-br] Como mapear numeração de ruas?
Já tinha mandado o link haha. E tinha pedido para ele quando ele falou que não conseguiu. Acho que vou pedir de novo mais pra frente. Em 25 de fevereiro de 2014 21:19, Fernando Trebien < fernando.treb...@gmail.com> escreveu: > Manda pra ele o link da conversa: > https://lists.openstreetmap.org/pipermail/talk-br/2014-February/thread.html > > E pede pra ele tentar ingressar de novo na lista. :D > > 2014-02-25 19:44 GMT-03:00 John Packer : > > Atualização: O meu amigo disse que não conseguiu entrar na lista. (não > > entendi muito bem o que aconteceu, mas ele não chegou a tentar > novamente). > > No final das contas, ele colocou os números das ruas como loc_ref=*. > > > > Acho que ficou apropriado. > > > > > > Em 10 de fevereiro de 2014 22:27, Wille escreveu: > > > >> Já vi em algumas cidades que nas placas com o nome da rua aparece um > >> código chamado Logradouro. Porém nunca vi nenhum caso em que esse número > >> fosse utilizado pela população ou que aparecesse nos mapas da > prefeitura. > >> > >> > >> > >> On 10-02-2014 09:29, John Packer wrote: > >> > >> Pedi clarificações para ele. Segue abaixo a resposta: > >>> > >>> Então, desde que eu era pequeno me chamava a atenção isso (não sei por > >>> quê hahahaha), e em Joinville também era comum essa prática de numerar > as > >>> ruas, mas de repente não se usou mais isso. Mas em Jaraguá as ruas > recebem > >>> números e nomes, as vezes só números. Em tudo o que se refere a ruas, > como > >>> mapas, as placas com nomes das ruas, vai o número, sempre antes do > nome. > >>> > >>> Enfim, como todas as ruas e servidões têm um número e um nome, acredito > >>> que seja um código da prefeitura, embora seja popular e bastante > utilizado, > >>> mas não sendo nem nome alternativo, nem nome antigo... não sei dizer > qual > >>> seria a tag mais adequada para essa numeração. > >> > >> > >> Fico em dúvida como proceder. > >> A minha impressão é que realmente ref é a etiqueta adequada, mas a > >> visualização do mapa fica bem inadequada... > >> Pedi para ele contactar algum mapeador ativo de Jaraguá do Sul (espero > que > >> tenha algum mapeador experiente nessa região) > >> > >> Vou pedir para ele passar o link do mapa que verificou. > >> > >> Abs, > >> João > >> > >> > >> Em 9 de fevereiro de 2014 20:32, Arlindo Pereira > >> escreveu: > >>> > >>> Se a numeração for o nome da rua (Rua 1, Rua 2 etc.) coloque "Rua Um" > na > >>> tag name e "Rua 1" na tag alt_name (ou o contrário, se preferir). A tag > >>> alt_name não aparece na renderização do mapa mas é usada pelos > serviços de > >>> busca, e poderia ser usada por roteadores GPS. > >>> > >>> Se for o nome antigo (Rua Fulano de Tal, antiga Rua 1) coloque na tag > >>> old_name. > >>> > >>> []s > >>> > >>> Em 09/02/2014 19:08, "John Packer" escreveu: > > Olá pessoal, > > Um amigo meu foi para "Jaraguá do Sul, SC" e percebeu que as ruas de > lá > tinham um número associado com elas. Ele confirmou isso vendo no mapa > da > prefeitura. > Então ele colocou esses números na etiqueta ref. Mas a renderização no > Mapnik ficou bem, digamos, inadequada. > > Como é tratado esse tipo de coisa? > Por mais que seja errado etiquetar para o renderizador, deixar como > está > não parece ser uma boa idéia. Será que podemos colocar como > "alt_name=Rua > #numero" ? > Será que deveriamos contactar algum mapeador ativo de Jaraguá do Sul? > > Abs, > João > > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br > > >>> > >>> ___ > >>> Talk-br mailing list > >>> Talk-br@openstreetmap.org > >>> https://lists.openstreetmap.org/listinfo/talk-br > >>> > >> > >> > >> > >> ___ > >> Talk-br mailing list > >> Talk-br@openstreetmap.org > >> https://lists.openstreetmap.org/listinfo/talk-br > >> > >> > >> > >> ___ > >> Talk-br mailing list > >> Talk-br@openstreetmap.org > >> https://lists.openstreetmap.org/listinfo/talk-br > >> > > > > > > ___ > > Talk-br mailing list > > Talk-br@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/talk-br > > > > > > -- > Fernando Trebien > +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 > 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] Restrições de conversão usando linha como intermediário
Pois é. Com apenas esses dois casos simples, cobríamos todo caso de restrição. Não sei porque há tantos tipos de restrições no OSM. Eu colocaria no máximo por tipo de veículo. Em 26 de fevereiro de 2014 18:38, Raffaello Bruno Limongi Freire < raffaellobr...@hotmail.com> escreveu: > Por isso que no Editor de Nós do Tracksource, de autoria do Paulo > Carvalho, as restrições eram criadas por nós. Definindo-se 3 nós (no caso > de curvas) ou 4 nós (no caso de retornos em U) dava para facilmente criar > as restrições sem ter que quebrar nada. > > Se o compilador cgpsmapper que parou no tempo entendia as restrições, > porque no mkgmap não funciona? Ou o problema não tem nada a ver com > compilador? > > > From: fernando.treb...@gmail.com > > Date: Wed, 26 Feb 2014 17:20:26 -0300 > > To: talk-br@openstreetmap.org > > Subject: Re: [Talk-br] Restrições de conversão usando linha como > intermediário > > > > > Um pouco diferente disso. > > > > Até há pouco tempo, as restrições no OSM envolviam sempre: 2 vias > > (entrada + saída) + 1 ponto de passagem. Recentemente, ampliaram a > > definição para permitir N vias de passagem. > > > > Você tem que quebrá-las porque você precisa indicar de qual direção > > para qual outra a restrição se refere. Se você usasse a via inteira, > > sem quebrar, não daria pra distinguir se o sentido é norte/sul ou > > leste/oeste (ou coisas assim). > > > > Olha o exemplo 2 aqui: > > > http://wiki.openstreetmap.org/wiki/Pt-br:Tutorial:Restri%C3%A7%C3%B5es_de_Convers%C3%A3o#Cria.C3.A7.C3.A3o > > > > Se você não quebrar e usar apenas as vias X e Y inteiras com > > no_left_turn, não dá pra saber se é proibido dobrar de Y1 para X1 ou > > se a proibição é de Y2 para X2 (ou se é as duas coisas). > > > > 2014-02-26 16:09 GMT-03:00 Paulo Carvalho >: > > > Segundo o que eu entendi restrições de manobra são relações apenas > entre > > > vias, por isso você tem que quebrá-las. > > > > > > Mas acho interessante propor a mudança da relação para nós e não vias. > > > > > > > > > Em 26 de fevereiro de 2014 15:48, Erick de Oliveira Leal > > > escreveu: > > > > > >> Ontem que comecei a criar restrições, nunca tinha criado uma antes. No > > >> TrackSource não precisavamos quebrar uma via para fazer uma restrição > nela, > > >> apenas ligavamos os pontos onde nao se podia. Quando fui fazer pelo > josm, o > > >> plugin de restrições disse que eu tinha que quebrar e já até > apresentava um > > >> botão pra automatizar isso. Então no JOSM sempre vai ser assim, não > dá pra > > >> fazer por nós? > > >> > > >> > > >> Em 26 de fevereiro de 2014 15:45, Nelson A. de Oliveira < > nao...@gmail.com> > > >> escreveu: > > >> > > >>> 2014-02-26 15:24 GMT-03:00 Fernando Trebien < > fernando.treb...@gmail.com>: > > >>> > Opiniões? > > >>> > > >>> Eu pessoalmente prefiro manter a geometria correta da rodovia, mesmo > > >>> que acabe ficando com uma restrição não-funcional. > > >>> O que dá para fazer em alguns casos é substituir por uma restrição > > >>> equivalente. > > >>> Por exemplo, locais com proibido retornar + proibido virar à esquerda > > >>> podem ser representados apenas com um proibido virar à esquerda > > >>> (usando um nó como via). > > >>> > > >>> ___ > > >>> Talk-br mailing list > > >>> Talk-br@openstreetmap.org > > >>> https://lists.openstreetmap.org/listinfo/talk-br > > >> > > >> > > >> > > >> ___ > > >> Talk-br mailing list > > >> Talk-br@openstreetmap.org > > >> https://lists.openstreetmap.org/listinfo/talk-br > > >> > > > > > > > > > ___ > > > Talk-br mailing list > > > Talk-br@openstreetmap.org > > > https://lists.openstreetmap.org/listinfo/talk-br > > > > > > > > > > > -- > > Fernando Trebien > > +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 > > 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] Restrições de conversão usando linha como intermediário
Não ajudei. Eu sim fiz a ferramenta, sozinho. Desculpe o tom, mas é o fato. Em 26 de fevereiro de 2014 17:28, Erick de Oliveira Leal < erickdeoliveiral...@gmail.com> escreveu: > O Paulo Carvalho sabe melhor pois ajudou a desenvolver as ferramentas. Eu > só as usava. > Em 26/02/2014 17:25, "Fernando Trebien" > escreveu: > > Ligavam os pontos? Interessante. Como funcionava isso, exatamente? >> >> A resposta é: sim, você sempre precisa quebrar. É preciso que as vias >> de entrada e saída sejam pedaços conectados, e que cada pedaço tenha >> como ponto "extremo" (ponto final): >> - o ponto intermediário (da interseção); ou >> - o início e o fim das vias intermediárias >> >> Depois dá uma lida nessas duas seções: >> >> - >> http://wiki.openstreetmap.org/wiki/Pt-br:Tutorial:Restri%C3%A7%C3%B5es_de_Convers%C3%A3o#Cria.C3.A7.C3.A3o >> >> - >> http://wiki.openstreetmap.org/wiki/Pt-br:Tutorial:Restri%C3%A7%C3%B5es_de_Convers%C3%A3o#Linha_como_intermedi.C3.A1rio >> >> E se tiver dúvidas já me avisa pra eu tentar tornar o tutorial mais >> claro e fácil de digerir. >> >> 2014-02-26 15:48 GMT-03:00 Erick de Oliveira Leal >> : >> > Ontem que comecei a criar restrições, nunca tinha criado uma antes. No >> > TrackSource não precisavamos quebrar uma via para fazer uma restrição >> nela, >> > apenas ligavamos os pontos onde nao se podia. Quando fui fazer pelo >> josm, o >> > plugin de restrições disse que eu tinha que quebrar e já até >> apresentava um >> > botão pra automatizar isso. Então no JOSM sempre vai ser assim, não dá >> pra >> > fazer por nós? >> > >> > >> > Em 26 de fevereiro de 2014 15:45, Nelson A. de Oliveira < >> nao...@gmail.com> >> > escreveu: >> > >> >> 2014-02-26 15:24 GMT-03:00 Fernando Trebien < >> fernando.treb...@gmail.com>: >> >> > Opiniões? >> >> >> >> Eu pessoalmente prefiro manter a geometria correta da rodovia, mesmo >> >> que acabe ficando com uma restrição não-funcional. >> >> O que dá para fazer em alguns casos é substituir por uma restrição >> >> equivalente. >> >> Por exemplo, locais com proibido retornar + proibido virar à esquerda >> >> podem ser representados apenas com um proibido virar à esquerda >> >> (usando um nó como via). >> >> >> >> ___ >> >> Talk-br mailing list >> >> Talk-br@openstreetmap.org >> >> https://lists.openstreetmap.org/listinfo/talk-br >> > >> > >> > >> > ___ >> > Talk-br mailing list >> > Talk-br@openstreetmap.org >> > https://lists.openstreetmap.org/listinfo/talk-br >> > >> >> >> >> -- >> Fernando Trebien >> +55 (51) 9962-5409 >> >> "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 >> 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] Restrições de conversão usando linha como intermediário
Nesse caso, alterando a geometria, tem sim, mas não é o ideal. Você suprime v (transformando-a num ponto) e daí conecta A diretamente a B. Pra minimizar a confusão, A pode ser paralela a D e seguir bem próxima dela. Na interseção de A, B, C e D, você coloca todas as restrições. O resultado: - se A for bem próxima de D, a separação das duas só será visível com muita ampliação - as instruções de voz dadas pelo navegador GPS seriam corretas Isso funciona na nossa atual estrutura (do ponto de vista das aplicações). E eu concordo que queremos (e devemos) fugir disto, mas o dilema é ninguém suportar o caso ideal ainda. 2014-02-26 18:01 GMT-03:00 Nelson A. de Oliveira : > 2014-02-26 17:44 GMT-03:00 Fernando Trebien : >> Mas quando se tem um cruzamento grande mesmo, não tem muito como fugir >> do dilema entre usar uma linha como intermediário ou um ponto e fazer >> alterações na geometria (a questão principal talvez seja quais são a >> "menos pior" nesse instante). > > Isso, tem situação que não tem como escapar de usar um ou mais > caminhos como via ou então alterar a geometria. > Mas tem casos que não enxergo solução a não ser usar um caminho como via. > Por exemplo: http://i.imgur.com/GKKytx4.png > > Quem vem de A só pode seguir para B (caminho verde). Não pode virar no > caminho vermelho, para C. > Quem vem de D não tem restrição: pode ir para B ou C > > Então não daria para utilizar uma restrição com nó ou no trecho v, > porque também afetaria quem vem de D. A única solução é um proibido > que tenha from A to C via v (com v sendo um way) > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://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 https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Tutorial de restrições de conversão
Fiz justamente pensando nessa gente nova. Se tiver dúvidas ou souber de dúvidas frequentes de outros, me manda que eu tento complementar o tutorial. 2014-02-26 18:12 GMT-03:00 Raffaello Bruno Limongi Freire : > Ótima iniciativa, Fernando. > > Note que há muita gente nova entrando no projeto que fica meio perdida com > tantas informações espalhadas. > >> From: fernando.treb...@gmail.com >> Date: Wed, 26 Feb 2014 02:47:57 -0300 >> To: talk-br@openstreetmap.org >> Subject: [Talk-br] Tutorial de restrições de conversão > >> >> Pessoal, >> >> Escrevi um tutorial detalhado sobre restrições de conversão usando o >> JOSM. O objetivo é que o tutorial possa levar uma pessoa do nível >> "iniciante" para o nível "avançado" nesse assunto. >> >> >> http://wiki.openstreetmap.org/wiki/Pt-br:Tutorial:Restri%C3%A7%C3%B5es_de_Convers%C3%A3o >> >> Vou relê-lo em breve para consertar eventuais problemas, mas aceito >> sugestões de melhorias (formas diferentes de explicar a mesma coisa, >> formas diferentes de colocar a mesma frase, etc.), correções, e >> sugestões de acréscimos. >> >> Bom proveito! >> >> -- >> 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 >> https://lists.openstreetmap.org/listinfo/talk-br > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br > -- Fernando Trebien +55 (51) 9962-5409 "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 https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Restrições de conversão usando linha como intermediário
Tem a ver com o compilador sim, o compilador entende as restrições e pode transformar as vias envolvidas em "vias virtuais" (sobrepostas) com conexões que expressam a restrição. O mkgmap poderia fazer isso. Só que esse processo de separar as vias do resto da malha e criar as vias virtuais que é complicado de codificar e testar. (Vou tentar fazer um exemplo gráfico mais tarde.) 2014-02-26 18:38 GMT-03:00 Raffaello Bruno Limongi Freire : > Por isso que no Editor de Nós do Tracksource, de autoria do Paulo Carvalho, > as restrições eram criadas por nós. Definindo-se 3 nós (no caso de curvas) > ou 4 nós (no caso de retornos em U) dava para facilmente criar as restrições > sem ter que quebrar nada. > > Se o compilador cgpsmapper que parou no tempo entendia as restrições, porque > no mkgmap não funciona? Ou o problema não tem nada a ver com compilador? > >> From: fernando.treb...@gmail.com >> Date: Wed, 26 Feb 2014 17:20:26 -0300 >> To: talk-br@openstreetmap.org >> Subject: Re: [Talk-br] Restrições de conversão usando linha como >> intermediário > >> >> Um pouco diferente disso. >> >> Até há pouco tempo, as restrições no OSM envolviam sempre: 2 vias >> (entrada + saída) + 1 ponto de passagem. Recentemente, ampliaram a >> definição para permitir N vias de passagem. >> >> Você tem que quebrá-las porque você precisa indicar de qual direção >> para qual outra a restrição se refere. Se você usasse a via inteira, >> sem quebrar, não daria pra distinguir se o sentido é norte/sul ou >> leste/oeste (ou coisas assim). >> >> Olha o exemplo 2 aqui: >> >> http://wiki.openstreetmap.org/wiki/Pt-br:Tutorial:Restri%C3%A7%C3%B5es_de_Convers%C3%A3o#Cria.C3.A7.C3.A3o >> >> Se você não quebrar e usar apenas as vias X e Y inteiras com >> no_left_turn, não dá pra saber se é proibido dobrar de Y1 para X1 ou >> se a proibição é de Y2 para X2 (ou se é as duas coisas). >> >> 2014-02-26 16:09 GMT-03:00 Paulo Carvalho : >> > Segundo o que eu entendi restrições de manobra são relações apenas entre >> > vias, por isso você tem que quebrá-las. >> > >> > Mas acho interessante propor a mudança da relação para nós e não vias. >> > >> > >> > Em 26 de fevereiro de 2014 15:48, Erick de Oliveira Leal >> > escreveu: >> > >> >> Ontem que comecei a criar restrições, nunca tinha criado uma antes. No >> >> TrackSource não precisavamos quebrar uma via para fazer uma restrição >> >> nela, >> >> apenas ligavamos os pontos onde nao se podia. Quando fui fazer pelo >> >> josm, o >> >> plugin de restrições disse que eu tinha que quebrar e já até >> >> apresentava um >> >> botão pra automatizar isso. Então no JOSM sempre vai ser assim, não dá >> >> pra >> >> fazer por nós? >> >> >> >> >> >> Em 26 de fevereiro de 2014 15:45, Nelson A. de Oliveira >> >> >> >> escreveu: >> >> >> >>> 2014-02-26 15:24 GMT-03:00 Fernando Trebien >> >>> : >> >>> > Opiniões? >> >>> >> >>> Eu pessoalmente prefiro manter a geometria correta da rodovia, mesmo >> >>> que acabe ficando com uma restrição não-funcional. >> >>> O que dá para fazer em alguns casos é substituir por uma restrição >> >>> equivalente. >> >>> Por exemplo, locais com proibido retornar + proibido virar à esquerda >> >>> podem ser representados apenas com um proibido virar à esquerda >> >>> (usando um nó como via). >> >>> >> >>> ___ >> >>> Talk-br mailing list >> >>> Talk-br@openstreetmap.org >> >>> https://lists.openstreetmap.org/listinfo/talk-br >> >> >> >> >> >> >> >> ___ >> >> Talk-br mailing list >> >> Talk-br@openstreetmap.org >> >> https://lists.openstreetmap.org/listinfo/talk-br >> >> >> > >> > >> > ___ >> > Talk-br mailing list >> > Talk-br@openstreetmap.org >> > https://lists.openstreetmap.org/listinfo/talk-br >> > >> >> >> >> -- >> Fernando Trebien >> +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 >> https://lists.openstreetmap.org/listinfo/talk-br > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br > -- Fernando Trebien +55 (51) 9962-5409 "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 https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Restrições de conversão usando linha como intermediário
Por isso que no Editor de Nós do Tracksource, de autoria do Paulo Carvalho, as restrições eram criadas por nós. Definindo-se 3 nós (no caso de curvas) ou 4 nós (no caso de retornos em U) dava para facilmente criar as restrições sem ter que quebrar nada. Se o compilador cgpsmapper que parou no tempo entendia as restrições, porque no mkgmap não funciona? Ou o problema não tem nada a ver com compilador? > From: fernando.treb...@gmail.com > Date: Wed, 26 Feb 2014 17:20:26 -0300 > To: talk-br@openstreetmap.org > Subject: Re: [Talk-br]Restrições de conversão usando linha como > intermediário > > Um pouco diferente disso. > > Até há pouco tempo, as restrições no OSM envolviam sempre: 2 vias > (entrada + saída) + 1 ponto de passagem. Recentemente, ampliaram a > definição para permitir N vias de passagem. > > Você tem que quebrá-las porque você precisa indicar de qual direção > para qual outra a restrição se refere. Se você usasse a via inteira, > sem quebrar, não daria pra distinguir se o sentido é norte/sul ou > leste/oeste (ou coisas assim). > > Olha o exemplo 2 aqui: > http://wiki.openstreetmap.org/wiki/Pt-br:Tutorial:Restri%C3%A7%C3%B5es_de_Convers%C3%A3o#Cria.C3.A7.C3.A3o > > Se você não quebrar e usar apenas as vias X e Y inteiras com > no_left_turn, não dá pra saber se é proibido dobrar de Y1 para X1 ou > se a proibição é de Y2 para X2 (ou se é as duas coisas). > > 2014-02-26 16:09 GMT-03:00 Paulo Carvalho : > > Segundo o que eu entendi restrições de manobra são relações apenas entre > > vias, por isso você tem que quebrá-las. > > > > Mas acho interessante propor a mudança da relação para nós e não vias. > > > > > > Em 26 de fevereiro de 2014 15:48, Erick de Oliveira Leal > > escreveu: > > > >> Ontem que comecei a criar restrições, nunca tinha criado uma antes. No > >> TrackSource não precisavamos quebrar uma via para fazer uma restrição nela, > >> apenas ligavamos os pontos onde nao se podia. Quando fui fazer pelo josm, o > >> plugin de restrições disse que eu tinha que quebrar e já até apresentava um > >> botão pra automatizar isso. Então no JOSM sempre vai ser assim, não dá pra > >> fazer por nós? > >> > >> > >> Em 26 de fevereiro de 2014 15:45, Nelson A. de Oliveira > >> escreveu: > >> > >>> 2014-02-26 15:24 GMT-03:00 Fernando Trebien : > >>> > Opiniões? > >>> > >>> Eu pessoalmente prefiro manter a geometria correta da rodovia, mesmo > >>> que acabe ficando com uma restrição não-funcional. > >>> O que dá para fazer em alguns casos é substituir por uma restrição > >>> equivalente. > >>> Por exemplo, locais com proibido retornar + proibido virar à esquerda > >>> podem ser representados apenas com um proibido virar à esquerda > >>> (usando um nó como via). > >>> > >>> ___ > >>> Talk-br mailing list > >>> Talk-br@openstreetmap.org > >>> https://lists.openstreetmap.org/listinfo/talk-br > >> > >> > >> > >> ___ > >> Talk-br mailing list > >> Talk-br@openstreetmap.org > >> https://lists.openstreetmap.org/listinfo/talk-br > >> > > > > > > ___ > > Talk-br mailing list > > Talk-br@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/talk-br > > > > > > -- > Fernando Trebien > +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 > 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] Tutorial de restrições de conversão
Ótima iniciativa, Fernando. Note que há muita gente nova entrando no projeto que fica meio perdida com tantas informações espalhadas. > From: fernando.treb...@gmail.com > Date: Wed, 26 Feb 2014 02:47:57 -0300 > To: talk-br@openstreetmap.org > Subject: [Talk-br] Tutorial de restrições de conversão > > Pessoal, > > Escrevi um tutorial detalhado sobre restrições de conversão usando o > JOSM. O objetivo é que o tutorial possa levar uma pessoa do nível > "iniciante" para o nível "avançado" nesse assunto. > > http://wiki.openstreetmap.org/wiki/Pt-br:Tutorial:Restri%C3%A7%C3%B5es_de_Convers%C3%A3o > > Vou relê-lo em breve para consertar eventuais problemas, mas aceito > sugestões de melhorias (formas diferentes de explicar a mesma coisa, > formas diferentes de colocar a mesma frase, etc.), correções, e > sugestões de acréscimos. > > Bom proveito! > > -- > 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 > 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] Restrições de conversão usando linha como intermediário
2014-02-26 17:44 GMT-03:00 Fernando Trebien : > Mas quando se tem um cruzamento grande mesmo, não tem muito como fugir > do dilema entre usar uma linha como intermediário ou um ponto e fazer > alterações na geometria (a questão principal talvez seja quais são a > "menos pior" nesse instante). Isso, tem situação que não tem como escapar de usar um ou mais caminhos como via ou então alterar a geometria. Mas tem casos que não enxergo solução a não ser usar um caminho como via. Por exemplo: http://i.imgur.com/GKKytx4.png Quem vem de A só pode seguir para B (caminho verde). Não pode virar no caminho vermelho, para C. Quem vem de D não tem restrição: pode ir para B ou C Então não daria para utilizar uma restrição com nó ou no trecho v, porque também afetaria quem vem de D. A única solução é um proibido que tenha from A to C via v (com v sendo um way) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Restrições de conversão usando linha como intermediário
Tem razão, nessa situação eu sempre faço com no_turn_left também. Vou acrescentar no tutorial. Mas quando se tem um cruzamento grande mesmo, não tem muito como fugir do dilema entre usar uma linha como intermediário ou um ponto e fazer alterações na geometria (a questão principal talvez seja quais são a "menos pior" nesse instante). 2014-02-26 17:40 GMT-03:00 Nelson A. de Oliveira : > 2014-02-26 17:29 GMT-03:00 Fernando Trebien : >> Hm preciso fazer um exemplo disso. Mas acho que se você mudar a via >> intermediária por 1 nó só e proibir somente a conversão à esquerda, >> você acaba permitindo o retorno, não? > > Não em alguns casos. > Exemplo: http://i.imgur.com/uiRNLqd.png > > Ao invés de fazer um proibido conversão com from A, via B, to C, > pode-se fazer um proibido virar com from A, via n, to B. > Essa proibição já impede de entrar no trecho B e portanto não vai dar > para fazer um retorno para C. > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://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 https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Restrições de conversão usando linha como intermediário
"posteriormente alguém acaba alterando/quebrando/mesclando esse caminho" Alguém que usa o Potlatch né, porque tanto o iD quanto o JOSM tratam corretamente dessa situação. Mas concordo (até que consertem o Potlatch). "Outro porém de usar um "siga em frente" é que a aplicação pode renderizar a placa de forma não muito correta" Concordo. Mas existe uma aplicação amplamente usada que mostra as restrições? Se não existir, ou se servir só pra controle de qualidade no OSM, talvez isso não seja muito importante. Eu na verdade acho que só deveriam existir relações do tipo "no_", isso eliminaria quase todas essas confusões. As "only_" são um subconjunto (você pode expressá-las usando uma mais do tipo "no_"). Só que as "only_" são as mais comuns na Alemanha (pelo jeito com que eles organizam o tráfego), e como quem desenvolve o JOSM é a comunidade alemã e a comunidade alemã é uma das mais participativas no OSM... difícil voltarem atrás. 2014-02-26 17:34 GMT-03:00 Nelson A. de Oliveira : > O problema de usar um "siga em frente" ao invés de um "proibido virar" > é que dá mais margem para gerar erros. > Usando esse exemplo: http://i.imgur.com/j6VKrIp.png > > É proibido virar à esquerda (em vermelho), mas caso a pessoa utilize > um siga em frente (em verde) e esse caminho de destino for muito > grande, posteriormente alguém acaba alterando/quebrando/mesclando esse > caminho (e de alguma forma quebrando a relação de restrição). > Utilizando apenas o pequeno trecho que interliga as duas vias para > criar uma restrição de proibido acaba dando menos margem para > possíveis erros posteriores. > > Outro porém de usar um "siga em frente" é que a aplicação pode > renderizar a placa de forma não muito correta (na rua vai ter uma > placa dizendo "proibido virar" enquanto que a aplicação vai desenhar > "siga em frente"; é algo mínimo que na prática gera o mesmo resultado, > mas gera uma diferença de indicação) > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://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 https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Restrições de conversão usando linha como intermediário
2014-02-26 17:29 GMT-03:00 Fernando Trebien : > Hm preciso fazer um exemplo disso. Mas acho que se você mudar a via > intermediária por 1 nó só e proibir somente a conversão à esquerda, > você acaba permitindo o retorno, não? Não em alguns casos. Exemplo: http://i.imgur.com/uiRNLqd.png Ao invés de fazer um proibido conversão com from A, via B, to C, pode-se fazer um proibido virar com from A, via n, to B. Essa proibição já impede de entrar no trecho B e portanto não vai dar para fazer um retorno para C. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Restrições de conversão usando linha como intermediário
O problema de usar um "siga em frente" ao invés de um "proibido virar" é que dá mais margem para gerar erros. Usando esse exemplo: http://i.imgur.com/j6VKrIp.png É proibido virar à esquerda (em vermelho), mas caso a pessoa utilize um siga em frente (em verde) e esse caminho de destino for muito grande, posteriormente alguém acaba alterando/quebrando/mesclando esse caminho (e de alguma forma quebrando a relação de restrição). Utilizando apenas o pequeno trecho que interliga as duas vias para criar uma restrição de proibido acaba dando menos margem para possíveis erros posteriores. Outro porém de usar um "siga em frente" é que a aplicação pode renderizar a placa de forma não muito correta (na rua vai ter uma placa dizendo "proibido virar" enquanto que a aplicação vai desenhar "siga em frente"; é algo mínimo que na prática gera o mesmo resultado, mas gera uma diferença de indicação) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Restrições de conversão usando linha como intermediário
Hm preciso fazer um exemplo disso. Mas acho que se você mudar a via intermediária por 1 nó só e proibir somente a conversão à esquerda, você acaba permitindo o retorno, não? Esse negócio de juntar num nó só geralmente é o que eu faço quando você pode virar à esquerda e não retornar, ou pode retornar mas não virar à esquerda. Mas eu acho (acho) que entendi a sua idéia, e concordo em tentar não alterar a geometria da via demais. Então, você estaria mais a favor das ligações "inventadas" se elas não alterarem muito a geometria, certo? 2014-02-26 15:45 GMT-03:00 Nelson A. de Oliveira : > 2014-02-26 15:24 GMT-03:00 Fernando Trebien : >> Opiniões? > > Eu pessoalmente prefiro manter a geometria correta da rodovia, mesmo > que acabe ficando com uma restrição não-funcional. > O que dá para fazer em alguns casos é substituir por uma restrição > equivalente. > Por exemplo, locais com proibido retornar + proibido virar à esquerda > podem ser representados apenas com um proibido virar à esquerda > (usando um nó como via). > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://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 https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Restrições de conversão usando linha como intermediário
Instalei o plugins Michigan left aqui, muito bom. Em 26/02/2014 17:25, "Fernando Trebien" escreveu: > Ligavam os pontos? Interessante. Como funcionava isso, exatamente? > > A resposta é: sim, você sempre precisa quebrar. É preciso que as vias > de entrada e saída sejam pedaços conectados, e que cada pedaço tenha > como ponto "extremo" (ponto final): > - o ponto intermediário (da interseção); ou > - o início e o fim das vias intermediárias > > Depois dá uma lida nessas duas seções: > > - > http://wiki.openstreetmap.org/wiki/Pt-br:Tutorial:Restri%C3%A7%C3%B5es_de_Convers%C3%A3o#Cria.C3.A7.C3.A3o > > - > http://wiki.openstreetmap.org/wiki/Pt-br:Tutorial:Restri%C3%A7%C3%B5es_de_Convers%C3%A3o#Linha_como_intermedi.C3.A1rio > > E se tiver dúvidas já me avisa pra eu tentar tornar o tutorial mais > claro e fácil de digerir. > > 2014-02-26 15:48 GMT-03:00 Erick de Oliveira Leal > : > > Ontem que comecei a criar restrições, nunca tinha criado uma antes. No > > TrackSource não precisavamos quebrar uma via para fazer uma restrição > nela, > > apenas ligavamos os pontos onde nao se podia. Quando fui fazer pelo > josm, o > > plugin de restrições disse que eu tinha que quebrar e já até apresentava > um > > botão pra automatizar isso. Então no JOSM sempre vai ser assim, não dá > pra > > fazer por nós? > > > > > > Em 26 de fevereiro de 2014 15:45, Nelson A. de Oliveira < > nao...@gmail.com> > > escreveu: > > > >> 2014-02-26 15:24 GMT-03:00 Fernando Trebien >: > >> > Opiniões? > >> > >> Eu pessoalmente prefiro manter a geometria correta da rodovia, mesmo > >> que acabe ficando com uma restrição não-funcional. > >> O que dá para fazer em alguns casos é substituir por uma restrição > >> equivalente. > >> Por exemplo, locais com proibido retornar + proibido virar à esquerda > >> podem ser representados apenas com um proibido virar à esquerda > >> (usando um nó como via). > >> > >> ___ > >> Talk-br mailing list > >> Talk-br@openstreetmap.org > >> https://lists.openstreetmap.org/listinfo/talk-br > > > > > > > > ___ > > Talk-br mailing list > > Talk-br@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/talk-br > > > > > > -- > Fernando Trebien > +55 (51) 9962-5409 > > "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 > 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] Restrições de conversão usando linha como intermediário
O Paulo Carvalho sabe melhor pois ajudou a desenvolver as ferramentas. Eu só as usava. Em 26/02/2014 17:25, "Fernando Trebien" escreveu: > Ligavam os pontos? Interessante. Como funcionava isso, exatamente? > > A resposta é: sim, você sempre precisa quebrar. É preciso que as vias > de entrada e saída sejam pedaços conectados, e que cada pedaço tenha > como ponto "extremo" (ponto final): > - o ponto intermediário (da interseção); ou > - o início e o fim das vias intermediárias > > Depois dá uma lida nessas duas seções: > > - > http://wiki.openstreetmap.org/wiki/Pt-br:Tutorial:Restri%C3%A7%C3%B5es_de_Convers%C3%A3o#Cria.C3.A7.C3.A3o > > - > http://wiki.openstreetmap.org/wiki/Pt-br:Tutorial:Restri%C3%A7%C3%B5es_de_Convers%C3%A3o#Linha_como_intermedi.C3.A1rio > > E se tiver dúvidas já me avisa pra eu tentar tornar o tutorial mais > claro e fácil de digerir. > > 2014-02-26 15:48 GMT-03:00 Erick de Oliveira Leal > : > > Ontem que comecei a criar restrições, nunca tinha criado uma antes. No > > TrackSource não precisavamos quebrar uma via para fazer uma restrição > nela, > > apenas ligavamos os pontos onde nao se podia. Quando fui fazer pelo > josm, o > > plugin de restrições disse que eu tinha que quebrar e já até apresentava > um > > botão pra automatizar isso. Então no JOSM sempre vai ser assim, não dá > pra > > fazer por nós? > > > > > > Em 26 de fevereiro de 2014 15:45, Nelson A. de Oliveira < > nao...@gmail.com> > > escreveu: > > > >> 2014-02-26 15:24 GMT-03:00 Fernando Trebien >: > >> > Opiniões? > >> > >> Eu pessoalmente prefiro manter a geometria correta da rodovia, mesmo > >> que acabe ficando com uma restrição não-funcional. > >> O que dá para fazer em alguns casos é substituir por uma restrição > >> equivalente. > >> Por exemplo, locais com proibido retornar + proibido virar à esquerda > >> podem ser representados apenas com um proibido virar à esquerda > >> (usando um nó como via). > >> > >> ___ > >> Talk-br mailing list > >> Talk-br@openstreetmap.org > >> https://lists.openstreetmap.org/listinfo/talk-br > > > > > > > > ___ > > Talk-br mailing list > > Talk-br@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/talk-br > > > > > > -- > Fernando Trebien > +55 (51) 9962-5409 > > "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 > 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] Restrições de conversão usando linha como intermediário
Ligavam os pontos? Interessante. Como funcionava isso, exatamente? A resposta é: sim, você sempre precisa quebrar. É preciso que as vias de entrada e saída sejam pedaços conectados, e que cada pedaço tenha como ponto "extremo" (ponto final): - o ponto intermediário (da interseção); ou - o início e o fim das vias intermediárias Depois dá uma lida nessas duas seções: - http://wiki.openstreetmap.org/wiki/Pt-br:Tutorial:Restri%C3%A7%C3%B5es_de_Convers%C3%A3o#Cria.C3.A7.C3.A3o - http://wiki.openstreetmap.org/wiki/Pt-br:Tutorial:Restri%C3%A7%C3%B5es_de_Convers%C3%A3o#Linha_como_intermedi.C3.A1rio E se tiver dúvidas já me avisa pra eu tentar tornar o tutorial mais claro e fácil de digerir. 2014-02-26 15:48 GMT-03:00 Erick de Oliveira Leal : > Ontem que comecei a criar restrições, nunca tinha criado uma antes. No > TrackSource não precisavamos quebrar uma via para fazer uma restrição nela, > apenas ligavamos os pontos onde nao se podia. Quando fui fazer pelo josm, o > plugin de restrições disse que eu tinha que quebrar e já até apresentava um > botão pra automatizar isso. Então no JOSM sempre vai ser assim, não dá pra > fazer por nós? > > > Em 26 de fevereiro de 2014 15:45, Nelson A. de Oliveira > escreveu: > >> 2014-02-26 15:24 GMT-03:00 Fernando Trebien : >> > Opiniões? >> >> Eu pessoalmente prefiro manter a geometria correta da rodovia, mesmo >> que acabe ficando com uma restrição não-funcional. >> O que dá para fazer em alguns casos é substituir por uma restrição >> equivalente. >> Por exemplo, locais com proibido retornar + proibido virar à esquerda >> podem ser representados apenas com um proibido virar à esquerda >> (usando um nó como via). >> >> ___ >> Talk-br mailing list >> Talk-br@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-br > > > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br > -- Fernando Trebien +55 (51) 9962-5409 "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 https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Restrições de conversão usando linha como intermediário
Eu também prefiro, e recomendei a mesma coisa (com uma justificativa) aqui: http://wiki.openstreetmap.org/wiki/Pt-br:Tutorial:Restri%C3%A7%C3%B5es_de_Convers%C3%A3o#Alternativas_equivalentes 2014-02-26 16:56 GMT-03:00 Gerald Weber : > > >> Eu pessoalmente prefiro manter a geometria correta da rodovia, mesmo >> que acabe ficando com uma restrição não-funcional. >> O que dá para fazer em alguns casos é substituir por uma restrição >> equivalente. >> Por exemplo, locais com proibido retornar + proibido virar à esquerda >> podem ser representados apenas com um proibido virar à esquerda >> (usando um nó como via). > > > Às vezes eu prefiro colocar um "obrigatório seguir em frente" no lugar de um > "proibido virar à esquerda". Não acompanhei a discussão toda, mas talvez > isto seja de ajuda. > > abraço > > Gerald > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://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 https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Restrições de conversão usando linha como intermediário
Um pouco diferente disso. Até há pouco tempo, as restrições no OSM envolviam sempre: 2 vias (entrada + saída) + 1 ponto de passagem. Recentemente, ampliaram a definição para permitir N vias de passagem. Você tem que quebrá-las porque você precisa indicar de qual direção para qual outra a restrição se refere. Se você usasse a via inteira, sem quebrar, não daria pra distinguir se o sentido é norte/sul ou leste/oeste (ou coisas assim). Olha o exemplo 2 aqui: http://wiki.openstreetmap.org/wiki/Pt-br:Tutorial:Restri%C3%A7%C3%B5es_de_Convers%C3%A3o#Cria.C3.A7.C3.A3o Se você não quebrar e usar apenas as vias X e Y inteiras com no_left_turn, não dá pra saber se é proibido dobrar de Y1 para X1 ou se a proibição é de Y2 para X2 (ou se é as duas coisas). 2014-02-26 16:09 GMT-03:00 Paulo Carvalho : > Segundo o que eu entendi restrições de manobra são relações apenas entre > vias, por isso você tem que quebrá-las. > > Mas acho interessante propor a mudança da relação para nós e não vias. > > > Em 26 de fevereiro de 2014 15:48, Erick de Oliveira Leal > escreveu: > >> Ontem que comecei a criar restrições, nunca tinha criado uma antes. No >> TrackSource não precisavamos quebrar uma via para fazer uma restrição nela, >> apenas ligavamos os pontos onde nao se podia. Quando fui fazer pelo josm, o >> plugin de restrições disse que eu tinha que quebrar e já até apresentava um >> botão pra automatizar isso. Então no JOSM sempre vai ser assim, não dá pra >> fazer por nós? >> >> >> Em 26 de fevereiro de 2014 15:45, Nelson A. de Oliveira >> escreveu: >> >>> 2014-02-26 15:24 GMT-03:00 Fernando Trebien : >>> > Opiniões? >>> >>> Eu pessoalmente prefiro manter a geometria correta da rodovia, mesmo >>> que acabe ficando com uma restrição não-funcional. >>> O que dá para fazer em alguns casos é substituir por uma restrição >>> equivalente. >>> Por exemplo, locais com proibido retornar + proibido virar à esquerda >>> podem ser representados apenas com um proibido virar à esquerda >>> (usando um nó como via). >>> >>> ___ >>> Talk-br mailing list >>> Talk-br@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/talk-br >> >> >> >> ___ >> Talk-br mailing list >> Talk-br@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-br >> > > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br > -- Fernando Trebien +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 https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Restrições de conversão usando linha como intermediário
Eu pessoalmente prefiro manter a geometria correta da rodovia, mesmo > que acabe ficando com uma restrição não-funcional. > O que dá para fazer em alguns casos é substituir por uma restrição > equivalente. > Por exemplo, locais com proibido retornar + proibido virar à esquerda > podem ser representados apenas com um proibido virar à esquerda > (usando um nó como via). Às vezes eu prefiro colocar um "obrigatório seguir em frente" no lugar de um "proibido virar à esquerda". Não acompanhei a discussão toda, mas talvez isto seja de ajuda. abraço Gerald ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Plugin confaltion do JOSM
Srs, Desculpem a demora em responder, estava enrolado em achar o Java 6 para instalação. Pois bem. Instalei o Ubuntu do zero, com o java 6. Usei os JOSMs 6502, 6409 e 6296 Sempre com o mesmo erro, consigo até listar os erros encontrados nos mapas, mas na hora de conflacionar, erro!!! Aliás, na versão 6296 o conflation nem carregou, deu pau na inicialização. Se alguem tiver uma combinação JOSM + JAVA funcional, por favor me avise. Ou outra ferramenta que faça a mesma coisa. Agradeço às dicas recebidas, Att, Marcelo Pereira Em 24 de fevereiro de 2014 19:13, Paulo Carvalho < paulo.r.m.carva...@gmail.com> escreveu: > Pode ser mesmo biblioteca incompatível. Agora qual eu não sei. Estou sem > condição de investigar isso. Estou com coisas mais fundamentais para > investigar como a compilação com mkgmap. > > > Em 24 de fevereiro de 2014 16:31, Fernando Trebien < > fernando.treb...@gmail.com> escreveu: > > Esses erros de introspecção já foram relatados no bug tracker do >> plugin, mas o desenvolvedor parece ter meio que abandonado o projeto, >> ou pelo menos não o estar priorizando (afinal, se funciona com Java >> 6...). Lembro vagamente de ter lido algum stack trace que sugeria que >> o erro acontece numa das bibliotecas de que o plugin depende, uma das >> usadas para calcular a semelhança topológica entre as duas malhas. >> >> 2014-02-22 15:22 GMT-03:00 Paulo Carvalho : >> > Faz sentido usar JOSMs mais antigos. O erro postado pelo Marcelo >> parece ser >> > um erro de introspecção (erro de funcionamento interno). A grosso modo >> o >> > plugin não está falando a mesma língua do framework (JOSM). O >> desenvolvedor >> > do plugin de conflação deve dar uma olhada nas APIs novas e removidas do >> > JOSM. >> > >> > >> > Em 22 de fevereiro de 2014 12:40, Erick de Oliveira Leal >> > escreveu: >> > >> >> Marcelo, vai testando com esses JOSMs mais antigos: >> >> http://josm.openstreetmap.de/download/Archiv/ >> >> >> >> Vai tentando com intervalos de 2 em 2 meses pra ser mais rapido >> >> >> >> >> >> Em 22 de fevereiro de 2014 12:35, Marcelo Pereira >> >> escreveu: >> >> >> >>> Erick, >> >>> >> >>> Obrigado pela ajuda, segue o erro apresentado >> >>> >> >>> >> >>> >> >>> >> >>> ERROR: java.lang.NoSuchMethodError: >> >>> >> org.openstreetmap.josm.command.AddPrimitivesCommand.(Ljava/util/List;Lorg/openstreetmap/josm/gui/layer/OsmDataLayer;)V >> >>> java.lang.NoSuchMethodError: >> >>> >> org.openstreetmap.josm.command.AddPrimitivesCommand.(Ljava/util/List;Lorg/openstreetmap/josm/gui/layer/OsmDataLayer;)V >> >>> at >> >>> >> org.openstreetmap.josm.plugins.conflation.ConflateMatchCommand.(ConflateMatchCommand.java:42) >> >>> at >> >>> >> org.openstreetmap.josm.plugins.conflation.ConflationToggleDialog$ConflateAction.conflateMatchActionPerformed(ConflationToggleDialog.java:570) >> >>> at >> >>> >> org.openstreetmap.josm.plugins.conflation.ConflationToggleDialog$ConflateAction.actionPerformed(ConflationToggleDialog.java:547) >> >>> at >> >>> >> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2018) >> >>> at >> >>> >> javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2341) >> >>> at >> >>> >> javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402) >> >>> at >> javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259) >> >>> at >> >>> >> javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:252) >> >>> at >> >>> >> java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:289) >> >>> at java.awt.Component.processMouseEvent(Component.java:6505) >> >>> at javax.swing.JComponent.processMouseEvent(JComponent.java:3320) >> >>> at java.awt.Component.processEvent(Component.java:6270) >> >>> at java.awt.Container.processEvent(Container.java:2229) >> >>> at java.awt.Component.dispatchEventImpl(Component.java:4861) >> >>> at java.awt.Container.dispatchEventImpl(Container.java:2287) >> >>> at java.awt.Component.dispatchEvent(Component.java:4687) >> >>> at >> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4832) >> >>> at >> java.awt.LightweightDispatcher.processMouseEvent(Container.java:4492) >> >>> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4422) >> >>> at java.awt.Container.dispatchEventImpl(Container.java:2273) >> >>> at java.awt.Window.dispatchEventImpl(Window.java:2719) >> >>> at java.awt.Component.dispatchEvent(Component.java:4687) >> >>> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:735) >> >>> at java.awt.EventQueue.access$200(EventQueue.java:103) >> >>> at java.awt.EventQueue$3.run(EventQueue.java:694) >> >>> at java.awt.EventQueue$3.run(EventQueue.java:692) >> >>> at java.security.AccessController.doPrivileged(Native Method) >> >>> at >> >>> >> java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76) >> >>> at >> >>> >> java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:87) >> >>> at java.awt.Eve
Re: [Talk-br] Restrições de conversão usando linha como intermediário
Segundo o que eu entendi restrições de manobra são relações apenas entre vias, por isso você tem que quebrá-las. Mas acho interessante propor a mudança da relação para nós e não vias. Em 26 de fevereiro de 2014 15:48, Erick de Oliveira Leal < erickdeoliveiral...@gmail.com> escreveu: > Ontem que comecei a criar restrições, nunca tinha criado uma antes. No > TrackSource não precisavamos quebrar uma via para fazer uma restrição nela, > apenas ligavamos os pontos onde nao se podia. Quando fui fazer pelo josm, o > plugin de restrições disse que eu tinha que quebrar e já até apresentava um > botão pra automatizar isso. Então no JOSM sempre vai ser assim, não dá pra > fazer por nós? > > > Em 26 de fevereiro de 2014 15:45, Nelson A. de Oliveira > escreveu: > > 2014-02-26 15:24 GMT-03:00 Fernando Trebien : >> > Opiniões? >> >> Eu pessoalmente prefiro manter a geometria correta da rodovia, mesmo >> que acabe ficando com uma restrição não-funcional. >> O que dá para fazer em alguns casos é substituir por uma restrição >> equivalente. >> Por exemplo, locais com proibido retornar + proibido virar à esquerda >> podem ser representados apenas com um proibido virar à esquerda >> (usando um nó como via). >> >> ___ >> 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] Restrições de conversão usando linha como intermediário
Ontem que comecei a criar restrições, nunca tinha criado uma antes. No TrackSource não precisavamos quebrar uma via para fazer uma restrição nela, apenas ligavamos os pontos onde nao se podia. Quando fui fazer pelo josm, o plugin de restrições disse que eu tinha que quebrar e já até apresentava um botão pra automatizar isso. Então no JOSM sempre vai ser assim, não dá pra fazer por nós? Em 26 de fevereiro de 2014 15:45, Nelson A. de Oliveira escreveu: > 2014-02-26 15:24 GMT-03:00 Fernando Trebien : > > Opiniões? > > Eu pessoalmente prefiro manter a geometria correta da rodovia, mesmo > que acabe ficando com uma restrição não-funcional. > O que dá para fazer em alguns casos é substituir por uma restrição > equivalente. > Por exemplo, locais com proibido retornar + proibido virar à esquerda > podem ser representados apenas com um proibido virar à esquerda > (usando um nó como via). > > ___ > 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] Restrições de conversão usando linha como intermediário
2014-02-26 15:24 GMT-03:00 Fernando Trebien : > Opiniões? Eu pessoalmente prefiro manter a geometria correta da rodovia, mesmo que acabe ficando com uma restrição não-funcional. O que dá para fazer em alguns casos é substituir por uma restrição equivalente. Por exemplo, locais com proibido retornar + proibido virar à esquerda podem ser representados apenas com um proibido virar à esquerda (usando um nó como via). ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
[Talk-br] Restrições de conversão usando linha como intermediário
Pessoal, Repensando um pouco sobre este tutorial (http://wiki.openstreetmap.org/wiki/Pt-br:Tutorial:Restri%C3%A7%C3%B5es_de_Convers%C3%A3o#Linha_como_intermedi.C3.A1rio), fico na dúvida do que exatamente recomendar pros iniciantes. O problema é que restrições que usam linhas com o papel "via" (ao invés de só um ponto) não são suportadas em nenhuma aplicação. Mapear desta forma faria o roteamento dar errado em todas as aplicações que existem hoje. Eu relatei essa situação no final dessa seção. O que eu recomendei foi usar um ponto intermediário e circular o cruzamento com uma linha com fixme, mas eu me pergunto se não seria "menos pior" inventar conexões (como descreve a seção seguinte) e colocar um fixme nelas mesmas. Contras de usar um ponto: - instruções ligeiramente erradas no navegador - aspecto visual estranho Prós de usar conexões "virtuais": - instruções corretas - aspecto visual quase correto (depende de como a linha é desenhada) Contras: - infringe a semântica da separação das vias Opiniões? -- 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 https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Mapas do IBGE
Ola,
No ano passado, abaixei alguns mapas do IBGE e fiz um processamento
segundo as etapas abaixo. O resultado nao e perfeito, mais...
A etapa #5 e a mais trablahosa e tem 30+ setores censitarios no
minicipio :-(
Abs, Hermann
-
# 0. Create a working directory and use it
mkdir mapas_de_setores_censitarios
cd mapas_de_setores_censitarios
# 1. Download IBGE maps for Ivoti, RS
wget
ftp://geoftp.ibge.gov.br/mapas_estatisticos/censo_2010/mapas_de_setores_censitarios/RS/4310801.zip
# 2. Extract all relevant maps (there are 34 sectors in Ivoti)
unzip -j 4310801.zip "*/4310801.pdf"
# 3. Convert maps to PNG, in reasonable resolution (200 dpi)
for f in *.pdf ; do convert -density 200 $f ${f%pdf}png ; done
# 4. Georeference 43108010501.png, through visual inspection :-(
# Upper left corner of the actual map at pixel 164,121
-51d09'51" = -51.164167 longitude
-29d35'20" = -29.59 latitude
# Lower right corner of the actual map at pixel 2226,2838
-51d09'23" = -51.156389 longitude
-29d35'57" = -29.599167 latitide
# 5. Apply the above values as ground control points (GCPs)
# Assuming that the undocumented datum is SIRGAS2000 = EPSG:4674
gdal_translate 43108010501.png 43108010501.tif \
-gcp 164 121 -51.164167 -29.59 \
-gcp 2226 2838 -51.156389 -29.599167 \
-gcp 2226 121 -51.156389 -29.59 \
-a_srs epsg:4674
# 6. JOSM/PicLayer only supports PNG, JPEG or GIF formats
# only EPSG:3857 is supported, world files are understood
# Warp the file to EPSG:3857 = WGS 84 / Pseudo-Mercator
gdalwarp 43108010501.tif 43108010501_epsg3857.tif \
-t_srs epsg:3857 -co tfw=yes
# Change image format, rename world file
convert 43108010501_epsg3857.tif 43108010501_epsg3857.jpg
mv 43108010501_epsg3857.tfw 43108010501_epsg3857.wld
On 2014-02-25 19:29, Fernando Trebien wrote:
Como era o seu antigo método? Não temos preconceitos. :D
On Feb 25, 2014 1:57 PM, "Raffaello Bruno Limongi Freire"
mailto:raffaellobruno-pkbjnfxxiarbdgjk7y7...@public.gmane.org>> wrote:
Arlindo/Vitor,
consegui visualizar e georreferenciar um mapa do IBGE no JOSM, mas
deu tando trabalho que eu não sei se será mais eficiente do que meu
antigo método "tabajara"... :)
Uma vantagem que eu vejo é que só precisa calibrar uma vez para
visualizar quantas vezes quiser.
Obrigado.
From:
openstreetmap-qpc2wcgjr8vppgbeqg0jjtbpr1lh4...@public.gmane.org
Date: Mon, 24 Feb 2014 20:37:28 -0300
To: talk-br-3+rWM/WnaLOn4i5uJCXUsti2O/jbr...@public.gmane.org
Subject: Re: [Talk-br] Mapas do IBGE
O Vitor foi mais rápido que eu. :-P
Discutimos isso ano passado:
https://lists.openstreetmap.org/pipermail/talk-br/2013-January/003109.html
2014-02-24 20:27 GMT-03:00 Vítor Rodrigo Dias
mailto:vitor.dias-re5jqeeqqe8avxtiumw...@public.gmane.org>>:
Raffaello,
O ideal é converter os PDFs para imagem e usar o PicLayer para
colocá-los como imagens de fundo. Uma outra dica é, no PicLayer,
alinhar os limites dos PDFs usando o KML do IBGE com os limites
de setores censitários.
Abraços,
Vítor Dias
Em 24/02/2014 20:20, "Raffaello Bruno Limongi Freire"
mailto:raffaellobruno-pkbjnfxxiarbdgjk7y7...@public.gmane.org>>
escreveu:
Oi, Arlindo,
não sei se vou ser claro, mas minha dúvida é como visualizar
esses mapas do IBGE como uma camada adicional no editor, ou
seja, como visualizar os dados do IBGE e do OSM em uma mesma
janela, _caso possível_, para facilitar o mapeamento.
O procedimento "artesanal" que faço para o Tracksouce, e que
eu queria otimizar no OSM, é abrir os PDFs do IBGE e os
mapas em janelas separadas para ficar comparando, o que não
é muito produtivo.
Para ficar mais claro, por exemplo, abro um mapa do IBGE e
visualizo um cruzamento entre a Rua X e a Rua Y. Aí, eu abro
o mapa do Tracksource (em outro aplicativo) e tento
localizar esse cruzamento. Feito isso, saio comparando as
informações nessa região para ver se não há mais alguma
informação que eu possa adicionar, como nomes de ruas faltantes.
O problema, é que esses arquivos de mapas, em formato PDF,
são muito fragmentados, e dá muito trabalho ficar abrindo um
por um em janelas distintas das janelas do editor.
Obrigado.
Raffaello Bruno
From:
openstreetmap-qpc2wcgjr8vppgbeqg0jjtbpr1lh4...@public.gmane.org
Date: Mon, 24 Feb 2
