date:20130726

2013/7/26 Hans Schmidt z0idb...@gmx.de

 There is much to map in Germany, but you have to get outside to the real
 world



+1
cheers,
Martin
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Interesting website stuff in the works

2013-07-26 Thread Michal Migurski

I appreciate that these pulls and discussions are being surfaced to the talk 
list, thank you. 

-mike.

---
michal migurski http://mike.teczno.com

On Jul 25, 2013, at 10:48 PM, Paul Norman penor...@mac.com wrote:

 I'm trying something different in the hopes of getting more awareness about
 potential website changes with significant feature or UI impacts. The
 suggested place for comments is on the github issues or pull requests
 
 Reorganize export/share UI - the next set of changes to the share UI.
 Github page for change at
 https://github.com/openstreetmap/openstreetmap-website/pull/351
 Test deployment at http://mapui.apis.dev.openstreetmap.org/
 
 Add welcome page - Providing a better introductory page, filling a gap in
 existing materials. 
 Github page for change at
 https://github.com/openstreetmap/openstreetmap-website/pull/338
 
 Rationalize multiple locate me type functions - Discussion about confusion
 and duplication between Where am I?, home and the new geolocation button.
 Github page for change at
 https://github.com/openstreetmap/openstreetmap-website/issues/373

 Use a hash anchor for location/zoom persistence - using #zoom/lon/lat
 instead of ?lon=Alat=Bzoom=C
 Github page for change at
 https://github.com/openstreetmap/openstreetmap-website/pull/378
 
 
 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk
 

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

[talk-au] Missing Silver Lake

2013-07-26 Thread Brett Russell

Hi

I sometimes managed to stuff up multipolygon relationships and
 have no idea what is wrong so no idea how to fix them.  The most recent
 one is Silver Lake. It does not come up in the search in mapnik, nor does the 
name display in mapnik nor JOSM.  It is the lake north of Lake Antimony 
in Tasmania on the Pine River.  Can someone have a look at it and advise
 me how to fix it.

Cheers Brett  ___
Talk-au mailing list
Talk-au@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Missing Silver Lake

2013-07-26 Thread Stephen Backway

Brett,

I have fixed/created the multipolygon.

In JOSM you needed to select the lake way, and the two islands and then go to 
Tools-Create Multipolygon. JOSM takes care of the rest.

Regards
Stephen.
- Original Message -
From: Brett Russell
Sent: 07/26/13 08:45 PM
To: OSM Australia mailing list
Subject: [talk-au] Missing Silver Lake

Hi

I sometimes managed to stuff up multipolygon relationships and have no idea 
what is wrong so no idea how to fix them. The most recent one is Silver Lake. 
It does not come up in the search in mapnik, nor does the name display in 
mapnik nor JOSM. It is the lake north of Lake Antimony in Tasmania on the Pine 
River. Can someone have a look at it and advise me how to fix it.

Cheers Brett
___
Talk-au mailing list
Talk-au@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-br] Nomes de rua abreviados

Há um tempo eu fiz um script em Python para arquivos .osm que faz
substituições de strings (incluindo expressões regulares) nos valores
das tags escolhidas (filtradas pelo nome da chave e por tipo de
elemento - nó, linha, relação, etc.) ajustando corretamente o atributo
action de cada elemento e considerando ou ignorando maiúsculas e
minúsculas. Ele funciona em linha de comando (inclui um help básico),
mas ainda não tive tempo de concluir a interface gráfica (posso dar
uma acelerada nisso e disponibilizar). Já usei ele em alguns datasets
meus e em Brasília onde um usuário importou dados com problemas nos
caracteres acentuados.

Acho que seria útil para esse trabalho já que seria essencialmente
substituir as seguintes expressões regulares (ignorando maiúsculas e
minúsculas) nas linhas highway:

^R[. ]  Rua
^Av[. ]  Avenida

Podemos fazer mais dessas, baseados nessa lista de abreviaturas:
http://wiki.openstreetmap.org/wiki/Name_finder:Abbreviations#Portugu.C3.AAs_-_Portuguese

O bot poderia simplesmente baixar os pedaços do mapa, aplicar o script
e então submeter o resultado.

2013/7/25 Arlindo Pereira openstreet...@arlindopereira.com:
 Pessoal,

 a discussão sobre endereçamento me lembrou de um outro problema: ainda
 existem diversas cidades no país com uma grande quantidade de ruas com nomes
 abreviados. Por exemplo, Manaus:

 http://openstreetmap.org/?lat=-3.12454lon=-60.00528zoom=17layers=M

 Alguém anima uma força tarefa para corrigir isso? Me parece o tipo de tarefa
 apropriada para um bot.

 []s
 Arlindo Nighto Pereira

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




-- 
Fernando Trebien
+55 (51) 9962-5409

The speed of computer chips doubles every 18 months. (Moore's law)
The speed of software halves every 18 months. (Gates' law)

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

Re: [Talk-br] Endereçamento com interpoladores





Acho que eu tb no usaria o 3 apenas pelo fato da busca no osm no
retornar para todos os nmeros. Eu at acho isso meio irritante, mas
como os nros aparecem no mapa, d pra se localizar.

Os dados para serem importados possuem apenas as pontas dos
quarteires? Se tiver mais nros nas posies corretas, acho que seria
interessante importar todos, assim algum poderia desenhar os contornos
sem ter que inspecionar tudo..

Atenciosamente,
Roger.

--
Arlindo Pereira escreveu:

  O mtodo 3 me parece estritamente errado. Os endereos
no existem, ponto. Adicion-los me parece, usando uma gria carioca,
"forao de barra" para evitar uma falha/bug/feature do buscador. Uma
espcie de "tag for the renderer".
  
  
  []s
  
  2013/7/25 Fernando Trebien fernando.treb...@gmail.com
  Uma
imagem vale mais do que mil palavras, ento s pra explicar
melhor: http://i.imgur.com/uwNSCWA.png

Ignorem os pontos e as cruzes amarelas (no me aventurei a descobrir
uma forma de escond-las).

A rua 1 est feita com o mtodo mais simples. Serve bem para as ruas
onde a numerao obedeceu a regra da distncia desde o incio da rua.
Tem a eventual desvantagem de, em alguns casos, gerar coordenadas que
so mais prximas de uma das vias transversais do que da via
principal.

A rua 2 est feita da forma que eu observei no RJ.  a mais
estritamente correta, mas se algum procurar por um nmero que cairia
dentro do cruzamento, nenhum resultado  encontrado.

A rua 3 est feita da forma que eu observei em Buenos Aires. Notem que
na rua mais  direita a numerao original foi preservada por causa da
grande diferena de numerao entre os dois lados. No  to correta,
mas a interpolao (por ser uma aproximao) tambm no , e teria a
vantagem de sempre chegar a uma posio aproximada (mesmo que o
endereo no exista, ou seja um endereo novo ainda no mapeado,
etc.). Penso que seja a melhor para conversores e importaes
automticas, a menos que se tenha certeza do cuidado que tiveram com a
numerao.

Claro que todas esses mtodos tambm servem para 1 nico interpolador
ao invs de 2 (um para cada lado).

Se algum quiser o arquivo original para modificar e fazer seus
prprios exemplos: http://db.tt/vtIIhLjG

O que eu fiz em Porto Alegre no  nenhum desses 3 mtodos :P Seria
basicamente um misto da rua 2 com a rua 1 passando a linha do
interpolador pelo meio do cruzamento sempre. Mas estou tendendo mais
ao mtodo da rua 3 agora.

2013/7/25 Fernando Trebien fernando.treb...@gmail.com:

 Acho que no foi ainda bem estabelecida a
forma mais "correta" de usar
 os interpoladores. Para o Nominatim e para o meu GPS (MapFactor
 Navigator) basta:
 - addr:interpolation na linha (o interpolador) que acompanha via
 principal pela lateral
 - addr:housenumber em alguns dos ns ao longo dessa linha, sempre
 acompanhado de addr:street com o valor correto (os ns sem nmero
 servem apenas para definir o contorno do interpolador e gerar
 coordenadas nos lugares certos, algo importante em curvas)

 Colocar addr:street na linha me pareceu o jeito mais natural desde
o
 comeo, mas acabei descobrindo que no  necessrio. Por outro
lado,
 repetir esse mesmo valor em cada n com numerao me parece uma
 tremenda redundncia de informao... no fao idia do que a
 comunidade tinha em mente quando decidiram fazer assim.

 2013/7/25 Arlindo Pereira openstreet...@arlindopereira.com:
 O que eu tenho feito  mapear vias com addr:street=[nome da
rua] e
 addr:interpolation:[odd|even], com seus ns tendo
addr:street=[nome da rua]
 (de novo) e addr:housenumber=[numero], uma para cada
quarteiro.

 Por exemplo: Procurem por Rua Bento Lisboa, 60.
 http://openstreetmap.org/?lat=-22.926233lon=-43.179654zoom=18layers=M

 Nesse exemplo, os nmeros dos prdios na Rua Bento Lisboa
antes e depois da
 Rua Tavares Bastos so 72 e 96. Dessa forma, procurando antes
ou depois de
 qualquer um desses nmeros a interpolao funciona, mas entre
os dois no,
 pois de fato no h casas com este endereo.

 No sei se  a forma mais correta, mas funciona. =)

 []s
 Arlindo "Nighto" Pereira

 2013/7/25 Roger C. Soares rogersoa...@gmail.com

 Deveria. Na minha opinio no seria necessrio nem um way
com
 addr:interpolation, o engine deveria saber pegar os nros
com o mesmo
 addr:street e interpolar segundo as regras de uma rea que
contm a rua, o
 pas por exemplo.


 Mas o wiki define que interpolao tem que ter um way e
talvez seja at pq
 a minha idia no funcione para o mundo todo. A minha
dvida : Como se
 mapeia a interpolao de forma contnua para a rua toda?

 Eu tenho colocado os nros conforme eu vou encontrando e
ligando com
 addr:interpolation, me parece lgico. Segundo o
comportamento do Nominatim
 descrito pelo Fernando, o que eu estou fazendo no
funciona, e na prtica
 realmente no funciona (sempre). Agora, isso  bug ou
feature do Nominatim?
 Quem decide? Tem outro jeito correto para mapear? 
correto manter a
 interpolao e tb numerar o contorno da construo? Muitas
perguntas? :)

 Atenciosamente,
 Roger.

 --
 Gerald Weber escreveu:

 Oi Pessoal

Re: [Talk-br] Nomes de rua abreviados





Coloca o "Rua: " tb, j vi algumas ocorrncias..

Fernando Trebien escreveu:

  H um tempo eu fiz um script em Python para arquivos .osm que faz
substituies de strings (incluindo expresses regulares) nos valores
das tags escolhidas (filtradas pelo nome da chave e por tipo de
elemento - n, linha, relao, etc.) ajustando corretamente o atributo
"action" de cada elemento e considerando ou ignorando maisculas e
minsculas. Ele funciona em linha de comando (inclui um help bsico),
mas ainda no tive tempo de concluir a interface grfica (posso dar
uma acelerada nisso e disponibilizar). J usei ele em alguns datasets
meus e em Braslia onde um usurio importou dados com problemas nos
caracteres acentuados.

Acho que seria til para esse trabalho j que seria essencialmente
substituir as seguintes expresses regulares (ignorando maisculas e
minsculas) nas linhas "highway":

"^R[. ]"  "Rua"
"^Av[. ]"  "Avenida"

Podemos fazer mais dessas, baseados nessa lista de abreviaturas:
http://wiki.openstreetmap.org/wiki/Name_finder:Abbreviations#Portugu.C3.AAs_-_Portuguese

O bot poderia simplesmente baixar os pedaos do mapa, aplicar o script
e ento submeter o resultado.

2013/7/25 Arlindo Pereira openstreet...@arlindopereira.com:
  
  
Pessoal,

a discusso sobre endereamento me lembrou de um outro problema: ainda
existem diversas cidades no pas com uma grande quantidade de ruas com nomes
abreviados. Por exemplo, Manaus:

http://openstreetmap.org/?lat=-3.12454lon=-60.00528zoom=17layers=M

Algum anima uma fora tarefa para corrigir isso? Me parece o tipo de tarefa
apropriada para um bot.

[]s
Arlindo "Nighto" Pereira

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


  
  


  





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

Re: [Talk-br] Endereçamento com interpoladores

Eu sabia que deveria ter feito a rua 4 e a rua 5 no exemplo. :P

Não tenho dúvidas de que é estritamente errado. Aliás, estritamente,
os interpoladores são errados, pois produzem vários números
interpolados que não existem na realidade. Tomando como exemplo as
quadras de Buenos Aires de 100m de comprimento e com intervalo de
numeração de 100 números: se houver 20 prédios em cada quadra (10 de
cada lado da via), 80% dos números interpolados não existirão.

Se são errados, por que são usados? Porque são úteis. A minha questão
é se é útil ao usuário final saber que existe o buraco na numeração
ou se é mais útil obter uma aproximação sempre que possível. Todos os
outros mapas que eu conheço (particularmente os dois melhores, Google
Maps e Nokia HERE Maps) não têm esses buracos. O meu receio é que um
usuário, ao se deparar com um buraco desses, considere o OSM como um
sistema inferior.

Mas então, a rua 4 e a rua 5 seriam variações da rua 2, com uma
modificação: estenderíamos a linha interpoladora através do
cruzamento, passando pela via transversal. Na rua 4 a ligação entre os
números de cada lado seria simplesmente uma linha reta. A rua 5 é o
exemplo de como eu fiz em Porto Alegre, onde essa extensão passaria
necessariamente pelo nó central do cruzamento. Acho que a rua 4 seria
o melhor equilíbrio entre o útil e o estritamente correto.

A rua 4 então modificaria a rua 2 acrecentando interpoladores (linhas
retas) entre os números: 18 e 24, 15 e 27, 52 e 64, 69 e 63.

O resultado: os números exatos são renderizados, e posições
aproximadas são obtidas para todo o intervalo da numeração.

Para completar, essas extensões que passam pelo cruzamento poderiam
receber a tag addr:inclusion=potential. Que tal?

2013/7/25 Arlindo Pereira openstreet...@arlindopereira.com:
 O método 3 me parece estritamente errado. Os endereços não existem, ponto.
 Adicioná-los me parece, usando uma gíria carioca, forçação de barra para
 evitar uma falha/bug/feature do buscador. Uma espécie de tag for the
 renderer.

 []s


 2013/7/25 Fernando Trebien fernando.treb...@gmail.com

 Uma imagem vale mais do que mil palavras, então só pra explicar
 melhor: http://i.imgur.com/uwNSCWA.png

 Ignorem os pontos e as cruzes amarelas (não me aventurei a descobrir
 uma forma de escondê-las).

 A rua 1 está feita com o método mais simples. Serve bem para as ruas
 onde a numeração obedeceu a regra da distância desde o início da rua.
 Tem a eventual desvantagem de, em alguns casos, gerar coordenadas que
 são mais próximas de uma das vias transversais do que da via
 principal.

 A rua 2 está feita da forma que eu observei no RJ. É a mais
 estritamente correta, mas se alguém procurar por um número que cairia
 dentro do cruzamento, nenhum resultado é encontrado.

 A rua 3 está feita da forma que eu observei em Buenos Aires. Notem que
 na rua mais à direita a numeração original foi preservada por causa da
 grande diferença de numeração entre os dois lados. Não é tão correta,
 mas a interpolação (por ser uma aproximação) também não é, e teria a
 vantagem de sempre chegar a uma posição aproximada (mesmo que o
 endereço não exista, ou seja um endereço novo ainda não mapeado,
 etc.). Penso que seja a melhor para conversores e importações
 automáticas, a menos que se tenha certeza do cuidado que tiveram com a
 numeração.

 Claro que todas esses métodos também servem para 1 único interpolador
 ao invés de 2 (um para cada lado).

 Se alguém quiser o arquivo original para modificar e fazer seus
 próprios exemplos: http://db.tt/vtIIhLjG

 O que eu fiz em Porto Alegre não é nenhum desses 3 métodos :P Seria
 basicamente um misto da rua 2 com a rua 1 passando a linha do
 interpolador pelo meio do cruzamento sempre. Mas estou tendendo mais
 ao método da rua 3 agora.

 2013/7/25 Fernando Trebien fernando.treb...@gmail.com:
  Acho que não foi ainda bem estabelecida a forma mais correta de usar
  os interpoladores. Para o Nominatim e para o meu GPS (MapFactor
  Navigator) basta:
  - addr:interpolation na linha (o interpolador) que acompanha via
  principal pela lateral
  - addr:housenumber em alguns dos nós ao longo dessa linha, sempre
  acompanhado de addr:street com o valor correto (os nós sem número
  servem apenas para definir o contorno do interpolador e gerar
  coordenadas nos lugares certos, algo importante em curvas)
 
  Colocar addr:street na linha me pareceu o jeito mais natural desde o
  começo, mas acabei descobrindo que não é necessário. Por outro lado,
  repetir esse mesmo valor em cada nó com numeração me parece uma
  tremenda redundância de informação... não faço idéia do que a
  comunidade tinha em mente quando decidiram fazer assim.
 
  2013/7/25 Arlindo Pereira openstreet...@arlindopereira.com:
  O que eu tenho feito é mapear vias com addr:street=[nome da rua] e
  addr:interpolation:[odd|even], com seus nós tendo addr:street=[nome da
  rua]
  (de novo) e addr:housenumber=[numero], uma para cada quarteirão.
 
  Por exemplo: Procurem por Rua Bento Lisboa,

Re: [Talk-br] Endereçamento com interpoladores

Os dados que eu tenho registram apenas o número inicial e final de
cada quadra. Ainda tenho que confirmar se são números reais ou
potenciais (ex.: atribuindo número para um terreno na esquina onde
nada foi construído ainda). Os do TrackSource eu não sei, mas acredito
que varie por região e/ou desenvolvedor.

Só pra tirar a dúvida: o caso da rua 3 é o caso em que o OSM encontra
resultados para todos os endereços (exceto quando há uma quebra muito
forte entre duas quadras consecutivas). O da rua 2 é o que tem buracos
na numeração, que poderia lhe deixar sem resultados caso você
procurasse por 60 (o número aproximado) ao invés de 65 ou 66 (o número
exato). O da rua 1 retornaria todo o intervalo mas, por causa da forte
quebra na última quadra, a interpolação seria bastante imprecisa
(nesse exemplo ela jogaria você para a quadra errada quase 75% das
vezes).

2013/7/26 Roger C. Soares rogersoa...@gmail.com:
 Acho que eu tb não usaria o 3 apenas pelo fato da busca no osm não retornar
 para todos os números. Eu até acho isso meio irritante, mas como os nros
 aparecem no mapa, dá pra se localizar.

 Os dados para serem importados possuem apenas as pontas dos quarteirões? Se
 tiver mais nros nas posições corretas, acho que seria interessante importar
 todos, assim alguém poderia desenhar os contornos sem ter que inspecionar
 tudo..


 Atenciosamente,
 Roger.

 --
 Arlindo Pereira escreveu:

 O método 3 me parece estritamente errado. Os endereços não existem, ponto.
 Adicioná-los me parece, usando uma gíria carioca, forçação de barra para
 evitar uma falha/bug/feature do buscador. Uma espécie de tag for the
 renderer.

 []s

 2013/7/25 Fernando Trebien fernando.treb...@gmail.com

 Uma imagem vale mais do que mil palavras, então só pra explicar
 melhor: http://i.imgur.com/uwNSCWA.png

 Ignorem os pontos e as cruzes amarelas (não me aventurei a descobrir
 uma forma de escondê-las).

 A rua 1 está feita com o método mais simples. Serve bem para as ruas
 onde a numeração obedeceu a regra da distância desde o início da rua.
 Tem a eventual desvantagem de, em alguns casos, gerar coordenadas que
 são mais próximas de uma das vias transversais do que da via
 principal.

 A rua 2 está feita da forma que eu observei no RJ. É a mais
 estritamente correta, mas se alguém procurar por um número que cairia
 dentro do cruzamento, nenhum resultado é encontrado.

 A rua 3 está feita da forma que eu observei em Buenos Aires. Notem que
 na rua mais à direita a numeração original foi preservada por causa da
 grande diferença de numeração entre os dois lados. Não é tão correta,
 mas a interpolação (por ser uma aproximação) também não é, e teria a
 vantagem de sempre chegar a uma posição aproximada (mesmo que o
 endereço não exista, ou seja um endereço novo ainda não mapeado,
 etc.). Penso que seja a melhor para conversores e importações
 automáticas, a menos que se tenha certeza do cuidado que tiveram com a
 numeração.

 Claro que todas esses métodos também servem para 1 único interpolador
 ao invés de 2 (um para cada lado).

 Se alguém quiser o arquivo original para modificar e fazer seus
 próprios exemplos: http://db.tt/vtIIhLjG

 O que eu fiz em Porto Alegre não é nenhum desses 3 métodos :P Seria
 basicamente um misto da rua 2 com a rua 1 passando a linha do
 interpolador pelo meio do cruzamento sempre. Mas estou tendendo mais
 ao método da rua 3 agora.

 2013/7/25 Fernando Trebien fernando.treb...@gmail.com:
  Acho que não foi ainda bem estabelecida a forma mais correta de usar
  os interpoladores. Para o Nominatim e para o meu GPS (MapFactor
  Navigator) basta:
  - addr:interpolation na linha (o interpolador) que acompanha via
  principal pela lateral
  - addr:housenumber em alguns dos nós ao longo dessa linha, sempre
  acompanhado de addr:street com o valor correto (os nós sem número
  servem apenas para definir o contorno do interpolador e gerar
  coordenadas nos lugares certos, algo importante em curvas)
 
  Colocar addr:street na linha me pareceu o jeito mais natural desde o
  começo, mas acabei descobrindo que não é necessário. Por outro lado,
  repetir esse mesmo valor em cada nó com numeração me parece uma
  tremenda redundância de informação... não faço idéia do que a
  comunidade tinha em mente quando decidiram fazer assim.
 
  2013/7/25 Arlindo Pereira openstreet...@arlindopereira.com:
  O que eu tenho feito é mapear vias com addr:street=[nome da rua] e
  addr:interpolation:[odd|even], com seus nós tendo addr:street=[nome da
  rua]
  (de novo) e addr:housenumber=[numero], uma para cada quarteirão.
 
  Por exemplo: Procurem por Rua Bento Lisboa, 60.
 
  http://openstreetmap.org/?lat=-22.926233lon=-43.179654zoom=18layers=M
 
  Nesse exemplo, os números dos prédios na Rua Bento Lisboa antes e
  depois da
  Rua Tavares Bastos são 72 e 96. Dessa forma, procurando antes ou depois
  de
  qualquer um desses números a interpolação funciona, mas entre os dois
  não,
  pois de fato não há casas com este endereço.
 
  Não sei se é a

Re: [Talk-br] Nomes de rua abreviados





Por enquanto s vi com rua.

Fernando Trebien escreveu:

  Anotado. Voc viu s com "rua" ou ser que podem ter feito tambm
alguma "Avenida: " ?

2013/7/26 Roger C. Soares rogersoa...@gmail.com:
  
  
Coloca o "Rua: " tb, j vi algumas ocorrncias..

Fernando Trebien escreveu:

H um tempo eu fiz um script em Python para arquivos .osm que faz
substituies de strings (incluindo expresses regulares) nos valores
das tags escolhidas (filtradas pelo nome da chave e por tipo de
elemento - n, linha, relao, etc.) ajustando corretamente o atributo
"action" de cada elemento e considerando ou ignorando maisculas e
minsculas. Ele funciona em linha de comando (inclui um help bsico),
mas ainda no tive tempo de concluir a interface grfica (posso dar
uma acelerada nisso e disponibilizar). J usei ele em alguns datasets
meus e em Braslia onde um usurio importou dados com problemas nos
caracteres acentuados.

Acho que seria til para esse trabalho j que seria essencialmente
substituir as seguintes expresses regulares (ignorando maisculas e
minsculas) nas linhas "highway":

"^R[. ]"  "Rua"
"^Av[. ]"  "Avenida"

Podemos fazer mais dessas, baseados nessa lista de abreviaturas:
http://wiki.openstreetmap.org/wiki/Name_finder:Abbreviations#Portugu.C3.AAs_-_Portuguese

O bot poderia simplesmente baixar os pedaos do mapa, aplicar o script
e ento submeter o resultado.

2013/7/25 Arlindo Pereira openstreet...@arlindopereira.com:


Pessoal,

a discusso sobre endereamento me lembrou de um outro problema: ainda
existem diversas cidades no pas com uma grande quantidade de ruas com nomes
abreviados. Por exemplo, Manaus:

http://openstreetmap.org/?lat=-3.12454lon=-60.00528zoom=17layers=M

Algum anima uma fora tarefa para corrigir isso? Me parece o tipo de tarefa
apropriada para um bot.

[]s
Arlindo "Nighto" Pereira

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







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


  
  


  





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

Re: [Talk-br] Endereçamento com interpoladores

2013-07-26 Thread Arlindo Pereira

Só para ver se eu entendi direito, teríamos então uma via com os números
reais de endereçamento na ponta dos quarteirões e, entre eles, isto é,
embaixo da rua transversal teríamos a média entre esses números?

Por exemplo: 72-|80|-88

Se for isso mesmo, com uma tag específica para esses casos, acho que estou
de acordo.

[]s
Em 26/07/2013 10:38, Fernando Trebien fernando.treb...@gmail.com
escreveu:

 Eu sabia que deveria ter feito a rua 4 e a rua 5 no exemplo. :P

 Não tenho dúvidas de que é estritamente errado. Aliás, estritamente,
 os interpoladores são errados, pois produzem vários números
 interpolados que não existem na realidade. Tomando como exemplo as
 quadras de Buenos Aires de 100m de comprimento e com intervalo de
 numeração de 100 números: se houver 20 prédios em cada quadra (10 de
 cada lado da via), 80% dos números interpolados não existirão.

 Se são errados, por que são usados? Porque são úteis. A minha questão
 é se é útil ao usuário final saber que existe o buraco na numeração
 ou se é mais útil obter uma aproximação sempre que possível. Todos os
 outros mapas que eu conheço (particularmente os dois melhores, Google
 Maps e Nokia HERE Maps) não têm esses buracos. O meu receio é que um
 usuário, ao se deparar com um buraco desses, considere o OSM como um
 sistema inferior.

 Mas então, a rua 4 e a rua 5 seriam variações da rua 2, com uma
 modificação: estenderíamos a linha interpoladora através do
 cruzamento, passando pela via transversal. Na rua 4 a ligação entre os
 números de cada lado seria simplesmente uma linha reta. A rua 5 é o
 exemplo de como eu fiz em Porto Alegre, onde essa extensão passaria
 necessariamente pelo nó central do cruzamento. Acho que a rua 4 seria
 o melhor equilíbrio entre o útil e o estritamente correto.

 A rua 4 então modificaria a rua 2 acrecentando interpoladores (linhas
 retas) entre os números: 18 e 24, 15 e 27, 52 e 64, 69 e 63.

 O resultado: os números exatos são renderizados, e posições
 aproximadas são obtidas para todo o intervalo da numeração.

 Para completar, essas extensões que passam pelo cruzamento poderiam
 receber a tag addr:inclusion=potential. Que tal?

 2013/7/25 Arlindo Pereira openstreet...@arlindopereira.com:
  O método 3 me parece estritamente errado. Os endereços não existem,
 ponto.
  Adicioná-los me parece, usando uma gíria carioca, forçação de barra
 para
  evitar uma falha/bug/feature do buscador. Uma espécie de tag for the
  renderer.
 
  []s
 
 
  2013/7/25 Fernando Trebien fernando.treb...@gmail.com
 
  Uma imagem vale mais do que mil palavras, então só pra explicar
  melhor: http://i.imgur.com/uwNSCWA.png
 
  Ignorem os pontos e as cruzes amarelas (não me aventurei a descobrir
  uma forma de escondê-las).
 
  A rua 1 está feita com o método mais simples. Serve bem para as ruas
  onde a numeração obedeceu a regra da distância desde o início da rua.
  Tem a eventual desvantagem de, em alguns casos, gerar coordenadas que
  são mais próximas de uma das vias transversais do que da via
  principal.
 
  A rua 2 está feita da forma que eu observei no RJ. É a mais
  estritamente correta, mas se alguém procurar por um número que cairia
  dentro do cruzamento, nenhum resultado é encontrado.
 
  A rua 3 está feita da forma que eu observei em Buenos Aires. Notem que
  na rua mais à direita a numeração original foi preservada por causa da
  grande diferença de numeração entre os dois lados. Não é tão correta,
  mas a interpolação (por ser uma aproximação) também não é, e teria a
  vantagem de sempre chegar a uma posição aproximada (mesmo que o
  endereço não exista, ou seja um endereço novo ainda não mapeado,
  etc.). Penso que seja a melhor para conversores e importações
  automáticas, a menos que se tenha certeza do cuidado que tiveram com a
  numeração.
 
  Claro que todas esses métodos também servem para 1 único interpolador
  ao invés de 2 (um para cada lado).
 
  Se alguém quiser o arquivo original para modificar e fazer seus
  próprios exemplos: http://db.tt/vtIIhLjG
 
  O que eu fiz em Porto Alegre não é nenhum desses 3 métodos :P Seria
  basicamente um misto da rua 2 com a rua 1 passando a linha do
  interpolador pelo meio do cruzamento sempre. Mas estou tendendo mais
  ao método da rua 3 agora.
 
  2013/7/25 Fernando Trebien fernando.treb...@gmail.com:
   Acho que não foi ainda bem estabelecida a forma mais correta de usar
   os interpoladores. Para o Nominatim e para o meu GPS (MapFactor
   Navigator) basta:
   - addr:interpolation na linha (o interpolador) que acompanha via
   principal pela lateral
   - addr:housenumber em alguns dos nós ao longo dessa linha, sempre
   acompanhado de addr:street com o valor correto (os nós sem número
   servem apenas para definir o contorno do interpolador e gerar
   coordenadas nos lugares certos, algo importante em curvas)
  
   Colocar addr:street na linha me pareceu o jeito mais natural desde o
   começo, mas acabei descobrindo que não é necessário. Por outro lado,
   repetir esse

Re: [Talk-br] Endereçamento com interpoladores

Acho que é isso sim. Só pra não ter dúvidas: o número 80 não seria um
nó, seria o número interpolado, certo? Os únicos nós seriam o 72 e o
88, um de cada lado da via transversal, ambos próximos do cruzamento,
e o tracejado (---) seria o interpolador conectando os dois, com a
tag addr:inclusion=potential.

2013/7/26 Arlindo Pereira openstreet...@arlindopereira.com:
 Só para ver se eu entendi direito, teríamos então uma via com os números
 reais de endereçamento na ponta dos quarteirões e, entre eles, isto é,
 embaixo da rua transversal teríamos a média entre esses números?

 Por exemplo: 72-|80|-88

 Se for isso mesmo, com uma tag específica para esses casos, acho que estou
 de acordo.

 []s

 Em 26/07/2013 10:38, Fernando Trebien fernando.treb...@gmail.com
 escreveu:

 Eu sabia que deveria ter feito a rua 4 e a rua 5 no exemplo. :P

 Não tenho dúvidas de que é estritamente errado. Aliás, estritamente,
 os interpoladores são errados, pois produzem vários números
 interpolados que não existem na realidade. Tomando como exemplo as
 quadras de Buenos Aires de 100m de comprimento e com intervalo de
 numeração de 100 números: se houver 20 prédios em cada quadra (10 de
 cada lado da via), 80% dos números interpolados não existirão.

 Se são errados, por que são usados? Porque são úteis. A minha questão
 é se é útil ao usuário final saber que existe o buraco na numeração
 ou se é mais útil obter uma aproximação sempre que possível. Todos os
 outros mapas que eu conheço (particularmente os dois melhores, Google
 Maps e Nokia HERE Maps) não têm esses buracos. O meu receio é que um
 usuário, ao se deparar com um buraco desses, considere o OSM como um
 sistema inferior.

 Mas então, a rua 4 e a rua 5 seriam variações da rua 2, com uma
 modificação: estenderíamos a linha interpoladora através do
 cruzamento, passando pela via transversal. Na rua 4 a ligação entre os
 números de cada lado seria simplesmente uma linha reta. A rua 5 é o
 exemplo de como eu fiz em Porto Alegre, onde essa extensão passaria
 necessariamente pelo nó central do cruzamento. Acho que a rua 4 seria
 o melhor equilíbrio entre o útil e o estritamente correto.

 A rua 4 então modificaria a rua 2 acrecentando interpoladores (linhas
 retas) entre os números: 18 e 24, 15 e 27, 52 e 64, 69 e 63.

 O resultado: os números exatos são renderizados, e posições
 aproximadas são obtidas para todo o intervalo da numeração.

 Para completar, essas extensões que passam pelo cruzamento poderiam
 receber a tag addr:inclusion=potential. Que tal?

 2013/7/25 Arlindo Pereira openstreet...@arlindopereira.com:
  O método 3 me parece estritamente errado. Os endereços não existem,
  ponto.
  Adicioná-los me parece, usando uma gíria carioca, forçação de barra
  para
  evitar uma falha/bug/feature do buscador. Uma espécie de tag for the
  renderer.
 
  []s
 
 
  2013/7/25 Fernando Trebien fernando.treb...@gmail.com
 
  Uma imagem vale mais do que mil palavras, então só pra explicar
  melhor: http://i.imgur.com/uwNSCWA.png
 
  Ignorem os pontos e as cruzes amarelas (não me aventurei a descobrir
  uma forma de escondê-las).
 
  A rua 1 está feita com o método mais simples. Serve bem para as ruas
  onde a numeração obedeceu a regra da distância desde o início da rua.
  Tem a eventual desvantagem de, em alguns casos, gerar coordenadas que
  são mais próximas de uma das vias transversais do que da via
  principal.
 
  A rua 2 está feita da forma que eu observei no RJ. É a mais
  estritamente correta, mas se alguém procurar por um número que cairia
  dentro do cruzamento, nenhum resultado é encontrado.
 
  A rua 3 está feita da forma que eu observei em Buenos Aires. Notem que
  na rua mais à direita a numeração original foi preservada por causa da
  grande diferença de numeração entre os dois lados. Não é tão correta,
  mas a interpolação (por ser uma aproximação) também não é, e teria a
  vantagem de sempre chegar a uma posição aproximada (mesmo que o
  endereço não exista, ou seja um endereço novo ainda não mapeado,
  etc.). Penso que seja a melhor para conversores e importações
  automáticas, a menos que se tenha certeza do cuidado que tiveram com a
  numeração.
 
  Claro que todas esses métodos também servem para 1 único interpolador
  ao invés de 2 (um para cada lado).
 
  Se alguém quiser o arquivo original para modificar e fazer seus
  próprios exemplos: http://db.tt/vtIIhLjG
 
  O que eu fiz em Porto Alegre não é nenhum desses 3 métodos :P Seria
  basicamente um misto da rua 2 com a rua 1 passando a linha do
  interpolador pelo meio do cruzamento sempre. Mas estou tendendo mais
  ao método da rua 3 agora.
 
  2013/7/25 Fernando Trebien fernando.treb...@gmail.com:
   Acho que não foi ainda bem estabelecida a forma mais correta de
   usar
   os interpoladores. Para o Nominatim e para o meu GPS (MapFactor
   Navigator) basta:
   - addr:interpolation na linha (o interpolador) que acompanha via
   principal pela lateral
   - addr:housenumber em alguns dos nós ao

Re: [Talk-br] Nomes de rua abreviados

2013-07-26 Thread Blademir Andrade de Lima

Bom dia.
Não acho correto usar Rua e Avenida com inicial maiúscula, já que não se 
trata de nome próprio, e sim característica/classificação, mas é o que uso por 
estar de acordo com a maioria dos usuários.
Mas por exemplo, se o nome Avenida faz parte do nome da rua, como em alguns 
casos da minha cidade, como Quarta Avenida, Quinta Avenida, aí sim, o uso 
da maiúscula está correto.
Ja o uso dos dois pontos Rua: etc desconheço.
Sugestão, ja que existe Ruas e Avenidas, no OSM, ao selecionar por residential 
street, que se escolha se é rua ou aenida em um box separado, e deixar o campo 
do nome somente para o nome.

Quanto as abreviações, não as uso mais, como foi de acordo.
Blademir Andrade de Lima

Date: Fri, 26 Jul 2013 10:51:38 -0300
From: rogersoa...@gmail.com
To: talk-br@openstreetmap.org
Subject: Re: [Talk-br] Nomes de rua abreviados




  


Por enquanto só vi com rua.



Fernando Trebien escreveu:

  Anotado. Você viu só com rua ou será que podem ter feito também
alguma Avenida:  ?

2013/7/26 Roger C. Soares rogersoa...@gmail.com:
  
  
Coloca o Rua:  tb, já vi algumas ocorrências..

Fernando Trebien escreveu:

Há um tempo eu fiz um script em Python para arquivos .osm que faz
substituições de strings (incluindo expressões regulares) nos valores
das tags escolhidas (filtradas pelo nome da chave e por tipo de
elemento - nó, linha, relação, etc.) ajustando corretamente o atributo
action de cada elemento e considerando ou ignorando maiúsculas e
minúsculas. Ele funciona em linha de comando (inclui um help básico),
mas ainda não tive tempo de concluir a interface gráfica (posso dar
uma acelerada nisso e disponibilizar). Já usei ele em alguns datasets
meus e em Brasília onde um usuário importou dados com problemas nos
caracteres acentuados.

Acho que seria útil para esse trabalho já que seria essencialmente
substituir as seguintes expressões regulares (ignorando maiúsculas e
minúsculas) nas linhas highway:

^R[. ]  Rua
^Av[. ]  Avenida

Podemos fazer mais dessas, baseados nessa lista de abreviaturas:
http://wiki.openstreetmap.org/wiki/Name_finder:Abbreviations#Portugu.C3.AAs_-_Portuguese

O bot poderia simplesmente baixar os pedaços do mapa, aplicar o script
e então submeter o resultado.

2013/7/25 Arlindo Pereira openstreet...@arlindopereira.com:


Pessoal,

a discussão sobre endereçamento me lembrou de um outro problema: ainda
existem diversas cidades no país com uma grande quantidade de ruas com nomes
abreviados. Por exemplo, Manaus:

http://openstreetmap.org/?lat=-3.12454lon=-60.00528zoom=17layers=M

Alguém anima uma força tarefa para corrigir isso? Me parece o tipo de tarefa
apropriada para um bot.

[]s
Arlindo Nighto Pereira

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







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


  
  
  







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

Re: [Talk-br] Nomes de rua abreviados

2013-07-26 Thread Nelson A. de Oliveira

2013/7/26 Blademir Andrade de Lima blademi...@hotmail.com:
 Não acho correto usar Rua e Avenida com inicial maiúscula, já que não se
 trata de nome próprio, e sim característica/classificação, mas é o que uso
 por estar de acordo com a maioria dos usuários.

É maiúsculo por ser a primeira letra da frase, não?

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

Re: [Talk-br] Nomes de rua abreviados

2013-07-26 Thread Arlindo Pereira

Bom dia!

Olha, sempre vejo o prefixo da rua capitalizado. Desde estradas até ruas
residenciais. Como exemplo, procurei o nome da minha rua - rua capitão cruz
- no google e todos os resultados vieram com rua capitalizado.

[]s

2013/7/26 Blademir Andrade de Lima blademi...@hotmail.com

Bom dia.

Não acho correto usar Rua e Avenida com inicial maiúscula, já que não
se trata de nome próprio, e sim característica/classificação, mas é o que
uso por estar de acordo com a maioria dos usuários.

Mas por exemplo, se o nome Avenida faz parte do nome da rua, como em
alguns casos da minha cidade, como Quarta Avenida, Quinta Avenida, aí
sim, o uso da maiúscula está correto.

Ja o uso dos dois pontos Rua: etc desconheço.

Sugestão, ja que existe Ruas e Avenidas, no OSM, ao selecionar por
residential street, que se escolha se é rua ou aenida em um box separado, e
deixar o campo do nome somente para o nome.

Quanto as abreviações, não as uso mais, como foi de acordo.

Blademir Andrade de Lima

--
Date: Fri, 26 Jul 2013 10:51:38 -0300
From: rogersoa...@gmail.com
To: talk-br@openstreetmap.org
Subject: Re: [Talk-br] Nomes de rua abreviados

Por enquanto só vi com rua.

Fernando Trebien escreveu:

Anotado. Você viu só com rua ou será que podem ter feito também
alguma Avenida: ?

2013/7/26 Roger C. Soares rogersoa...@gmail.com rogersoa...@gmail.com:

Coloca o Rua: tb, já vi algumas ocorrências..

Fernando Trebien escreveu:

Há um tempo eu fiz um script em Python para arquivos .osm que faz
substituições de strings (incluindo expressões regulares) nos valores
das tags escolhidas (filtradas pelo nome da chave e por tipo de
elemento - nó, linha, relação, etc.) ajustando corretamente o atributo
action de cada elemento e considerando ou ignorando maiúsculas e
minúsculas. Ele funciona em linha de comando (inclui um help básico),
mas ainda não tive tempo de concluir a interface gráfica (posso dar
uma acelerada nisso e disponibilizar). Já usei ele em alguns datasets
meus e em Brasília onde um usuário importou dados com problemas nos
caracteres acentuados.

Acho que seria útil para esse trabalho já que seria essencialmente
substituir as seguintes expressões regulares (ignorando maiúsculas e
minúsculas) nas linhas highway:

^R[. ] Rua
^Av[. ] Avenida

Podemos fazer mais dessas, baseados nessa lista de
abreviaturas:http://wiki.openstreetmap.org/wiki/Name_finder:Abbreviations#Portugu.C3.AAs_-_Portuguese

O bot poderia simplesmente baixar os pedaços do mapa, aplicar o script
e então submeter o resultado.

2013/7/25 Arlindo Pereira openstreet...@arlindopereira.com
openstreet...@arlindopereira.com:

Pessoal,

a discussão sobre endereçamento me lembrou de um outro problema: ainda
existem diversas cidades no país com uma grande quantidade de ruas com nomes
abreviados. Por exemplo, Manaus:
http://openstreetmap.org/?lat=-3.12454lon=-60.00528zoom=17layers=M

Alguém anima uma força tarefa para corrigir isso? Me parece o tipo de tarefa
apropriada para um bot.

[]s
Arlindo Nighto Pereira

___
Talk-br mailing
listTalk-br@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-br

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

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

Re: [Talk-br] Nomes de rua abreviados

2013-07-26 Thread Vítor Rodrigo Dias

Blademir,

A gramática (
http://www.gramaticaonline.com.br/texto/804/Mai%C3%BAsculas_e_min%C3%BAsculas)
diz
que o uso de letra inicial maiúscula e minúscula é facultativo no caso de
tipos de logradouros. Porém, como via de regra o logradouro no OSM será
início de frase, deve-se usá-lo com letra inicial maiúscula.

Quanto à sugestão de separar tipos de logradouros, eu respeitosamente
discordo. Acho que o tipo do logradouro faz sim parte do seu nome, pelo
menos na realidade brasileira.

Abraços!

Vítor Rodrigo Dias
Revisor de textos
Tradutor port/ing/port e port/esp/port
Telefone: (31) 9895-3975 - TIM

Em 26 de julho de 2013 11:30, Blademir Andrade de Lima
blademi...@hotmail.com escreveu:

Bom dia.

Mas por exemplo, se o nome Avenida faz parte do nome da rua, como em
alguns casos da minha cidade, como Quarta Avenida, Quinta Avenida, aí
sim, o uso da maiúscula está correto.

Ja o uso dos dois pontos Rua: etc desconheço.

Sugestão, ja que existe Ruas e Avenidas, no OSM, ao selecionar por
residential street, que se escolha se é rua ou aenida em um box separado, e
deixar o campo do nome somente para o nome.

Quanto as abreviações, não as uso mais, como foi de acordo.

Blademir Andrade de Lima

--
Date: Fri, 26 Jul 2013 10:51:38 -0300
From: rogersoa...@gmail.com
To: talk-br@openstreetmap.org
Subject: Re: [Talk-br] Nomes de rua abreviados

Por enquanto só vi com rua.

Fernando Trebien escreveu:

Anotado. Você viu só com rua ou será que podem ter feito também
alguma Avenida: ?

2013/7/26 Roger C. Soares rogersoa...@gmail.com rogersoa...@gmail.com:

Coloca o Rua: tb, já vi algumas ocorrências..

Fernando Trebien escreveu:

Acho que seria útil para esse trabalho já que seria essencialmente
substituir as seguintes expressões regulares (ignorando maiúsculas e
minúsculas) nas linhas highway:

^R[. ] Rua
^Av[. ] Avenida

Podemos fazer mais dessas, baseados nessa lista de
abreviaturas:http://wiki.openstreetmap.org/wiki/Name_finder:Abbreviations#Portugu.C3.AAs_-_Portuguese

O bot poderia simplesmente baixar os pedaços do mapa, aplicar o script
e então submeter o resultado.

2013/7/25 Arlindo Pereira openstreet...@arlindopereira.com
openstreet...@arlindopereira.com:

Pessoal,

Alguém anima uma força tarefa para corrigir isso? Me parece o tipo de tarefa
apropriada para um bot.

[]s
Arlindo Nighto Pereira

___
Talk-br mailing
listTalk-br@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-br

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

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

Re: [Talk-br] Nomes de rua abreviados

2013-07-26 Thread Vitor George

Eu também gostaria que houvesse uma revisão humana antes da edição. O que
eu faço é buscar ruas com abreviações utilizando filtros do JOSM, e aí vou
editando manualmente.

Acho que o ideal seria um plug-in pro JOSM que mostrasse um elemento
abreviado e a sugestão da expansão, mas aí já é bem mais avançado.



2013/7/26 Bráulio brauliobeze...@gmail.com

 Se for para separar o tipo somente no editor, eu sou a favor. O usuário
 veria tipo e nome separados, mas o editor gravaria tudo no campo name.
 Seria uma boa para evitar as abreviações.

 On Friday, July 26, 2013, Vítor Rodrigo Dias vitor.d...@gmail.com wrote:
  ...

  Quanto à sugestão de separar tipos de logradouros, eu respeitosamente
 discordo. Acho que o tipo do logradouro faz sim parte do seu nome, pelo
 menos na realidade brasileira.
 

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


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

Re: [Talk-br] Endereçamento com interpoladores

2013-07-26 Thread Arlindo Pereira

Legal. Testei com Rua General Caldwell, 720 - Porto Alegre e funcionou de
boa.

Eu tinha largado um pouco de mão endereçamento interpolado ao mapear novas
regiões, mas vou retomar os trabalhos na medida do possível.

[]s

2013/7/26 Fernando Trebien fernando.treb...@gmail.com

 Arlindo, para otimização da base de dados, acho melhor mesmo ter uma
 via só. Mas daí usaríamos a tag addr:inclusion=potential ? Ou tanto
 faz? (Sugeri isso só pra indicar que os números no interior do
 cruzamento podem não existir, pro usuário faz pouca diferença.)

 Adaptei os interpoladores que eu tinha colocado no mapa:
 http://openstreetmap.org/?lat=-30.050652lon=-51.225083zoom=18layers=M

 O que você acha? Adicionamos aquela tag addr:inclusion, ou deixamos sem?

 Roger, se você quiser olhar como eu fiz o interpolador para tentar
 replicar a estrutura no seu, as linhas ficaram assim:
 http://www.openstreetmap.org/browse/way/229632046
 http://www.openstreetmap.org/browse/way/229632047

 Clique em qualquer nó nessas listas para ver como ficaram os nós.
 Repare especialmente nas tags que vão na linha e nas que vão nos nós.

 Se você pesquisar por 701 rua general caldwell poa ele retorna um
 resultado interpolado como se esperaria.

 (poa = porto alegre porque eu adicionei esse valor na tag
 loc_name no nó que representa a cidade. De fato, muitas pessoas aqui
 se referem à cidade dessa forma, e vários nomes de produtos - como o
 BikePoa - o usam também. Só a imprensa que não usa.)

 Por causa dessa limitação do Nominatim (aquela validação de
 sanidade), pode ser uma boa idéia (mas não é obrigatório) quebrar
 os interpoladores nos trechos em que há uma variação muito brusca na
 numeração.

 --
 Fernando Trebien
 +55 (51) 9962-5409

 The speed of computer chips doubles every 18 months. (Moore's law)
 The speed of software halves every 18 months. (Gates' law)

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

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

Re: [Talk-br] Endereçamento com interpoladores





Legal,  exatamente assim que eu tenho mapeado. Qdo o nmero  de um
prdio eu tb coloco o nome no addr:housename, pra quando algum fizer o
contorno ter a informao l.

Eu dei uma olhada em algumas interpolaes que eu fiz e qdo as
distncias so prximas realmente esto funcionando legal. Como
numerao pra mim no  prioridade no momento eu coloco s algumas que
eu fotografo, e as vezes eu ligava um nro numa interpolao que estava
funcionando e ela parava de funcionar, ou vice-versa, provavelmente pq
o nro coletado estava muito longe dos outros ou eu colocava um nro
intermediario que fazia passar na validao. Um trecho que no passe na
validao invalida a interpolao toda... isso me confundiu, mas
sabendo disso d pra quebrar estrategicamente algumas e com o tempo,
conforme forem entrando mais nmeros, as buscas devem melhorar.

O modo que vc usou em Porto Alegre eu tinha achado interessante para
ligar o incio e talvez o final da interpolao na rua. Assim ficaria a
metragem inteira da rua coberta. A princpio eu preferia deixar o n
sem nmero, mas pelo visto ele no gera um valor intermedirio pra ns
sem nmero, ento teria que ter um 0 como nmero do n, talvez o mesmo
n para os dois lados da rua... O que vocs acham?  til ou ficaria
muito poludo?

Atenciosamente,
Roger.

--
Fernando Trebien escreveu:

  Arlindo, para otimizao da base de dados, acho melhor mesmo ter uma
via s. Mas da usaramos a tag "addr:inclusion=potential" ? Ou tanto
faz? (Sugeri isso s pra indicar que os nmeros no interior do
cruzamento podem no existir, pro usurio faz pouca diferena.)

Adaptei os interpoladores que eu tinha colocado no mapa:
http://openstreetmap.org/?lat=-30.050652lon=-51.225083zoom=18layers=M

O que voc acha? Adicionamos aquela tag addr:inclusion, ou deixamos sem?

Roger, se voc quiser olhar como eu fiz o interpolador para tentar
replicar a estrutura no seu, as linhas ficaram assim:
http://www.openstreetmap.org/browse/way/229632046
http://www.openstreetmap.org/browse/way/229632047

Clique em qualquer n nessas listas para ver como ficaram os ns.
Repare especialmente nas tags que vo na linha e nas que vo nos ns.

Se voc pesquisar por "701 rua general caldwell poa" ele retorna um
resultado interpolado como se esperaria.

("poa" = "porto alegre" porque eu adicionei esse valor na tag
"loc_name" no n que representa a cidade. De fato, muitas pessoas aqui
se referem  cidade dessa forma, e vrios nomes de produtos - como o
BikePoa - o usam tambm. S a imprensa que no usa.)

Por causa dessa limitao do Nominatim (aquela validao de
"sanidade"), pode ser uma "boa idia" (mas no  obrigatrio) quebrar
os interpoladores nos trechos em que h uma variao muito brusca na
numerao.

2013/7/26 Arlindo Pereira openstreet...@arlindopereira.com:
  
  
Hm, mas a isso envolveria ter de quebrar as vias em muitos pedaos. Nesse
caso, no seria melhor ter uma s via? Dessa forma, os nmeros das esquinas
seriam corretos, e os interpolados entre os cruzamentos se localizariam
nestes.

[]s


2013/7/26 Fernando Trebien fernando.treb...@gmail.com


  Acho que  isso sim. S pra no ter dvidas: o nmero 80 no seria um
n, seria o nmero interpolado, certo? Os nicos ns seriam o 72 e o
88, um de cada lado da via transversal, ambos prximos do cruzamento,
e o tracejado (---) seria o interpolador conectando os dois, com a
tag addr:inclusion=potential.

2013/7/26 Arlindo Pereira openstreet...@arlindopereira.com:
  
  
S para ver se eu entendi direito, teramos ento uma via com os nmeros
reais de endereamento na ponta dos quarteires e, entre eles, isto ,
"embaixo" da rua transversal teramos a mdia entre esses nmeros?

Por exemplo: 72-|80|-88

Se for isso mesmo, com uma tag especfica para esses casos, acho que
estou
de acordo.

[]s

Em 26/07/2013 10:38, "Fernando Trebien" fernando.treb...@gmail.com
escreveu:



  Eu sabia que deveria ter feito a rua 4 e a rua 5 no exemplo. :P

No tenho dvidas de que  estritamente errado. Alis, estritamente,
os interpoladores so errados, pois produzem vrios nmeros
interpolados que no existem na realidade. Tomando como exemplo as
quadras de Buenos Aires de 100m de comprimento e com intervalo de
numerao de 100 nmeros: se houver 20 prdios em cada quadra (10 de
cada lado da via), 80% dos nmeros interpolados no existiro.

Se so errados, por que so usados? Porque so teis. A minha questo
 se  til ao usurio final saber que existe o "buraco" na numerao
ou se  mais til obter uma aproximao sempre que possvel. Todos os
outros mapas que eu conheo (particularmente os dois melhores, Google
Maps e Nokia HERE Maps) no tm esses buracos. O meu receio  que um
usurio, ao se deparar com um buraco desses, considere o OSM como um
sistema inferior.

Mas ento, a rua 4 e a rua 5 seriam variaes da rua 2, com uma
modificao: estenderamos a linha interpoladora atravs do
cruzamento, passando pela via transversal. Na rua 4 a ligao entre os
nmeros de cada lado seria simplesmente uma linha reta. A rua 5  o
exemplo de como eu fiz em

Re: [Talk-de] Import von unklaren Daten geht weiter bitte sofort stoppen

2013-07-26 Thread rainerU

Hallo Hennig,

Am 25.07.2013 23:29, schrieb Henning Scholland:
 ich habe eben kurz mit Frederik Rücksprache gehalten und derzeit sind wir 
 beide
 derzeit der Ansicht, dass es sich hier nicht unbedingt um einen Fall für die 
 DWG
 handelt, sondern besser unter den Mappern geklärt werden sollte.

Ich denke auch, dass die Verhältnismäßigkeit der Mittel eingehalten werden
sollte und direkter Kontakt besser ist als langes Hin- und Her auf der Liste.
Ich halte im konkreten Fall ein moderates Eingreifen der DWG durchaus für
angebracht, wenn es darum geht die Einhaltung der Import Guidelines
durchzusetzen. Das ist erstens ein kritisches Thema, da es um
Lizenzangelegenheiten geht und außerdem kennt sich da der gemeine Mapper meist
nicht so gut aus.

Wenn ich die Wiki-Seite sehe, die die Firma inzwischen angelegt hat, dann komme
ich mir als einer, der für einem weit weniger kritischen Import einen eigenen
Account angelegt hat und in Josm ständig zwischen diesem und meinem üblichen
Account hin und herswitcht, schon etwas veräppelt vor:  Accounts, die
*möglicherweise* an diesem Import arbeiten, kein Wort geschweige denn ein
Nachweis zur rechtlichen Grundlage für die Nutzung der Daten, usw.

Ich finde die Aktion ansonsten für begrüßenswert und unterstützungswürdig.

Gruß
Rainer


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

Re: [Talk-de] Gibt OSM auch Daten über die Beitragenden heraus?

2013-07-26 Thread Peter Wendorff

Hallo Tirkon,

Du sprichst das Thema unter anderem unter (lizenz)rechtlichen Punkten
an, die will ich mal bewusst außen vor lassen; die Frage, ob die
Herausgabe der Metadaten über den Bearbeiter eines OSM-Objekts von den
CT abgedeckt ist sowie ob diese Daten bei Herausgabe mit unter ODBL
stehen (sollten) ignorere ich hier also.

Rein praktisch betrachtet - kannst Du mal skizzieren, wie dein Vorschlag
aussieht?
Also: Wenn die Daten zu Nutzern, die bisher in den von OSM
veröffentlichten Daten enthalten sind, nicht mehr enthalten sein sollen,
wie du das vorschlägst - wie genau sieht das dann aus?

Momentan sind die Daten mehr oder weniger überall da verfügbar, wo die
OSM-Geodaten selbst auch auftauchen:
- über die API (die von Editoren etc. genutzt wird)
- im Planet (der das grundlegende Produkt von OSM ist)
 - über diesen in beinahe jedem Extrakt wie denen der Geofabrik, der
Overpass-API und so weiter

Du schlägst vor, diese Daten nur zur internen Verwendung zu nutzen, und
für die Veröffentlichung ein Opt-Out zu erlauben - aber wo hört intern
auf und fängt extern an?

Intern ist auf jeden Fall der OSM-Server mit der Webseite. Hier gibt es
vollen Zugriff auf die Datenbank, insbesondere auch den auf z.B.
Mailadressen etc., natürlich nicht für Nutzer, sondern für die
Serversoftware selbst.

Nochmal zur Erinnerung: Herausgegeben werden BenutzerID und Benutzername.

Wenn diese Daten aus dem Planet (und allen Folgeprodukten) verschwinden,
schadet das vermutlich erstmal nicht weiter, verhindert aber auch nichts.
Verschwinden diese Daten auch aus der API, so gibt es keine Möglichkeit
für Mapper, sich untereinander zu verständigen, weil es keinerlei
Zuordnung zwischen Objekt/Bearbeitung zum Mapper mehr gibt.
Wie also sollte diese Zuordnung einerseits intern passieren, in diesem
Intern aber die Community der Mapper mit einschließen?

Gruß
Peter

P.S.: Wie gesagt - wie deutlich das wo gesagt werden muss, ist eine
andere Frage, die ich hier mit dieser Mail nicht klären möchte. Es gibt
zwei Möglichkeiten, das Problem anzugehen: Daten nicht mehr
veröffentlichen, oder die Veröffentlichung der Daten deutlicher zu
machen. Ich halte ersteres für unpraktikabel, darauf beziehe ich mich hier.


Am 25.07.2013 18:51, schrieb Tirkon:
 Moin,
 
 Wenn die Karte ergänzt wird, werden auch Daten über den Beitragenden
 hochgeladen, z.B. wer wann wo was editiert hat. Schließlich soll die
 Community die Möglichkeit haben, Fehler festzustellen und andere User
 darauf hinzuweisen sowie miteinander ins Gespräch zu kommen - das was
 man gemeinhin zu den Eigenschaften einer Community zählt. Da ist gut
 so. 
 
 Wenngleich sich auch hier die Frage stellt, wie weit die Analysen
 gehen müssen. Staatlichen Einrichtungen werden oft Begehrlichkeiten
 bezüglich der Datenerfassung und -Auswertung vorgeworfen. Nicht alles
 was möglich ist, ist auch nötig. Prominentes Beispiel sind hier die
 Mautbrücken, die einige Leute auch zu anderen Zwecken nutzen wollen,
 als ursprünglich gedacht. Gehen wir also verantwortungsvoll mit den
 Daten der Mapper um, die diese uns anvertrauen.  
 
 Kürzlich geführte Diskussionen ließen in mir immer mehr den Verdacht
 aufsteigen, dass die Daten über die Beitragenden nicht nur intern
 genutzt werden, sondern - ebenfalls unter freier Lizenz - auch
 herausgegeben werden. Ich möchte mich zunächst vergewissern: Ist das
 richtig so? 
 
 Wenn ja:
 
 Auf osm.org steht: 
 OpenStreetMap ist eine freie, editierbare Karte der gesamten Welt, die
 von Menschen wie dir erstellt wird.
 
 Im Wiki steht:
 Willkommen bei OpenStreetMap, dem Projekt, welches freie geografische
 Daten erstellt und bereitstellt. Aus diesen Daten können zum Beispiel
 Straßen-, Wander- oder Fahrradkarten, Routenplaner oder andere
 wissenswerte Informationen erstellt werden. 
 
 Es ist also die Rede von einer Karte und von Geodaten. Es ist
 nirgendwo die Rede von Daten über die zur Karte Beitragenden. In
 sofern wäre zu überlegen, sich zukünftig auch das zu halten, was
 draußen draufsteht und wirklich nur die **GEO**-Daten zur freien
 Nutzung heraus zu geben. Die Daten über die Mapper werden nur zu
 internen Zwecken verwendet.
 
 Ansonsten müsste sich OSM eine Mogelpackung vorhalten lassen, sollten
 tatsächlich die Daten der Beitragenden mit ausgeliefert werden. Mit
 großen Lettern steht draußen was drauf, was sich nach genauem
 Hinschauen nicht als der eimzige Inhalt erweist und somit die
 freiwilligen Helfer in die Irre führt. Ähnliche Fälle lassen sich in
 der c't allmonatlich in der Rubrik Vorsicht Kunde nachlesen. Und
 dazu sollte OSM nicht gehören.
 
 Zumindest sollte es ein Opt-out für die Herausgabe der Daten der
 freiwilligen Helfer nach außen geben, indem alle out-optierenden bei
 der Herausgabe eine Art Nullwert verpasst bekommen. Dann kann man auch
 mit ruhigem Gewissen weiter für die Mitarbeit bei OSM werben. 
 
 Denn wenn diese Daten herausgegeben werden, dann könnte ja jede
 X-beliebige Person dieselben Analysen durchführen, die Pascal intern

Re: [Talk-de] Import von unklaren Daten geht weiter bitte sofort stoppen

2013-07-26 Thread Henning Scholland


Am 26.07.2013 09:14, schrieb rainerU:

Ich denke auch, dass die Verhältnismäßigkeit der Mittel eingehalten werden
sollte und direkter Kontakt besser ist als langes Hin- und Her auf der Liste.
Ich halte im konkreten Fall ein moderates Eingreifen der DWG durchaus für
angebracht, wenn es darum geht die Einhaltung der Import Guidelines
durchzusetzen. Das ist erstens ein kritisches Thema, da es um
Lizenzangelegenheiten geht und außerdem kennt sich da der gemeine Mapper meist
nicht so gut aus.
Solltet ihr mit einer direkten Kontaktaufnahme nicht weiter kommen, kann 
derjenige sich hinterher gerne an die DWG wenden. Zu Lizenz wurde hier 
ja schon einiges geschrieben. Da macht es auch keinen Unterschied, ob 
das nun eine Erstveröffentlichung ist oder nicht. Ein Mapper, der ein 
Neubaugebiet oder eine neue Straße erfasst macht letztlich nichts 
anderes. Ansonsten hat die DWG derzeit keinen Anhaltspunkt, dass es sich 
hier um einen automatischen Import handelt, sondern dass dies manuell 
passiert. Außerdem denken wir, dass die Accounts für nicht viel mehr, 
als diese Geschichte verwendet werden. Wie aber bereits gesagt, sollte 
es sich hinterher herausstellen, dass die Daten nicht sauber sind, ist 
ein Revert möglich.



Wenn ich die Wiki-Seite sehe, die die Firma inzwischen angelegt hat, dann komme
ich mir als einer, der für einem weit weniger kritischen Import einen eigenen
Account angelegt hat und in Josm ständig zwischen diesem und meinem üblichen
Account hin und herswitcht, schon etwas veräppelt vor:  Accounts, die
*möglicherweise* an diesem Import arbeiten, kein Wort geschweige denn ein
Nachweis zur rechtlichen Grundlage für die Nutzung der Daten, usw.
Das könnte daran liegen, dass die Wiki-Seite nicht von der Firma stammt, 
sondern von Tirkon zusammen getragen wurde. Dafür im übrigen ein Danke. 
Aus diesem Grund sollte der oder die jenige(n), die einen direkten 
Kontakt aufnehmen, bzw. diesen schon haben, die Firma dazu ermuntern, 
die Dokumentation zu vervollständigen. Vor allem in Hinsicht Lizenz.


Viele Grüße
Henning, für die DWG


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

Re: [Talk-de] Gebäudenummern auf Firmengelände

2013-07-26 Thread Marvin Preuss

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, 22. Jul 22:40, Michael Bemmerl wrote:

 ich benutze für sowas den Key building:ref

Super Idee. Sowas habe ich für Universitätsgebäude gesucht. Nur würde ich mir 
wünschen das es dort gerendert werden würde. Ich weiß nie was ich nehmen soll. 
name ist ja dann auch irgendwie unpassend.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJR8kEGAAoJEJA5GTOuzd28XlIH/RHjvCuvf+Y5x85XV/sBsTsU
i6jurmrDERgGIMuT4csxt4RPIGlbl4M+ibyymvvqSNiWfN2RYBFqA0qA/GsoCsry
CPzFZHlJKZYlG9iS9vDN0U9B0OMbCAo+CbL/RomAVB5u1/MPLQvzMt+rRBtLybQW
OlzMSOeSSquPBqKAgeZtUNgW099V9GE5M7t1yzwFzk7NtB7wlvzy2/F/nMjaBpyA
uFTKJ+2kIP3WzygxdhqTczorPNHBusaja/gZzw6IPTzIOtWZF1XkbjicwGs/dAiN
kTS4xd3VJRKB1Dd7rbnOUJ+aSuu4HGHmMLU+qtAlat1jFNkTUHJwoqg6lz1XbpU=
=yWsD
-END PGP SIGNATURE-

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

Re: [Talk-de] Gebäudenummern auf Firmengelände

Am 22. Juli 2013 09:08 schrieb Florian Lohoff f...@zz.de:

 Ich habe fuer solche fälle einfach ref genommen. Es ist ja eine
 referenznummer - Bezugssystem nicht geklärt :)



+1

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

Re: [Talk-de] Gebäudenummern auf Firmengelände

2013-07-26 Thread gmbo


Am 26.07.2013 11:27, schrieb Marvin Preuss:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, 22. Jul 22:40, Michael Bemmerl wrote:


ich benutze für sowas den Key building:ref

Super Idee. Sowas habe ich für Universitätsgebäude gesucht. Nur würde ich mir wünschen 
das es dort gerendert werden würde. Ich weiß nie was ich nehmen soll. name 
ist ja dann auch irgendwie unpassend.

Bei Unigebäuden würde ich würde ich im Normalfall name=* benutzen Da 
finde ich die Nummerierung  meist auch mit Buchstaben schon als 
technischen Namen  in Ordnung.

http://www.openstreetmap.org/index.html?lat=51.4456lon=7.2675zoom=16
Da wird dann der Gebäudename auch  gerendert.
Ich finde das hat man an der Bochumer Uni so gut gemacht.

Hat zwar auch einen Nachteil, denn man sieht keine getagten Hausnummern.

Aber in Firmengeländen, die nur eine Hausnummer haben würde ich auch 
über ref arbeiten. Da käme eher die Firma in name des Gebäudes wenn das 
gesamte Gebäude für diese Firma  reserviert ist.


LG Gisbert




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

Re: [Talk-de] Gebäudenummern auf Firmengelände

Am 26. Juli 2013 12:45 schrieb gmbo g...@kilometerfresser.eu:

 Bei Unigebäuden würde ich würde ich im Normalfall name=* benutzen Da finde
 ich die Nummerierung  meist auch mit Buchstaben schon als technischen Namen
  in Ordnung.
 http://www.openstreetmap.org/**index.html?lat=51.4456lon=7.**2675zoom=16http://www.openstreetmap.org/index.html?lat=51.4456lon=7.2675zoom=16
 Da wird dann der Gebäudename auch  gerendert.
 Ich finde das hat man an der Bochumer Uni so gut gemacht.



Wobei das alles Abkürzungen zu sein scheinen, m.E. ist das Tagging für den
Renderer, besser wäre es, den vollen Namen in den name-tag zu schreiben
und die Abkürzung in einen alternativen tag wie ref oder short_name oder so.

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

Re: [Talk-de] Import von unklaren Daten geht weiter bitte sofort stoppen

2013-07-26 Thread fly

On 25.07.2013 23:29, Henning Scholland wrote:
 Hallo,
 ich habe eben kurz mit Frederik Rücksprache gehalten und derzeit sind
 wir beide derzeit der Ansicht, dass es sich hier nicht unbedingt um
 einen Fall für die DWG handelt, sondern besser unter den Mappern geklärt
 werden sollte.

Ich denke, dass sieht hier etwas anders aus. Es wurde bereits alles hier
auf der Liste erwähnt aber anstatt endlich mal das Tagging-Schema zu
dokumentieren und darüber zu diskutieren wird einfach munter weitergemappt.

Natürlich habe ich schon angefangen persönliche Mails zu senden und
werde es auch weiter machen, allerdings habe ich in letzter Zeit leider
etliche nicht so positive Erfahrungen gemacht und bald keine Lust mehr.


 Hier haben sich ja nun einige Mapper gefunden, die an einer Klärung
 durchaus ein Interesse haben. Evtl. wäre es eine gute Idee, wenn diese
 Mapper direkten Kontakt mit den besagten Mappern aufnehmen und die
 Probleme auf einer sachlichen Ebene ansprechen würden. Ich habe eher den
 Eindruck, als dass die Firma etwas mit dem Umfang dieser Mailingliste
 überfordert ist, sodass der direkte Kontakt zu einer guten Lösung für
 beide Seiten führen dürfte. Bevor das einer von der DWG macht, der Du,
 Du, Du sagt, denke ich, dass es sinnvoller ist, wenn sich ein
 Interessierter dazu bereit erklärt und zwischen den beiden Welten
 versucht eine Brücke zu bauen. Evtl. kann der besagte Stammtisch auch
 etwas Grundlagenarbeit leisten und aufzeigen, wie das Mappen bei OSM
 funktioniert.
 Dabei wäre sicherlich auch sinnvoll, wenn die Firma gebeten wird, die
 wiki-Seite, die ihr angelegt habt, selbst mit Inhalt füllt oder
 zumindest den Inhalt liefert.

Genau, die Lizenz klären, die eigenen Daten überprüfen (notfalls vor
Ort) und lokale Mapper_innen einbeziehen.

Dokumentieren und erarbeiten eines Taggingschema und dann erst editieren.

 Ein Revert ist immer noch möglich, sollte es nötig sein.

Unter den getroffenen Absprachen fange ich damit jetzt an.

Heute wird der name=Bahnhof als einziger Tag an nodes gehängt.
Eindeutig Vandalismus.

Grüße
fly

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

Re: [Talk-de] Import von unklaren Daten geht weiter bitte sofort stoppen

2013-07-26 Thread Dirk Sohler

fly schrieb:
 Ich denke, dass sieht hier etwas anders aus. Es wurde bereits alles
 hier auf der Liste erwähnt aber anstatt endlich mal das
 Tagging-Schema zu dokumentieren und darüber zu diskutieren wird
 einfach munter weitergemappt.

Ich habe ein wenig das Gefühl, dass das Unternehmen lediglich
informieren, und nicht diskutieren will, und nur die OSM-Infrastruktur
benutzen möchte, anstatt selbst entsprechende Server bereitzustellen.
Das fing schon mit dem völlig verqueren Tagnamen an …

Grüße,
Dirk

-- 
Local time :: Ortszeit :: DE-HH
2013-07-26T15:21:42+0200


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

Re: [Talk-de] Qualitätsverbesserung von SpeedCamera-Relationen

2013-07-26 Thread Tirkon

Jan Tappenbeck o...@tappenbeck.net wrote:

Es gibt zwar ein Querposting hierzu unter [2] aber irgendwie kommt keine 
Reaktion zu diesem Thema.

Ich denke, dass die Enforcement-Wikiseite 
http://wiki.openstreetmap.org/wiki/DE:Relation:enforcement
mit ihren Relationen und ellenlanger komplizierter Beschreibung die
meisten User vom Mappen der Speedcams abschreckt. 

Es geht auch einfacher:

highway=speed_camera
maxspeed=X 

Auch wenn dabei möglicherweise in der nicht betroffenen Fahrtrichtung
gewarnt wird.

http://wiki.openstreetmap.org/wiki/DE:Relation:enforcement#einfache_Methode


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

Re: [Talk-de] Gibt OSM auch Daten über die Beitragenden heraus?

2013-07-26 Thread Tirkon

Peter Wendorff wendo...@uni-paderborn.de wrote:

Du sprichst das Thema unter anderem unter (lizenz)rechtlichen Punkten
an, die will ich mal bewusst außen vor lassen; die Frage, ob die
Herausgabe der Metadaten über den Bearbeiter eines OSM-Objekts von den
CT abgedeckt ist sowie ob diese Daten bei Herausgabe mit unter ODBL
stehen (sollten) ignorere ich hier also.

Ich bin Dir sehr dankbar dafür, dass Du das hier nicht in den
Mittelpunkt stellst. Es geht mir in diesem Thread insbesondere darum,
die Werbung für OSM mit der CT in Einklang zu bringen. Hier einen
Mapper mit Technobabble Spitzfindigkeiten wie dem Unterschied zwischen
Daten und Metadaten zu leimen, von denen der Angler, Radfahrer etc
keinen Schimmer hat, sollte IMHO gerade einem Projekt nicht anstehen,
das auf freiwillige Helfer setzt. 

Was ich hier anspreche, ist die Täuschung der freiwilligen Helfer und
der Unterschied zwischen dem Kleingedruckten und dem, was auf der
Verpackung steht. Dabei bin ich mir im Klaren darüber, dass dies
vermutlich nicht absichtlich geschah. Da OSM ursprünglich vermutlich
nur aus Nerds bestand, war es für diese kein Problem zu erkennen, was
da ausgeliefert wird. Später kamen die einfachen Mapper hinzu, die
dies nicht eruieren können, sondern nur lesen, dass hier **Geo**-Daten
veröffentlicht werden.

Rein praktisch betrachtet - kannst Du mal skizzieren, wie dein Vorschlag
aussieht?

Nein, da sich für mich gerade erst der Status Quo klärt. 

Also: Wenn die Daten zu Nutzern, die bisher in den von OSM
veröffentlichten Daten enthalten sind, nicht mehr enthalten sein sollen,
wie du das vorschlägst - wie genau sieht das dann aus?

Momentan sind die Daten mehr oder weniger überall da verfügbar, wo die
OSM-Geodaten selbst auch auftauchen:
- über die API (die von Editoren etc. genutzt wird)
- im Planet (der das grundlegende Produkt von OSM ist)
 - über diesen in beinahe jedem Extrakt wie denen der Geofabrik, der
Overpass-API und so weiter

Du schlägst vor, diese Daten nur zur internen Verwendung zu nutzen, und
für die Veröffentlichung ein Opt-Out zu erlauben - aber wo hört intern
auf und fängt extern an?

Dass eine solche Trennung nicht existiert, habe ich - fehlgeleitet
durch die schon zitierte Homepage und Wikiseite - erst in den letzten
Tagen vor diesem Posting gelernt. Insbesondere klärt sich für mich
gerade erst, dass diese Grenze nicht so leicht zu ziehen ist und
folglich eine solche Trennung schwierig ist.

Intern ist auf jeden Fall der OSM-Server mit der Webseite. Hier gibt es
vollen Zugriff auf die Datenbank, insbesondere auch den auf z.B.
Mailadressen etc., natürlich nicht für Nutzer, sondern für die
Serversoftware selbst.

Nochmal zur Erinnerung: Herausgegeben werden BenutzerID und Benutzername.

Mir ist klar, dass die Mailadresse nicht herausgegeben wird.
Allerdings zeigt sich dank der Auswertungen von Pascal, dass
insbesondere aktive Mapper trotz Nichname durch deren persönliches
Umfeld identifizierbar werden, welches kaum beeinflussbar ist.
Beispielsweiae kann sich ein Parlaments-Bediensteter nicht aussuchen,
wer in dieses Parlament gewählt wird oder wer dort durch
unterschiedlichste Beteiligte eingestellt wird oder wer in seiner
Nachbarschaft wohnt.

Es gibt
zwei Möglichkeiten, das Problem anzugehen: Daten nicht mehr
veröffentlichen, ... 

Dass dies im Community Umfeld nicht machbar ist und zudem das
Erreichen des Zieles verunmöglicht, habe ich im Eingangsposting schon
gesagt. 

... oder die Veröffentlichung der Daten deutlicher zu machen. 

Das wäre auch dann dasjenige, was ich als Ergebnis dieser Diskussion
vorgeschlagen hätte. IMHO sollte dies an gleicher prominenter Stelle
erfolgen, wo in großen Lettern die unbestreitbaren Vorzüge des
Projektes zu lesen sind. Damit brächte man die Werbung dann auch mit
der CT in Einklang. Ansonsten wäre man dem Vorwurf ausgesetzt, den
bisher nicht so richtig wahrgenommenen Unterschied zwischen Verpackung
und Kleingedruckten nunmehr in voller Kenntnis und somit arglistig zu
akzeptieren.


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

Re: [Talk-it] Convenzioni importazioni CTRN Veneto

2013-07-26 Thread Paolo Monegato


Il 25/07/2013 21:02, bredy ha scritto:

Mi stavo leggendo le codifiche di importazione delle CTRN del Veneto per
farmi un'idea sulle cose da taggare e che tag usare.

Mi sono imbattuto sulla dicitura LIVCOD=0105P Chiesa (pertinenza) taggato
come amenity=place of worship
ma se leggo il wiki mi dice che solo la chiesa come luogo di culto va
taggato con questa indicazione e non va usato come landuse o per taggare
altri luoghi della chiesa, se questa ha anche altre strutture forse sarebbe
più indicato amenity=monastery


Dato che anche il sagrato è luogo di culto direi che il tag adottato 
dalla comunità veneta è giusto (ovviamente altre strutture non 
consacrate vanno tenute fuori). La chiesa si distingue dal resto per il 
fatto che è un building.


Il tag non viene usato come un landuse, ma semplicemente per delimitare 
l'area dedicata al culto (che non è la sola chiesa).


Monastery invece mi sembra più adatto per altre strutture.

ciao
Paolo M

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

[Talk-it] Linee elettriche e sub-station

2013-07-26 Thread bredy

Ma per collegare le linee elettriche alle sotto stazioni, per capirci quelle
piccole casette grigie ai bordi delle strade devo disegnarci sopra un pilone
o palo?



--
View this message in context: 
http://gis.19327.n5.nabble.com/Linee-elettriche-e-sub-station-tp5771458.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-it] Convenzioni importazioni CTRN Veneto



Il giorno 26/lug/2013, alle ore 09:55, Paolo Monegato 
gato.selvad...@gmail.com ha scritto:

 Dato che anche il sagrato è luogo di culto direi che il tag adottato dalla 
 comunità veneta è giusto (ovviamente altre strutture non consacrate vanno 
 tenute fuori). La chiesa si distingue dal resto per il fatto che è un 
 building.
 
 Il tag non viene usato come un landuse, ma semplicemente per delimitare 
 l'area dedicata al culto (che non è la sola chiesa).
 
 Monastery invece mi sembra più adatto per altre strutture.


+1, lo vedo come problema del rendering

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

Re: [Talk-it] Linee elettriche e sub-station

2013-07-26 Thread Cascafico Giovanni

se vogliamo rappresentare la realtà direi di no
Il giorno 26/lug/2013 11.08, bredy bredy...@yahoo.it ha scritto:

 Ma per collegare le linee elettriche alle sotto stazioni, per capirci
 quelle
 piccole casette grigie ai bordi delle strade devo disegnarci sopra un
 pilone
 o palo?



 --
 View this message in context:
 http://gis.19327.n5.nabble.com/Linee-elettriche-e-sub-station-tp5771458.html
 Sent from the Italy General mailing list archive at Nabble.com.

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

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

Re: [Talk-it] Linee elettriche e sub-station

2013-07-26 Thread bredy

però così facendo si genera un errore in josm



--
View this message in context: 
http://gis.19327.n5.nabble.com/Linee-elettriche-e-sub-station-tp5771458p5771473.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-it] Grafica mancante

2013-07-26 Thread Simone Cortesi

2013/7/25 bredy bredy...@yahoo.it:
 Una casa di riposo è al pari di un ospedale una struttura complessa e se
 vogliamo simili, sarebbe molto più facile identificare un luogo se anche
 questa fosse rappresentata correttamente con lo stesso colore giallo, come
 le scuole. Potrebbe essere il colore delle landuse per le infrastrutture
 pubbliche

non sto mettendo in dubbio questo, cio' che voglio dire è che quella
che vedi su osm è UNA delle possibili rappresentazioni dei dati, nel
caso specifico puoi chiedere che il curatore del foglio di stile ha
deciso che si vedessero certe caratteristiche e non altre.

se vuoi proporre modifiche, manda suggerimenti qui:
https://trac.openstreetmap.org/

-- 
-S

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

Re: [Talk-it] Garmux ora permette la ricerca per indirizzi

2013-07-26 Thread Michele Armani

Lo sto testando con il .pbf dell'Italia appena scaricato.
Ho un vecchio centrino dual core con 3gb di ram e mi sta dando dei
problemi credo legati alla quantità di memoria.
Ho provato a ripartire la memoria attribuendo 1g al programma e 1g al
rendering. Ha macianto bene per un paio di minuti facendo lavorare a
dovere i due core ma poi si è come arenato con un messaggio di out of
memory (ti giro l'ultima parte dei messaggi del terminale):

..
MAP occupancy: 346538
MAP occupancy: 33440
40.000.000 nodes processed... id=1598782467
MAP occupancy: 23821645
MAP occupancy: 3788871
MAP occupancy: 355703
MAP occupancy: 33781
Exception in thread main java.lang.OutOfMemoryError: Java heap space
at 
it.unimi.dsi.fastutil.longs.LongArrays.ensureCapacity(LongArrays.java:107)
at 
it.unimi.dsi.fastutil.longs.LongArrayList.ensureCapacity(LongArrayList.java:202)
at it.unimi.dsi.fastutil.longs.LongArrayList.size(LongArrayList.java:271)
at 
uk.me.parabola.splitter.SparseInt2ShortMapInline.resizeTo(SparseInt2ShortMapInline.java:97)
at 
uk.me.parabola.splitter.SparseInt2ShortMapInline.put(SparseInt2ShortMapInline.java:125)
at 
uk.me.parabola.splitter.SparseInt2ShortMultiMap$Inner.put(SparseInt2ShortMultiMap.java:81)
at 
uk.me.parabola.splitter.SparseInt2ShortMultiMap.put(SparseInt2ShortMultiMap.java:31)
at uk.me.parabola.splitter.SplitProcessor.writeNode(SplitProcessor.java:209)
at 
uk.me.parabola.splitter.SplitProcessor.processNode(SplitProcessor.java:118)
at 
uk.me.parabola.splitter.BinaryMapParser.parseDense(BinaryMapParser.java:50)
at crosby.binary.BinaryParser.parse(BinaryParser.java:124)
at crosby.binary.BinaryParser.handleBlock(BinaryParser.java:68)
at crosby.binary.file.FileBlock.process(FileBlock.java:135)
at crosby.binary.file.BlockInputStream.process(BlockInputStream.java:34)
at uk.me.parabola.splitter.Main.processMap(Main.java:403)
at uk.me.parabola.splitter.Main.writeAreas(Main.java:368)
at uk.me.parabola.splitter.Main.split(Main.java:190)
at uk.me.parabola.splitter.Main.start(Main.java:118)
at uk.me.parabola.splitter.Main.main(Main.java:107)
Elapsed time: 6m 0s   Memory: Current 982MB (719MB used, 263MB free) Max 982MB
Elapsed time: 8m 0s   Memory: Current 982MB (720MB used, 262MB free) Max 982MB
..

Ho provato a modificare lo script impostando 1.9G al posto di 2.7G
come predefinito.
A quel punto ho fatto ripartire il programma Garmux da terminale
affidando 1.9G al programma e 0.5G al render. La cpu ha lavorato per
un tempo più lungo, ma poi il programma si è di nuovo arenato.
Invertendo i valori mi va anche peggio :)
Posso provare a fare qualcos'altro o è proprio il mio sistema a essere
sottodimensionato?

Grazie mille

Michele


2013/7/25 Stefano Droghetti stefano.droghe...@gmail.com:
 Ciao a tutti :-) Come da oggetto: Garmux, il programmino per Linux che
 abbiamo sviluppato insieme tempo fa in questa stessa mailing list, che
 trasforma le mappe di Openstreetmap in mappe per dispositivi Garmin, da me
 sviluppato partendo da uno script di Stefano Salvador, a sua volta derivato
 da CreateIMG.bat beta05 per Windows di Marco Certelli, a sua volta basato su
 mkgmaps.jar, da oggi aggiunge la possibilità di cercare le strade e le città
 direttamente nella ricerca indirizzi dei dispositivi Garmin Nuvi.

 Qui trovate la nuova versione, la 2.0:

 http://sites.google.com/site/stefanodroghetti/nuvi

 Chi vuole la testi e mi faccia sapere :-)

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

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

Re: [Talk-it] OSMIT 2013 in arrivo: Rovereto (TN) 4-6 ottobre 2013

2013-07-26 Thread Simone Cortesi

On Thu, Jul 25, 2013 at 2:52 PM, Cristian Consonni
kikkocrist...@gmail.com wrote:
 Ho creato la pagina sul wiki:
 http://wiki.openstreetmap.org/wiki/IT:OSMit2013

 e anche su Wikipedia:
 http://it.wikipedia.org/wiki/Wikipedia:Raduni/Rovereto_OSMit_(evento_Wiki-OSM)

ciao,
approfittando della presenza (che attendiamo numerosa) di wikimedia
italia, non pensate possa essere una buona idea per intavolare, magari
gia' adesso in mailinglist un processo associativo.

ne parliamo da anni, non è arrivato il momento di avere una voce
ufficiale come osm in italia, e magari diventare chapter italiano
della osm foundation sotto wikimedia italia?

che ne dite?

-- 
-S

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

Re: [Talk-it] OSMIT 2013 in arrivo: Rovereto (TN) 4-6 ottobre 2013

2013-07-26 Thread Maurizio Napolitano

 ne parliamo da anni, non è arrivato il momento di avere una voce
 ufficiale come osm in italia, e magari diventare chapter italiano
 della osm foundation sotto wikimedia italia?

 che ne dite?

Dal mio personale punto di vista questa e' una ottima proposta.
Wikimedia Italia e' una delle associazioni, in campo delle
condivisione della conoscenza, fra le piu' attive.
Il progetto OpenStreetMap ha molto in comune (tanto che
spesso si dice la wiki mappa).
Si potrebbe anche ragionare sull'essere un ente a se, ma questo
genera molto lavoro extra. Invece, in collaborazione con
una associazione solida e ben strutturata, il tutto andrebbe
in discesa.
Certo c'e' da capire la formula.
Cercando la via piu' breve penso che basterebbe che Wikimedia
Italia si occupasse anche di OpenStreetMap e che fra i soci
venga eletto un rappresentate sul tema con la funzione
di interagire con la OSM Foundation e chiunque si vuole
avvicinare alla comunita' italiana.

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

Re: [Talk-it] OSMIT 2013 in arrivo: Rovereto (TN) 4-6 ottobre 2013

2013-07-26 Thread sabas88

Il giorno 26 luglio 2013 16:09, Simone Cortesi sim...@cortesi.com ha
scritto:

 On Thu, Jul 25, 2013 at 2:52 PM, Cristian Consonni
 kikkocrist...@gmail.com wrote:
  Ho creato la pagina sul wiki:
  http://wiki.openstreetmap.org/wiki/IT:OSMit2013
 
  e anche su Wikipedia:
 
 http://it.wikipedia.org/wiki/Wikipedia:Raduni/Rovereto_OSMit_(evento_Wiki-OSM)

 ciao,
 approfittando della presenza (che attendiamo numerosa) di wikimedia
 italia, non pensate possa essere una buona idea per intavolare, magari
 gia' adesso in mailinglist un processo associativo.

 ne parliamo da anni, non è arrivato il momento di avere una voce
 ufficiale come osm in italia, e magari diventare chapter italiano
 della osm foundation sotto wikimedia italia?

 che ne dite?


+1


 --
 -S

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

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

Re: [Talk-it] OSMIT 2013 in arrivo: Rovereto (TN) 4-6 ottobre 2013

2013/7/26 Simone Cortesi sim...@cortesi.com

 On Thu, Jul 25, 2013 at 2:52 PM, Cristian Consonni
 kikkocrist...@gmail.com wrote:
  Ho creato la pagina sul wiki:
  http://wiki.openstreetmap.org/wiki/IT:OSMit2013
 
  e anche su Wikipedia:
 
 http://it.wikipedia.org/wiki/Wikipedia:Raduni/Rovereto_OSMit_(evento_Wiki-OSM)

 ciao,
 approfittando della presenza (che attendiamo numerosa) di wikimedia
 italia, non pensate possa essere una buona idea per intavolare, magari
 gia' adesso in mailinglist un processo associativo.

 ne parliamo da anni, non è arrivato il momento di avere una voce
 ufficiale come osm in italia, e magari diventare chapter italiano
 della osm foundation sotto wikimedia italia?

 che ne dite?




se non ci limita. Non conosco la comunità italiana di Wikipedia, ma quella
tedesca sono sicuro che non vorrei che OSM diventasse una
sotto-divisione. Potresti spiegare cosa secondo te sarebbe il vantaggio
di associarsi a loro?

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

Re: [Talk-it] Garmux ora permette la ricerca per indirizzi

2013-07-26 Thread Stefano Droghetti

Con Xubuntu 32bit e 4GB di RAM devo impostare per entrambi 1GB. Con altri
non saprei.
Il problema è relativo a java e mkgmaps, non saprei. Se mi aiutate a capire
come superarlo sarete ovviamente accreditati tra gli autori :-)
Il giorno 26/lug/2013 13:50, Michele Armani michele.arm...@gmail.com ha
scritto:

 Lo sto testando con il .pbf dell'Italia appena scaricato.
 Ho un vecchio centrino dual core con 3gb di ram e mi sta dando dei
 problemi credo legati alla quantità di memoria.
 Ho provato a ripartire la memoria attribuendo 1g al programma e 1g al
 rendering. Ha macianto bene per un paio di minuti facendo lavorare a
 dovere i due core ma poi si è come arenato con un messaggio di out of
 memory (ti giro l'ultima parte dei messaggi del terminale):

 ..
 MAP occupancy: 346538
 MAP occupancy: 33440
 40.000.000 nodes processed... id=1598782467
 MAP occupancy: 23821645
 MAP occupancy: 3788871
 MAP occupancy: 355703
 MAP occupancy: 33781
 Exception in thread main java.lang.OutOfMemoryError: Java heap space
 at
it.unimi.dsi.fastutil.longs.LongArrays.ensureCapacity(LongArrays.java:107)
 at
it.unimi.dsi.fastutil.longs.LongArrayList.ensureCapacity(LongArrayList.java:202)
 at
it.unimi.dsi.fastutil.longs.LongArrayList.size(LongArrayList.java:271)
 at
uk.me.parabola.splitter.SparseInt2ShortMapInline.resizeTo(SparseInt2ShortMapInline.java:97)
 at
uk.me.parabola.splitter.SparseInt2ShortMapInline.put(SparseInt2ShortMapInline.java:125)
 at
uk.me.parabola.splitter.SparseInt2ShortMultiMap$Inner.put(SparseInt2ShortMultiMap.java:81)
 at
uk.me.parabola.splitter.SparseInt2ShortMultiMap.put(SparseInt2ShortMultiMap.java:31)
 at
uk.me.parabola.splitter.SplitProcessor.writeNode(SplitProcessor.java:209)
 at
uk.me.parabola.splitter.SplitProcessor.processNode(SplitProcessor.java:118)
 at
uk.me.parabola.splitter.BinaryMapParser.parseDense(BinaryMapParser.java:50)
 at crosby.binary.BinaryParser.parse(BinaryParser.java:124)
 at crosby.binary.BinaryParser.handleBlock(BinaryParser.java:68)
 at crosby.binary.file.FileBlock.process(FileBlock.java:135)
 at
crosby.binary.file.BlockInputStream.process(BlockInputStream.java:34)
 at uk.me.parabola.splitter.Main.processMap(Main.java:403)
 at uk.me.parabola.splitter.Main.writeAreas(Main.java:368)
 at uk.me.parabola.splitter.Main.split(Main.java:190)
 at uk.me.parabola.splitter.Main.start(Main.java:118)
 at uk.me.parabola.splitter.Main.main(Main.java:107)
 Elapsed time: 6m 0s   Memory: Current 982MB (719MB used, 263MB free) Max
982MB
 Elapsed time: 8m 0s   Memory: Current 982MB (720MB used, 262MB free) Max
982MB
 ..

 Ho provato a modificare lo script impostando 1.9G al posto di 2.7G
 come predefinito.
 A quel punto ho fatto ripartire il programma Garmux da terminale
 affidando 1.9G al programma e 0.5G al render. La cpu ha lavorato per
 un tempo più lungo, ma poi il programma si è di nuovo arenato.
 Invertendo i valori mi va anche peggio :)
 Posso provare a fare qualcos'altro o è proprio il mio sistema a essere
 sottodimensionato?

 Grazie mille

 Michele


 2013/7/25 Stefano Droghetti stefano.droghe...@gmail.com:
  Ciao a tutti :-) Come da oggetto: Garmux, il programmino per Linux che
  abbiamo sviluppato insieme tempo fa in questa stessa mailing list, che
  trasforma le mappe di Openstreetmap in mappe per dispositivi Garmin, da
me
  sviluppato partendo da uno script di Stefano Salvador, a sua volta
derivato
  da CreateIMG.bat beta05 per Windows di Marco Certelli, a sua volta
basato su
  mkgmaps.jar, da oggi aggiunge la possibilità di cercare le strade e le
città
  direttamente nella ricerca indirizzi dei dispositivi Garmin Nuvi.
 
  Qui trovate la nuova versione, la 2.0:
 
  http://sites.google.com/site/stefanodroghetti/nuvi
 
  Chi vuole la testi e mi faccia sapere :-)
 
  ___
  Talk-it mailing list
  Talk-it@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-it

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

Re: [Talk-it] OSMIT 2013 in arrivo: Rovereto (TN) 4-6 ottobre 2013

2013-07-26 Thread Cristian Consonni

Il 26 luglio 2013 17:43, Martin Koppenhoefer dieterdre...@gmail.com
ha scritto:
 se non ci limita. Non conosco la comunità italiana di Wikipedia, ma quella
 tedesca sono sicuro che non vorrei che OSM diventasse una sotto-divisione.

Potresti fornire qualche esempio pratico del perché sarebbe un problema?
Nota:  qui si parla di Wikimedia Italia, non di Wikipedia, inoltre
bisognerebbe specificare cosa si intende con sotto-divisione,
immagino che la cosa migliore sia inziare a discutere le varie
possibilità.
Io sono qui, a disposizione, se serve.

Cristian
(incidentalmente Vicepresidente di Wikimedia Italia)

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

Re: [Talk-it] OSMIT 2013 in arrivo: Rovereto (TN) 4-6 ottobre 2013

2013-07-26 Thread Simone Cortesi

2013/7/26 Cristian Consonni kikkocrist...@gmail.com:
 se non ci limita. Non conosco la comunità italiana di Wikipedia, ma quella
 tedesca sono sicuro che non vorrei che OSM diventasse una sotto-divisione.

 Potresti fornire qualche esempio pratico del perché sarebbe un problema?
 Nota:  qui si parla di Wikimedia Italia, non di Wikipedia, inoltre
 bisognerebbe specificare cosa si intende con sotto-divisione,
 immagino che la cosa migliore sia inziare a discutere le varie
 possibilità.
 Io sono qui, a disposizione, se serve.

infatti, credo che sia arrivato il momento di discutere e di vedere se
c'e' questo fit che in molti vedono.

-- 
-S

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

[Talk-at] Franzisco-Josephinische Landesaufnahme

2013-07-26 Thread Friedrich Volkmann

Diese Landesaufnahme ist für uns äußerst interessant, weil viele 
topografische Namen (Bergnamen usw.) eingezeichnet sind, die in ÖK usw. 
nicht mehr drinstehen. Außerdem brauchen wir auf Grund des Alters niemanden 
um Erlaubnis fragen.


Auf Wikimedia Commons hat ein gewisser Josef Moser viele Aufnahmeblätter 
hochgeladen, aber bei weitem nicht alle. Die Frage ist nun, wo wir die 
restlichen herbekommen? Die Nationalbibliothek hat sie, aber das Procedere 
ist oder zumindest war dort extrem umständlich.


--
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria


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

Re: [Talk-at] Franzisco-Josephinische Landesaufnahme

2013-07-26 Thread AleXXw

http://lazarus.elte.hu/hun/digkonyv/topo/3felmeres.htm

LG Alex


2013/7/26 Friedrich Volkmann b...@volki.at

 Diese Landesaufnahme ist für uns äußerst interessant, weil viele
 topografische Namen (Bergnamen usw.) eingezeichnet sind, die in ÖK usw.
 nicht mehr drinstehen. Außerdem brauchen wir auf Grund des Alters niemanden
 um Erlaubnis fragen.

 Auf Wikimedia Commons hat ein gewisser Josef Moser viele Aufnahmeblätter
 hochgeladen, aber bei weitem nicht alle. Die Frage ist nun, wo wir die
 restlichen herbekommen? Die Nationalbibliothek hat sie, aber das Procedere
 ist oder zumindest war dort extrem umständlich.

 --
 Friedrich K. Volkmann   http://www.volki.at/
 Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria


 __**_
 Talk-at mailing list
 Talk-at@openstreetmap.org
 http://lists.openstreetmap.**org/listinfo/talk-athttp://lists.openstreetmap.org/listinfo/talk-at

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

Re: [Talk-at] Franzisco-Josephinische Landesaufnahme

2013-07-26 Thread Friedrich Volkmann


On 26.07.2013 21:11, AleXXw wrote:

http://lazarus.elte.hu/hun/digkonyv/topo/3felmeres.htm


Danke, das ist schon mal ganz schön. Allerdings finde ich da nur die 
1:20. Gibt es auch die 1:25000?


--
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Talk-cat] Un de nou

2013-07-26 Thread Jaume Figueras i Jové


Benvingut Eloi,

què ets qui portes el web i projecte de mapa de les gavarres?

http://perdutalesgavarres.blogspot.com.es/

Salut!

On 25/07/13 10:01, Konfrare Albert wrote:

Hola Eloi,

Benvingut a la llista!
M'he estat mirant la zona que mapes, i només puc felicitar-te per la
impressionant tasca que has fet. Sens dubte contribucions com la teva
aporten a OSM un valor afegit :)

Sobre els consells per mapar... més que consells idees per si et són útils:

  * Jo als torrents a waterway=stream els hi afegeixo intermittent=yes
http://wiki.openstreetmap.org/wiki/Key:intermittent per
diferenciar-los de les rieres on el pas de l'aigua hi és constant. A
http://hikebikemap.de/ es renderitzen de forma intermitent. Exemple:
http://hikebikemap.de/?zoom=15lat=41.4095lon=1.95568layers=BF
  * Després he agafat una petita zona de les Gavarres i he comprovat que
als highway=track no hi havia la key tracktype=*
http://wiki.openstreetmap.org/wiki/Key:tracktype. Entenc que no és
una etiqueta massa objectiva, però permet fer-nos una idea de com
serà la pista.
  * El mateix pels highway=path. Hi ha keys que ajuden a entendre com és
el camí si es té un bon coneixement de la zona. Per exemple:
sac_scale http://wiki.openstreetmap.org/wiki/Key:sac_scale,
smoothness http://wiki.openstreetmap.org/wiki/Key:smoothness,
trail_visibility
http://wiki.openstreetmap.org/wiki/Key:trail_visibility, surface
http://wiki.openstreetmap.org/wiki/Key:surface, obstacle
http://wiki.openstreetmap.org/wiki/Proposed_features/Obstacle, etc.

Salut, mapes i bon estiu!


El dia 24 de juliol de 2013 21.13, Eloi . balu...@hotmail.com
mailto:balu...@hotmail.com ha escrit:

Hola a tots,

Em dic Eloi i sóc de Palamós. Estic mapejant la zona rural de les
Gavarres.
Tots els consells per mapejar aquest tipus de zones seran benvinguts!

Ade

ElOi

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




--
*KONFRARE ALBERT*
La Konfraria de la Vila del Pingüí
de La Palma de Cervelló
www.konfraria.org http://www.konfraria.org • @La_Konfraria
http://twitter.com/La_Konfraria



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



--
   Jaume Figueras i Jové
o o o  Responsable de projectes SIG
o o o  inLab FIB
o o o
U P C  Universitat Politècnica de Catalunya - Barcelona Tech

   E-mail : jaume.figue...@upc.edu
   Web: http://inlab.fib.upc.edu/
   Telf   : +34937398621 (intern UPC: 98621)
   Mòbil  : +34650756456 (intern UPC: 44785)
   Fax: +34937398628 (intern UPC: 98628)

   Adreça : inLab FIB
Edifici B5-S102
C/ Jordi Girona, 31
08025 BARCELONA

Ubuntu User #14347 - Linux User #504317

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

Re: [Talk-cat] Un de nou

2013-07-26 Thread Jaume Figueras i Jové


Home, doncs FELICITATS!!

Nosaltres, per la zona de Sant Llorenç de Munt i l'Obac hi hem 
involucrat el centre excursionista, que ja disposava d'una cartografia i 
sobretot toponímia acurada.


Potser els centres excursionistes de la zona et poden ajudar. Si vols 
podem comentar experiències al respecte!!


Salut!

On 26/07/13 19:09, Eloi . wrote:

Sí sóc l'Eloi de les Gavarres.

Per cert sense gaire èxit buscant ajundants i ho tinc molt parat perquè
he estat pare!

Salut!

ElOi

  Date: Fri, 26 Jul 2013 18:49:13 +0200
  From: jaume.figue...@upc.edu
  To: talk-cat@openstreetmap.org
  Subject: Re: [Talk-cat] Un de nou
 
  Benvingut Eloi,
 
  què ets qui portes el web i projecte de mapa de les gavarres?
 
  http://perdutalesgavarres.blogspot.com.es/
 
  Salut!
 
  On 25/07/13 10:01, Konfrare Albert wrote:
   Hola Eloi,
  
   Benvingut a la llista!
   M'he estat mirant la zona que mapes, i només puc felicitar-te per la
   impressionant tasca que has fet. Sens dubte contribucions com la teva
   aporten a OSM un valor afegit :)
  
   Sobre els consells per mapar... més que consells idees per si et
són útils:
  
   * Jo als torrents a waterway=stream els hi afegeixo intermittent=yes
   http://wiki.openstreetmap.org/wiki/Key:intermittent per
   diferenciar-los de les rieres on el pas de l'aigua hi és constant. A
   http://hikebikemap.de/ es renderitzen de forma intermitent. Exemple:
  
http://hikebikemap.de/?zoom=15lat=41.4095lon=1.95568layers=BF
   * Després he agafat una petita zona de les Gavarres i he comprovat que
   als highway=track no hi havia la key tracktype=*
   http://wiki.openstreetmap.org/wiki/Key:tracktype. Entenc que no és
   una etiqueta massa objectiva, però permet fer-nos una idea de com
   serà la pista.
   * El mateix pels highway=path. Hi ha keys que ajuden a entendre com és
   el camí si es té un bon coneixement de la zona. Per exemple:
   sac_scale http://wiki.openstreetmap.org/wiki/Key:sac_scale,
   smoothness http://wiki.openstreetmap.org/wiki/Key:smoothness,
   trail_visibility
   http://wiki.openstreetmap.org/wiki/Key:trail_visibility, surface
   http://wiki.openstreetmap.org/wiki/Key:surface, obstacle
   http://wiki.openstreetmap.org/wiki/Proposed_features/Obstacle, etc.
  
   Salut, mapes i bon estiu!
  
  
   El dia 24 de juliol de 2013 21.13, Eloi . balu...@hotmail.com
   mailto:balu...@hotmail.com ha escrit:
  
   Hola a tots,
  
   Em dic Eloi i sóc de Palamós. Estic mapejant la zona rural de les
   Gavarres.
   Tots els consells per mapejar aquest tipus de zones seran benvinguts!
  
   Ade
  
   ElOi
  
   ___
   Talk-cat mailing list
   Talk-cat@openstreetmap.org mailto:Talk-cat@openstreetmap.org
   http://lists.openstreetmap.org/listinfo/talk-cat
  
  
  
  
   --
   *KONFRARE ALBERT*
   La Konfraria de la Vila del Pingüí
   de La Palma de Cervelló
   www.konfraria.org http://www.konfraria.org • @La_Konfraria
   http://twitter.com/La_Konfraria
  
  
  
   ___
   Talk-cat mailing list
   Talk-cat@openstreetmap.org
   http://lists.openstreetmap.org/listinfo/talk-cat
  
 
  --
  Jaume Figueras i Jové
  o o o Responsable de projectes SIG
  o o o inLab FIB
  o o o
  U P C Universitat Politècnica de Catalunya - Barcelona Tech
 
  E-mail : jaume.figue...@upc.edu
  Web : http://inlab.fib.upc.edu/
  Telf : +34937398621 (intern UPC: 98621)
  Mòbil : +34650756456 (intern UPC: 44785)
  Fax : +34937398628 (intern UPC: 98628)
 
  Adreça : inLab FIB
  Edifici B5-S102
  C/ Jordi Girona, 31
  08025 BARCELONA
 
  Ubuntu User #14347 - Linux User #504317
 
  ___
  Talk-cat mailing list
  Talk-cat@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-cat


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



--
   Jaume Figueras i Jové
o o o  Responsable de projectes SIG
o o o  inLab FIB
o o o
U P C  Universitat Politècnica de Catalunya - Barcelona Tech

   E-mail : jaume.figue...@upc.edu
   Web: http://inlab.fib.upc.edu/
   Telf   : +34937398621 (intern UPC: 98621)
   Mòbil  : +34650756456 (intern UPC: 44785)
   Fax: +34937398628 (intern UPC: 98628)

   Adreça : inLab FIB
Edifici B5-S102
C/ Jordi Girona, 31
08025 BARCELONA

Ubuntu User #14347 - Linux User #504317

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

[Talk-cz] Hromadná ubytovací zařízení České republiky

2013-07-26 Thread Pavel Kwiecien

Zdravím, narazil jsem na zajímavou databázi ubytovacích zařízení:

http://www.czso.cz/lexikon/uz.nsf/index

Podle prvního nahlédnutí ještě není doplněná o všechny zařízení, ale i tak je 
zde mnoho zajímavých informací. Podle informací z webu zřejmě není problém s 
licencí.

Informace získané ze zveřejněného seznamu mohou uživatelé využít nejen pro 
analytické účely související s podnikatelskými záměry či při zvažování změn v 
regionálních územních plánech, ale také pro orientaci při hledání ubytování o 
dovolené.

Zdraví Pavel Kwiecien
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

[OSM-talk-fr] Greffon Cadastre

2013-07-26 Thread Dominique Lavoille


Bonjour,
Chez moi j'ai un bug avec JOSM et le greffon cadastre en utilisant la 
fenêtre d'outil d'aide pour ajouter des adresses.
Quand j'utilise cette fenêtre pour ajouter des nœuds d'adresse à 
l'écran, si je veux rafraichir le cadastre (F10) et que j'appuie par 
mégarde (nul n'est parfait avec des gros doigts sur un petit clavier!) 
sur F11 (plein écran), alors la fenêtre d'aide d'adresse disparait de 
l'écran. En la rappelant, elle est alors vide. Pour la faire 
réapparaitre normalement, il faut sortir et relancer JOSM.
Avez-vous constaté cela?.

Merci d'avance
Cordialement
Dominique

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

Re: [OSM-talk-fr] Le rendu fr pret pour l'exportation

Le 26 juillet 2013 07:54, Philippe Verdy verd...@wanadoo.fr a écrit :
 Une des remarques faites est que les cartes d'OSM France affichent
 préférablement le français (donc Londres et pas London).


Le projet TileMill est disponible sur github, il suffit de repartir de
là et de faire les adaptations locales.

 Pour une utilisation internationale, il faudrait afficher de préférence la
 langue locale (voire plusieurs), qui devrait être le nom par défaut sans
 suffixe de code langue (et, si ce n'est pas une langue officielle, une
 version romanisée entre parenthèses, en français sinon anglais lorsque les
 noms en langue locale ne sont pas en caractères latins, mais par exemple en
 écriture arabe, hebreu, cyrillique, grecque, sinographique, ou une des
 écritures indo-brahmiques)

 En conséquence une version internationale afficherait les noms français en
 France et au Québec et Afrique fracophone, anglais au Royaume-Uni, en
 Irlande aux USA et le reste du Canada, espagnol en Espagne et la majeure
 partie de l'Amerique centrale et du Sud, portugais au Portugal et au Brésil,
 suédois en Suède, etc. En Russie on verrait le nom russe suivi du nom
 anglais entre parenthèses, en Chine le nom chinois sinographique suivi du
 nom anglais (sinon du nom en romanisation pinyin), etc.

 Noter que c'est ce que font déjà Google Maps/Earth, Bing Maps (même si
 Google maintenant essaye de localiser les noms dans la langue du visiteur).

 L'idéal serait d'avoir une couche de libellé transparente séparée du reste
 du rendu (bien que les étiquettes de numéros de référence des routes ou
 numéros de bâtiments dans les rues ne soient pas dépendants de la langue,
 ils interfèrent entre eux et devraient aller aussi dans cette couche
 transparente).


C'est un peu plus complexe que ça. Il faudrait une couche où tout les
éléments placés figurent, c'est à dire, les libellés et références
de routes, mais aussi les symboles (icônes) qui jouent aussi sur le
placement de texte.

L'icône d'un symbole (par exemple le bretzel d'une boulangerie) va
prendre la place et un texte ne pourra pas être placé au même
endroit. On ne peut donc pas dissocier les uns des autres si on veut
quelque chose de cohérent au final.

Il y a du coup une couche de fond (occupation des sols, routes, etc)
sans placement, où chaque élément est superposé, et une couche
placée.


 L'ennui c'est que multiplier les couches c'est aussi augmenter la place
 nécessaire pour le stockage Une place qui peut être considérablemetn réduite
 en la fabriquant non pas au format bitmap mais au format vectoriel (quitte à
 inclure sur le serveur un rendu bitmap instantané à partir d'un pavage
 cectoriel précalculé, au moyen d'un serveur proxy cache annexe, pour
 permettre la compatibilité avec des visualisations sur navigateurs non
 pourvus en capacité de rendu vectoriel. Ce serveur proxy pourrait aussi
 combiner plusieurs couches pour produire à la volée une couche bitmap
 unique, sans avoir à cacher la totalité des niveaux, avec une place disque
 énorme (ce serait seulement un cache FIFO pouvant tenir entièrement dans un
 seul SSD à prix modique, avec la moitié du cache pour les pavés sources
 téléchargés du serveur de rendu OSM France, l'autre moitié du cache pour le
 pavage précombiné).

 On n'exploite pas encore assez la possibilité de mutusliser les rendus avec
 des caches intermédiaires pour des rendus transparents superposables,
 pourtant cela permettrait des économies de bande passante sur les serveurs
 et permettrait de répartir la charge, tout en augmentant même la réactivité
 à terme, puisque les couches transparentes plus simples seraient plus
 rapides à calculer et demanderaient moins de données depuis la base OSM.
 Encore actuellement toutes les couches Mapnik sont calculées successivement
 sur le même serveur de rendu qui effectue toutes les compositions.


C'est un peu la voie que j'ai exploré sur les faibles zooms, en
déconnectant la couche de fond de la couche de détail même si c'était
dans un autre objectif.

C'est sûr que le vectoriel va rebattre les cartes, mais ne va pas non
plus être une solution miracle, surtout à ce niveau de zoom.
Les quantités de données manipulées sont très importantes et posera de
nouveaux problèmes de volumes de données à tranférer et à traiter où
alors on devra rester dans un rendu léger, qui ne devra choisir qu'un
faible nombre d'objets à rendre ou alors faire de gros
pré-traitements.


 Le système de distribution du pavage n'est pas optimal en terme de capacité
 et répartition de charge, car chaque serveur de rendu veut faire la totalité
 du rendu lui-même et aucun ne veut collaborer pour travailler à plusieurs
 pour construire un rendu final (pour pouvoir le faire il faudrait disposer
 d'outils de mesure de la réactivité et la fraicheur de chaque serveur
 participant, et une gestion fine des dates de péremption des caches, adaptée
 à la capacité locale de stockage, de calcul, et de bande passante montante
 et descendante).


On pourrait

Re: [OSM-talk-fr] Rendu des fossés d'irrigation sur le fond OSM-FR

2013-07-26 Thread Nicolas Moyroud



Le 24/07/2013 17:51, Pierre Knobel a écrit :

On trouve tout de même beaucoup de fossés qu'on voit à peine sous la
végétation et qui sont à sec 99% du temps, je ne sais pas si un rendu
plus gras serait approprié dans ces cas.

Oui certes, mais bon là ils sont quasi invisibles. Vouloir afficher des 
objets de la base et le faire de telle manière qu'on ne les voit 
quasiment pas c'est quand même étrange. Dans ces cas là peut-être 
faudrait-il plutôt envisager de ne pas les afficher du tout. Ce qui dans 
mon cas ne m'arrangerait pas, mais bon... ;-)
Je pense qu'un trait légèrement plus large de quelques pixels ne nuirait 
pas énormément au reste et permettrait qu'on les voit un peu mieux. Il 
faudrait peut-être faire un test pour voir ce que ça donne.


Nicolas

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

[OSM-talk-fr] Le serveur osm7 ne répond plus...

2013-07-26 Thread Nicolas Moyroud

... et donc l'outil de saisie des numéros d'adresse non plus. C'est 
grave docteur ? :-)


Nicolas

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

Re: [OSM-talk-fr] Réunion mensuelle osm idf

2013-07-26 Thread Fabien

Le 25 juillet 2013 15:47, Marc SIBERT m...@sibert.fr a écrit :
 Bonjour,

 Pas très réactif par cette chaleur, je vous propose la rencontre mensuelle
 ce vendredi 26 juillet des 19h au Pere Fouettard (comme d'habitude en fait)

 N'hésitez pas à vous faire connaître pour s' assurer qu'il y aura un
 corum...

Bonjour,

Je ne pourrais pas être présent ce mois-ci. Question aussi : c'est
bien un restaurant vers Châtelet ? Vous mangez là-bas ?

Fabien

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

Re: [OSM-talk-fr] Réunion mensuelle osm idf

2013-07-26 Thread Ab_fab

Bonjour,

Ce ne sera pas possible ce mois-ci pour ma part

Fabien : oui, c'est un restaurant, il est possible de dîner sur place

Bonne journée


Le 25 juillet 2013 15:47, Marc SIBERT m...@sibert.fr a écrit :

 Bonjour,

 Pas très réactif par cette chaleur, je vous propose la rencontre mensuelle
 ce vendredi 26 juillet des 19h au Pere Fouettard (comme d'habitude en fait)

 N'hésitez pas à vous faire connaître pour s' assurer qu'il y aura un
 corum...

 --
 Marc Sibert
 m...@sibert.fr

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




-- 
ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab
Il n'y a pas de pas perdus, Nadja
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Réunion mensuelle osm idf

2013-07-26 Thread Marc SIBERT

Pour le moment, ça ne fait que 2 personnes avec moi-même
Heu, c'est pas que j'ai des saisies de gare du RER C à faire mais si je
peux rester chez moi ce soir...

Pour le moment, la réunion n'est pas confirmée.

A+


Le 25 juillet 2013 15:47, Marc SIBERT m...@sibert.fr a écrit :

 Bonjour,

 Pas très réactif par cette chaleur, je vous propose la rencontre mensuelle
 ce vendredi 26 juillet des 19h au Pere Fouettard (comme d'habitude en fait)

 N'hésitez pas à vous faire connaître pour s' assurer qu'il y aura un
 corum...

 --
 Marc Sibert
 m...@sibert.fr




-- 
Marc Sibert
m...@sibert.fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Guide de saisie des commerces (POI) Était : Re: Rôtisserie ?

2013-07-26 Thread Pieren

2013/7/24 Jean-Baptiste Holcroft jb.holcr...@gmail.com:
 En prenant le problème à l'envers, la traduction de la page Map_Features est
 intéressante même si elle ne répond pas à la problématique :
 http://wiki.openstreetmap.org/wiki/FR:Map_Features#Commerce_.28shop.29

Ou ici:
http://wiki.openstreetmap.org/wiki/Shop

C'est le même template (utilisé pour la traduction de l'anglais) mais
rien n'enpêche d'ajouter un deuxième tableau avec des valeurs plus
spécifiques à un pays, comme rôtissierie en France.
Maintenant, il faut aussi faire attention, en particulier avcec ce
terme qui semble couvrir plusieurs types d'activités (rôtisseries qui
font plus dans le traiteur, ou la boucherie, ou la restauration, ou la
restauration rapide, avec ou sans roulettes)

 Je créerai bien une page sur ce modèle mais dans l'autre sens : nom -- tags
 adaptés.

Une page de ce genre existe déjà:
http://wiki.openstreetmap.org/wiki/FR:How_to_map_a

Pieren

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

Re: [OSM-talk-fr] Différence tag cycleway dans le wiki

2013-07-26 Thread Pieren

2013/7/24 Romain MEHUT romain.me...@gmail.com:
 Le 24 juillet 2013 13:00, JB jb...@mailoo.org a écrit :

 Fichus anglais qui roulent de l'autre coté de la route, je pense.

 Je ne pense pas, le wiki version anglaise est plus précis. Je me demande
 donc pourquoi la version française ne reprends pas ces mêmes valeurs?

Le cas de figure doit se présenter dans de nombreux pays et pas
seulement ceux qui roulent à gauche ;-) La version anglaise du wiki
évolue plus vite que sa traduction en français tout simplement parce
qu'il y a plus de contributeurs qui la lisent et l'améliorent.
Il faut juste trouver quelqu'un pour mettre à jour la version
française de temps à autre (en vérifiant que ce qui est proposé par la
version anglaise soit bien établie et pas juste du wiki fiddling
temporaire).

Pieren

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

Re: [OSM-talk-fr] Greffon Cadastre

2013-07-26 Thread Cavok

Oui l'erreur est déjà reportée.

Le 26 juillet 2013 08:44, Dominique Lavoille domijet...@yahoo.fr a écrit :


 Bonjour,
 Chez moi j'ai un bug avec JOSM et le greffon cadastre en utilisant la
 fenêtre d'outil d'aide pour ajouter des adresses.
 Quand j'utilise cette fenêtre pour ajouter des nœuds d'adresse à
 l'écran, si je veux rafraichir le cadastre (F10) et que j'appuie par
 mégarde (nul n'est parfait avec des gros doigts sur un petit clavier!)
 sur F11 (plein écran), alors la fenêtre d'aide d'adresse disparait de
 l'écran. En la rappelant, elle est alors vide. Pour la faire
 réapparaitre normalement, il faut sortir et relancer JOSM.
 Avez-vous constaté cela?.

 Merci d'avance
 Cordialement
 Dominique

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


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

Re: [OSM-talk-fr] Projet adresses

2013-07-26 Thread Pieren

2013/7/24 Tony Emery tony.em...@yahoo.fr:

 D'ailleurs, Pieren disait que les communes multi postales étaient rares,
 c'est vrai. Mais cela concerne essentiellement les grandes villes, donc
 celles pour lesquelles on a le plus de chance de vouloir faire un calcul
 d'itinéraire et donc qui engendrera plus d'erreurs...

Tout ce qui se dit pour le code postal est aussi valable pour la
ville, le département, la région, le pays, etc. c.a.d qu'il faut un
mécanisme capable de restituer un attribut défini par un polygone
englobant. Si on peut le faire pour le pays ou la région ou la
ville, on peut alors facilement l'étendre aux codes postaux.

 En France, il y a 36000 communes pour seulement 6300 code postaux. On voit
 bien que l'exception à la règle est plus fréquent que l'application de la
 règle (c'est comme pour l'orthographe en français)

L'exception, ce sont les grandes villes qui ont plusieurs codes
postaux. Avec celles-là, on ne peut effectivement pas réutiliser le
polygone des limites communales. Pour toutes les autres (en gros les
35900 restantes), la réutilisation est possible. Et c'est vrai qu'un
code postal sert fréquemment plusieurs communes. Mais rien n'empêche
de mettre plusieurs fois le même code postal sur plusieurs
multipolygones admin.

Pieren

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

Re: [OSM-talk-fr] Différence tag cycleway dans le wiki

J'ai un cas non prévu par le wiki...

voie cyclable + stationnement + chaussée (2 voies en double sens) +
stationnement + voie cyclable

J'ai des photos pour prouver que j'ai pas abusé sur le chouchen !

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

Re: [OSM-talk-fr] Le serveur osm7 ne répond plus...

2013-07-26 Thread Jocelyn Jaubert

On Fri, Jul 26, 2013 at 10:42:28AM +0200, Nicolas Moyroud wrote:
 ... et donc l'outil de saisie des numéros d'adresse non plus. C'est
 grave docteur ? :-)

Merci d'avoir prévenu.

J'ai contacté l'hébergeur, et osm7 (+ osm8) sont de nouveau accessibles.

-- 
Jocelyn

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

Re: [OSM-talk-fr] Le serveur osm7 ne répond plus...

2013-07-26 Thread Nicolas Moyroud


Merci pour la remise en route.

Nicolas

Le 26/07/2013 17:02, Jocelyn Jaubert a écrit :

Merci d'avoir prévenu.

J'ai contacté l'hébergeur, et osm7 (+ osm8) sont de nouveau accessibles.




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

Re: [OSM-talk-fr] Différence tag cycleway dans le wiki

2013-07-26 Thread Jean-Baptiste Holcroft

Pourquoi T1 ou S3 ne s'appliquent pas ?
--
Jean-Baptiste Holcroft


Le 26 juillet 2013 16:51, Christian Quest cqu...@openstreetmap.fr a écrit
:

 J'ai un cas non prévu par le wiki...

 voie cyclable + stationnement + chaussée (2 voies en double sens) +
 stationnement + voie cyclable

 J'ai des photos pour prouver que j'ai pas abusé sur le chouchen !

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

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

Re: [OSM-talk-fr] Différence tag cycleway dans le wiki

T1: pas bon, car il n'y a pas de séparation physique, mais bon, ça
pourrait aller...

S3: le voie cyclable n'est pas sur le trottoir mais sur la chaussée
entre le stationnement et la bordure de trottoir.

Voici une photo: http://www.flickr.com/photos/cq94/9372191550/



Le 26 juillet 2013 17:45, Jean-Baptiste Holcroft
jb.holcr...@gmail.com a écrit :
 Pourquoi T1 ou S3 ne s'appliquent pas ?
 --
 Jean-Baptiste Holcroft


 Le 26 juillet 2013 16:51, Christian Quest cqu...@openstreetmap.fr a écrit
 :

 J'ai un cas non prévu par le wiki...

 voie cyclable + stationnement + chaussée (2 voies en double sens) +
 stationnement + voie cyclable

 J'ai des photos pour prouver que j'ai pas abusé sur le chouchen !

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



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




-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

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

Re: [OSM-talk-fr] Différence tag cycleway dans le wiki

2013-07-26 Thread Jean-Baptiste Holcroft

C'est plus une interrogation qu'une affirmation, mais je pensais que la
notion de séparation physique était plus un concept que forcément une
bordure sur-élevée.
Citation : La séparation peut être limitée à une bordure surélevée
s'opposant aux franchissements volontaires, ou constitué par une surface
engazonnée, voire plantée d'arbustes [1]

Dans ce cas, j'aurais utilisé T1 dans sa version recommandée en 3 way avec
sur le way du mlieu un parking:lane pour indiquer ces notions de parking.

Par ailleurs, existe-t-il un rendu dédié aux voies accessibles aux vélos
permettant de voir clairement quand une piste cyclable est taguée à
contre-sens, sur le highway des véhicules, sur un way séparé ou cycle=yes ?
Dans tous les rendus que j'ai vu, la priorité est donnée aux highway
automobiles, ce qui oblige à aller voir les propriétés de chaque objet, ce
qui n'est pas pratique.

[1] http://www.securite-routiere.org/infrastructure/cyclables/cyclistes.htm
--
Jean-Baptiste Holcroft


Le 26 juillet 2013 18:07, Christian Quest cqu...@openstreetmap.fr a écrit
:

 T1: pas bon, car il n'y a pas de séparation physique, mais bon, ça
 pourrait aller...

 S3: le voie cyclable n'est pas sur le trottoir mais sur la chaussée
 entre le stationnement et la bordure de trottoir.

 Voici une photo: http://www.flickr.com/photos/cq94/9372191550/



 Le 26 juillet 2013 17:45, Jean-Baptiste Holcroft
 jb.holcr...@gmail.com a écrit :
  Pourquoi T1 ou S3 ne s'appliquent pas ?
  --
  Jean-Baptiste Holcroft
 
 
  Le 26 juillet 2013 16:51, Christian Quest cqu...@openstreetmap.fr a
 écrit
  :
 
  J'ai un cas non prévu par le wiki...
 
  voie cyclable + stationnement + chaussée (2 voies en double sens) +
  stationnement + voie cyclable
 
  J'ai des photos pour prouver que j'ai pas abusé sur le chouchen !
 
  ___
  Talk-fr mailing list
  Talk-fr@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-fr
 
 
 
  ___
  Talk-fr mailing list
  Talk-fr@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-fr
 



 --
 Christian Quest - OpenStreetMap France
 Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

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

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

Re: [OSM-talk-fr] Le rendu fr pret pour l'exportation

2013-07-26 Thread Philippe Verdy

Le 26 juillet 2013 09:10, Christian Quest cqu...@openstreetmap.fr a écrit
:

 Le 26 juillet 2013 07:54, Philippe Verdy verd...@wanadoo.fr a écrit :
  Une des remarques faites est que les cartes d'OSM France affichent
  préférablement le français (donc Londres et pas London).
 

 Le projet TileMill est disponible sur github, il suffit de repartir de
 là et de faire les adaptations locales.


Méfie-toi du terme il suffit affirmé trop vite ici.

Certes au plan logiciel on a ce qu'il faut mais le principal obstacle ce
n'est pas le logiciel mais le serveur pour sa disponibilité et la basnde
passante. Pour héberger un simple site statique tout le monde a accès à des
sites persos. mais pour un serveur de rendu c'est bien plus compliqué (et
plus cher car il faut un serveur dédié à ça, l'autre solution de
l'hébergement à domicile ne tenant pas la route pour servir à plus d'une
poignée de personnes).

Ta solution github ne concerne que la partie logicielle.

L'autre solution c'est l'hébergement mutualisé, mais pour un serveur de
rendu les solutions LAMP classiques ne peuvent pas prendre en charge les
outils demandés, ou alors il reste des services mutualisés comme uMap, masi
on n'a plus du tout le moindre contrôle de la solution technique (TileMill
sur github ne servira à rien du tout).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Le rendu fr pret pour l'exportation

L'avantage d'avoir tout le soft disponible sous licence libre c'est
qu'on peut si on a les compétence et l'infrastructure matérielle
adaptée monter ses propres service en indépendance et autonomie de
fonctionnement.

Bien sûr que le projet github ne suffit pas, mais au moins la partie
soft est disponible. Ensuite soit on se charge de dégoter la partie
hard, soit on se contente de ce que d'autres ont mis en place, sans
garantie de service, etc, etc.

Github permet au moins de multiplier le soft à l'infini, pour le hard
il faut encore attendre ;)


Le 26 juillet 2013 19:27, Philippe Verdy verd...@wanadoo.fr a écrit :
 Le 26 juillet 2013 09:10, Christian Quest cqu...@openstreetmap.fr a écrit
 :

 Le 26 juillet 2013 07:54, Philippe Verdy verd...@wanadoo.fr a écrit :
  Une des remarques faites est que les cartes d'OSM France affichent
  préférablement le français (donc Londres et pas London).
 

 Le projet TileMill est disponible sur github, il suffit de repartir de
 là et de faire les adaptations locales.


 Méfie-toi du terme il suffit affirmé trop vite ici.

 Certes au plan logiciel on a ce qu'il faut mais le principal obstacle ce
 n'est pas le logiciel mais le serveur pour sa disponibilité et la basnde
 passante. Pour héberger un simple site statique tout le monde a accès à des
 sites persos. mais pour un serveur de rendu c'est bien plus compliqué (et
 plus cher car il faut un serveur dédié à ça, l'autre solution de
 l'hébergement à domicile ne tenant pas la route pour servir à plus d'une
 poignée de personnes).

 Ta solution github ne concerne que la partie logicielle.

 L'autre solution c'est l'hébergement mutualisé, mais pour un serveur de
 rendu les solutions LAMP classiques ne peuvent pas prendre en charge les
 outils demandés, ou alors il reste des services mutualisés comme uMap, masi
 on n'a plus du tout le moindre contrôle de la solution technique (TileMill
 sur github ne servira à rien du tout).


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




-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

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

Re: [OSM-talk-fr] Différence tag cycleway dans le wiki

2013-07-26 Thread Tetsuo Shima

La zone de stationnement n'est elle pas en soit une séparation physique?

Le 26 juillet 2013 18:07, Christian Quest cqu...@openstreetmap.fr a écrit :
 T1: pas bon, car il n'y a pas de séparation physique, mais bon, ça
 pourrait aller...

 S3: le voie cyclable n'est pas sur le trottoir mais sur la chaussée
 entre le stationnement et la bordure de trottoir.

 Voici une photo: http://www.flickr.com/photos/cq94/9372191550/



 Le 26 juillet 2013 17:45, Jean-Baptiste Holcroft
 jb.holcr...@gmail.com a écrit :
 Pourquoi T1 ou S3 ne s'appliquent pas ?
 --
 Jean-Baptiste Holcroft


 Le 26 juillet 2013 16:51, Christian Quest cqu...@openstreetmap.fr a écrit
 :

 J'ai un cas non prévu par le wiki...

 voie cyclable + stationnement + chaussée (2 voies en double sens) +
 stationnement + voie cyclable

 J'ai des photos pour prouver que j'ai pas abusé sur le chouchen !

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



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




 --
 Christian Quest - OpenStreetMap France
 Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

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

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

Re: [Talk-us] JuicyTrails Map and App based on OSM data released

2013-07-26 Thread Mark Newnham

Just downloaded it onto a Samsung Galaxy 2. 
1. when the phone goes to sleep, as soon as it wakes up, the position of the 
map reverts back to the current position. If I'm using the phone to review 
where I'm going to walk before I get to the start point, this is really 
annoying. Suggest that:
a. This is the default behavior when the app is recording a trace.
b. Maybe it could be user definable when not recording?

2. No search by town name. If reviewing the map prior to walking,  I have to 
drag the map across a distance. On the phone, again, really annoying. In 
addition, at a zoom level high enough to make scrolling easier, the text of the 
town names is to small to read. I'm pretty sure at least one competitor product 
allows a settable minimum text size


 From: derrick nehrenberg derricknehrenb...@gmail.com
To: talk-us@openstreetmap.org 
Sent: Thursday, July 25, 2013 7:55 PM
Subject: [Talk-us] JuicyTrails Map and App based on OSM data released
 


Hi OSM folks,

I posted my GPS tracking and trail map app to the Google Play store today.  I 
am writing because I am interested in getting some early feedback from the OSM 
community, especially regarding feature requests or improvements to the map, 
website, and app. 

It would also be great to hear thoughts about how juicytrails can facilitate 
trail mapping.  

Here is the Google Play app store link 
https://play.google.com/store/apps/details?id=com.juicytrails.juicytrailsfreehl=en

If people like it, it would be nice to get some good reviews going...

The trail map features all kinds of dirt trails (hiking, horse, bicycle, 
motorcycle, ATV, and 4WD) as well as paved footways and cycleways, all based on 
OSM data. I started this project basically to fulfill my own trail navigation 
needs. I have done quite a bit of OSM trail mapping myself, but even I was 
shocked how many trails appeared when we turned the rendering lights on in the 
USA. Denver, Boston, and California have the most mapped trails. I have mapped 
quite a bit in Moab, Utah, Fruita, Durango, Crested Butte, and Salida Colorado.


Here is our burgeoning website and map.

http://juicytrails.com/

A central goal of this project is to turn hardcopy trail maps into trail 
dollars. We have actually already been doing this part of the project for a 
couple years. We are working with a growing list of trail associations to get 
their trails on OSM and juicytrails.com and then subsequently on hardcopy maps 
which we will sell directly to trail associations for a very, very small 
production fee of $.50 per map. The trail associations then sell directly to 
retailers for $1.50 each, and then the retailers sell for $2.99 each, clearing 
$1.00 minimum per map. The hardcopy maps have download codes used for 
installing offline versions of the maps into the Free Juicytrails App. These 
maps have been a minor hit, and have sold extremely well in some locations.

Thanks for reading. 

derrick nehrenberg 
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] access restriction, water only: How to tag?

2013-07-26 Thread Mark Newnham

True, but the thread has not identified that it is indeed on an island.

If it is boat-only for that reason, then of course.

If it is at a place where you could walk there legally, but that the conditions 
make it very dangerous to get there, then why not?



 From: Thomas Colson thomas_col...@nps.gov
To: talk-us@openstreetmap.org 
Sent: Friday, July 26, 2013 5:57 AM
Subject: Re: [Talk-us] access restriction, water only: How to tag?
 


Yes. If a campsite is on a lake shore, or an island, and the only way to get 
there is by boat, I don’t see how sac_scale depicts that information. 
 
From:Mark Newnham [mailto:m...@newnhams.com] 
Sent: Friday, July 26, 2013 7:46 AM
To: Open Street Map Talk-US
Subject: Re: [Talk-us] access restriction, water only: How to tag?
 
Is there something about sac_scale=* that doesn't work here?
 



From:Mike Thompson miketh...@gmail.com
To: Thomas Colson thomas_col...@nps.gov 
Cc: Open Street Map Talk-US talk-us@openstreetmap.org 
Sent: Thursday, July 25, 2013 9:25 PM
Subject: Re: [Talk-us] access restriction, water only: How to tag?
 
 By foot, impossible and serious  injury if attempted.   
What is the specific thing that makes it dangerous?  A cliff? swamp? dense 
undergrowth?  Perhaps a landuse tag or natural=cliff would be appropriate?

Agree with Richard that access= is about legal restrictions not about danger or 
practicality.  
 
Mike

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


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

Re: [Talk-us] access restriction, water only: How to tag?

Yes. If a campsite is on a lake shore, or an island, and the only way to
get there is by boat, I don’t see how sac_scale depicts that information
If the campsite is on an island, then I feel that no additional tagging is
necessary.

If it is on shore, and the land around it is too dangerous, that is where
you might use a tag for that *land* to indicate that.  I haven't seen
sac_scale used on an area, but it seems reasonable.  For example, if one
must climb down a steep cliff to get to the camp from land,
sac_scale=difficult_alpine_hiking.
 Again, we need to know more about the nature of the danger.
Mike
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] access restriction, water only: How to tag?

2013-07-26 Thread Martin Koppenhöfer



Am 26.07.2013 um 14:17 schrieb Mike Thompson miketh...@gmail.com:

 I haven't seen sac_scale used on an area, but it seems reasonable


-1, it is clearly thought and defined for (osm-)highways and not for an area. 
There are usually several possibilities where to cross an area, especially if 
you include difficult climbing, so I suggest to either not map any way from 
land to go there (and maybe put a note on the campsite for other mappers to 
indicate that it isn't simply not yet mapped), or if there is a climbing 
route(s) map these routes and add suitable tags to them.

Cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] access restriction, water only: How to tag?

2013-07-26 Thread Tod Fitch

While I can't point to an example, I believe I've seen some state park 
campsites that actually have a legal restriction against being accessed by 
land. It might be that the terrain is considered too dangerous (park does not 
want to assume liability for injuries), too ecologically sensitive or requires 
traversing private property. In those cases it does seem to me that 
access=water_only (or some equivalent) really does fit.

I haven't seen anything in this thread that indicates that this is the case in 
the original question but I don't see how one could rule out the use of an 
access tag altogether in all situations.

-Tod



On Jul 26, 2013, at 6:12 AM, Martin Koppenhöfer wrote:

 
 
 Am 26.07.2013 um 14:17 schrieb Mike Thompson miketh...@gmail.com:
 
 I haven't seen sac_scale used on an area, but it seems reasonable
 
 
 -1, it is clearly thought and defined for (osm-)highways and not for an area. 
 There are usually several possibilities where to cross an area, especially if 
 you include difficult climbing, so I suggest to either not map any way from 
 land to go there (and maybe put a note on the campsite for other mappers to 
 indicate that it isn't simply not yet mapped), or if there is a climbing 
 route(s) map these routes and add suitable tags to them.
 
 Cheers,
 Martin
 ___
 Talk-us mailing list
 Talk-us@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-us


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

Re: [Talk-us] JuicyTrails Map and App based on OSM data released

2013-07-26 Thread derrick nehrenberg

Clifford,

Thanks for your comments. In fact plugging in OSM .gpx trace sharing is the
next item on our To Do list. The app supports waypoint note taking which
would enable users to note trail names, surface, difficulty...After reading
your comment, I wonder if it possible to implement a little more
functionality like drop-down lists where users select surface, difficulty,
etc.)

Anyone know if this is possible? Any examples already out there.

thanks again,

derrick

On Thu, Jul 25, 2013 at 8:51 PM, Clifford Snow cliff...@snowandsnow.uswrote:


 On Thu, Jul 25, 2013 at 6:55 PM, derrick nehrenberg 
 derricknehrenb...@gmail.com wrote:

 I posted my GPS tracking and trail map app to the Google Play store
 today.  I am writing because I am interested in getting some early feedback
 from the OSM community, especially regarding feature requests or
 improvements to the map, website, and app.

 It would also be great to hear thoughts about how juicytrails can
 facilitate trail mapping.


 I would be interested in how you plan to contribute back to OSM. Can users
 enter OSM notes? Will gps tracks be uploaded to OSM?

 With other sites, users can upload information that they use to create
 trails. It would be nice if we had traces uploaded into OSM for tracing
 into trails along with information such as trail name, surface, etc.

 I'd certainly like to hear more.


 --
 Clifford

 OpenStreetMap: Maps with a human touch

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

Re: [Talk-us] JuicyTrails Map and App based on OSM data released

2013-07-26 Thread derrick nehrenberg

Mark,

Thanks for taking the time to check it out and share your thoughts.

It is possible to turn off Auto Centering by unselecting Center Map from
the menu options icon (usually found in the top right hand corner of the
screen).

Good call, on the City search feature. Adding it to our To Do list.

RE minimal text size feature, would you mind sharing the competitor name. I
would like to check that out.

Thanks,

derrick



On Fri, Jul 26, 2013 at 6:03 AM, Mark Newnham m...@newnhams.com wrote:

 Just downloaded it onto a Samsung Galaxy 2.
 1. when the phone goes to sleep, as soon as it wakes up, the position of
 the map reverts back to the current position. If I'm using the phone to
 review where I'm going to walk before I get to the start point, this is
 really annoying. Suggest that:
 a. This is the default behavior when the app is recording a trace.
 b. Maybe it could be user definable when not recording?

 2. No search by town name. If reviewing the map prior to walking,  I have
 to drag the map across a distance. On the phone, again, really annoying. In
 addition, at a zoom level high enough to make scrolling easier, the text of
 the town names is to small to read. I'm pretty sure at least one competitor
 product allows a settable minimum text size
   --
  *From:* derrick nehrenberg derricknehrenb...@gmail.com
 *To:* talk-us@openstreetmap.org
 *Sent:* Thursday, July 25, 2013 7:55 PM
 *Subject:* [Talk-us] JuicyTrails Map and App based on OSM data released

 Hi OSM folks,

 I posted my GPS tracking and trail map app to the Google Play store today.
  I am writing because I am interested in getting some early feedback from
 the OSM community, especially regarding feature requests or improvements to
 the map, website, and app.

 It would also be great to hear thoughts about how juicytrails can
 facilitate trail mapping.

 Here is the Google Play app store link

 https://play.google.com/store/apps/details?id=com.juicytrails.juicytrailsfreehl=en

 If people like it, it would be nice to get some good reviews going...

 The trail map features all kinds of dirt trails (hiking, horse, bicycle,
 motorcycle, ATV, and 4WD) as well as paved footways and cycleways, all
 based on OSM data. I started this project basically to fulfill my own trail
 navigation needs. I have done quite a bit of OSM trail mapping myself, but
 even I was shocked how many trails appeared when we turned the rendering
 lights on in the USA. Denver, Boston, and California have the most mapped
 trails. I have mapped quite a bit in Moab, Utah, Fruita, Durango, Crested
 Butte, and Salida Colorado.

 Here is our burgeoning website and map.

 http://juicytrails.com/

 A central goal of this project is to turn hardcopy trail maps into trail
 dollars. We have actually already been doing this part of the project for a
 couple years. We are working with a growing list of trail associations to
 get their trails on OSM and juicytrails.com and then subsequently on
 hardcopy maps which we will sell directly to trail associations for a very,
 very small production fee of $.50 per map. The trail associations then sell
 directly to retailers for $1.50 each, and then the retailers sell for $2.99
 each, clearing $1.00 minimum per map. The hardcopy maps have download codes
 used for installing offline versions of the maps into the Free Juicytrails
 App. These maps have been a minor hit, and have sold extremely well in some
 locations.

 Thanks for reading.

 derrick nehrenberg

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



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

Re: [Talk-us] JuicyTrails Map and App based on OSM data released

2013-07-26 Thread derrick nehrenberg

Hi Mike,

What you are seeing in the right pain are lists of .gpx files for rides
that have been uploaded for that area. If an area doesn't contain any
uploaded .gpx files then nothing appears in the right pane.

This is a work in progress, and has not yet been fully implemented. We are
in the process of incorporating user accounts that will enable anyone to
upload .gpx files of hikes, bicycle rides, motorcycle rides, etc. For now
we are the only ones who can upload this kind of content.

RE tagging trails...the .gpx files are totally separate from the map data.
For trails to appear, yes that OSM data has to be tagged with a minimum of
highway=path or highway=track to appear.

thanks,

derrick

On Thu, Jul 25, 2013 at 9:12 PM, Mike Thompson miketh...@gmail.com wrote:

 Derrick,

 I like the rendering style.  Really makes the trails stand out.

 Nice that your documentation encourages your users to contribute to OSM.

 I clicked on your link for your website.  Initially the map was centered
 over Salida, CO.  There was a nice list of trails on the right margin that
 one could click on, thus highlighting the trail on the map.  Once one pans
 away from Salida, this functionality seems not to be in place.  Am I doing
 something wrong?  Do the trails in my area have to be tagged in a special
 way to enable the full functionality of JuicyTrails?

 Mike




 On Thu, Jul 25, 2013 at 7:55 PM, derrick nehrenberg 
 derricknehrenb...@gmail.com wrote:

 Hi OSM folks,

 I posted my GPS tracking and trail map app to the Google Play store
 today.  I am writing because I am interested in getting some early feedback
 from the OSM community, especially regarding feature requests or
 improvements to the map, website, and app.

 It would also be great to hear thoughts about how juicytrails can
 facilitate trail mapping.

 Here is the Google Play app store link

 https://play.google.com/store/apps/details?id=com.juicytrails.juicytrailsfreehl=en

 If people like it, it would be nice to get some good reviews going...

 The trail map features all kinds of dirt trails (hiking, horse, bicycle,
 motorcycle, ATV, and 4WD) as well as paved footways and cycleways, all
 based on OSM data. I started this project basically to fulfill my own trail
 navigation needs. I have done quite a bit of OSM trail mapping myself, but
 even I was shocked how many trails appeared when we turned the rendering
 lights on in the USA. Denver, Boston, and California have the most mapped
 trails. I have mapped quite a bit in Moab, Utah, Fruita, Durango, Crested
 Butte, and Salida Colorado.

 Here is our burgeoning website and map.

 http://juicytrails.com/

 A central goal of this project is to turn hardcopy trail maps into trail
 dollars. We have actually already been doing this part of the project for a
 couple years. We are working with a growing list of trail associations to
 get their trails on OSM and juicytrails.com and then subsequently on
 hardcopy maps which we will sell directly to trail associations for a very,
 very small production fee of $.50 per map. The trail associations then sell
 directly to retailers for $1.50 each, and then the retailers sell for $2.99
 each, clearing $1.00 minimum per map. The hardcopy maps have download codes
 used for installing offline versions of the maps into the Free Juicytrails
 App. These maps have been a minor hit, and have sold extremely well in some
 locations.

 Thanks for reading.

 derrick nehrenberg

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



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

Re: [Talk-us] access restriction, water only: How to tag?

2013/7/26 Tod Fitch t...@fitchdesign.com

 While I can't point to an example, I believe I've seen some state park
 campsites that actually have a legal restriction against being accessed by
 land. It might be that the terrain is considered too dangerous (park does
 not want to assume liability for injuries), too ecologically sensitive or
 requires traversing private property. In those cases it does seem to me
 that access=water_only (or some equivalent) really does fit.



Also in these cases I won't tag it like this on the campsite.
access=water_only isn't really understandable: only water can access??
If there are restrictions on the areas in front of the campsite (or any
other feature), simply map those restrictions (boundary=protected_area,
etc., access=no, ...) to where they apply. IMHO it isn't an attribute of
the campsite but an attribute of the areas in front of it. If you want to
be explicit for visitors of the campsite (like a description in a leaflet
from the campsite probably would), add a free text like note (for other
mappers) or description (for data consumers) to the campsite with an
explanation.

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] JuicyTrails Map and App based on OSM data released

Derrick,

Thanks for the explanation.

The list of trails in the right pane is a very helpful feature. Consider
making it work solely off of OSM data.  It would provide a great way to
find a trail by its name, especially by someone who is new to the area or
who is a visitor.

Mike



On Fri, Jul 26, 2013 at 8:45 AM, derrick nehrenberg 
derricknehrenb...@gmail.com wrote:

 Hi Mike,

 What you are seeing in the right pain are lists of .gpx files for rides
 that have been uploaded for that area. If an area doesn't contain any
 uploaded .gpx files then nothing appears in the right pane.

 This is a work in progress, and has not yet been fully implemented. We are
 in the process of incorporating user accounts that will enable anyone to
 upload .gpx files of hikes, bicycle rides, motorcycle rides, etc. For now
 we are the only ones who can upload this kind of content.

 RE tagging trails...the .gpx files are totally separate from the map data.
 For trails to appear, yes that OSM data has to be tagged with a minimum of
 highway=path or highway=track to appear.

 thanks,

 derrick


 On Thu, Jul 25, 2013 at 9:12 PM, Mike Thompson miketh...@gmail.comwrote:

 Derrick,

 I like the rendering style.  Really makes the trails stand out.

 Nice that your documentation encourages your users to contribute to OSM.

 I clicked on your link for your website.  Initially the map was centered
 over Salida, CO.  There was a nice list of trails on the right margin that
 one could click on, thus highlighting the trail on the map.  Once one pans
 away from Salida, this functionality seems not to be in place.  Am I doing
 something wrong?  Do the trails in my area have to be tagged in a special
 way to enable the full functionality of JuicyTrails?

 Mike




 On Thu, Jul 25, 2013 at 7:55 PM, derrick nehrenberg 
 derricknehrenb...@gmail.com wrote:

 Hi OSM folks,

 I posted my GPS tracking and trail map app to the Google Play store
 today.  I am writing because I am interested in getting some early feedback
 from the OSM community, especially regarding feature requests or
 improvements to the map, website, and app.

 It would also be great to hear thoughts about how juicytrails can
 facilitate trail mapping.

 Here is the Google Play app store link

 https://play.google.com/store/apps/details?id=com.juicytrails.juicytrailsfreehl=en

 If people like it, it would be nice to get some good reviews going...

 The trail map features all kinds of dirt trails (hiking, horse, bicycle,
 motorcycle, ATV, and 4WD) as well as paved footways and cycleways, all
 based on OSM data. I started this project basically to fulfill my own trail
 navigation needs. I have done quite a bit of OSM trail mapping myself, but
 even I was shocked how many trails appeared when we turned the rendering
 lights on in the USA. Denver, Boston, and California have the most mapped
 trails. I have mapped quite a bit in Moab, Utah, Fruita, Durango, Crested
 Butte, and Salida Colorado.

 Here is our burgeoning website and map.

 http://juicytrails.com/

 A central goal of this project is to turn hardcopy trail maps into trail
 dollars. We have actually already been doing this part of the project for a
 couple years. We are working with a growing list of trail associations to
 get their trails on OSM and juicytrails.com and then subsequently on
 hardcopy maps which we will sell directly to trail associations for a very,
 very small production fee of $.50 per map. The trail associations then sell
 directly to retailers for $1.50 each, and then the retailers sell for $2.99
 each, clearing $1.00 minimum per map. The hardcopy maps have download codes
 used for installing offline versions of the maps into the Free Juicytrails
 App. These maps have been a minor hit, and have sold extremely well in some
 locations.

 Thanks for reading.

 derrick nehrenberg

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




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

Re: [Talk-us] access restriction, water only: How to tag?

  IMHO it isn't an attribute of the campsite but an attribute of the areas
in front of it.
agree (if by areas in front you mean the non water areas)

 On Fri, Jul 26, 2013 at 9:31 AM, Martin Koppenhoefer 
dieterdre...@gmail.com wrote:
 I haven't seen sac_scale used on an area, but it seems reasonable
 -1, it is clearly thought and defined for (osm-)highways and not for an
area. There are usually several possibilities where to cross an area,
especially if you include difficult climbing, so I suggest to either not
map any way from land to go there (and maybe put a note on the campsite for
other mappers to indicate that it isn't simply not yet mapped), or if there
is a climbing route(s) map these routes and add suitable tags to them

Fair enough.  However, as a map user, my assumption would be that an open
space on the map in a National Park, without any highway=* ways, and
without any land cover type tags (or natural=cliff, barrier=*, etc) would
be that I *might* be able to traverse that area on foot with only moderate
difficulty and little danger.  If we want to make the map explicit as to
the difficulty of foot travel, then we should have a tag that can be
applied to an area indicating this.  Perhaps it isn't sac_scale, but we
should have something.

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

Re: [Talk-us] access restriction, water only: How to tag?

2013/7/26 Mike Thompson miketh...@gmail.com

 If we want to make the map explicit as to the difficulty of foot travel,
 then we should have a tag that can be applied to an area indicating this.
 Perhaps it isn't sac_scale, but we should have something.



the only established tags for areas I am aware of are natural=scrub and
natural=wetland with sub tags (swamp, etc.), maybe this can be further
refined if required (density), or we can come up with new tags for stuff
like quicksand. Suitable keys might be natural (for geographic features),
landcover, landuse and maybe more. First of all you should tell us what it
is that makes the area difficult for foot travel. ;-)

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] access restriction, water only: How to tag?