date:20140228

Dê um exemplo de alteração.


Em 28 de fevereiro de 2014 11:21, Wallace Silva wsi...@gmail.com escreveu:

 Pessoal estou com um dúvida aqui, estou colocando nome a algumas avenidas
 do estado do Rio, porém estou pegando estas informações do site do DNIT.
 neste caso posso atualizar o nome sem problemas?

 --
 Cordeiro de Deus que tira os pecados do mundo, tenha piedade de nós...

 ___
 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] DNIT

Por poder quer dizer ter autorização legal para isso? Acho que sim.

Daí é só uma questão de saber se o cadastro do DNIT está bem atualizado.

2014-02-28 11:21 GMT-03:00 Wallace Silva wsi...@gmail.com:
 Pessoal estou com um dúvida aqui, estou colocando nome a algumas avenidas do
 estado do Rio, porém estou pegando estas informações do site do DNIT. neste
 caso posso atualizar o nome sem problemas?

 --
 Cordeiro de Deus que tira os pecados do mundo, tenha piedade de nós...

 ___
 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] Importação Funai

2014-02-28 Thread Augusto Stoffel

Pessoal,

Importei o primeiro arquivo do conjunto de dados da Funai.  Se você
quiser ajudar importando um arquivo, dê uma olhada em

http://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Terras_ind%C3%
ADgenas

Na wiki há algumas instruções para importadores.  Qualquer dúvida, não
hesite em me contatar.

Para fazer uma pequena propaganda, queria lembrar que terras indígenas
ocupam algo em torno de 20 a 30% da Amazônia e essa importação vai
reduzir drasticamente a quantidade de vazio na região norte.



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

Re: [Talk-br] Nós isolados sem tags

Fernando,
estou alinhando um trecho de BR-316 pelo iD e achei alguns pontos (por exemplo: 
Nó: 658400960), que aparentemente não têm tag alguma. Posso excluí-los? Já 
excluí alguns, mas depois fiquei com receio que houvesse algo escondido 
nesses pontos.
Obrigado.Raffaello Bruno
 From: fernando.treb...@gmail.com
 Date: Thu, 27 Feb 2014 19:33:36 -0300
 To: talk-br@openstreetmap.org
 Subject: Re: [Talk-br] Nós isolados sem tags

 Só pra esclarecer (pro Paulo e talvez outros que estejam vendo pela
 primeira vez): type:node untagged -child é uma expressão pra busca
 no JOSM.

 2014-02-27 19:18 GMT-03:00 John Packer john.pack...@gmail.com:
  Encontrei aqui como selecionar:
  https://help.openstreetmap.org/questions/18424/josm-search-function-find-orphan-nodes
  A resposta é type:node untagged -child

  Em 27 de fevereiro de 2014 19:07, Paulo Carvalho
  paulo.r.m.carva...@gmail.com escreveu:

  Pessoal,

 Como selecionar nós soltos e sem tags no JOSM?  Tentei usar os filtors,
  mas não consegui uma forma de separar os nós sem tags que pertencem a 
  linhas
  (esses devem ficar, evidentemente) daqueles que estão soltos (esses quero
  eliminar).

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

 -- 
 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] Formatação de trevos e rotatórias

2014-02-28 16:46 GMT-03:00 Raffaello Bruno Limongi Freire
raffaellobr...@hotmail.com:
 Por exemplo, estou analisando aa rotatória representada pela Linha:
 248097232, onde a formatação está como unclassified. Porém, ela liga BRs que
 têm a classificação primary. Além disso, as vias de acesso estão formatadas
 como secondary_link. Acho que todas essas vias (rotatórias e acessos) devem
 ter a mesma formatação das vias ao quais estão interligadas, para que não
 haja descontinuidades de formatação que poderiam influenciar o roteamento.

Não é uma rotatória :-)
E esse trecho, junto com os secondary_link, devem ser todos
primary_link na verdade.

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

Re: [Talk-br] Formatação de trevos e rotatórias

Verdade, não é um círculo completo, mas na falta de outro termo chamei de 
rotatória mesmo :).
Aproveitando a oportunidade, não seria somente o semi-círculo que deveria ser 
formatado como primary_link? Ou sempre que uma via se divide em duas de mão 
única esses trechos devem ser formatados como links? Teria problema deixar os 
acessos como primary também, visto serem apenas a continuação da BR?
Obrigado pela atenção.Raffaello Bruno

 Date: Fri, 28 Feb 2014 16:49:31 -0300
 From: nao...@gmail.com
 To: talk-br@openstreetmap.org
 Subject: Re: [Talk-br]Formatação de trevos e rotatórias

 2014-02-28 16:46 GMT-03:00 Raffaello Bruno Limongi Freire
 raffaellobr...@hotmail.com:
  Por exemplo, estou analisando aa rotatória representada pela Linha:
  248097232, onde a formatação está como unclassified. Porém, ela liga BRs que
  têm a classificação primary. Além disso, as vias de acesso estão formatadas
  como secondary_link. Acho que todas essas vias (rotatórias e acessos) devem
  ter a mesma formatação das vias ao quais estão interligadas, para que não
  haja descontinuidades de formatação que poderiam influenciar o roteamento.

 Não é uma rotatória :-)
 E esse trecho, junto com os secondary_link, devem ser todos
 primary_link na verdade.

 ___
 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] Formatação de trevos e rotatórias

2014-02-28 17:53 GMT-03:00 Raffaello Bruno Limongi Freire
raffaellobr...@hotmail.com:
 Aproveitando a oportunidade, não seria somente o semi-círculo que deveria
 ser formatado como primary_link? Ou sempre que uma via se divide em duas de
 mão única esses trechos devem ser formatados como links? Teria problema
 deixar os acessos como primary também, visto serem apenas a continuação da
 BR?

Os dois acessos que partem da BR-424 abaixo até poderiam ser primary.
Mas o resto é primary_link (o semi-círculo + acessos das BR-316)

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

Re: [Talk-br] Formatação de trevos e rotatórias

Ah, só acrescentando uma informação pro Raffaello: rotatória é só
quando o trânsito é livre ao longo de todo o ciclo, e tem que ser um
ciclo completo, geralmente é um círculo mas pode ter umas formas
mais estranhas. Se tiver placa Pare (ou sinalização horizontal
equivalente) ou semáforo, não é rotatória, é só uma estrutura
circular.

Eu não sou de Maceió e o Street View não me ajuda muito nesse caso,
mas pelo que parece você é obrigado a parar para entrar na BR-316.

Olhando pela imagem do satélite (que surpreendentemente está melhor no
Bing do que no Google), não tem sinalização horizontal, então só
visitando o lugar pra ter certeza das placas.

Mas vou tentar adivinhar (posso estar errado): quem vem pelo círculo
provavelmente precisa parar pra entrar nas ligações secundárias,
principalmente porque o trecho no círculo em que se pode acelerar é
curto e o trecho das ligações nas entradas vindo das rodovias BR-316 e
BR-424 é longo e suave, dando a entender que foram feitos para deixar
os veículos passar em alta velocidade.

Dois outros detalhes que reparei: tanto o círculo quanto as ligações
seriam primary_link porque ligam vias primárias, e faltam restrições
de conversão no_u_turn:
- aqui: http://www.openstreetmap.org/way/248097237
- e aqui: http://www.openstreetmap.org/node/2549421845

Se tiver dúvidas, só avisar. :D

2014-02-28 16:49 GMT-03:00 Nelson A. de Oliveira nao...@gmail.com:
 2014-02-28 16:46 GMT-03:00 Raffaello Bruno Limongi Freire
 raffaellobr...@hotmail.com:
 Por exemplo, estou analisando aa rotatória representada pela Linha:
 248097232, onde a formatação está como unclassified. Porém, ela liga BRs que
 têm a classificação primary. Além disso, as vias de acesso estão formatadas
 como secondary_link. Acho que todas essas vias (rotatórias e acessos) devem
 ter a mesma formatação das vias ao quais estão interligadas, para que não
 haja descontinuidades de formatação que poderiam influenciar o roteamento.

 Não é uma rotatória :-)
 E esse trecho, junto com os secondary_link, devem ser todos
 primary_link na verdade.

 ___
 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] Nós isolados sem tags

Se eles não têm tags e não for deformar a geometria (eu sigo a regra
de que qualquer ponto ao longo da linha desenhada tem que estar a no
máximo 3m de distância do centro da via, pra qualquer dos lados - 3m é
aproximadamente a largura de uma pista), então pode remover sim.

Pessoas diferentes adotam um limiar diferente - 3m, 2m, 1m. Meus 3m
vieram da configuração padrão do simplificador do JOSM, e até hoje
foram poucos os casos em que eu precisei de mais precisão do que isso
(mas às vezes 3m fica meio grotesco, especialmente em curvas muito
fechadas, daí precisa mais pontos).

2014-02-28 16:24 GMT-03:00 Raffaello Bruno Limongi Freire
raffaellobr...@hotmail.com:
 Fernando,

 estou alinhando um trecho de BR-316 pelo iD e achei alguns pontos (por
 exemplo: Nó: 658400960), que aparentemente não têm tag alguma. Posso
 excluí-los? Já excluí alguns, mas depois fiquei com receio que houvesse algo
 escondido nesses pontos.

 Obrigado.
 Raffaello Bruno

 From: fernando.treb...@gmail.com
 Date: Thu, 27 Feb 2014 19:33:36 -0300
 To: talk-br@openstreetmap.org
 Subject: Re: [Talk-br] Nós isolados sem tags


 Só pra esclarecer (pro Paulo e talvez outros que estejam vendo pela
 primeira vez): type:node untagged -child é uma expressão pra busca
 no JOSM.

 2014-02-27 19:18 GMT-03:00 John Packer john.pack...@gmail.com:
  Encontrei aqui como selecionar:
 
  https://help.openstreetmap.org/questions/18424/josm-search-function-find-orphan-nodes
  A resposta é type:node untagged -child
 
 
  Em 27 de fevereiro de 2014 19:07, Paulo Carvalho
  paulo.r.m.carva...@gmail.com escreveu:
 
  Pessoal,
 
  Como selecionar nós soltos e sem tags no JOSM? Tentei usar os filtors,
  mas não consegui uma forma de separar os nós sem tags que pertencem a
  linhas
  (esses devem ficar, evidentemente) daqueles que estão soltos (esses
  quero
  eliminar).
 
  []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
 



 --
 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] Formatação de trevos e rotatórias

2014-02-28 Thread John Packer

Olá Raffaelo, estou enviando esta mensagem somente para você.

Só queria avisar que os seus emails de hoje  estão com uma formatação
estranha (com 3 fontes diferentes sendo usadas, e 2 tamanhos de fonte).

Abs,
João


Em 28 de fevereiro de 2014 16:46, Raffaello Bruno Limongi Freire 
raffaellobr...@hotmail.com escreveu:

 Oi,

 gostaria de saber se há alguma orientação disponível sobre a formatação
 de trevos e rotatórias.

 Por exemplo, estou analisando aa rotatória representada pela Linha:
 248097232, onde a formatação está como unclassified. Porém, ela liga BRs
 que têm a classificação primary. Além disso, as vias de acesso estão
 formatadas como secondary_link. Acho que todas essas vias (rotatórias e
 acessos) devem ter a mesma formatação das vias ao quais estão interligadas,
 para que não haja descontinuidades de formatação que poderiam influenciar o
 roteamento.

 Obrigado.
 Raffaello Bruno


 ___
 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] Formatação de trevos e rotatórias

2014-02-28 18:13 GMT-03:00 John Packer john.pack...@gmail.com:
 Olá Raffaelo, estou enviando esta mensagem somente para você.

Veio para todo mundo :-)

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

Re: [Talk-br] Formatação de trevos e rotatórias

Oi, João,
obrigado pela observação. Foi que eu copiei o número da Linha do iD, aí veio 
com uma fonte diferente.
:)Raffaello Bruno

From: john.pack...@gmail.com
Date: Fri, 28 Feb 2014 18:13:11 -0300
To: talk-br@openstreetmap.org
Subject: Re: [Talk-br]  Formatação de trevos e rotatórias

Olá Raffaelo, estou enviando esta mensagem somente para você.

Só queria avisar que os seus emails de hoje  estão com uma formatação estranha 
(com 3 fontes diferentes sendo usadas, e 2 tamanhos de fonte).

Abs,
João

Em 28 de fevereiro de 2014 16:46, Raffaello Bruno Limongi Freire 
raffaellobr...@hotmail.com escreveu:

Oi,
gostaria de saber se há alguma orientação disponível sobre a formatação de 
trevos e rotatórias.

Por exemplo, estou analisando aa rotatória representada pela Linha: 248097232, 
onde a formatação está como unclassified. Porém, ela liga BRs que têm a 
classificação primary. Além disso, as vias de acesso estão formatadas como 
secondary_link. Acho que todas essas vias (rotatórias e acessos) devem ter a 
mesma formatação das vias ao quais estão interligadas, para que não haja 
descontinuidades de formatação que poderiam influenciar o roteamento.

Obrigado.

Raffaello Bruno

___

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] Nós isolados sem tags

Acho que vc está se referindo a nós que interligam segmentos das vias, que às 
vezes eu removo também para reduzir o excesso de fragmentação (principalmente 
quando são divisões desnecessárias em um trecho que é reto), mas a minha dúvida 
era sobre uns pontos que eu achei fora da via e aparentemente sem tag alguma.
Acho que se não aparecer nada no iD é porque realmente não tem tag alguma, não 
é?
Obrigado.

 From: fernando.treb...@gmail.com
 Date: Fri, 28 Feb 2014 18:06:06 -0300
 To: talk-br@openstreetmap.org
 Subject: Re: [Talk-br] Nós isolados sem tags

 Se eles não têm tags e não for deformar a geometria (eu sigo a regra
 de que qualquer ponto ao longo da linha desenhada tem que estar a no
 máximo 3m de distância do centro da via, pra qualquer dos lados - 3m é
 aproximadamente a largura de uma pista), então pode remover sim.

 Pessoas diferentes adotam um limiar diferente - 3m, 2m, 1m. Meus 3m
 vieram da configuração padrão do simplificador do JOSM, e até hoje
 foram poucos os casos em que eu precisei de mais precisão do que isso
 (mas às vezes 3m fica meio grotesco, especialmente em curvas muito
 fechadas, daí precisa mais pontos).

 2014-02-28 16:24 GMT-03:00 Raffaello Bruno Limongi Freire
 raffaellobr...@hotmail.com:
  Fernando,

  estou alinhando um trecho de BR-316 pelo iD e achei alguns pontos (por
  exemplo: Nó: 658400960), que aparentemente não têm tag alguma. Posso
  excluí-los? Já excluí alguns, mas depois fiquei com receio que houvesse algo
  escondido nesses pontos.

  Obrigado.
  Raffaello Bruno

  From: fernando.treb...@gmail.com
  Date: Thu, 27 Feb 2014 19:33:36 -0300
  To: talk-br@openstreetmap.org
  Subject: Re: [Talk-br] Nós isolados sem tags

  Só pra esclarecer (pro Paulo e talvez outros que estejam vendo pela
  primeira vez): type:node untagged -child é uma expressão pra busca
  no JOSM.

  2014-02-27 19:18 GMT-03:00 John Packer john.pack...@gmail.com:
   Encontrei aqui como selecionar:

   https://help.openstreetmap.org/questions/18424/josm-search-function-find-orphan-nodes
   A resposta é type:node untagged -child

   Em 27 de fevereiro de 2014 19:07, Paulo Carvalho
   paulo.r.m.carva...@gmail.com escreveu:

   Pessoal,

   Como selecionar nós soltos e sem tags no JOSM? Tentei usar os filtors,
   mas não consegui uma forma de separar os nós sem tags que pertencem a
   linhas
   (esses devem ficar, evidentemente) daqueles que estão soltos (esses
   quero
   eliminar).

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

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

Re: [Talk-br] Parque aquático não renderizado no slippy map do OSM

Valeu. Abri um ticket lá.

[]s

Em 27 de fevereiro de 2014 19:32, Fernando Trebien
fernando.treb...@gmail.com escreveu:

A folha de estilo padrão do site (que usa um estilo Mapcss carregado
pelo TileMill, que usa o Mapnik por baixo dos panos) e o OSM-Carto:
https://github.com/gravitystorm/openstreetmap-carto/

Enquanto não atenderem o seu ticket, acho que você pode atribuir uma
tag landuse=recreation_ground (além das tags que já tem).

Acho que você sugerir uma renderização igual a park ou a recreation ground.

Alguns outros valores de leisure (como leisure=dog_park e
leisure=firepit) também não são renderizados e talvez deveriam ser.
http://wiki.openstreetmap.org/wiki/Key:leisure

2014-02-27 19:09 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com:
Eu coloquei o estacionamento, o clube, o acesso (esses três aparecem) e o
parque no mesmo changeset. Se fosse problema de cache nenhum deles
deveria
aparecer.

Em 27 de fevereiro de 2014 18:59, Gerald Weber gwebe...@gmail.com
escreveu:

Para mim aparece. Há quanto tempo você colocou? Pode ser um problema do
cache do seu navegador.

abraço

Gerald

2014-02-27 18:54 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com
:

Pessoal,

Recentemente coloquei um parque aquático aqui:
http://www.openstreetmap.org/#map=17/-22.98126/-43.48673 , mas o
mesmo não
está sendo renderizado. Pesquisei onde reportar o problema, mas
aparentemente não existe onde reportar:

http://wiki.openstreetmap.org/wiki/Talk:Slippy_Map#Contcact.2C_error_.2B_wishlist_reporting.3F
.
Parece algum problema da folha de estilo e não do Mapnik. O parque
deveria aparece ao sul do estacionamento e à direita do caminho
acesso Rio
Water Planet

[]s

___
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] Nós isolados sem tags

2014-02-28 Thread Arlindo Pereira

Verifique se os pontos, apesar de não possuírem tags, fazem parte de uma
relação.

[]s

2014-02-28 18:21 GMT-03:00 Raffaello Bruno Limongi Freire 
raffaellobr...@hotmail.com:

 Acho que vc está se referindo a nós que interligam segmentos das vias, que
 às vezes eu removo também para reduzir o excesso de fragmentação
 (principalmente quando são divisões desnecessárias em um trecho que é
 reto), mas a minha dúvida era sobre uns pontos que eu achei fora da via e
 aparentemente sem tag alguma.

 Acho que se não aparecer nada no iD é porque realmente não tem tag alguma,
 não é?

 Obrigado.

  From: fernando.treb...@gmail.com
  Date: Fri, 28 Feb 2014 18:06:06 -0300

  To: talk-br@openstreetmap.org
  Subject: Re: [Talk-br] Nós isolados sem tags
 
  Se eles não têm tags e não for deformar a geometria (eu sigo a regra
  de que qualquer ponto ao longo da linha desenhada tem que estar a no
  máximo 3m de distância do centro da via, pra qualquer dos lados - 3m é
  aproximadamente a largura de uma pista), então pode remover sim.
 
  Pessoas diferentes adotam um limiar diferente - 3m, 2m, 1m. Meus 3m
  vieram da configuração padrão do simplificador do JOSM, e até hoje
  foram poucos os casos em que eu precisei de mais precisão do que isso
  (mas às vezes 3m fica meio grotesco, especialmente em curvas muito
  fechadas, daí precisa mais pontos).
 
  2014-02-28 16:24 GMT-03:00 Raffaello Bruno Limongi Freire
  raffaellobr...@hotmail.com:
   Fernando,
  
   estou alinhando um trecho de BR-316 pelo iD e achei alguns pontos (por
   exemplo: Nó: 658400960), que aparentemente não têm tag alguma. Posso
   excluí-los? Já excluí alguns, mas depois fiquei com receio que
 houvesse algo
   escondido nesses pontos.
  
   Obrigado.
   Raffaello Bruno
  
   From: fernando.treb...@gmail.com
   Date: Thu, 27 Feb 2014 19:33:36 -0300
   To: talk-br@openstreetmap.org
   Subject: Re: [Talk-br] Nós isolados sem tags
  
  
   Só pra esclarecer (pro Paulo e talvez outros que estejam vendo pela
   primeira vez): type:node untagged -child é uma expressão pra busca
   no JOSM.
  
   2014-02-27 19:18 GMT-03:00 John Packer john.pack...@gmail.com:
Encontrei aqui como selecionar:
   
   
 https://help.openstreetmap.org/questions/18424/josm-search-function-find-orphan-nodes
A resposta é type:node untagged -child
   
   
Em 27 de fevereiro de 2014 19:07, Paulo Carvalho
paulo.r.m.carva...@gmail.com escreveu:
   
Pessoal,
   
Como selecionar nós soltos e sem tags no JOSM? Tentei usar os
 filtors,
mas não consegui uma forma de separar os nós sem tags que
 pertencem a
linhas
(esses devem ficar, evidentemente) daqueles que estão soltos (esses
quero
eliminar).
   
[]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
   
  
  
  
   --
   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

 ___
 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] Nós isolados sem tags

Sem relações e sem etiquetas. Já excluí.
Obrigado pela observação.

From: openstreet...@arlindopereira.com
Date: Fri, 28 Feb 2014 19:00:57 -0300
To: talk-br@openstreetmap.org
Subject: Re: [Talk-br] Nós isolados sem tags

Verifique se os pontos, apesar de não possuírem tags, fazem parte de uma 
relação.
[]s

2014-02-28 18:21 GMT-03:00 Raffaello Bruno Limongi Freire 
raffaellobr...@hotmail.com:

Acho que vc está se referindo a nós que interligam segmentos das vias, que às 
vezes eu removo também para reduzir o excesso de fragmentação (principalmente 
quando são divisões desnecessárias em um trecho que é reto), mas a minha dúvida 
era sobre uns pontos que eu achei fora da via e aparentemente sem tag alguma.

Acho que se não aparecer nada no iD é porque realmente não tem tag alguma, não 
é?
Obrigado.

 From: fernando.treb...@gmail.com

 Date: Fri, 28 Feb 2014 18:06:06 -0300
 To: talk-br@openstreetmap.org
 Subject: Re: [Talk-br] Nós isolados sem tags

 Se eles não têm tags e não for deformar a geometria (eu sigo a regra
 de que qualquer ponto ao longo da linha desenhada tem que estar a no
 máximo 3m de distância do centro da via, pra qualquer dos lados - 3m é

 aproximadamente a largura de uma pista), então pode remover sim.

 Pessoas diferentes adotam um limiar diferente - 3m, 2m, 1m. Meus 3m
 vieram da configuração padrão do simplificador do JOSM, e até hoje

 foram poucos os casos em que eu precisei de mais precisão do que isso
 (mas às vezes 3m fica meio grotesco, especialmente em curvas muito
 fechadas, daí precisa mais pontos).

 2014-02-28 16:24 GMT-03:00 Raffaello Bruno Limongi Freire

 raffaellobr...@hotmail.com:
  Fernando,

  estou alinhando um trecho de BR-316 pelo iD e achei alguns pontos (por

  exemplo: Nó: 658400960), que aparentemente não têm tag alguma. Posso
  excluí-los? Já excluí alguns, mas depois fiquei com receio que houvesse algo
  escondido nesses pontos.

  Obrigado.
  Raffaello Bruno

  From: fernando.treb...@gmail.com
  Date: Thu, 27 Feb 2014 19:33:36 -0300

  To: talk-br@openstreetmap.org
  Subject: Re: [Talk-br] Nós isolados sem tags

  Só pra esclarecer (pro Paulo e talvez outros que estejam vendo pela

  primeira vez): type:node untagged -child é uma expressão pra busca
  no JOSM.

  2014-02-27 19:18 GMT-03:00 John Packer john.pack...@gmail.com:

   Encontrei aqui como selecionar:

   https://help.openstreetmap.org/questions/18424/josm-search-function-find-orphan-nodes

   A resposta é type:node untagged -child

   Em 27 de fevereiro de 2014 19:07, Paulo Carvalho
   paulo.r.m.carva...@gmail.com escreveu:

   Pessoal,

   Como selecionar nós soltos e sem tags no JOSM? Tentei usar os filtors,
   mas não consegui uma forma de separar os nós sem tags que pertencem a

   linhas
   (esses devem ficar, evidentemente) daqueles que estão soltos (esses
   quero
   eliminar).

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

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

___

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] Formatação de trevos e rotatórias

A tag para assinalar rotatórias é junction=roundabout .

Em 28 de fevereiro de 2014 18:29, Raffaello Bruno Limongi Freire 
raffaellobr...@hotmail.com escreveu:

 Tem alguma tag pra dizer se é rotatória ou não?

  From: fernando.treb...@gmail.com
  Date: Fri, 28 Feb 2014 17:59:43 -0300

  To: talk-br@openstreetmap.org
  Subject: Re: [Talk-br] Formatação de trevos e rotatórias

  Ah, só acrescentando uma informação pro Raffaello: rotatória é só
  quando o trânsito é livre ao longo de todo o ciclo, e tem que ser um
  ciclo completo, geralmente é um círculo mas pode ter umas formas
  mais estranhas. Se tiver placa Pare (ou sinalização horizontal
  equivalente) ou semáforo, não é rotatória, é só uma estrutura
  circular.

  Eu não sou de Maceió e o Street View não me ajuda muito nesse caso,
  mas pelo que parece você é obrigado a parar para entrar na BR-316.

  Olhando pela imagem do satélite (que surpreendentemente está melhor no
  Bing do que no Google), não tem sinalização horizontal, então só
  visitando o lugar pra ter certeza das placas.

  Mas vou tentar adivinhar (posso estar errado): quem vem pelo círculo
  provavelmente precisa parar pra entrar nas ligações secundárias,
  principalmente porque o trecho no círculo em que se pode acelerar é
  curto e o trecho das ligações nas entradas vindo das rodovias BR-316 e
  BR-424 é longo e suave, dando a entender que foram feitos para deixar
  os veículos passar em alta velocidade.

  Dois outros detalhes que reparei: tanto o círculo quanto as ligações
  seriam primary_link porque ligam vias primárias, e faltam restrições
  de conversão no_u_turn:
  - aqui: http://www.openstreetmap.org/way/248097237
  - e aqui: http://www.openstreetmap.org/node/2549421845

  Se tiver dúvidas, só avisar. :D

  2014-02-28 16:49 GMT-03:00 Nelson A. de Oliveira nao...@gmail.com:

   2014-02-28 16:46 GMT-03:00 Raffaello Bruno Limongi Freire
   raffaellobr...@hotmail.com:
   Por exemplo, estou analisando aa rotatória representada pela Linha:
   248097232, onde a formatação está como unclassified. Porém, ela liga
 BRs que
   têm a classificação primary. Além disso, as vias de acesso estão
 formatadas
   como secondary_link. Acho que todas essas vias (rotatórias e acessos)
 devem
   ter a mesma formatação das vias ao quais estão interligadas, para que
 não
   haja descontinuidades de formatação que poderiam influenciar o
 roteamento.

   Não é uma rotatória :-)
   E esse trecho, junto com os secondary_link, devem ser todos
   primary_link na verdade.

   ___
   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] Formatação de trevos e rotatórias

Um artigo compreensivo sobre rotatórias e assemelhados:
http://wiki.openstreetmap.org/wiki/Tag:junction%3Droundabout


Em 28 de fevereiro de 2014 19:06, Paulo Carvalho 
paulo.r.m.carva...@gmail.com escreveu:

 A tag para assinalar rotatórias é junction=roundabout .


 Em 28 de fevereiro de 2014 18:29, Raffaello Bruno Limongi Freire 
 raffaellobr...@hotmail.com escreveu:

  Tem alguma tag pra dizer se é rotatória ou não?

  From: fernando.treb...@gmail.com
  Date: Fri, 28 Feb 2014 17:59:43 -0300

  To: talk-br@openstreetmap.org
  Subject: Re: [Talk-br] Formatação de trevos e rotatórias
 
  Ah, só acrescentando uma informação pro Raffaello: rotatória é só
  quando o trânsito é livre ao longo de todo o ciclo, e tem que ser um
  ciclo completo, geralmente é um círculo mas pode ter umas formas
  mais estranhas. Se tiver placa Pare (ou sinalização horizontal
  equivalente) ou semáforo, não é rotatória, é só uma estrutura
  circular.
 
  Eu não sou de Maceió e o Street View não me ajuda muito nesse caso,
  mas pelo que parece você é obrigado a parar para entrar na BR-316.
 
  Olhando pela imagem do satélite (que surpreendentemente está melhor no
  Bing do que no Google), não tem sinalização horizontal, então só
  visitando o lugar pra ter certeza das placas.
 
  Mas vou tentar adivinhar (posso estar errado): quem vem pelo círculo
  provavelmente precisa parar pra entrar nas ligações secundárias,
  principalmente porque o trecho no círculo em que se pode acelerar é
  curto e o trecho das ligações nas entradas vindo das rodovias BR-316 e
  BR-424 é longo e suave, dando a entender que foram feitos para deixar
  os veículos passar em alta velocidade.
 
  Dois outros detalhes que reparei: tanto o círculo quanto as ligações
  seriam primary_link porque ligam vias primárias, e faltam restrições
  de conversão no_u_turn:
  - aqui: http://www.openstreetmap.org/way/248097237
  - e aqui: http://www.openstreetmap.org/node/2549421845
 
  Se tiver dúvidas, só avisar. :D
 
  2014-02-28 16:49 GMT-03:00 Nelson A. de Oliveira nao...@gmail.com:

   2014-02-28 16:46 GMT-03:00 Raffaello Bruno Limongi Freire
   raffaellobr...@hotmail.com:
   Por exemplo, estou analisando aa rotatória representada pela Linha:
   248097232, onde a formatação está como unclassified. Porém, ela liga
 BRs que
   têm a classificação primary. Além disso, as vias de acesso estão
 formatadas
   como secondary_link. Acho que todas essas vias (rotatórias e
 acessos) devem
   ter a mesma formatação das vias ao quais estão interligadas, para
 que não
   haja descontinuidades de formatação que poderiam influenciar o
 roteamento.
  
   Não é uma rotatória :-)
   E esse trecho, junto com os secondary_link, devem ser todos
   primary_link na verdade.
  
   ___
   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] Nós isolados sem tags

Mais um motivo pro editor alertar né. No JOSM não precisa se preocupar com
isso.
On Feb 28, 2014 7:02 PM, Arlindo Pereira openstreet...@arlindopereira.com
wrote:

 Verifique se os pontos, apesar de não possuírem tags, fazem parte de uma
 relação.

 []s

 2014-02-28 18:21 GMT-03:00 Raffaello Bruno Limongi Freire 
 raffaellobr...@hotmail.com:

 Acho que vc está se referindo a nós que interligam segmentos das vias,
 que às vezes eu removo também para reduzir o excesso de fragmentação
 (principalmente quando são divisões desnecessárias em um trecho que é
 reto), mas a minha dúvida era sobre uns pontos que eu achei fora da via e
 aparentemente sem tag alguma.

 Acho que se não aparecer nada no iD é porque realmente não tem tag
 alguma, não é?

 Obrigado.

  From: fernando.treb...@gmail.com
  Date: Fri, 28 Feb 2014 18:06:06 -0300

  To: talk-br@openstreetmap.org
  Subject: Re: [Talk-br] Nós isolados sem tags
 
  Se eles não têm tags e não for deformar a geometria (eu sigo a regra
  de que qualquer ponto ao longo da linha desenhada tem que estar a no
  máximo 3m de distância do centro da via, pra qualquer dos lados - 3m é
  aproximadamente a largura de uma pista), então pode remover sim.
 
  Pessoas diferentes adotam um limiar diferente - 3m, 2m, 1m. Meus 3m
  vieram da configuração padrão do simplificador do JOSM, e até hoje
  foram poucos os casos em que eu precisei de mais precisão do que isso
  (mas às vezes 3m fica meio grotesco, especialmente em curvas muito
  fechadas, daí precisa mais pontos).
 
  2014-02-28 16:24 GMT-03:00 Raffaello Bruno Limongi Freire
  raffaellobr...@hotmail.com:
   Fernando,
  
   estou alinhando um trecho de BR-316 pelo iD e achei alguns pontos (por
   exemplo: Nó: 658400960), que aparentemente não têm tag alguma. Posso
   excluí-los? Já excluí alguns, mas depois fiquei com receio que
 houvesse algo
   escondido nesses pontos.
  
   Obrigado.
   Raffaello Bruno
  
   From: fernando.treb...@gmail.com
   Date: Thu, 27 Feb 2014 19:33:36 -0300
   To: talk-br@openstreetmap.org
   Subject: Re: [Talk-br] Nós isolados sem tags
  
  
   Só pra esclarecer (pro Paulo e talvez outros que estejam vendo pela
   primeira vez): type:node untagged -child é uma expressão pra busca
   no JOSM.
  
   2014-02-27 19:18 GMT-03:00 John Packer john.pack...@gmail.com:
Encontrei aqui como selecionar:
   
   
 https://help.openstreetmap.org/questions/18424/josm-search-function-find-orphan-nodes
A resposta é type:node untagged -child
   
   
Em 27 de fevereiro de 2014 19:07, Paulo Carvalho
paulo.r.m.carva...@gmail.com escreveu:
   
Pessoal,
   
Como selecionar nós soltos e sem tags no JOSM? Tentei usar os
 filtors,
mas não consegui uma forma de separar os nós sem tags que
 pertencem a
linhas
(esses devem ficar, evidentemente) daqueles que estão soltos
 (esses
quero
eliminar).
   
[]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
   
  
  
  
   --
   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

 ___
 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] Formatação de trevos e rotatórias

2014-02-28 18:29 GMT-03:00 Raffaello Bruno Limongi Freire
raffaellobr...@hotmail.com:
 Tem alguma tag pra dizer se é rotatória ou não?

junction = roundabout

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

Re: [Talk-br] Formatação de trevos e rotatórias

Criei duas restrições. Depois alguém confere por favor.
http://www.openstreetmap.org/node/2549421845http://www.openstreetmap.org/node/2549421866

 From: fernando.treb...@gmail.com
 Date: Fri, 28 Feb 2014 17:59:43 -0300
 To: talk-br@openstreetmap.org
 Subject: Re: [Talk-br]Formatação de trevos e rotatórias

 Ah, só acrescentando uma informação pro Raffaello: rotatória é só
 quando o trânsito é livre ao longo de todo o ciclo, e tem que ser um
 ciclo completo, geralmente é um círculo mas pode ter umas formas
 mais estranhas. Se tiver placa Pare (ou sinalização horizontal
 equivalente) ou semáforo, não é rotatória, é só uma estrutura
 circular.

 Eu não sou de Maceió e o Street View não me ajuda muito nesse caso,
 mas pelo que parece você é obrigado a parar para entrar na BR-316.

 Olhando pela imagem do satélite (que surpreendentemente está melhor no
 Bing do que no Google), não tem sinalização horizontal, então só
 visitando o lugar pra ter certeza das placas.

 Mas vou tentar adivinhar (posso estar errado): quem vem pelo círculo
 provavelmente precisa parar pra entrar nas ligações secundárias,
 principalmente porque o trecho no círculo em que se pode acelerar é
 curto e o trecho das ligações nas entradas vindo das rodovias BR-316 e
 BR-424 é longo e suave, dando a entender que foram feitos para deixar
 os veículos passar em alta velocidade.

 Dois outros detalhes que reparei: tanto o círculo quanto as ligações
 seriam primary_link porque ligam vias primárias, e faltam restrições
 de conversão no_u_turn:
 - aqui: http://www.openstreetmap.org/way/248097237
 - e aqui: http://www.openstreetmap.org/node/2549421845

 Se tiver dúvidas, só avisar. :D

 2014-02-28 16:49 GMT-03:00 Nelson A. de Oliveira nao...@gmail.com:
  2014-02-28 16:46 GMT-03:00 Raffaello Bruno Limongi Freire
  raffaellobr...@hotmail.com:
  Por exemplo, estou analisando aa rotatória representada pela Linha:
  248097232, onde a formatação está como unclassified. Porém, ela liga BRs 
  que
  têm a classificação primary. Além disso, as vias de acesso estão formatadas
  como secondary_link. Acho que todas essas vias (rotatórias e acessos) devem
  ter a mesma formatação das vias ao quais estão interligadas, para que não
  haja descontinuidades de formatação que poderiam influenciar o roteamento.

  Não é uma rotatória :-)
  E esse trecho, junto com os secondary_link, devem ser todos
  primary_link na verdade.

  ___
  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] BR-101

2014-02-28 Thread John Packer

Pessoal, sobre a BR-101,
A relação dela está bem quebrada.
Isso sempre foi assim, ou quebraram com o tempo?

Achei engraçado que uma igreja se adicionou na relação por alguma razão.

Link da relação: http://www.openstreetmap.org/relation/53556

Abs,
João
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] BR-101

2014-02-28 Thread Arlindo Pereira

Não sei dizer, mas sei que é esse tipo de relação que o Trebien se refere
quando reclama dos editores que não suportam corretamente relações.
Em 28/02/2014 20:21, John Packer john.pack...@gmail.com escreveu:

 Pessoal, sobre a BR-101,
 A relação dela está bem quebrada.
 Isso sempre foi assim, ou quebraram com o tempo?

 Achei engraçado que uma igreja se adicionou na relação por alguma razão.

 Link da relação: http://www.openstreetmap.org/relation/53556

 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

Re: [Talk-br] Plugin confaltion do JOSM

2014-02-28 Thread Marcelo Pereira

Já abri o ticket, espero que o meu ingleis tenha sido inteligível.

Obrigado pelas dicas.

Marcelo Pereira


Em 27 de fevereiro de 2014 11:00, Fernando Trebien 
fernando.treb...@gmail.com escreveu:

 +1000

 2014-02-26 19:53 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com:
  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.com
  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
  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

Re: [Talk-br] Formatação de trevos e rotatórias

Estão certas. :D

Agora só falta mais uma na parte sul (onde começa a BR-424) envolvendo
as duas ligações.

2014-02-28 19:24 GMT-03:00 Raffaello Bruno Limongi Freire
raffaellobr...@hotmail.com:
 Criei duas restrições. Depois alguém confere por favor.

 http://www.openstreetmap.org/node/2549421845
 http://www.openstreetmap.org/node/2549421866

 From: fernando.treb...@gmail.com
 Date: Fri, 28 Feb 2014 17:59:43 -0300
 To: talk-br@openstreetmap.org
 Subject: Re: [Talk-br] Formatação de trevos e rotatórias

 Ah, só acrescentando uma informação pro Raffaello: rotatória é só
 quando o trânsito é livre ao longo de todo o ciclo, e tem que ser um
 ciclo completo, geralmente é um círculo mas pode ter umas formas
 mais estranhas. Se tiver placa Pare (ou sinalização horizontal
 equivalente) ou semáforo, não é rotatória, é só uma estrutura
 circular.

 Eu não sou de Maceió e o Street View não me ajuda muito nesse caso,
 mas pelo que parece você é obrigado a parar para entrar na BR-316.

 Olhando pela imagem do satélite (que surpreendentemente está melhor no
 Bing do que no Google), não tem sinalização horizontal, então só
 visitando o lugar pra ter certeza das placas.

 Mas vou tentar adivinhar (posso estar errado): quem vem pelo círculo
 provavelmente precisa parar pra entrar nas ligações secundárias,
 principalmente porque o trecho no círculo em que se pode acelerar é
 curto e o trecho das ligações nas entradas vindo das rodovias BR-316 e
 BR-424 é longo e suave, dando a entender que foram feitos para deixar
 os veículos passar em alta velocidade.

 Dois outros detalhes que reparei: tanto o círculo quanto as ligações
 seriam primary_link porque ligam vias primárias, e faltam restrições
 de conversão no_u_turn:
 - aqui: http://www.openstreetmap.org/way/248097237
 - e aqui: http://www.openstreetmap.org/node/2549421845

 Se tiver dúvidas, só avisar. :D

 2014-02-28 16:49 GMT-03:00 Nelson A. de Oliveira nao...@gmail.com:
  2014-02-28 16:46 GMT-03:00 Raffaello Bruno Limongi Freire
  raffaellobr...@hotmail.com:
  Por exemplo, estou analisando aa rotatória representada pela Linha:
  248097232, onde a formatação está como unclassified. Porém, ela liga
  BRs que
  têm a classificação primary. Além disso, as vias de acesso estão
  formatadas
  como secondary_link. Acho que todas essas vias (rotatórias e acessos)
  devem
  ter a mesma formatação das vias ao quais estão interligadas, para que
  não
  haja descontinuidades de formatação que poderiam influenciar o
  roteamento.
 
  Não é uma rotatória :-)
  E esse trecho, junto com os secondary_link, devem ser todos
  primary_link na verdade.
 
  ___
  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] BR-101

Tem o plugin public_transport do JOSM que ajuda a mapear rotas de
ônibus, mas a sua vantagem principal é reconhecer as paradas e
incluí-las na relação da rota. Se você só quer consertar a rota, o
editor genérico do JOSM até dá menos trabalho.

Os passos são sempre os mesmos: criar uma relação (se não existir) ou
baixá-la no JOSM (menu Arquivo/Ficheiro Descarregar Objeto), e
adicionar os membros que faltam. Pra garantir que não sobraram
buracos, tem um botão no editor de relações do JOSM que põe em ordem
os membros da relação de acordo com a ordem em que se conectam, e daí
a terceira coluna (destaque #2 da primeira imagem aqui:
http://wiki.openstreetmap.org/wiki/File:Tutorial-restricoes-07-exemplo-05-linha-como-intermediario.png)
indica em que trechos a via não está conectada (onde faltam pedaços ou
onde há pedaços que se sobrepõem). Use o botão, olhe a coluna, inclua
os trechos que faltam, ordene de novo, observe a coluna de novo,
repita até não sobrarem falhas. É um trabalho chato, mas não tem jeito
melhor de fazer (ainda). E em algumas situações, não há uma correção
óbvia: você tem que parar e descobrir como a rota era originalmente
pra descobrir qual membro reincluir na relação.

Ah, e o validador do JOSM também avisa sobre relações de rota com
trechos desconectados.

2014-02-28 21:36 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com:
Confesso que andei quebrando umas rotas, porém não consegui consertar. É
muito complicado de fazer no JOSM, ainda mais essas rotas que são muito
extensas. Há algum plugin ou tutorial que ensine a desenhar essas rotas de
transporte público?

Em 28 de fevereiro de 2014 20:20, John Packer john.pack...@gmail.com
escreveu:

Pessoal, sobre a BR-101,
A relação dela está bem quebrada.
Isso sempre foi assim, ou quebraram com o tempo?

Achei engraçado que uma igreja se adicionou na relação por alguma razão.

Link da relação: http://www.openstreetmap.org/relation/53556

Abs,
Joã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-de] Eintrag von Gewann-Namen

2014-02-28 Thread Falk Zscheile

Am 27. Februar 2014 23:16 schrieb Bernhard Weiskopf bweisk...@gmx.de:
 Hallo an alle,

 wie trägt man in OSM die Namen von Gewannen ein, dass sie in Mapnik
 angezeigt werden?


Wenn das Gewann nicht noch in einzelne Felder unterteilt ist, so würde
ich es einfach an das entsprechende Feld als name-Tag setzen.
Andernfalls hilft vielleicht auch eine site-Relation (?). Schließlich
gibt es noch place=locality name=value. Letzteres wird auch für Fälle
wie deinen gebraucht.

Gruß
Falk

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Keine Namen in Mapnik und anderen Karten

2014-02-28 Thread Georg Feddern


Am 28.02.2014 01:24, schrieb Martin Koppenhoefer:



Am 28/feb/2014 um 01:02 schrieb Frederik Ramm frede...@remote.org:

und das gilt im Kleinen auch in der Innenstadt - gehört die
Grasfläche jetzt noch zum Platz oder nicht, und so weiter.


und wenn sie dazugehört, wie taggt man das dann?

Ich habe bei innerstädtischen Plätzen eigentlich nie oder nur höchst selten ein 
Problem damit, die Grenzen zu erkennen [...] einen spezifischen Tag für diese 
Art Toponym haben wir aber bisher nicht entwickelt abseits von befestigten 
(Verkehrs-)Flächen, könnte man mal machen.


mal ganz dreist spekuliert:
Im Prinzip handelt es doch 'nur' um einen benannten Ort resp. ein 
benanntes Gebiet ...
Da einen spezifischen Tag für Platz zu finden, kann einfach 
(Definition) oder schwierig (Konsens) sein - je wie man will.


Stellt sich die Frage, ob man place=locality dafür verwenden will.
Ebenso wie place=neighbourhood für die Mannheimer Quadrate - so denn 
dieser Tag dort nicht bereits für übergreifende Gebiete verwendet wird.

Und ob man dann diese Tags auch entsprechend bei Mapnik rendern möchte

Was allerdings auch einer Flugverbotszone Tür und Tor öffnen würde. :-(

Georg

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Access-Tags

2014-02-28 Thread Georg Feddern


Moin,

Am 27.02.2014 15:12, schrieb Martin Koppenhoefer:



Am 27/feb/2014 um 12:56 schrieb Fabian Schmidt 
fschm...@informatik.uni-leipzig.de:

Ich gehe davon aus, dass der Default gilt


echte Daten (d.h. vor Ort vom Mapper erhobene und dann eingetragene 
Informationen) sind besser als ein sich verlassen auf vermeintliche Defaults.


auch wenn ich selbst aufgrund der unterschiedlichen Sicht von defaults 
(siehe track) lieber explizite access-Werte eintrage,

so darf doch die Problematik nicht außer Acht gelassen werden:
Explizit gesetzte 'defaults' (also allgemeine gesetzliche Vorgaben) 
müssen auch explizit angepasst werden, falls sie mal geändert werden.
Insofern sind dort eigentlich auch zusätzliche source-Tags nötig, wie 
bei den default maxspeed.



  Klar, jeder kann eintragen was er will, aber Sachen rauszulöschen, die zwar 
stimmen aber vom einzelnen Mapper als redundant wg. defaults angesehen werden, 
ist m.E. dagegen nicht ok


Das ist zumindest ein Gebot der Höflichkeit, solange da keine echte 
Einigkeit aufgrund von 'Standards' besteht - und das wird ja oft genug 
kontrovers betrachtet.


Das Problem sind ja nicht default- Werte an sich (1) - sondern die 
kontroverse Sicht der Mapper und Anwender.


Georg

(1) Abgesehen von der Mapper-Erfassungproblematik: 'Fehlt hier noch was?'

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Access-Tags

2014-02-28 Thread chris66

Am 27.02.2014 23:02, schrieb Michael Kugelmann:

 die Erfahrung habe ich vor einigen (!) Jahren bei OSM auch gemacht. In
 der Anfangszeit von OSM hatte man die highway=motorway_link nicht
 explizit mit oneway=yes gekennzeichnet sondern als Default des Typs
 motorway_link angenommen. Diese Definition wurde irgendwann urplötzlich
 geändert. Und seit dieser schlechten Erfahrung versuche ich mich nicht
 mehr auf Default zu verlassen...

 PS: ich hoffe ich erinnere mich noch korrekt, oder war das motorway
 selber? ist bestimmt schon 5 Jahre her...

Moin,
bei beiden ist nach-wie-vor oneway=yes impliziert.

Was im Falle des _link zu vielen Routingfehlern führt, bei Routern
die dies wiki-konform implementiert haben (z.B. OSRM).

[1] http://wiki.openstreetmap.org/wiki/Tag%3Ahighway%3Dmotorway
[2] http://wiki.openstreetmap.org/wiki/Tag%3Ahighway%3Dmotorway_link

(rechte Spalte unter Implikationen).

Chris




___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Keine Namen in Mapnik und anderen Karten

Am 28. Februar 2014 09:26 schrieb Georg Feddern o...@bavarianmallet.de:

 mal ganz dreist spekuliert:
 Im Prinzip handelt es doch 'nur' um einen benannten Ort resp. ein
 benanntes Gebiet ...
 Da einen spezifischen Tag für Platz zu finden, kann einfach (Definition)
 oder schwierig (Konsens) sein - je wie man will.

 Stellt sich die Frage, ob man place=locality dafür verwenden will.




m.E. eher nicht, weil das so allgemein ist, dass es zwar irgendwie einen
Namen verortet, aber eben nicht klar ist, welcher Natur das benamste Objekt
ist, und daher z.B. auch beim Rendering kaum sinnvolle Darstellungsregeln
entwickelt werden können (z.B. ab welcher Zoomstufe man ein Objekt sichtbar
macht, und wie die Schrift aussieht).

Eher nicht, weil mit einem Zusatztag wie locality=square würde das
vielleicht schon wieder anders aussehen (und in einem nächsten Schritt
könnte man das place=locality gleich ganz weglassen und nur locality=*
taggen). Alternativ vielleicht auch toponym=square oder so?

Gruß Martin
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Ziele [war: Eintrag von Gewann-Namen]

2014-02-28 Thread Markus


Hallo Bernd,


Ich will für die Benutzer taggen


:-) Das ist m.E. eine gute Einstellung.

Bei allem was wir tun ist die Frage wichtig:
- wozu?
- wem nützt es?
- wie kann ich es am besten umsetzen?

Hallo Michael,


wer sind die user


Das ist eine wesentliche Frage.
Nur so kann ich von ihnen erfahren, was sie gerne hätten,
und mir dann überlegen, wie man das gut umsetzen könnte.


Die richtige Denkweise wäre


richtig gibt es immer nur in Bezug auf etwas.
Für OSM ist der Bezug m.E. immer die Benutzer :-)


OSM sammelt Geo-Daten welche die Wirklichkeit da draußen beschreiben.


OSM ist eine *Weltkarte*.
/Dafür/ werden Geo-Daten erhoben und in einer DB abgelegt.

*Karte und Daten* ist eine systemische Einheit.
Das erfordert eine gezielte Zusammenarbeit zwischen denen die Daten 
sammeln und denen die sie anzeigen, bzw denen die die Karte nutzen :-)



eine mögliche Benutzung dieser Daten ist das Rendering mit Mapnik


Mapnik ist /die Karte/ :-)

Selbstverständlich /kann/ man aus den Daten auch noch viele und tolle 
Spezialanwendungen machen: Spezialkarten, Routing, Statistik, ...


Und selbstverständlich brauchen Anwendungen sinnvolle Datenschemen als 
Grundlage. Deshalb sind Daten(-Struktur) immer als Einheit mit der 
geplanten Anwendung zu betrachten und zu verstehen - und zu entwickeln 
und zu verbessern.



Stil


Ein einheitliches Erscheinungsbild hilft OSM als Marke zu etablieren.
Dabei sind Ziele zu erfüllen wie schnelles Orientieren und Erkennen, 
schnelles präzises Finden, sinnvolle Verknüpfung von Information, etc.

Iterativ und gemeinsam ist das Optimum zu finden.

Dabei kann man gute Fremd-Beispiele nutzen und die besten Ideen daraus 
übernehmen.
Es macht aber m.E. wenig Sinn, diese nur deshalb nachzuahmen, weil man 
sie gewohnt ist.


Bei den iterativen Suchprozessen macht es auch Sinn, immer mal wieder 
etwas ganz anderes auszuprobieren - um die gefundenen Essenzen dann 
synergetisch in das Produkt zu integrieren.

Es macht aber m.E. wenig Sinn, viele Skins zu haben.

- - - -

Zur Frage nach dem Rendering von Gewann-Namen:
Namen von Gegenden helfen bei der Orientierung.
Solche Namen auf der Karte zu haben ist ein sinnvolles Anliegen.

Solange wir dafür kein brauchbares Konzept haben, werden Benutzer immer 
wieder versuchen, die Namen irgendwie so in die DB zu schreiben 
/damit/ sie gerendert werden.


Mit herzlichem Gruss,
Markus

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Ziele [war: Eintrag von Gewann-Namen]

2014-02-28 Thread Falk Zscheile

Am 28. Februar 2014 11:59 schrieb Markus liste12a4...@gmx.de:

 OSM sammelt Geo-Daten welche die Wirklichkeit da draußen beschreiben.


 OSM ist eine *Weltkarte*.
 /Dafür/ werden Geo-Daten erhoben und in einer DB abgelegt.

Nein, OSM ist eine Datenbank, die geographische Informationen sammelt.

 *Karte und Daten* ist eine systemische Einheit.
Nein, Daten und Karte sind systematisch getrennt. Man kann aus den
Daten alles mögliche machen. Von Statistik bis Routing, ist alles
möglich. Karten sind nur ein kleiner, wenn auch der eingänglichste,
Anwendungsbereich.

 Das erfordert eine gezielte Zusammenarbeit zwischen denen die Daten sammeln
 und denen die sie anzeigen, bzw denen die die Karte nutzen :-)

nein, die Zusammenarbeit muss zwischen Datensammlern und Datennutzern
erfolgen. eine der großen Herausforderungen von OSM ist es, ein
Datenschema zu entwickeln, das mehr taugt, als eine Karte zu malen.
Das Problem ist: man kennt die konkrete Anwendung der Daten nicht.
Wenn man sich immer nur auf Karten fixiert (welche eigentlich --
Papierkarten, Onlinekarten, Routingfähig oder nicht) verbaut man sich
vielleicht andere Anwendungsmöglichkeiten. Man kann sollte das
Datenschema nicht unter dem Gesichtspunkt Kann man damit eine schöne
Karte malen? sehen sondern Bilde ich damit die Wirklichkeit
eindeutig und verständlich ab?

 eine mögliche Benutzung dieser Daten ist das Rendering mit Mapnik


 Mapnik ist /die Karte/ :-)

Nein, Mapnik ist ein Renderer und und die Karte auf openstreetmap.org
das Ergebnis einer Renderanweisung. Ich mag das Renderergebnis, wie es
auf opentopomap.de erscheint viel mehr :-) Die Karte auf
openstreetmap.org ist eine gute (!) Standartanwendung, aber nicht das
maß der Dinge.

 Selbstverständlich /kann/ man aus den Daten auch noch viele und tolle
 Spezialanwendungen machen: Spezialkarten, Routing, Statistik, ...

genau

 Und selbstverständlich brauchen Anwendungen sinnvolle Datenschemen als
 Grundlage. Deshalb sind Daten(-Struktur) immer als Einheit mit der geplanten
 Anwendung zu betrachten und zu verstehen - und zu entwickeln und zu
 verbessern.

Du meinst für jede Anwendung ein eigenes Datenschema? Übertrieben
würde das heißen, man muss Wege nicht verbinden, wenn man nur eine
Karte braucht. Die Leute, die Routing betreiben sollen möchten dann
bitte ein eigenes Schema haben, bei dem sie ihre Straßen verbinden.
Das kann es nicht sein. Ziel sollte schon die universelle Nutzbarkeit
der Daten sein ...

Gruß Falk


 Stil


 Ein einheitliches Erscheinungsbild hilft OSM als Marke zu etablieren.
 Dabei sind Ziele zu erfüllen wie schnelles Orientieren und Erkennen,
 schnelles präzises Finden, sinnvolle Verknüpfung von Information, etc.
 Iterativ und gemeinsam ist das Optimum zu finden.

 Dabei kann man gute Fremd-Beispiele nutzen und die besten Ideen daraus
 übernehmen.
 Es macht aber m.E. wenig Sinn, diese nur deshalb nachzuahmen, weil man sie
 gewohnt ist.

 Bei den iterativen Suchprozessen macht es auch Sinn, immer mal wieder etwas
 ganz anderes auszuprobieren - um die gefundenen Essenzen dann synergetisch
 in das Produkt zu integrieren.
 Es macht aber m.E. wenig Sinn, viele Skins zu haben.

 - - - -

 Zur Frage nach dem Rendering von Gewann-Namen:
 Namen von Gegenden helfen bei der Orientierung.
 Solche Namen auf der Karte zu haben ist ein sinnvolles Anliegen.

 Solange wir dafür kein brauchbares Konzept haben, werden Benutzer immer
 wieder versuchen, die Namen irgendwie so in die DB zu schreiben /damit/
 sie gerendert werden.

 Mit herzlichem Gruss,
 Markus

 ___
 Talk-de mailing list
 Talk-de@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-de

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Ziele [war: Eintrag von Gewann-Namen]



 Am 28/feb/2014 um 12:24 schrieb Falk Zscheile falk.zsche...@gmail.com:
 
 Man kann sollte das
 Datenschema nicht unter dem Gesichtspunkt Kann man damit eine schöne
 Karte malen? sehen sondern Bilde ich damit die Wirklichkeit
 eindeutig und verständlich ab?


+1

Gruß,
Martin
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Ziele [war: Eintrag von Gewann-Namen]

Hallo Markus,

Am Freitag, den 28.02.2014, 11:59 +0100 schrieb Markus:
Manuelle Ergänzung
 Am Freitag, den 28.02.2014, 08:50 schrieb Michael Kugelmann:
 Am Freitag, den 28.02.2014, 00:08 schrieb Bernhard Weiskopf:
/Manuelle Ergänzung
 Hallo Bernd,
 
  Ich will für die Benutzer taggen
 
 :-) Das ist m.E. eine gute Einstellung.
 
 Bei allem was wir tun ist die Frage wichtig:
 - wozu?
 - wem nützt es?
 - wie kann ich es am besten umsetzen?

soweit +1

 
 Hallo Michael,
 
  wer sind die user
 
 Das ist eine wesentliche Frage.
 Nur so kann ich von ihnen erfahren, was sie gerne hätten,
 und mir dann überlegen, wie man das gut umsetzen könnte.
 
  Die richtige Denkweise wäre
 
 richtig gibt es immer nur in Bezug auf etwas.
 Für OSM ist der Bezug m.E. immer die Benutzer :-)
 
  OSM sammelt Geo-Daten welche die Wirklichkeit da draußen beschreiben.
 
 OSM ist eine *Weltkarte*.
 /Dafür/ werden Geo-Daten erhoben und in einer DB abgelegt.
 
 *Karte und Daten* ist eine systemische Einheit.
 Das erfordert eine gezielte Zusammenarbeit zwischen denen die Daten 
 sammeln und denen die sie anzeigen, bzw denen die die Karte nutzen :-)

Nein, genau das ist nicht so. Die osm.org (Mapnik-Karten) -
Darstellung ist /eine/ mögliche Interpretation der Daten, die noch dazu
eben /nicht/ ein Aushängeschild oder eine Marke darstellen soll.
Primärzweck ist, die Mapper, insbesondere Anfänger, zu motivieren und
eine großen Anteil von viel benutzen Tags anzuzeigen.

Es gibt noch einen ganzen Haufen anderer Karten. Letztens ist jede Karte
nur eine Auswahl der Daten, und jede Karte hat ihr eigenes Thema.
Deshalb sollten die Tags so genau und sinnvoll wie sachlich möglich
gesetzt werden - im Prinzip ohne Rücksicht auf die Mapnik-Karte.

Das heißt aber nicht, dass damit jetzt jeder seine Tags möglichst
individuell gestalten sollte. Sinnvoll ist natürlich, nach dem Wiki
vorzugehen, soweit die Tags für die Objekte sinnvoll und richtig sind.
Damit wird der größte Teil der Tags auch in der Mapnik-Karte dargestellt
werden. Sollte das aber nicht so sein, sollte - soweit sinnvoll - der
Stil der Karte und nicht das Mappen verändert werden.

 
  eine mögliche Benutzung dieser Daten ist das Rendering mit Mapnik
 
 Mapnik ist /die Karte/ :-)

Eben nicht.

 
 Selbstverständlich /kann/ man aus den Daten auch noch viele und tolle 
 Spezialanwendungen machen: Spezialkarten, Routing, Statistik, ...
 
 Und selbstverständlich brauchen Anwendungen sinnvolle Datenschemen als 
 Grundlage. Deshalb sind Daten(-Struktur) immer als Einheit mit der 
 geplanten Anwendung zu betrachten und zu verstehen - und zu entwickeln 
 und zu verbessern.
 
  Stil
 
 Ein einheitliches Erscheinungsbild hilft OSM als Marke zu etablieren.
 Dabei sind Ziele zu erfüllen wie schnelles Orientieren und Erkennen, 
 schnelles präzises Finden, sinnvolle Verknüpfung von Information, etc.
 Iterativ und gemeinsam ist das Optimum zu finden.
 
 Dabei kann man gute Fremd-Beispiele nutzen und die besten Ideen daraus 
 übernehmen.
 Es macht aber m.E. wenig Sinn, diese nur deshalb nachzuahmen, weil man 
 sie gewohnt ist.
 
 Bei den iterativen Suchprozessen macht es auch Sinn, immer mal wieder 
 etwas ganz anderes auszuprobieren - um die gefundenen Essenzen dann 
 synergetisch in das Produkt zu integrieren.
 Es macht aber m.E. wenig Sinn, viele Skins zu haben.

Ich glaube, du denkst jetzt zu sehr an den Namen OpenStreetMap. Damit
hat es zwar angefangen, aber der Name trifft heute nicht mehr zu.
Eigentlich müsste das ganze Ding jetzt OpenGeoBase heißen, nur ist der
Name nachträglich kaum noch zu ändern.

Will sagen: Wir machen überhaupt keine Karten. Wir machen /nur/ eine
Datenbank. Unsere Karten sind lediglich Beispiele und
Motivationselemente, sonst nichts. Interpretieren kann das jeder, wie er
will und in welchem Stil er Lust hat. Insofern sind unterschiedliche
Skins selbstverständlich.

Sinnvolles Taggen im Stile des Wiki, wenn es passt, ja.

Uminterpretieren, verbiegen, absichtliche Unschärfen, nicht so ganz
passende Tags nehmen, damit etwas dargestellt wird = Taggen für einen
bestimmten Stil eines einzelnen Renderers = Wertlosigkeit der Daten für
andere Anwendungen und keinerlei Weiterentwicklung = nein.

Aus Prinzip andere Tags benutzen, obwohl es geeignete gibt = taggen
gegen den Renderer = auch nein.

 
 - - - -
 
 Zur Frage nach dem Rendering von Gewann-Namen:
 Namen von Gegenden helfen bei der Orientierung.
 Solche Namen auf der Karte zu haben ist ein sinnvolles Anliegen.

Richtig, aber Aufgabe der Renderer = Stil anpassen.
 
 Solange wir dafür kein brauchbares Konzept haben, werden Benutzer immer 
 wieder versuchen, die Namen irgendwie so in die DB zu schreiben 
 /damit/ sie gerendert werden.

Dann werden die entweder korrigiert oder gelöscht.

Gruß, Wolfgang


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Wald aufteilen um Namen anzuzeigen?

2014-02-28 Thread Michael Reichert

Hallo Bernhard,

Am 27.02.2014 23:44, schrieb Bernhard Weiskopf:
 Das zusammenhängende Naherholungsgebiet „Käfertaler Wald“
 http://osm.org/go/0DwVt4CE-?m= ist untergliedert in vier Teile (Käfertaler
 Wald, Herrschaftswald, Sandhofer Wald und Neuwald), die bis jetzt mit „area
 = yes“ eingetragen sind, nun aber nicht mehr angezeigt werden. Außerdem
 laufen breite Schneisen (Autobahnen) durch, aber nicht an den Grenzen der
 einzelnen Wälder.
 
  
 
 Muss man den Käfertaler Wald jetzt aufteilen in viele Wälder und die
 zusammengehörenden Teile mit Relationen wieder zusammenfügen oder die
 Autobahnen über Relationen herausnehmen oder gibt es eine einfachere Lösung,
 dass die Namen der Wälder wieder angezeigt werden?

So wie es jetzt gemappt ist, ist es IMHO Mappen für den Renderer.

http://www.openstreetmap.org/way/195283394
Dieser Way hat folgende Tags:
areayes
nameErholungsgebiet Käfertaler Wald
notelanduse = recreation_ground
operatorStadt Mannheim

Ways, die nur ein area=yes und ein name=* haben, sind für eine
Geodatenbank (OSM ist eine Geodatenbank und KEINE KARTE!) Fehl am Platz.
Solche Eintragungen erwarte ich eigentlich nur von iD-Newbies.

Wie auch viele andere hier, finde ich es sehr gut, dass so ein
Mapping-for-the-renderer-Schrott nicht mehr gerendert wird. Endlich!

Wenn du möchtest, dass der Käfertaler Wald wieder gerendert wird, musst
du ihn so eintragen, wie es gute fachliche Praxis ist.

Für den gesamten Käfertaler Wald legst du ein Multipolygon an, das aus
zwei outer-Inseln besteht – eine nördlich der A 6, eine südlich davon,
ggf. noch weitere Inseln, falls es zwischendrin breite Schneisen durch
Straßen/Stromleitungen/... gibt. Das Multipolygon trägt die Tags

type=multipolygon
landuse=forest
name=Käfertaler Wald

Die einzelnen Untereinheiten (Neuwald usw.) trägst du als geschlossene
Ways mit folgenden Tags ein:

place=locality
name=Neuwald

area=yes ist unnötig.

Alle anderen outer- und inner-Ways, die keine andere Bedeutung haben
(also keine Waldlichtungs-Wiese o.ä. sind), bekommen keine Tags (von
einem note=Multipolygon! Bitte nur mit JOSM bearbeiten! abgesehen).

Wenn zwei Untereinheiten aneinander grenzen, aber keine Schneise
dazwischen ist, solltest du an dieser Stelle nicht zwei outer-Ways des
Multipolygons dieselben Nodes nutzen lassen. Dann wäre das Multipolygon
nämlich ungültig/kaputt.

Wenn du es sehr ordentlich machen möchtest, kannst du bei aneinander
grenzenden Untereinheiten auch wie bei den Admin-Grenzen die
Untereinheiten als Multipolygone eintragen. Das wäre der aus technischer
Sicht schönste und ordentlichste Ansatz.

Viele Grüße

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt.



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Wald aufteilen um Namen anzuzeigen?

2014-02-28 Thread Manuel Reimer

Michael Reichert nakaner at gmx.net writes:
 Wenn du möchtest, dass der Käfertaler Wald wieder gerendert wird, musst
 du ihn so eintragen, wie es gute fachliche Praxis ist.
 
 Für den gesamten Käfertaler Wald legst du ein Multipolygon an, das aus
 zwei outer-Inseln besteht – eine nördlich der A 6, eine südlich davon,
 ggf. noch weitere Inseln, falls es zwischendrin breite Schneisen durch
 Straßen/Stromleitungen/... gibt. Das Multipolygon trägt die Tags
 
 type=multipolygon
 landuse=forest
 name=Käfertaler Wald
 
 Die einzelnen Untereinheiten (Neuwald usw.) trägst du als geschlossene
 Ways mit folgenden Tags ein:
 
 place=locality
 name=Neuwald

Im Prinzip war das auch mein erster Einfall.

Allerdings würde ich dazu tendieren das landuse=forest nicht im
multipolygon zu verstecken sondern an die Untereinheiten zu schreiben.
Ist meiner Ansicht nach dann für andere Mapper leichter nachzuvollziehen.

Ist beides richtig oder ist eine Variante zu bevorzugen?

Gruß

Manuel


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Wald aufteilen um Namen anzuzeigen?

Am 28. Februar 2014 13:25 schrieb Manuel Reimer manuel.s...@nurfuerspam.de
:


 Allerdings würde ich dazu tendieren das landuse=forest nicht im
 multipolygon zu verstecken sondern an die Untereinheiten zu schreiben.
 Ist meiner Ansicht nach dann für andere Mapper leichter nachzuvollziehen.

 Ist beides richtig oder ist eine Variante zu bevorzugen?



wenn man es nicht ans Multipolygon schreibt, weiss man nur, dass ein Objekt
aus Waldstücken besteht (die Relation), aber nicht, ob sich das Toponym auf
einen Wald bezieht. An dem Objekt mit dem Namen sollte auch ein tag sein
das sagt, worauf sich der Name bezieht.

Gruß,
Martin
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Wald aufteilen um Namen anzuzeigen?

Am 28. Februar 2014 12:56 schrieb Michael Reichert naka...@gmx.net:

 http://www.openstreetmap.org/way/195283394
 Dieser Way hat folgende Tags:
 areayes
 nameErholungsgebiet Käfertaler Wald
 notelanduse = recreation_ground
 operatorStadt Mannheim

 Ways, die nur ein area=yes und ein name=* haben, sind für eine
 Geodatenbank (OSM ist eine Geodatenbank und KEINE KARTE!) Fehl am Platz.
 Solche Eintragungen erwarte ich eigentlich nur von iD-Newbies.



das sehe ich ein bisschen entspannter, ein Toponym (name) mit seiner
Verortung/Ausdehnung ist auch dann in einer Geodatenbank interessant, wenn
der Eintrag noch nicht perfekt ist, d.h. wenn noch nicht genauer
spezifiziert ist, welche Art Toponym es ist.




 Wie auch viele andere hier, finde ich es sehr gut, dass so ein
 Mapping-for-the-renderer-Schrott nicht mehr gerendert wird. Endlich!



+1




 Wenn du möchtest, dass der Käfertaler Wald wieder gerendert wird, musst
 du ihn so eintragen, wie es gute fachliche Praxis ist.



das ist dann allerdings eher wieder ein Thema wie Frederik es bei den
Plätzen angedeutet hat (topographische Objekte mit unscharfen Grenzen).
Eine gute fachliche Praxis haben wir m.E. bisher dafür noch nicht
entwickelt. Wenn im Käfertaler Wald z.B. ein See ist, oder eine Lichtung,
dann ist durchaus normalerweise auch Teil des Käfertaler Walds. Ggf. könnte
man sowas mit natural=forest lösen, würde eher der bisherigen Entwicklung
des Mappings entsprechen m.E., es kommt nämlich durchaus auch oft vor, dass
ein Wald aus Waldstücken (mit jeweiligen Namen) besteht, und selbst ggf.
auch wieder Teil eines noch größeren Wald ist (Wald dem Namen nach, in
der Realität aber aus diversen Landnutzungen bestehend, beisp. Pfälzer
Wald, Schwarzwald, etc.)




 Für den gesamten Käfertaler Wald legst du ein Multipolygon an, das aus
 zwei outer-Inseln besteht – eine nördlich der A 6, eine südlich davon,
 ggf. noch weitere Inseln, falls es zwischendrin breite Schneisen durch
 Straßen/Stromleitungen/... gibt. Das Multipolygon trägt die Tags

 type=multipolygon
 landuse=forest
 name=Käfertaler Wald



s.o., die Schneisen sind auch Teil des Käfertaler Walds (obwohl nicht
landuse=forest).




 Die einzelnen Untereinheiten (Neuwald usw.) trägst du als geschlossene
 Ways mit folgenden Tags ein:

 place=locality
 name=Neuwald

 area=yes ist unnötig.



Ob area=yes nötig ist oder nicht, ist nicht völlig klar, schaden tut es
sicher nicht.

Gruß Martin
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Keine Namen in Mapnik und anderen Karten

2014-02-28 Thread bkmap

Am 28.02.2014 11:38, schrieb Martin Koppenhoefer:
 
 Eher nicht, weil mit einem Zusatztag wie locality=square würde das
 vielleicht schon wieder anders aussehen (und in einem nächsten Schritt
 könnte man das place=locality gleich ganz weglassen und nur locality=*
 taggen). Alternativ vielleicht auch toponym=square oder so?

+1
Ich finde place=locality sowieso etwas unscharf, da es für sehr
unterschiedliche Typen von Örtlichkeiten Verwendung finden kann.
Mit name=Schwarzwald, place=locality wird eine recht bedeutende
Örtlichkeit beschrieben, wobei name=Grabenfeld, place=locality nur von
lokaler Bedeutung ist.
Die Auswerter sehen aber keinen Unterschied, es sei denn, der Tag ist an
eine Fläche gebunden. Dann könnte man Rückschlüsse aus der Größe ziehen.

Gruß Burkhard



___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Wald aufteilen um Namen anzuzeigen?

Am Freitag, den 28.02.2014, 14:27 +0100 schrieb Martin Koppenhoefer:

 s.o., die Schneisen sind auch Teil des Käfertaler Walds (obwohl nicht
 landuse=forest).

Das ist wieder so eine Sache der Definition. Ich würde dazu tendieren,
die Schneise als funktionales Sicherheits-Element des Waldes zu sehen
und damit im landuse=forest einzuschließen. Der Notausgang im Supermarkt
würde auch als Element des Supermarktes bezeichnet werden, obwohl man
auf dem Weg nichts einkaufen kann. Als Verkaufsfläche dagegen fiele er
raus. 

Wenn man zusätzlich landcover=forest mappt, bin ich aber bei dir, die
Schneise nicht im landcover zu lassen.

Gruß, Wolfgang


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Keine Namen in Mapnik und anderen Karten

Am Freitag, den 28.02.2014, 15:46 +0100 schrieb bkmap:
 Die Auswerter sehen aber keinen Unterschied, es sei denn, der Tag ist an
 eine Fläche gebunden. Dann könnte man Rückschlüsse aus der Größe ziehen.
 

+1

Insofern kann es sinnvoll sein, Gebiete mit einheitlichem Namen als
Polygone oder bei großen Gebieten wie dem Schwarzwald als Multipolygone
zur Namenskennzeichnung zu mappen. Das MP kann ja aus bereits
vorhandenen Polygonen zusammengesetzt werden. Dann kann der Renderer
erkennen, in welches Gebiet der Namen gehört und entscheiden, wie
prominent und auseinander gezogen er dargestellt werden soll.

Das ist nicht nur für den Renderer, sondern für jede Auswertung
sinnvoll, die sich mit irgendwelchen Regionalbegriffen, die nicht mit
Verwaltungseinheiten identisch sind, auseinander setzt.

Gruß, Wolfgang


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Wald aufteilen um Namen anzuzeigen?



 Am 28/feb/2014 um 16:00 schrieb Wolfgang Hinsch osm-lis...@ivkasogis.de:
 
 Das ist wieder so eine Sache der Definition. Ich würde dazu tendieren,
 die Schneise als funktionales Sicherheits-Element des Waldes zu sehen
 und damit im landuse=forest einzuschließen. Der Notausgang im Supermarkt
 würde auch als Element des Supermarktes bezeichnet werden, obwohl man
 auf dem Weg nichts einkaufen kann. Als Verkaufsfläche dagegen fiele er
 raus. 


Für mich wie im Wiki beschreibt Landuse die tatsächliche Bodennutzung. 
Vielleicht kann man bei der Schneise noch diskutieren, aber nimm mal 
Freudenstadt (im Schwarzwald). da passt landuse Forest sicher nicht. Liegt aber 
im Schwarzwald. Ich würde daher eher einen neuen Key für Gebiete vorschlagen, 
sowas wie georegion=forest
name=*

oder evtl. auch location anstatt georegion od. toponym od. natural oder...

Multipolygonrelation ist bei so großen Gebieten allerdings problematisch aus 
div. Gründen, zB Auffinden, dann fehleranfälligkeit (nur ein Loch macht sie 
schon ungültig) und die schiere Anzahl an members (OK, könnte man 
verschachteln), etc

Gelegentlich kam hier schon ein neuer Relationstyp ins Spiel, ein Gebiet zu 
definieren über einen Haufen von quasi zufälligen Objekten, die noch drin 
liegen (oder evtl auch role für nicht mehr drin), woraus man dann später ein 
ungefähres Gebiet errechnen kann.

Gruß,
Martin
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Wald aufteilen um Namen anzuzeigen?

Am Freitag, den 28.02.2014, 16:34 +0100 schrieb Martin Koppenhoefer:
 
  Am 28/feb/2014 um 16:00 schrieb Wolfgang Hinsch osm-lis...@ivkasogis.de:
  
  Das ist wieder so eine Sache der Definition. Ich würde dazu tendieren,
  die Schneise als funktionales Sicherheits-Element des Waldes zu sehen
  und damit im landuse=forest einzuschließen. Der Notausgang im Supermarkt
  würde auch als Element des Supermarktes bezeichnet werden, obwohl man
  auf dem Weg nichts einkaufen kann. Als Verkaufsfläche dagegen fiele er
  raus. 
 
 
 Für mich wie im Wiki beschreibt Landuse die tatsächliche Bodennutzung. 
 Vielleicht kann man bei der Schneise noch diskutieren, aber nimm mal 
 Freudenstadt (im Schwarzwald). da passt landuse Forest sicher nicht. Liegt 
 aber im Schwarzwald. Ich würde daher eher einen neuen Key für Gebiete 
 vorschlagen, sowas wie georegion=forest
 name=*

Bei Elementen, die nichts mit dem Wald zu tun haben, sind wir uns einig.
 
 oder evtl. auch location anstatt georegion od. toponym od. natural 
 oder...
 
 Multipolygonrelation ist bei so großen Gebieten allerdings problematisch aus 
 div. Gründen, zB Auffinden, dann fehleranfälligkeit (nur ein Loch macht sie 
 schon ungültig) und die schiere Anzahl an members (OK, könnte man 
 verschachteln), etc
 
 Gelegentlich kam hier schon ein neuer Relationstyp ins Spiel, ein Gebiet zu 
 definieren über einen Haufen von quasi zufälligen Objekten, die noch drin 
 liegen (oder evtl auch role für nicht mehr drin), woraus man dann später ein 
 ungefähres Gebiet errechnen kann.

Man könnte vielleicht so eine Art Tangentenpolygon erfinden. Eine
Figur, die aus Polygonen, einfachen Ways und Punkten besteht. Sie wird
dadurch definiert, dass man eine Linie berechnet, die als Tangente um
alle Elemente außen herumläuft. Außen wird definiert als die andere
Seite der Elemente gegenüber dem geografischen Mittelpunkt.

Bei Polygonen und Wegen wird die Figur berechnet, indem zwischen 2
Elementen immer eine Linie genutzt wird, die die kürzeste Strecke
beschreibt, die 2 Punkte der beiden Elemente verbindet, die aber keine
Linie der Elemente schneidet (außen anliegt). Bei Punkten geht die
Figur genau durch den Punkt. Die Reihenfolge ist von Bedeutung.

Das hat den Vorteil, dass ein Gebiet wie z.B. die Alpen beschrieben
werden kann, ohne einen Riesenhaufen von verschachtelten Multipolygonen
zu erzeugen. Es werden nur ein paar signifikante Elemente benutzt, die
am Rand liegen. 

Für die Alpen könnte das z.B. ein Tangentenpolygon aus 

Nizza - Turin - Como - Verona - Belluno - Llubljana - Wien - Salzburg -
Bregenz - Luzern - Genf - Genoble - Nizza

sein (Vorsicht, nur als Beispiel und GANZ grob). Wobei ich festgestellt
habe, dass es sinnvoll sein könnte, mit outer und inner zu arbeiten,
wobei die Tangente außen am inner vorbeiläuft, es also dazugehört, und
innen am outer, es also ausschließt. 

Damit sollten große Gebiete ohne all zu viel zusätzliche Daten erfassbar
sein. So 100% trennscharf ist so eine Linie ohnehin nicht.

Nur so eine Idee...

Gruß, Wolfgang


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Keine Namen in Mapnik und anderen Karten

2014-02-28 Thread Bernhard Weiskopf

Namen für Gebiete an eine Fläche binden halte ich für absolut notwendig. 

Schließlich soll der Goetheplatz nur in den großen Zoomstufen angezeigt
werden, der Schwarzwald dagegen nur in mittleren, aber nicht mehr in
großen. Je nach Flächeninhalt muss man minimale und maximale Zoomstufe für
das Anzeigen festlegen. (Wenn wir eines Tages bis Zoom = 25 kommen, soll
Goetheplatz auch nicht mehr angezeigt werden.) 

Das müsste so ähnlich auch bereits mit anderen Objekten, wie Ländernamen,
Städtenamen usw. umgesetzt sein.

Bernhard

 -Ursprüngliche Nachricht-
 Von: Wolfgang Hinsch [mailto:osm-lis...@ivkasogis.de]
 Gesendet: Freitag, 28. Februar 2014 16:08
 An: Openstreetmap allgemeines in Deutsch
 Betreff: Re: [Talk-de] Keine Namen in Mapnik und anderen Karten
 
 Am Freitag, den 28.02.2014, 15:46 +0100 schrieb bkmap:
  Die Auswerter sehen aber keinen Unterschied, es sei denn, der Tag ist
  an eine Fläche gebunden. Dann könnte man Rückschlüsse aus der Größe
 ziehen.
 
 
 +1
 
 Insofern kann es sinnvoll sein, Gebiete mit einheitlichem Namen als
 Polygone oder bei großen Gebieten wie dem Schwarzwald als
 Multipolygone zur Namenskennzeichnung zu mappen. Das MP kann ja aus
 bereits vorhandenen Polygonen zusammengesetzt werden. Dann kann der
 Renderer erkennen, in welches Gebiet der Namen gehört und entscheiden,
 wie prominent und auseinander gezogen er dargestellt werden soll.
 
 Das ist nicht nur für den Renderer, sondern für jede Auswertung sinnvoll,
 die sich mit irgendwelchen Regionalbegriffen, die nicht mit
 Verwaltungseinheiten identisch sind, auseinander setzt.
 
 Gruß, Wolfgang
 
 
 ___
 Talk-de mailing list
 Talk-de@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-de


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Wald aufteilen um Namen anzuzeigen?

2014-02-28 Thread Roland Olbricht

Hallo zusammen,

 Wenn du möchtest, dass der Käfertaler Wald wieder gerendert wird, musst
 du ihn so eintragen, wie es gute fachliche Praxis ist.

Aus wessen Fach? Ich kenne andere Meinungen.

 Für den gesamten Käfertaler Wald legst du ein Multipolygon an, das aus
 zwei outer-Inseln besteht – eine nördlich der A 6, eine südlich davon,
 ggf. noch weitere Inseln, falls es zwischendrin breite Schneisen durch
 Straßen/Stromleitungen/... gibt. Das Multipolygon trägt die Tags

Generell sind großflächige Relationen aus technischer Sicht heikel, und daher 
ist von deren Gebrauch eher abzuraten.

OSM unterstützt drei Arten von Gliederung. Das eine ist String-Gleichheit, das 
zweite ist räumlicher Bezug, das dritte sind Relationen.

String-Gleichheit ist effizient zu komprimieren, robust gegen Fehler und 
einfach zu verstehen. Z.B. trägt ein Großteil unseres Straßennetzes Tags wie 
highway=residential oder highway=motorway. Auch Filialen eines verteilten 
Systems lassen sich gut identifizieren, z.B. operator=Sparkasse.

Räumlicher Bezug entsteht dadurch, dass ein Objekt in einem anderen enthalten 
ist. Wenn man z.B. alle Sparkassen-Filialen in Mannheim finden will, kann man 
mit PostGIS, QGIS, der Overpass API etc. einfach den Umriss von Mannheim 
anlegen. Das ist für Datennutzer etwas anspruchsvoller als String-Gleichheit, 
aber für Mapper sehr bequem, denn die Bezüge stimmen ebenfalls automatisch, 
wenn man das Objekt am richtigen Ort plaziert. Und umgekehrt hilft die Lage 
geographischer Objekte oft, andere zu plazieren. Wenn ich weiß, dass mein 
Lieblingsrestaurant rechts im Einkaufszentrum XY ist, kann ich den Node 
ausreichend genau legen, ohne das Einkaufszentrum ausmessen zu müssen.

Das dritte Kriterium zur Gliederung sind Relationen. Sie haben erhebliche 
Unfallgefahr: man sieht der Relation nicht automatisch an, welche 
Eigenschaften wie Tags und räumliche Ausdehnung sie haben und schlimmer, man 
sieht einem Objekt nicht automatisch an, dass es Teil einer Relation ist. 
Ändert man die Geometrie des Objektes, so zerstört man oft die Relation.

Daher ist aus der Sicht von Editoren, Tools zur OSM-Datennutzung, 
Datenformaten und dem Renderer sinnvoll, Relationen nur dann zu benutzen, wenn 
weder String-Gleichheit noch räumlicher Bezug vorhanden sind.

Im konkreten Fall liegt aber in jedem Fall räumlicher Bezug vor. Ein Baum 
steht im Käfertaler Wald, weil er sich innerhalb der scharfen oder unscharfen 
Grenzen des Käfertaler Waldes befindet und nicht, weil ihn irgendeine 
besondere Eigenschaft mit den übrigen Bäumen im Käfertaler Wald verbindet. 
Denkprobe: Wenn zu Weihnachten Weihnachtsbäume im Käfertaler Wald 
eingeschlagen werden, verteilt sich dann der Wald danach auf ein paar hundert 
Wohnungen? Wohl eher nicht.
Zweite Denkprobe: Einen hypothetischer See im Wald würde ich als liegt im 
Käfertaler Wald bezeichnen. Spricht ebenfalls für räumliche Zugehörigkeit.

würde es sich eher anbieten, außen herum die Grenze als place=locality, 
name=Käfertaler Wald zu taggen und die einzelnen Gebiete mit landuse=forest, 
name=[jeweils passender Name] taggen.

Schneisen sind eine schlechte Idee, da sie wiederum die Arbeit mit den Daten 
dazwischen enorm erschweren. Sie erwecken zudem den Eindruck, man hätte die 
genaue Straßenbreite berücksichtigt. Ich habe mehrmals die Freude gehabt, 
Straßen zwischen landuse-Nutzungen zu editieren, was enorm mühselig ist, weil 
der Editor nicht weiß, dass man jetzt Straßennodes und nicht landuse-Nodes 
anfassen möchte und schon gar nicht, dass die landuse-Nodes bei Verschiebungen 
den Straßennodes folgen müssten.

Auch da gilt: Dem Datennutzer ist durchaus bekannt, dass mitten auf der A6 
keine Bäume wachsen, und die Straßenbreite ist entweder an der Straße 
spezifiziert oder nicht genau bekannt.

Viele Grüße,

Roland


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Eintrag von Gewann-Namen

2014-02-28 Thread Bernhard Weiskopf

Danke, Gertrud und Martin,

place = locality hatte ich irgendwie übersehen.

Also
name = Ich heiße Gewann
place = locality
locality = field_name oder land_parcel oder ?

Die Angabe locality = halte ich auch für sinnvoll, denn place finde ich
auch zu allgemein. Die englische Übersetzung für Gewann kenne ich leider
nicht.

Damit könnte man auch andere Plätze eintragen und mit locality = genauer
spezifizieren.

Nominatim findet diese Einträge und nennt sie Flur.

Bernhard

 -Ursprüngliche Nachricht-
 Von: Martin Koppenhoefer [mailto:dieterdre...@gmail.com]
 Gesendet: Freitag, 28. Februar 2014 00:51
 An: Openstreetmap allgemeines in Deutsch
 Cc: Openstreetmap allgemeines in Deutsch
 Betreff: Re: [Talk-de] Eintrag von Gewann-Namen
 
 
 
  Am 28/feb/2014 um 00:28 schrieb Gertrud Simson
 simson.gert...@gmail.com:
 
  Dann gibt es wahrscheinlich noch keine Regel. Müsste man sich welche
  ausdenken und darauf einigen.
 
 
 +1
 
 
  Hier http://osm.org/go/0GB_460Q- sind Gewannen mit place=locality und
  name=* eingetragen.
  Laut http://wiki.openstreetmap.org/wiki/DE:Tag:place%3Dlocality passt
  das auch ganz gut zu Gewannen
 
 und nicht nur für die ;-)
 
 das ist das Problem an locality, dass es ziemlich unspezifisch ist.
 Man könnte vielleicht sowas wie locality=field_name verwenden.
 
 Gruß Martin
 ___
 Talk-de mailing list
 Talk-de@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-de


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Keine Namen in Mapnik und anderen Karten

Am Freitag, den 28.02.2014, 17:35 +0100 schrieb Bernhard Weiskopf:
 Namen für Gebiete an eine Fläche binden halte ich für absolut notwendig. 
 
 Schließlich soll der Goetheplatz nur in den großen Zoomstufen angezeigt
 werden, der Schwarzwald dagegen nur in mittleren, aber nicht mehr in
 großen. Je nach Flächeninhalt muss man minimale und maximale Zoomstufe für
 das Anzeigen festlegen. (Wenn wir eines Tages bis Zoom = 25 kommen, soll
 Goetheplatz auch nicht mehr angezeigt werden.) 
 
 Das müsste so ähnlich auch bereits mit anderen Objekten, wie Ländernamen,
 Städtenamen usw. umgesetzt sein.

Jetzt vermischst du wieder die Teilnehmer. Der Mapper legt nur fest, was
zum Schwarzwald und was zum Götheplatz gehört.

In welcher Zoomstufe welcher Renderer was anzeigt, muss er - und nur er
- selbst entscheiden. Wenn ich eine Karte von X-Dorf mache und das
mitten im Schwarzwald liegt, würde ich Schwarzwald nicht mehr rendern,
sondern auf den Kartentitel schreiben: X-Dorf im Schwarzwald.

Wenn das Dorf aber am Rande des Schwarzwaldes liegt, und der Schwarzwald
die linke Kartenhälfte ausmacht, würde der Begriff gerendert, unabhängig
vom Maßstab oder Zoomlevel.

Versuche doch einmal, eine Karte selbst zu machen. Beschäftige dich z.B.
mit Maperitive. Dann kannst du auch selbst festlegen, welche Bezeichnung
wo zu stehen hat. Kann ja erst mal der Ortsplan von X-Dorf sein ;-)

Gruß, Wolfgang


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Wald aufteilen um Namen anzuzeigen?

Am 28. Februar 2014 17:42 schrieb Roland Olbricht roland.olbri...@gmx.de:

 Auch da gilt: Dem Datennutzer ist durchaus bekannt, dass mitten auf der A6
 keine Bäume wachsen, und die Straßenbreite ist entweder an der Straße
 spezifiziert oder nicht genau bekannt.



für Abstandsflächen von Autobahnen gibt es sicherlich Normen, da muss man
nicht komplett im Dunkeln raten. Aber es könnte ja sein, dass der Wald über
oder unter der A6 wächst und jemand den layer tag vergessen hat? ;-)
Spätestens wenn man den Grünstreifen hinter der Leitplanke mappt geht es
wohl nicht mehr ohne eine Splittung des Wald-polygons.

Gruß Martin
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Ziele [war: Eintrag von Gewann-Namen]

2014-02-28 Thread Markus


Hallo Wolfgang,

Es scheint in OSM zwei kleine Lager zu geben,
(die Meisten gehören keinem an, sondern nutzen einfach die tolle Karte 
oder verbessern sie in unterschiedlichen Belangen)

die immer wieder aneinander vorbei reden,
weil beide behaupten recht zu haben.

Ich bin überzeugt, dass /beide/ recht haben :-)
Die zwei Meinungen sind nur eine unterschiedliche Sicht auf das Ganze:

Daten werden erst und nur dann relevant,
wenn sie erfahrbar werden.

Entscheidend ist die Erfahrung (bei Karten die Anzeige).
Voraussetzung ist, dass es etwas anzuzeigen gibt (die Daten).
Beides gehört unmittelbar zusammen und bedingt sich gegenseitig.
Daten und deren Darstellung sind immer eine systemische Einheit.

Manche Probleme in OSM haben ihre Ursache in der Negierung dieses 
Zusammenhanges und in der folgenden mangelnden Zusammenarbeit zwischen 
Datensammlern und Datendarstellern einerseits und den Nutzern andererseits.


Der Benutzer will eine *Karte*.
Ursprung von OSM ist die Idee, eine *freie Weltkarte* zu schaffen:
detailliert, aktuell, umfassend, für Jedermann.

Dafür werden Daten gesammelt, strukturiert, in eine DB gepackt, 
gerendert, und die ganze Infrastruktur geschaffen.
Ein tolles internationales Gemeinschaftswerk, das soziale, politische, 
kulturelle und wirtschaftliche Grenzen überwindet.


Klar gibt es in einem solchen Mega-Projekt eine Arbeitsteilung und 
Spezialisierung. Die einen sammeln Daten, andere bauen Anwendungen, oder 
kümmern sich um die Infrastruktur oder machen Schulung oder Pressearbeit 
und vieles mehr.

Klar sieht jede Arbeitsgruppe spezifische Erfordernisse.
Und klar führt das zu Widersprüchen.

Wenn wir uns aber alle gemeinsam bemühen, die Bedürfnisse der Benutzer 
zu verstehen, und uns gemeinsam verständigen, wie wir diese optimal 
erfüllen können, dann hat OSM ein beeindruckendes Potential!


Mit herzlichem Gruss,
Markus

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Ziele [war: Eintrag von Gewann-Namen]

2014-02-28 Thread Christoph Hormann

On Friday 28 February 2014, Markus wrote:
 [...]

 Der Benutzer will eine *Karte*.

Diese Annahme solltest Du denke ich durchaus mal hinterfragen.  Du 
kannst natürlich 'Benutzer' so definieren, dass nur 
Standardstil-Mapnik-Kartenbetrachter gemeint sind, wenn Du allerdings 
Benutzer als die Gesamtheit aller Menschen siehst, die aus den 
OSM-Daten einen Nutzen ziehen, dann ist die Annahme, die Du hier 
triffst, keineswegs selbstverständlich.

Ganz abgesehen davon müsste es natürlich heißen: der Benutzer will 20 
verschiedene Karten (entsprechend Zoomstufen 0-19).  Allein hieran kann 
man schon sehen, dass das Konzept die Daten so erfassen, dass man 
daraus eine schöne Karte malen kann nicht funktionieren kann - selbst 
wenn man sich auf die Kartendarstellung als einzige Anwendung 
beschränken würde.

-- 
Christoph Hormann
http://www.imagico.de/

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Ziele [war: Eintrag von Gewann-Namen]

2014-02-28 Thread Dirk Sohler

Christoph Hormann schrieb:
 Allein hieran kann man schon sehen, dass das Konzept die Daten so
 erfassen, dass man daraus eine schöne Karte malen kann nicht
 funktionieren kann

Zumal nicht die Daten für die Darstellung optimiert werden sollten,
sondern die Darstellung immer nach Wünschen des Endanwenders/Nutzers an
die Daten angepasst werden muss :) – Oder eben kurz: „Wir mappen nicht
für den Renderer“

Grüße,
Dirk

-- 
Local time :: Ortszeit :: DE-HH
2014-02-28T20:10:24+0100


signature.asc
Description: PGP signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Eintrag von Gewann-Namen

2014-02-28 Thread Frederik Ramm

Hi,

On 28.02.2014 17:53, Bernhard Weiskopf wrote:
 Damit könnte man auch andere Plätze eintragen und mit locality = genauer
 spezifizieren.

Solange es keine bewohnten Plätze sind; place=locality ist extra für
unbewohnte vorgesehen.

Neulich hat einer in Frankfurt diverse Bereiche eines Friedhofs damit
getaggt, zur besseren Orientierung auf dem Friedhof. Kann man sich jetzt
drüber streiten, ob der bewohnt ist ;)

Bye
Frederik--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09 E008°23'33

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Access-Tags

2014-02-28 Thread Michael Kugelmann


Am 28.02.2014 10:45, schrieb chris66:

bei beiden ist nach-wie-vor oneway=yes impliziert.
infolge schlechter Erfahrungen in der Vergangeheit vertraue ich nicht 
mehr auf den Default und setze explizit oneway=yes.


BTW: ich bin letztes Jahr auf dem Weg zur FOSSGIS auf einer schweizer 
Autobahn gefahren welche nur aus einer Fahrbahn ohne bauliche Trennung 
bestand. OK ich gebe zu das war Baustellen-bedingt. Aber die Fahrspuren 
in Gegenrichtung waren nur durch sporadisch Gummikegel getrennt. Und 
das ganze war über viele (!) km (IIRC mehrere AS). Und ich denke, dass 
dies auch keine Kurzzeit-Geschichte war sondern mehrere Tage/Wochen so 
geblieben ist = ein Ummappen bei OSM ist sehr wohl realistisch.Aber da 
passt dann wieder der Default nicht denn das bleibt eine Autobahn wo die 
Straße auch gegen die Mapping-Richtung befahren werden darf = man 
müsste explizit oneway=no setzen, das ist irgendwie auch etwas komisch 
(weil oneway=no auch ein default ist). Und welches Tool verlässt sich 
denn wirklich auf defaults? Wie gesagt, ich zweifle deren Gültigkeit 
grundsätzlich an...



Grüße,
Michael.


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Ziele [war: Eintrag von Gewann-Namen]

2014-02-28 Thread Christoph (TheFive@OSM)

Hi

Hier mal eine andere Toolanwendung als eine Mapnik Karte, die jeder von uns 
schon genutzt hat:

Nominatim Suche:

Dorfwiese (brit.) Goetheplatz, Calenberger Neustadt, Mitte, Hannover, Region 
Hannover, Niedersachsen, 30159, Deutschland, Europäische Union
Dorfwiese (brit.) Goetheplatz, Eppinghofen, Mülheim, Mülheim an der Ruhr, 
Regierungsbezirk Düsseldorf, Nordrhein-Westfalen, 46468, Deutschland, 
Europäische Union
Straße Goetheplatz, Bezirksteil Ludwigsvorstadt-Kliniken, Stadtbezirk 02 
Ludwigsvorstadt-Isarvorstadt, Am Schlachthof, München, Oberbayern, Bayern, 
80337, Deutschland, Europäische Union
Straße Goetheplatz, Altstadt, Weimar, Thüringen, 99423, Deutschland, 
Europäische Union


Ich finde durchaus interessant, das Nominatim das WAS auch dabei schreibt 
(nicht nur Unspezifiziertes Gebiet). (Neben Dorfwiese und Strasse kommt etwas 
später auch noch Fussgängerzone).

Christoph 


Am 28.02.2014 um 19:22 schrieb Christoph Hormann chris_horm...@gmx.de:

 On Friday 28 February 2014, Markus wrote:
 [...]
 
 Der Benutzer will eine *Karte*.
 
 Diese Annahme solltest Du denke ich durchaus mal hinterfragen.  Du 
 kannst natürlich 'Benutzer' so definieren, dass nur 
 Standardstil-Mapnik-Kartenbetrachter gemeint sind, wenn Du allerdings 
 Benutzer als die Gesamtheit aller Menschen siehst, die aus den 
 OSM-Daten einen Nutzen ziehen, dann ist die Annahme, die Du hier 
 triffst, keineswegs selbstverständlich.
 
 Ganz abgesehen davon müsste es natürlich heißen: der Benutzer will 20 
 verschiedene Karten (entsprechend Zoomstufen 0-19).  Allein hieran kann 
 man schon sehen, dass das Konzept die Daten so erfassen, dass man 
 daraus eine schöne Karte malen kann nicht funktionieren kann - selbst 
 wenn man sich auf die Kartendarstellung als einzige Anwendung 
 beschränken würde.
 
 -- 
 Christoph Hormann
 http://www.imagico.de/
 
 ___
 Talk-de mailing list
 Talk-de@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-de

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Eintrag von Gewann-Namen

2014-02-28 Thread Sven Geggus

Bernhard Weiskopf bweisk...@gmx.de wrote:

 wie trägt man in OSM die Namen von Gewannen ein, dass sie in Mapnik
 angezeigt werden?

Dass das eine eher schlechte Frage ist haben andere schon
beschrieben.

Ich kann Dir aber schreiben warum ich Gewannamen derzeit nicht
erfasse.

Gewann ist AFAIK ein Begriff, den es nur in BW gibt. Anderswo heißt
das oft Flurnamen.

Zumindest bei Gewannnamen ist es so, dass diese vom Kataster als eine
Gruppe von Flurstücken definiert sind. Unterm Strich bedeutet das,
dass wir diese nicht wirklich erfassen können, weil wir den
katasterplan nicht kennen.

Die Erfassung als Punkt gefällt mir nicht, daher lasse ich das
derzeit ganz.

Gruss

Sven

-- 
Das Internet wird vor allem von Leuten genutzt, die sich Pornografie
ansehen, während sie Bier trinken, es ist daher für Wahlen nicht
geeignet (Jaroslaw Kaczynski)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Wald aufteilen um Namen anzuzeigen?

2014-02-28 Thread Garry


Am 28.02.2014 17:42, schrieb Roland Olbricht:


Schneisen sind eine schlechte Idee, da sie wiederum die Arbeit mit den Daten
dazwischen enorm erschweren. Sie erwecken zudem den Eindruck, man hätte die
Schneisen sind eine gute Idee, sie schaffen Strukturen mit einem 
Wiedererkennungswert!



genaue Straßenbreite berücksichtigt. Ich habe mehrmals die Freude gehabt,

Straßenbreite != Schneisenbreite!
Das Gebüsch/Grünstreifen am Straßenrand das regelmäßig kurz geschnitten 
wird gehört sicher nicht zum landuse=forest etc. sondern zum eigenem 
landuse (= [Straße]).

Straßen zwischen landuse-Nutzungen zu editieren, was enorm mühselig ist, weil
der Editor nicht weiß, dass man jetzt Straßennodes und nicht landuse-Nodes
anfassen möchte und schon gar nicht, dass die landuse-Nodes bei Verschiebungen
den Straßennodes folgen müssten.
Mühselig ist es, dieses schönmalen für den Renderer wieder aufdröseln 
zu müssen um in das grobe

Waldgetünche etwas Detailierung zu bekommen.

Auch da gilt: Dem Datennutzer ist durchaus bekannt, dass mitten auf der A6
keine Bäume wachsen, und die Straßenbreite ist entweder an der Straße
spezifiziert oder nicht genau bekannt.
Straßenbreite und landuse haben nichts miteinander zu tun, das sind 
eigene Welten!



Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Wald aufteilen um Namen anzuzeigen?

2014-02-28 Thread Garry


Am 28.02.2014 16:34, schrieb Martin Koppenhoefer:


Für mich wie im Wiki beschreibt Landuse die tatsächliche Bodennutzung. 
Vielleicht kann man bei der Schneise noch diskutieren, aber nimm mal 
Freudenstadt (im Schwarzwald). da passt landuse Forest sicher nicht. Liegt aber 
im Schwarzwald. Ich würde daher eher einen neuen Key für Gebiete vorschlagen, 
sowas wie georegion=forest
Auch wenn der Schwarzwald den Wald im Namen trägt so ist es doch ein 
Mittelgebirge das diesen Namen trägt und nicht ein Stück Wald. Ein 
Grundbesitzer der den (Nach)Namen Bauer hat ist deswegen ja auch noch 
lange kein Landwirt bzw. sein Grundstück landuse = farmland.


Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Wald aufteilen um Namen anzuzeigen?

2014-02-28 Thread Garry


Am 28.02.2014 17:00, schrieb Wolfgang Hinsch:




Für mich wie im Wiki beschreibt Landuse die tatsächliche Bodennutzung. 
Vielleicht kann man bei der Schneise noch diskutieren, aber nimm mal 
Freudenstadt (im Schwarzwald). da passt landuse Forest sicher nicht. Liegt aber 
im


Wie definierst Du die Bodenutzung bei den Grünstreifen entlang von 
(klassifizierten, ausserörtlichen) Straßen?

Der vorwiegende Nutzen ist hier der Sicherheitsaspekt als Freihaltetrasse.

Ebenso bei Pipelines deren Trasse von grösserem Wurzelwerk freigehalten 
wird.


Garry

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Wald aufteilen um Namen anzuzeigen?

Am 28. Februar 2014 23:23 schrieb Garry garr...@gmx.de:

 Wie definierst Du die Bodenutzung bei den Grünstreifen entlang von
 (klassifizierten, ausserörtlichen) Straßen?



bisher noch gar nicht, aber man könnte sich evtl. auf landuse=highway
einigen vermute ich. Interessanter ist evtl. landcover, wenn es um die
Charakteristik geht.

Gruß Martin
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

[Talk-it] Sulle ortofoto a 50 cm rilasciate ieri da e-Geos

Ciao,
per chi volesse farsi un giro: http://aborruso.github.io/realvista-demo/

Le licenze sono questa http://goo.gl/JP2EwR e questa http://goo.gl/ZrQJzZ

Buona giornata,

a



-
Andrea Borruso 

 
email: aborr...@tin.it 
website: http://blog.spaziogis.it
my 2.0 life: http://aborruso.spaziogis.it
feed: http://feeds2.feedburner.com/Tanto
38° 7' 48 N, 13° 21' 9 E 

--
View this message in context: 
http://gis.19327.n5.nabble.com/Sulle-ortofoto-a-50-cm-rilasciate-ieri-da-e-Geos-tp5797851.html
Sent from the Italy General mailing list archive at Nabble.com.

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Sulle ortofoto a 50 cm rilasciate ieri da e-Geos

2014-02-28 Thread Francesco Pelullo

Sai dove reperire le informazioni sulla data di ripresa?
Nel foggiano sono senz'altro risalenti all'autunno 2006.

Ciao
/niubii/



Il giorno 28 febbraio 2014 09:50, aborruso aborr...@gmail.com ha scritto:

 Ciao,
 per chi volesse farsi un giro: http://aborruso.github.io/realvista-demo/

 Le licenze sono questa http://goo.gl/JP2EwR e questa http://goo.gl/ZrQJzZ

 Buona giornata,

 a



 -
 Andrea Borruso

 
 email: aborr...@tin.it
 website: http://blog.spaziogis.it
 my 2.0 life: http://aborruso.spaziogis.it
 feed: http://feeds2.feedburner.com/Tanto
 38° 7' 48 N, 13° 21' 9 E
 
 --
 View this message in context:
 http://gis.19327.n5.nabble.com/Sulle-ortofoto-a-50-cm-rilasciate-ieri-da-e-Geos-tp5797851.html
 Sent from the Italy General mailing list archive at Nabble.com.

 ___
 Talk-it mailing list
 Talk-it@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-it

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Sulle ortofoto a 50 cm rilasciate ieri da e-Geos

Ciao Francesco,
non ho idea se e-Geos pubblichi informazioni di dettaglio (provo a
chiedere).

Sul  sito
http://www.realvista.it/website/Joomla/index.php?option=com_contentview=articleid=15Itemid=128
  
si legge un generico 2006-2009.

Saluti



-
Andrea Borruso 

 
email: aborr...@tin.it 
website: http://blog.spaziogis.it
my 2.0 life: http://aborruso.spaziogis.it
feed: http://feeds2.feedburner.com/Tanto
38° 7' 48 N, 13° 21' 9 E 

--
View this message in context: 
http://gis.19327.n5.nabble.com/Sulle-ortofoto-a-50-cm-rilasciate-ieri-da-e-Geos-tp5797851p5797854.html
Sent from the Italy General mailing list archive at Nabble.com.

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Sulle ortofoto a 50 cm rilasciate ieri da e-Geos

2014-02-28 Thread cesare gerbino

Confermato che si possono usare per il mapping in OSM o c isono problemi?



Cesare Gerbino

http://cesaregerbino.wordpress.com/
http://www.facebook.com/cesare.gerbino
http://www.facebook.com/pages/Cesare-Gerbino-GIS-Blog/246234455498174?ref=hl
https://twitter.com/CesareGerbino
http://www.linkedin.com/pub/cesare-gerbino/56/494/77b



Il giorno 28 febbraio 2014 09:58, Francesco Pelullo
f.pelu...@gmail.comha scritto:

 Sai dove reperire le informazioni sulla data di ripresa?
 Nel foggiano sono senz'altro risalenti all'autunno 2006.

 Ciao
 /niubii/



 Il giorno 28 febbraio 2014 09:50, aborruso aborr...@gmail.com ha
 scritto:

 Ciao,

 per chi volesse farsi un giro: http://aborruso.github.io/realvista-demo/

 Le licenze sono questa http://goo.gl/JP2EwR e questa http://goo.gl/ZrQJzZ

 Buona giornata,

 a



 -
 Andrea Borruso

 
 email: aborr...@tin.it
 website: http://blog.spaziogis.it
 my 2.0 life: http://aborruso.spaziogis.it
 feed: http://feeds2.feedburner.com/Tanto
 38° 7' 48 N, 13° 21' 9 E
 
 --
 View this message in context:
 http://gis.19327.n5.nabble.com/Sulle-ortofoto-a-50-cm-rilasciate-ieri-da-e-Geos-tp5797851.html
 Sent from the Italy General mailing list archive at Nabble.com.

 ___
 Talk-it mailing list
 Talk-it@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-it



 ___
 Talk-it mailing list
 Talk-it@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-it


___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Sulle ortofoto a 50 cm rilasciate ieri da e-Geos

Cesare, non hai visto la mia piazzata ieri a Roma quando chiedevo questo
agli egeos? :-)

Cmq sì sono ok per osm

-- 
Sent from my rotary phone. Not a fruit.
On Feb 28, 2014 10:02 AM, cesare gerbino cesaregerb...@gmail.com wrote:

 Confermato che si possono usare per il mapping in OSM o c isono problemi?



 Cesare Gerbino

 http://cesaregerbino.wordpress.com/
 http://www.facebook.com/cesare.gerbino

 http://www.facebook.com/pages/Cesare-Gerbino-GIS-Blog/246234455498174?ref=hl
 https://twitter.com/CesareGerbino
 http://www.linkedin.com/pub/cesare-gerbino/56/494/77b



 Il giorno 28 febbraio 2014 09:58, Francesco Pelullo f.pelu...@gmail.comha 
 scritto:

 Sai dove reperire le informazioni sulla data di ripresa?
 Nel foggiano sono senz'altro risalenti all'autunno 2006.

 Ciao
 /niubii/



 Il giorno 28 febbraio 2014 09:50, aborruso aborr...@gmail.com ha
 scritto:

 Ciao,

 per chi volesse farsi un giro: http://aborruso.github.io/realvista-demo/

 Le licenze sono questa http://goo.gl/JP2EwR e questa
 http://goo.gl/ZrQJzZ

 Buona giornata,

 a



 -
 Andrea Borruso

 
 email: aborr...@tin.it
 website: http://blog.spaziogis.it
 my 2.0 life: http://aborruso.spaziogis.it
 feed: http://feeds2.feedburner.com/Tanto
 38° 7' 48 N, 13° 21' 9 E
 
 --
 View this message in context:
 http://gis.19327.n5.nabble.com/Sulle-ortofoto-a-50-cm-rilasciate-ieri-da-e-Geos-tp5797851.html
 Sent from the Italy General mailing list archive at Nabble.com.

 ___
 Talk-it mailing list
 Talk-it@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-it



 ___
 Talk-it mailing list
 Talk-it@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-it



 ___
 Talk-it mailing list
 Talk-it@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-it


___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Sulle ortofoto a 50 cm rilasciate ieri da e-Geos

E se magari lo chiedessimo in tanti:
https://twitter.com/aborruso/status/439325020666748928  ;)



-
Andrea Borruso 

 
email: aborr...@tin.it 
website: http://blog.spaziogis.it
my 2.0 life: http://aborruso.spaziogis.it
feed: http://feeds2.feedburner.com/Tanto
38° 7' 48 N, 13° 21' 9 E 

--
View this message in context: 
http://gis.19327.n5.nabble.com/Sulle-ortofoto-a-50-cm-rilasciate-ieri-da-e-Geos-tp5797851p5797856.html
Sent from the Italy General mailing list archive at Nabble.com.

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Sulle ortofoto a 50 cm rilasciate ieri da e-Geos

Ciao Simo,

Simone Cortesi wrote
 Cesare, non hai visto la mia piazzata ieri a Roma quando chiedevo questo
 agli egeos? :-)

io purtroppo non c'ero. Come mai la piazzata?






-
Andrea Borruso 

 
email: aborr...@tin.it 
website: http://blog.spaziogis.it
my 2.0 life: http://aborruso.spaziogis.it
feed: http://feeds2.feedburner.com/Tanto
38° 7' 48 N, 13° 21' 9 E 

--
View this message in context: 
http://gis.19327.n5.nabble.com/Sulle-ortofoto-a-50-cm-rilasciate-ieri-da-e-Geos-tp5797851p5797859.html
Sent from the Italy General mailing list archive at Nabble.com.

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Sulle ortofoto a 50 cm rilasciate ieri da e-Geos

2014-02-28 Thread Michele Mondelli

Molto belle e molto utili!

ciao,


2014-02-28 10:09 GMT+01:00 aborruso aborr...@gmail.com:

 Ciao Simo,

 Simone Cortesi wrote
  Cesare, non hai visto la mia piazzata ieri a Roma quando chiedevo questo
  agli egeos? :-)

 io purtroppo non c'ero. Come mai la piazzata?






 -
 Andrea Borruso

 
 email: aborr...@tin.it
 website: http://blog.spaziogis.it
 my 2.0 life: http://aborruso.spaziogis.it
 feed: http://feeds2.feedburner.com/Tanto
 38° 7' 48 N, 13° 21' 9 E
 
 --
 View this message in context:
 http://gis.19327.n5.nabble.com/Sulle-ortofoto-a-50-cm-rilasciate-ieri-da-e-Geos-tp5797851p5797859.html
 Sent from the Italy General mailing list archive at Nabble.com.

 ___
 Talk-it mailing list
 Talk-it@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-it




-- 
*Michele Mondelli*
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Sulle ortofoto a 50 cm rilasciate ieri da e-Geos

On Feb 28, 2014 10:09 AM, aborruso aborr...@gmail.com wrote:

 Ciao Simo,

 Simone Cortesi wrote
  Cesare, non hai visto la mia piazzata ieri a Roma quando chiedevo questo
  agli egeos? :-)

 io purtroppo non c'ero. Come mai la piazzata?

Check out @vincpatruno's Tweet:
https://twitter.com/vincpatruno/status/439007051529064450

Mi sporgo dal ponte della nave come il barbaro dei Gis che sono e chiedo se
si può usare per openstreetmap

Ieri a Roma.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Sulle ortofoto a 50 cm rilasciate ieri da e-Geos

2014-02-28 Thread cesare gerbino

c'ero, c'ero e ho visto anche la foto che ti immortala .. :-)
Ho scritto nel thread perchè almno così rimane tracciato per chi non c'era
...
buona giornata!

Cesare Gerbino

http://cesaregerbino.wordpress.com/
http://www.facebook.com/cesare.gerbino
http://www.facebook.com/pages/Cesare-Gerbino-GIS-Blog/246234455498174?ref=hl
https://twitter.com/CesareGerbino
http://www.linkedin.com/pub/cesare-gerbino/56/494/77b



Il giorno 28 febbraio 2014 10:20, Simone Cortesi sim...@cortesi.com ha
scritto:


 On Feb 28, 2014 10:09 AM, aborruso aborr...@gmail.com wrote:
 
  Ciao Simo,
 
  Simone Cortesi wrote
   Cesare, non hai visto la mia piazzata ieri a Roma quando chiedevo
 questo
   agli egeos? :-)
 
  io purtroppo non c'ero. Come mai la piazzata?
 
 Check out @vincpatruno's Tweet:
 https://twitter.com/vincpatruno/status/439007051529064450

 Mi sporgo dal ponte della nave come il barbaro dei Gis che sono e chiedo
 se si può usare per openstreetmap

 Ieri a Roma.

 ___
 Talk-it mailing list
 Talk-it@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-it


___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Sulle ortofoto a 50 cm rilasciate ieri da e-Geos

2014-02-28 Thread Francesco Pelullo

Sei diabolico!

Io al posto tuo mi sarei limitato a sputare di nascosto.

Ciao
/niubii/



Il giorno 28 febbraio 2014 10:20, Simone Cortesi sim...@cortesi.com ha
scritto:


 On Feb 28, 2014 10:09 AM, aborruso aborr...@gmail.com wrote:
 
  Ciao Simo,
 
  Simone Cortesi wrote
   Cesare, non hai visto la mia piazzata ieri a Roma quando chiedevo
 questo
   agli egeos? :-)
 
  io purtroppo non c'ero. Come mai la piazzata?
 
 Check out @vincpatruno's Tweet:
 https://twitter.com/vincpatruno/status/439007051529064450

 Mi sporgo dal ponte della nave come il barbaro dei Gis che sono e chiedo
 se si può usare per openstreetmap

 Ieri a Roma.

 ___
 Talk-it mailing list
 Talk-it@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-it


___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Sulle ortofoto a 50 cm rilasciate ieri da e-Geos

2014-02-28 Thread Giuliano


  
  
Nel veneziano vedo che sono confrontabili al
  PCN2006. Come qualit di immagine sono anche meglio, dipende dalle
  zone. Come georeferenziazione si discostano di solo 1 o 2 metri
  dal PCN...
  Bisognerebbe vedere in montagna.
  
  Comunque mlto bene!!
  
  Ciao
  Giuliano
  

Il 28/02/2014 10:13, Michele Mondelli
  ha scritto:


  Molto belle e molto utili!


ciao,
  
  

2014-02-28 10:09 GMT+01:00 aborruso aborr...@gmail.com:
  Ciao Simo,

Simone Cortesi wrote
 Cesare, non hai visto la mia piazzata
  ieri a Roma quando chiedevo questo
   agli egeos? :-)
  

io purtroppo non c'ero. Come mai la piazzata?

  
  
  
  
  
  -
  Andrea Borruso
  
  
  email: aborr...@tin.it
  website: http://blog.spaziogis.it
  my 2.0 life: http://aborruso.spaziogis.it
  feed: http://feeds2.feedburner.com/Tanto
  38 7' 48" N, 13 21' 9" E
  
  --

View this message in context: http://gis.19327.n5.nabble.com/Sulle-ortofoto-a-50-cm-rilasciate-ieri-da-e-Geos-tp5797851p5797859.html

  Sent from the Italy General mailing list
archive at Nabble.com.

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it
  

  





-- 
Michele Mondelli
  

  
  
  
  
  ___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it



  


___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] aggiornamenti wtosm

2014-02-28 Thread cascafico

Perdonatemi se questi già posti. 

Cos'è che stabilisce quando un oggetto (p.es un building) viene evidenziato
in rosso nella mappa aperta da Wikipedia? E' sufficiente che le coord siano
interne, c'è una tolleranza?

Per fiumi ed oggetti geograficamente estesi, c'è un template particolare per
evidenziarli in rosso? Come scegliere le coordinate?



-

--
cascafico.altervista.org
twitter.com/cascafico
--
View this message in context: 
http://gis.19327.n5.nabble.com/aggiornamenti-wtosm-tp5796622p5797868.html
Sent from the Italy General mailing list archive at Nabble.com.

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] GPX del confine amministrativo

2014-02-28 Thread Fabrizio Carrai

Ecco il codice corretto:

!--
Estrae i confini dei comuni specificati
--
osm-script timeout=25
  !-- gather results --
  union

!-- Comuni di interesse  --
query into=a type=relation
  has-kv k=admin_level modv= v=8/
  has-kv k=name v=Livorno/
/query

  recurse type=down/
  /union
  !-- print results --
  print mode=meta/
  recurse type=down/
  print mode=meta order=quadtile/
/osm-script


--
*FabC*


2014-02-26 9:40 GMT+01:00 bredy bredy...@yahoo.it:

 Non funziona mi dice che Error: line 11: static error: Unknown attribute
 reg in element has-kv.



 --
 View this message in context:
 http://gis.19327.n5.nabble.com/GPX-del-confine-amministrativo-tp5795396p5797525.html
 Sent from the Italy General mailing list archive at Nabble.com.

 ___
 Talk-it mailing list
 Talk-it@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-it




-- 
*Fabrizio*
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Sulle ortofoto a 50 cm rilasciate ieri da e-Geos

2014-02-28 9:50 GMT+01:00 aborruso aborr...@gmail.com:
 Ciao,
 per chi volesse farsi un giro: http://aborruso.github.io/realvista-demo/

http://goo.gl/ZrQJzZ

Andrea,
l'accesso tramite WMS è regolato dalla CCBY, non dalla CCBYSA come
scrivi tu nei credits.

-- 
-S

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Sulle ortofoto a 50 cm rilasciate ieri da e-Geos

2014-02-28 Thread Alberto Nogaro

From: sabas88 [mailto:saba...@gmail.com] 
Sent: venerdì 28 febbraio 2014 09:55
To: openstreetmap list - italiano
Subject: Re: [Talk-it] Sulle ortofoto a 50 cm rilasciate ieri da e-Geos

L'url per Josm è 
http://213.215.135.196/reflector/open/service?


Se è utilizzabile sarebbe utile aggiungerlo ai preset:

josm.openstreetmap.de/wiki/Maps/Italy

Ciao
Alberto


 


___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Sulle ortofoto a 50 cm rilasciate ieri da e-Geos

2014-02-28 11:42 GMT+01:00 Simone Cortesi sim...@cortesi.com:

 2014-02-28 9:50 GMT+01:00 aborruso aborr...@gmail.com:
  Ciao,
  per chi volesse farsi un giro: http://aborruso.github.io/realvista-demo/
 
 http://goo.gl/ZrQJzZ

 Andrea,
 l'accesso tramite WMS è regolato dalla CCBY, non dalla CCBYSA come
 scrivi tu nei credits.




si, confermo, la pagina della licenza è questa:
http://www.realvista.it/website/Joomla/index.php?option=com_contentview=articleid=15Itemid=128

Quel che non è chiaro e sarebbe da chiarire è se gli basta una citazione
nella nostra wiki tra le altre fonti (la parte by). Non è stato molto
chiaro ieri nel riguardo, parlava addirritura di logo da mettere.

ciao,
Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Sulle ortofoto a 50 cm rilasciate ieri da e-Geos

2014-02-28 11:46 GMT+01:00 Alberto Nogaro bartosom...@yahoo.it:

 Se è utilizzabile sarebbe utile aggiungerlo ai preset:

 josm.openstreetmap.de/wiki/Maps/Italy



si, ma finchè confermano che attribuzione nel wiki va bene, non possiamo
utilizzare questa fonte.

ciao,
Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Chiusura degli errori su OpenStreetBugs

2014-02-28 Thread Aury88

la maggior parte dei bug segnati in italia mi sembra fossero le colonnine sos
lungo le autostrade...ma ho visto anche che non era possibile verificare la
posizione dalle foto aeree e quindi alla fine è necessario che qualcuno
controlli di persona...insomma la maggior parte dei bug non era utilizzabile
se non sulla fiducia.



-
Ciao,
Aury
--
View this message in context: 
http://gis.19327.n5.nabble.com/Chiusura-degli-errori-su-OpenStreetBugs-tp5797812p5797879.html
Sent from the Italy General mailing list archive at Nabble.com.

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Sulle ortofoto a 50 cm rilasciate ieri da e-Geos

2014-02-28 11:46 GMT+01:00 Martin Koppenhoefer dieterdre...@gmail.com:
 Quel che non è chiaro e sarebbe da chiarire è se gli basta una citazione
 nella nostra wiki tra le altre fonti (la parte by). Non è stato molto
 chiaro ieri nel riguardo, parlava addirritura di logo da mettere.

ti sei perso un pezzo. gli ho ricordato che noi abbiamo una pagina
dove teniamo i credits e ha detto: ok, va bene lì.

-- 
-S

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Sulle ortofoto a 50 cm rilasciate ieri da e-Geos

Caro maestro Yoda,


Simone Cortesi wrote
 Andrea,
 l'accesso tramite WMS è regolato dalla CCBY, non dalla CCBYSA come

siccome sono tile, pensavo che la licenza fosse questa
http://www.realvista.it/website/Joomla/index.php?option=com_contentview=articleid=13:realvista1-0-tile-opencatid=24Itemid=128

Sbaglio?



-
Andrea Borruso 

 
email: aborr...@tin.it 
website: http://blog.spaziogis.it
my 2.0 life: http://aborruso.spaziogis.it
feed: http://feeds2.feedburner.com/Tanto
38° 7' 48 N, 13° 21' 9 E 

--
View this message in context: 
http://gis.19327.n5.nabble.com/Sulle-ortofoto-a-50-cm-rilasciate-ieri-da-e-Geos-tp5797851p5797882.html
Sent from the Italy General mailing list archive at Nabble.com.

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Sulle ortofoto a 50 cm rilasciate ieri da e-Geos

2014-02-28 11:54 GMT+01:00 Simone Cortesi sim...@cortesi.com:

 ti sei perso un pezzo. gli ho ricordato che noi abbiamo una pagina
 dove teniamo i credits e ha detto: ok, va bene lì.



si, l'ha detto, ma non dovrebbe scrivercelo qualcuno che ha il diritto di
questo tipo di dichiarazione? (Se aveva il diritto di rilasciare
dichiarazioni impegnativi o meno non lo so, ma la forma scritta è uno dei
requisiti fondamentali per qualsiasi chiarimento di licenza se ricordo
bene).

Oppure sono più papale del papa?

ciao,
Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] aggiornamenti wtosm

2014-02-28 Thread Simone F.

Il giorno 28 febbraio 2014 11:19, cascafico cascaf...@gmail.com ha
scritto:

 Perdonatemi se questi già posti.

 Cos'è che stabilisce quando un oggetto (p.es un building) viene
 evidenziato
 in rosso nella mappa aperta da Wikipedia?


Basta che l'oggetto in OSM abbia il tag per l'articolo corrispondente, es.
wikipedia=lingua:Titolo dell'articolo.
È il progetto WIWOSM, http://wiki.openstreetmap.org/wiki/WIWOSM.


Ciao,
Simone
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Sulle ortofoto a 50 cm rilasciate ieri da e-Geos

2014-02-28 12:18 GMT+01:00 Martin Koppenhoefer dieterdre...@gmail.com:
 si, l'ha detto, ma non dovrebbe scrivercelo qualcuno che ha il diritto di
 questo tipo di dichiarazione? (Se aveva il diritto di rilasciare
 dichiarazioni impegnativi o meno non lo so, ma la forma scritta è uno dei
 requisiti fondamentali per qualsiasi chiarimento di licenza se ricordo
 bene).

 Oppure sono più papale del papa?

Martin,
non rendiamo complicate le cose.
era lì a presentare il prodotto, ha risposto alle domande, c'e' la
registrazione.

mi sembra piu' che sufficiente.

-- 
-S

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] OT: aiutino con il SQL

2014-02-28 Thread Simone F.

Il giorno 26 febbraio 2014 14:59, Francesco Pelullo
f.pelu...@gmail.comha scritto:


 Ho una tabella, ogni riga è un tratto di strada.
 ...
 Vorrei per il campo PAVIM_STRA il valore che corrisponde al tratto di
 strada più lungo, quindi più rappresentativo:

 CREATE VIEW TABELLA_ESPORTAZIONE AS
 SELECT
 ID AS ID,
 NOME AS NOME,
 Sum(ST_Length(ST_LineMerge(geometry))) AS LUNGH_STRA,

 (SELECT PAVIM_STRA FROM ASSI_STRADALI AS a


ORDER BY ST_Length(a.geometry) DESC
LIMIT 1)


 AS PAVIM_STRA,

 FROM ASSI_STRADALI
 GROUP BY ID;

 L'istruzione SELECT concatenata è di pura fantasia.

 Help!


Ho vinto qualche cosa? :-)


Ciao,
Simone F.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] aggiornamenti wtosm

2014-02-28 Thread Cristian Consonni

Il 28 febbraio 2014 11:19, cascafico cascaf...@gmail.com ha scritto:
 Per fiumi ed oggetti geograficamente estesi, c'è un template particolare per
 evidenziarli in rosso? Come scegliere le coordinate?

Premesso che, come ti ha gà risposto Simone, la colorazione è dovuta
al fatto che *in OSM* c'è il tag
wikipedia=lingua:titolo

(per cui vedi, per esempio, [1] e [2])

Su Wikipedia non c'è alcuna linea guida particolare rispetto agli
oggetti estesi, c'è stata una discussione[3], ma non si è arrivati a
una decisione. Per gli edifici, io personalmente sceglierei il
centroide. Per i fiumi  la foce.

Ciao,

C

[1] https://it.wikipedia.org/wiki/Parco_Sempione_%28Milano%29
[2] http://www.openstreetmap.org/way/115896315
[3] 
https://it.wikipedia.org/wiki/Discussioni_template:Coord#Aggiunta_di_un_parametro_.22fonte.22_al_template

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Sulle ortofoto a 50 cm rilasciate ieri da e-Geos

On Fri, Feb 28, 2014 at 12:04 PM, aborruso aborr...@gmail.com wrote:
 Caro maestro Yoda,

Mio giovane Padawan,

 Simone Cortesi wrote
 Andrea,
 l'accesso tramite WMS è regolato dalla CCBY, non dalla CCBYSA come

 siccome sono tile, pensavo che la licenza fosse questa
 http://www.realvista.it/website/Joomla/index.php?option=com_contentview=articleid=13:realvista1-0-tile-opencatid=24Itemid=128

 Sbaglio?

il settore imaging intende, con la locuzione download e uso quando
scarichi e utilizzi per il tuo elaborato una loro immagine e questa
risulta visibile nell'elaborato finale.

-- 
-S

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Sulle ortofoto a 50 cm rilasciate ieri da e-Geos

2014-02-28 Thread Michele Mondelli

Scusate se mi intrometto, io mi trovo d'accordo con Martin.
In questo genere di cose, avere la traccia scritta è sempre la cosa
migliore.
Alla fine non costa niente scrivergli e farsi rispondere per e-mail.

ciao,


Il giorno 28 febbraio 2014 12:20, Simone Cortesi sim...@cortesi.com ha
scritto:

 2014-02-28 12:18 GMT+01:00 Martin Koppenhoefer dieterdre...@gmail.com:
  si, l'ha detto, ma non dovrebbe scrivercelo qualcuno che ha il diritto di
  questo tipo di dichiarazione? (Se aveva il diritto di rilasciare
  dichiarazioni impegnativi o meno non lo so, ma la forma scritta è uno dei
  requisiti fondamentali per qualsiasi chiarimento di licenza se ricordo
  bene).
 
  Oppure sono più papale del papa?

 Martin,
 non rendiamo complicate le cose.
 era lì a presentare il prodotto, ha risposto alle domande, c'e' la
 registrazione.

 mi sembra piu' che sufficiente.

 --
 -S

 ___
 Talk-it mailing list
 Talk-it@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-it




-- 
*Michele Mondelli*
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Sulle ortofoto a 50 cm rilasciate ieri da e-Geos

Andy borruso, li senti tu via Twitter che sai come fare?

-- 
Sent from my rotary phone. Not a fruit.
On Feb 28, 2014 12:39 PM, Michele Mondelli mithenks...@gmail.com wrote:

 Scusate se mi intrometto, io mi trovo d'accordo con Martin.
 In questo genere di cose, avere la traccia scritta è sempre la cosa
 migliore.
 Alla fine non costa niente scrivergli e farsi rispondere per e-mail.

 ciao,


 Il giorno 28 febbraio 2014 12:20, Simone Cortesi sim...@cortesi.com ha
 scritto:

 2014-02-28 12:18 GMT+01:00 Martin Koppenhoefer dieterdre...@gmail.com:
  si, l'ha detto, ma non dovrebbe scrivercelo qualcuno che ha il diritto
 di
  questo tipo di dichiarazione? (Se aveva il diritto di rilasciare
  dichiarazioni impegnativi o meno non lo so, ma la forma scritta è uno
 dei
  requisiti fondamentali per qualsiasi chiarimento di licenza se ricordo
  bene).
 
  Oppure sono più papale del papa?

 Martin,
 non rendiamo complicate le cose.
 era lì a presentare il prodotto, ha risposto alle domande, c'e' la
 registrazione.

 mi sembra piu' che sufficiente.

 --
 -S

 ___
 Talk-it mailing list
 Talk-it@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-it




 --
 *Michele Mondelli*


 ___
 Talk-it mailing list
 Talk-it@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-it


___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] aggiornamenti wtosm



 Am 28/feb/2014 um 12:33 schrieb Cristian Consonni kikkocrist...@gmail.com:
 
 Per gli edifici, io personalmente sceglierei il
 centroide. Per i fiumi  la foce.


e se c'è più di una foce (es un delta)? cosa sceglieresti per i paesi, 
sopratutto quando consistono anche di territori remoti? alla fine non si può 
scappare, serve una geometria più complessa di un nodo per gli oggetti estesi 
(osm)

ciao,
Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] aggiornamenti wtosm

2014-02-28 Thread Cristian Consonni

Il 28 febbraio 2014 12:50, Martin Koppenhoefer
dieterdre...@gmail.com ha scritto:
 e se c'è più di una foce (es un delta)? cosa sceglieresti per i paesi, 
 sopratutto quando consistono anche di territori remoti? alla fine non si può 
 scappare, serve una geometria più complessa di un nodo per gli oggetti estesi 
 (osm)

Ne sono consapevole, purtroppo però Wikipedia non prevedere altri
sistemi, almeno per il momento.
Il fatto che non ci sia una linea guida, rende legittimo che ciascuno
segua un po' il proprio sentimento...

C

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Sulle ortofoto a 50 cm rilasciate ieri da e-Geos