date:20140226

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] Restrições de conversão usando linha como intermediário

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

Re: [Talk-br] Restrições de conversão usando linha como intermediário

2014-02-26 Por tôpico 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.comescreveu:

 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

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 
 nao...@gmail.comescreveu:

 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

Re: [Talk-br] Plugin confaltion do JOSM

2014-02-26 Por tôpico Marcelo Pereira

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 paulo.r.m.carva...@gmail.com:
  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
  erickdeoliveiral...@gmail.com 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
  pereirahol...@gmail.com escreveu:
 
  Erick,
 
  Obrigado pela ajuda, segue o erro apresentado
 
 
 
 
  ERROR: java.lang.NoSuchMethodError:
 
 org.openstreetmap.josm.command.AddPrimitivesCommand.init(Ljava/util/List;Lorg/openstreetmap/josm/gui/layer/OsmDataLayer;)V
  java.lang.NoSuchMethodError:
 
 org.openstreetmap.josm.command.AddPrimitivesCommand.init(Ljava/util/List;Lorg/openstreetmap/josm/gui/layer/OsmDataLayer;)V
  at
 
 org.openstreetmap.josm.plugins.conflation.ConflateMatchCommand.init(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.EventQueue$4.run(EventQueue.java:708)
  at java.awt.EventQueue$4.run(EventQueue.java:706)
  at java.security.AccessController.doPrivileged(Native Method)
  at
 
 java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
  at

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 gwebe...@gmail.com:


 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

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
erickdeoliveiral...@gmail.com:
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

--
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 Por tôpico Erick de Oliveira Leal

O Paulo Carvalho sabe melhor pois ajudou a desenvolver as ferramentas. Eu
só as usava.
Em 26/02/2014 17:25, Fernando Trebien fernando.treb...@gmail.com
escreveu:

Ligavam os pontos? Interessante. Como funcionava isso, exatamente?

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
erickdeoliveiral...@gmail.com:
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?

___
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

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 nao...@gmail.com:
 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



-- 
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

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

2014-02-26 17:29 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com:
 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

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 nao...@gmail.com:
 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

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 nao...@gmail.com:
 2014-02-26 17:29 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com:
 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

2014-02-26 17:44 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com:
 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] Tutorial de restrições de conversão

2014-02-26 Por tôpico 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

Re: [Talk-br] Restrições de conversão usando linha como intermediário

2014-02-26 Por tôpico 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 paulo.r.m.carva...@gmail.com:
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 nao...@gmail.com
escreveu:

2014-02-26 15:24 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com:
Opiniões?

___
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

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
raffaellobr...@hotmail.com:
 Ó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

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 nao...@gmail.com:
 2014-02-26 17:44 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com:
 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] 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 fernando.treb...@gmail.com
escreveu:

Ligavam os pontos? Interessante. Como funcionava isso, exatamente?

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
erickdeoliveiral...@gmail.com:
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?

___
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] 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
pereirahol...@gmail.comescreveu:

 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 paulo.r.m.carva...@gmail.com
 :
  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
  erickdeoliveiral...@gmail.com 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
  pereirahol...@gmail.com escreveu:
 
  Erick,
 
  Obrigado pela ajuda, segue o erro apresentado
 
 
 
 
  ERROR: java.lang.NoSuchMethodError:
 
 org.openstreetmap.josm.command.AddPrimitivesCommand.init(Ljava/util/List;Lorg/openstreetmap/josm/gui/layer/OsmDataLayer;)V
  java.lang.NoSuchMethodError:
 
 org.openstreetmap.josm.command.AddPrimitivesCommand.init(Ljava/util/List;Lorg/openstreetmap/josm/gui/layer/OsmDataLayer;)V
  at
 
 org.openstreetmap.josm.plugins.conflation.ConflateMatchCommand.init(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

Re: [Talk-br] Nomes antigos