date:20130725

Pessoal,

O Paulo Carvalho tem desenvolvido um conversor TrackSource  OSM e eu
estou prestes a importar a numeração das casas em Porto Alegre via
script. Eu queria opiniões sobre um detalhe de como fazer isso para
produzir um resultado com mais qualidade.

Já encontrei interpoladores no Rio e em Buenos Aires (mas não em
outras grandes cidades de outros países, onde quase tudo está mapeado
edifício por edifício). Em ambos, sempre há 1 linha para cada quadra,
com um número associado ao nó inicial e outro ao final. No Rio, o
número usado foi exatamente o da última casa naquela quadra, logo
antes do cruzamento. Isso deixa alguns números faltando na sequência;
se alguém pesquisar por um desses números, o sistema não retorna
absolutamente nada. Em Buenos Aires, parece que eles escolheram
números de uma forma tal que não fiquem buracos na numeração: se de
um lado o último número é o 20 (numeração par), do outro o primeiro
número é o 22 ou o 18, mas não se pula para o 24 ou para o 16 (ou
qualquer número mais distante), o que deixaria o número 22 ou o 18 de
fora dos resultados da busca.

Exemplo em Buenos Aires:
http://openstreetmap.org/?lat=-34.60868lon=-58.37489zoom=17layers=M

Então, a questão: optamos pela exatidão absoluta e deixamos que o
usuário do mapa fique confuso de vez em quando (especialmente no caso
de novos endereços que ainda não foram mapeados), ou fazemos as
conversões fechando esses buracos? Por exemplo, se de um lado o número
é 20 e do outro é 40, aproximaríamos isso atribuindo um lado ao número
30 e o outro lado ao 32.

O fechamento seria feito somente quando a numeração dos dois lados é
próxima: se houver um salto muito grande, digamos, de mais de 100
(ex.: um lado é 80 e o outro é 190), os números originais seriam
usados.

A minha opinião é de que o fechamento seria interessante porque os
interpoladores são invariavelmente uma mera aproximação. Acho que a
exatidão absoluta faria mais sentido se todos os edifícios estivessem
mapeados individualmente, como é o caso de Berlim, Paris, Londres,
etc. Mas não sei se a minha opinião está de acordo com a opinião
geral, pesquisando não achei absolutamente nenhuma recomendação da
comunidade internacional para o uso dos interpoladores.

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

2013-07-25 Thread Gerald Weber

Oi Fernando

Lembre-se que no Brasil se adota um sistema métrico onde a numeração da
casa é sua distância aproximada do início da rua. Por exemplo o número 350
fica 350 metros do início da rua. Usualmente o início da rua é aquele que
fica mais próximo ao centro da cidade. Enfim, se você souber onde fica o
início da rua você consegue saber com boa aproximação onde fica o número
que procura.

Assim, se você está no número 200 e procura o 400 você sabe que ainda tem
de andar mais 200 metros.

Talvez isto seja útil para incorporar no interpolador que você quer fazer.

Abraço

Gerald
On Jul 25, 2013 9:59 AM, Fernando Trebien fernando.treb...@gmail.com
wrote:

 Pessoal,

 O Paulo Carvalho tem desenvolvido um conversor TrackSource  OSM e eu
 estou prestes a importar a numeração das casas em Porto Alegre via
 script. Eu queria opiniões sobre um detalhe de como fazer isso para
 produzir um resultado com mais qualidade.

 Já encontrei interpoladores no Rio e em Buenos Aires (mas não em
 outras grandes cidades de outros países, onde quase tudo está mapeado
 edifício por edifício). Em ambos, sempre há 1 linha para cada quadra,
 com um número associado ao nó inicial e outro ao final. No Rio, o
 número usado foi exatamente o da última casa naquela quadra, logo
 antes do cruzamento. Isso deixa alguns números faltando na sequência;
 se alguém pesquisar por um desses números, o sistema não retorna
 absolutamente nada. Em Buenos Aires, parece que eles escolheram
 números de uma forma tal que não fiquem buracos na numeração: se de
 um lado o último número é o 20 (numeração par), do outro o primeiro
 número é o 22 ou o 18, mas não se pula para o 24 ou para o 16 (ou
 qualquer número mais distante), o que deixaria o número 22 ou o 18 de
 fora dos resultados da busca.

 Exemplo em Buenos Aires:
 http://openstreetmap.org/?lat=-34.60868lon=-58.37489zoom=17layers=M

 Então, a questão: optamos pela exatidão absoluta e deixamos que o
 usuário do mapa fique confuso de vez em quando (especialmente no caso
 de novos endereços que ainda não foram mapeados), ou fazemos as
 conversões fechando esses buracos? Por exemplo, se de um lado o número
 é 20 e do outro é 40, aproximaríamos isso atribuindo um lado ao número
 30 e o outro lado ao 32.

 O fechamento seria feito somente quando a numeração dos dois lados é
 próxima: se houver um salto muito grande, digamos, de mais de 100
 (ex.: um lado é 80 e o outro é 190), os números originais seriam
 usados.

 A minha opinião é de que o fechamento seria interessante porque os
 interpoladores são invariavelmente uma mera aproximação. Acho que a
 exatidão absoluta faria mais sentido se todos os edifícios estivessem
 mapeados individualmente, como é o caso de Berlim, Paris, Londres,
 etc. Mas não sei se a minha opinião está de acordo com a opinião
 geral, pesquisando não achei absolutamente nenhuma recomendação da
 comunidade internacional para o uso dos interpoladores.

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

2013-07-25 Thread Aun Yngve Johnsen

Gerald, Pessoal

Tem um pouco duvida soubre estes metricos, bem meu casa e numero 97, e meu 
vinizio e 101, e pode ser uns 4 metros entre os portas, mas no outro lado, meu 
casa nao sao 97 metros dentro rua, e a casa no outro lado da rua nao sao entre 
97 e 101 que seria natural com seu argumento. Talvez voce pode dizer que 
numeros entre 1 e 100 geralmente e nos primeiros 100 metros da rua, 101 a 200 
os proximos 100 metros

Tambem no meu rua tem casas com numeros pulando, por exemplo um distanca em 
baixo meu casa tem numero 117, nao sei se a casa pertence outro rua, mas a 
entrada e no meu rua. Admito que sao curioso mas ainda nao perguntei p saber 
porque este pulo de numeracao

Aun Johnsen

On 25. juli 2013, at 10:13, Gerald Weber gwebe...@gmail.com wrote:

 Oi Fernando
 
 Lembre-se que no Brasil se adota um sistema métrico onde a numeração da 
 casa é sua distância aproximada do início da rua. Por exemplo o número 350 
 fica 350 metros do início da rua. Usualmente o início da rua é aquele que 
 fica mais próximo ao centro da cidade. Enfim, se você souber onde fica o 
 início da rua você consegue saber com boa aproximação onde fica o número que 
 procura.
 
 Assim, se você está no número 200 e procura o 400 você sabe que ainda tem de 
 andar mais 200 metros.
 
 Talvez isto seja útil para incorporar no interpolador que você quer fazer.
 
 Abraço
 
 Gerald
 
 On Jul 25, 2013 9:59 AM, Fernando Trebien fernando.treb...@gmail.com 
 wrote:
 Pessoal,
 
 O Paulo Carvalho tem desenvolvido um conversor TrackSource  OSM e eu
 estou prestes a importar a numeração das casas em Porto Alegre via
 script. Eu queria opiniões sobre um detalhe de como fazer isso para
 produzir um resultado com mais qualidade.
 
 Já encontrei interpoladores no Rio e em Buenos Aires (mas não em
 outras grandes cidades de outros países, onde quase tudo está mapeado
 edifício por edifício). Em ambos, sempre há 1 linha para cada quadra,
 com um número associado ao nó inicial e outro ao final. No Rio, o
 número usado foi exatamente o da última casa naquela quadra, logo
 antes do cruzamento. Isso deixa alguns números faltando na sequência;
 se alguém pesquisar por um desses números, o sistema não retorna
 absolutamente nada. Em Buenos Aires, parece que eles escolheram
 números de uma forma tal que não fiquem buracos na numeração: se de
 um lado o último número é o 20 (numeração par), do outro o primeiro
 número é o 22 ou o 18, mas não se pula para o 24 ou para o 16 (ou
 qualquer número mais distante), o que deixaria o número 22 ou o 18 de
 fora dos resultados da busca.
 
 Exemplo em Buenos Aires:
 http://openstreetmap.org/?lat=-34.60868lon=-58.37489zoom=17layers=M
 
 Então, a questão: optamos pela exatidão absoluta e deixamos que o
 usuário do mapa fique confuso de vez em quando (especialmente no caso
 de novos endereços que ainda não foram mapeados), ou fazemos as
 conversões fechando esses buracos? Por exemplo, se de um lado o número
 é 20 e do outro é 40, aproximaríamos isso atribuindo um lado ao número
 30 e o outro lado ao 32.
 
 O fechamento seria feito somente quando a numeração dos dois lados é
 próxima: se houver um salto muito grande, digamos, de mais de 100
 (ex.: um lado é 80 e o outro é 190), os números originais seriam
 usados.
 
 A minha opinião é de que o fechamento seria interessante porque os
 interpoladores são invariavelmente uma mera aproximação. Acho que a
 exatidão absoluta faria mais sentido se todos os edifícios estivessem
 mapeados individualmente, como é o caso de Berlim, Paris, Londres,
 etc. Mas não sei se a minha opinião está de acordo com a opinião
 geral, pesquisando não achei absolutamente nenhuma recomendação da
 comunidade internacional para o uso dos interpoladores.
 
 --
 Fernando Trebien
 +55 (51) 9962-5409
 
 The speed of computer chips doubles every 18 months. (Moore's law)
 The speed of software halves every 18 months. (Gates' law)
 
 ___
 Talk-br mailing list
 Talk-br@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-br
 ___
 Talk-br mailing list
 Talk-br@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-br
___
Talk-br mailing list
Talk-br@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-br

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

A forma mais simples é criar apenas um caminho, do começo da rua até o
fim, com addr:interpolation=all (a interpolação vai servir para os
lados par e ímpar) e addr:inclusion=estimate (para dizer que existirá
números na interpolação que não existem de fato na realidade).

Coloca no nó inicial o menor número que existe na rua e o nó final o
último número que existe na mesma.

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

[Talk-br] HOT Tasking Manager: interessaria a communidade brasileira ?/would interest the Brazilian community?

2013-07-25 Thread Severin MENARD

(version in English below)

Ola Fernando, je vais bien, et souhaite qu'il en est de même pour vous.

Desculpe para responder com atraso à suas perguntas.
Eu não sou especialista no assunto da hospedagem do Tasking Manager, por
isso eu acrescentei na resposta :
- Pierre Giraud, que desenvolveu a ferramenta on
GitHubhttps://github.com/hotosm/osm-tasking-manager
- Fernando Cypher Sanz, que (eu acho foi ele) criou a versão
argentinahttp://tareas.openstreetmap.org.ar/ do
Tasking Manager

Eles vão poder responder às suas perguntas técnicas para hospedar o
serviço. No que tange à regras administrativas, eu posso dar uma parte da
resposata: até hoje, cada contribuidor é registrado numa lista de usuários.
Por cada um, tem um quadrículo para tornar o usuário como administrador.
Somente um administrador pode fazer isso. Quer dizer desde que um usuário
se torna administrador, ela ou ela pode tornar outras pessoas como
administradores também. Ser administrador, na verdade, permite sobretudo de
criar novas tarefas. Mas tem o(s) super-administrador(es) que controle(m) a
plataforma técnica e os dados (sobre as tarefas, não os dados geográficos
evidentemente) que ela contem. Para HOT é o Pierre, não sei para a
comunidade argentina.

Cordialmente,

Severin

--
English starts here (not a translation as I need to explain the context of
the Brazilian thread)

Hi all,

I do not know if the HOT community knows, but there is at least one
nationwide community that has adopted the Tasking Manager for its own
projects, in Argentina. Here is the link:
http://tareas.openstreetmap.org.ar/. Would be interesting to know if there
are other examples elsewhere.
It is also interesting regarding the translation that has been made,
considering this is something we definitely want to add into the Tasking
Manager. I do not know if this code can be easily added to a future
multilingual capacity. Anyway.

I met the Argentinian OSM Community in April during the
FOSS4G+Sotmhttp://www.foss4g.org.ar/they organized in the National
Geographic Institute in Buenos Aires. I
wanted to make a blogpost in various languages but unfortunately did not
find the time to do it (you can see my presentation
herehttp://www.slideshare.net/Sev_hotosm/humanitarian-openstreetmap-team-respuesta-masiva-y-organizada-ante-y-post-crisisin
terrible Spanish). OSM Argentina is part of the Spanish-speaking
Geoinquietos
http://geoinquietos.drupalgardens.com/network, is quite active regarding
disaster response, as it can be seen through the topics of the jobs in
their Tasking Manager. I understand the need of a local response, but
please do not hesitate to tell the HOT community if you need quick help to
achieve an urgent job.

This email is also about the Brazilian OSM community to which I presented
the tool, and that would be interested to also install a local Tasking
Manager. Fernando Trebien would like to have some tips about the best
hosting services for the Tasking Manager, as he does not know the ones
listed in http://wiki.python.org/moin/PythonHosting
He also would like to know how the Tasking Manager is administrated to
create the tasks and guess a Brazilian team would be needed. I answered
regarding the basic administrator level (users able to create tasks and
make others uses admins as well) but I do not know about the super-admin
running the service itself
This is why I put both Pierre Giraud and Fernando Sanz in the loop, so that
they can provide their technical advice.

Yes someone could tell: OK why not having made an email with only the most
interested people? Actually I think this kind of crossovers are interesting
to know and can be the starting point of interactions between communities.

Sincerely,

Severin

Message: 3
Date: Sat, 13 Jul 2013 22:26:44 -0300
From: Fernando Trebien fernando.treb...@gmail.com
To: OSM talk-br talk-br@openstreetmap.org
Subject: Re: [Talk-br] Tasking Manager: interessaria a communidade
brasileira para mapear o Brasil ?
Message-ID:
CABcWbR746X-X5aFW7J=
dkmmy1wuymtqdfmd8+24_xv8ygq0...@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1

Bonjour Severin, vous allez bien? :D

Eu estaria disposto a ajudar com a instalação e os custos de
manutenção desse serviço no Brasil. Não tenho muita experiência com
hosting de aplicações feitas em Python, você (ou algum conhecido)
teria sugestões de serviços de hosting e/ou um tutorial para instalar
a aplicação no servidor? (O tutorial pra mim poderia ser em qualquer
uma dessas línguas: português, inglês, francês, espanhol, alemão.)
Fazer hosting em casa sai caro no Brasil e tem outros inconvenientes,
então provavelmente vale mais à pena pagar por um serviço remoto no
exterior.

Encontrei uma lista com sugestões de hostings mas não conheço nenhum
dos serviços indicados: http://wiki.python.org/moin/PythonHosting

Eu também queria saber mais sobre o projeto, por exemplo, quem é
responsável

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

Pessoal, acho que gerei um monte de dúvidas.

Certamente a idéia de poder deduzir a numeração a partir da
distância é tentadora (embora fazer isso só olhando para a métrica do
JOSM tenha uma tendência a introduzir erros de aproximação nas vias
mais longas). Mas no caso do conversor do Paulo e do meu script, esses
números podem ser gerados automaticamente a partir de bases confiáveis
(no caso dele os mapas já produzidos por DMs e DEs para o TrackSource,
no meu caso a base do Instituto de Geologia da UFRGS). Essas fontes de
dados já tem a numeração inicial de cada rua (e também as
intermediárias, por cruzamento). Creio que em muitos casos essa
numeração foi inspecionada e não medida ou deduzida, portanto, é mais
próxima da numeração oficial, incluindo os casos em que a regra da
distância não foi seguida à risca.

A minha questão é: o usuário busca por Rua A, 500 e esse valor cai
perto do meio do cruzamento. Os números mais próximos nos
interpoladores existentes são 496 e 512. É
aceitável/importante/útil/desejável/indesejável mudar os
interpoladores ligeiramente para que a busca do usuário retorne algum
resultado razoável? Se ajustarmos de 496 para 504 e de 512 para 506,
isso não faz quase nenhuma diferença no meio da quadra, mas a busca
passa a retornar resultados para os números intermediários (inclusive
o solicitado pelo usuário). Alguém que estiver procurando um endereço
com um GPS (e não olhando para o mapa) encontraria esse resultado
assim. Sem o ajuste, o resultado seria nada encontrado e o usuário
ficaria se perguntando se passaram o endereço errado pra ele, se ele
digitou errado, se o mapa é que é ruim, se o GPS é que não funciona,
etc.

Só lembrando: não é necessário mudar todos os interpoladores que já
foram mapeados, essa questão é mais para esses processos de conversão
automática. Se for desejável, uma boa hora pra implementar esse
recurso no conversor do Paulo (e no meu script de importação) é agora,
do contrário se um dia decidirmos que isso é bom vamos ter que ajustar
tudo à mão. Se for indesejável, me avisem. :D

2013/7/25 Nelson A. de Oliveira nao...@gmail.com:
 A forma mais simples é criar apenas um caminho, do começo da rua até o
 fim, com addr:interpolation=all (a interpolação vai servir para os
 lados par e ímpar) e addr:inclusion=estimate (para dizer que existirá
 números na interpolação que não existem de fato na realidade).

 Coloca no nó inicial o menor número que existe na rua e o nó final o
 último número que existe na mesma.

 ___
 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

2013/7/25 Fernando Trebien fernando.treb...@gmail.com:
 A minha questão é: o usuário busca por Rua A, 500 e esse valor cai
 perto do meio do cruzamento. Os números mais próximos nos
 interpoladores existentes são 496 e 512.

496 e 512 seriam os números de casa que existem na realidade ou são
valores aproximados?

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

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

A idéia seria continuar mapeando as construções e colocando o número 
exato nelas? Se a numeração for duplicada não vejo problema em 
considerar a interpolação como uma aproximação, inclusive seria até 
interessante que os nros na interpolação não batessem com o nro da 
construção para a busca não retornar 2 endereços repetidos. Tem a tag 
addr:inclusion pra dizer que o nro é aproximado e não o real.


Eu tenho feito inspeções, e eu pego alguns números, na maioria eu tento 
pegar as pontas dos quarteirões. Mas nem sempre, então eu escolhi o modo 
mais fácil pra mim, eu ignoro os quarteirões, sendo o mais simples 
conectar as pontas das ruas, e alguns números no meio caso a rua faça 
alguma curva só para ficar mais bonito na renderização. E sempre coloco 
o nro exato. Se tem um POI mapeado com o mesmo nro eu adiciono no POI tb.


Inclusive, eu acabei achando interessante conectar a rua inteira, tem 
algumas que são quebradas em alguma parte e continuam depois, a linha da 
interpolação me dá uma noção legal de continuidade do que deveria ser a 
rua, por exemplo:

http://www.openstreetmap.org/?lat=-21.193062lon=-47.801154zoom=18layers=M

O primeiro nro do quarteirão é 2210, mas se eu fosse guardar esse nro de 
cabeça eu iria buscar por 2200 ou 2000 (eu faço muito isso), e se a 
interpolação não estivesse conectada ela não retornaria nada. Com a 
interpolação contínua uma localização aproximada de onde eu quero ir 
deveria aparecer, mas pela minha experiência, nem sempre as 
interpolações funcionam no site do openstreetmap, já aconteceu dele 
ignorar o nro ou retornar em outra rua, e não entendi o pq na época...


Eu li em algum lugar que a interpolação é uma forma rápida para mapear 
os nros, mas que a intenção ainda era colocar os nros exatos de cada 
construção, então eu comecei a considerar as interpolações como algo 
auxiliar/temporário. Mas como eu busco um tanto por nros redondos, não 
gostaria de perder as aproximações...


Uma coisa que eu achei interessante em Porto Alegre, mas que não usei 
ainda foi:

http://www.openstreetmap.org/?lat=-21.193062lon=-47.801154zoom=18layers=M

A interpolação na rua General Câmara, entre a rua dos Andradas e Andrade 
Neves, ela tem o nro exato mas termina conectada com a rua. Talvez o nó 
da esquina poderia ter o nro intermediário...


Atenciosamente,
Roger.

--
Fernando Trebien escreveu:

Pessoal,

O Paulo Carvalho tem desenvolvido um conversor TrackSource  OSM e eu
estou prestes a importar a numeração das casas em Porto Alegre via
script. Eu queria opiniões sobre um detalhe de como fazer isso para
produzir um resultado com mais qualidade.

Já encontrei interpoladores no Rio e em Buenos Aires (mas não em
outras grandes cidades de outros países, onde quase tudo está mapeado
edifício por edifício). Em ambos, sempre há 1 linha para cada quadra,
com um número associado ao nó inicial e outro ao final. No Rio, o
número usado foi exatamente o da última casa naquela quadra, logo
antes do cruzamento. Isso deixa alguns números faltando na sequência;
se alguém pesquisar por um desses números, o sistema não retorna
absolutamente nada. Em Buenos Aires, parece que eles escolheram
números de uma forma tal que não fiquem buracos na numeração: se de
um lado o último número é o 20 (numeração par), do outro o primeiro
número é o 22 ou o 18, mas não se pula para o 24 ou para o 16 (ou
qualquer número mais distante), o que deixaria o número 22 ou o 18 de
fora dos resultados da busca.

Exemplo em Buenos Aires:
http://openstreetmap.org/?lat=-34.60868lon=-58.37489zoom=17layers=M

Então, a questão: optamos pela exatidão absoluta e deixamos que o
usuário do mapa fique confuso de vez em quando (especialmente no caso
de novos endereços que ainda não foram mapeados), ou fazemos as
conversões fechando esses buracos? Por exemplo, se de um lado o número
é 20 e do outro é 40, aproximaríamos isso atribuindo um lado ao número
30 e o outro lado ao 32.

O fechamento seria feito somente quando a numeração dos dois lados é
próxima: se houver um salto muito grande, digamos, de mais de 100
(ex.: um lado é 80 e o outro é 190), os números originais seriam
usados.

A minha opinião é de que o fechamento seria interessante porque os
interpoladores são invariavelmente uma mera aproximação. Acho que a
exatidão absoluta faria mais sentido se todos os edifícios estivessem
mapeados individualmente, como é o caso de Berlim, Paris, Londres,
etc. Mas não sei se a minha opinião está de acordo com a opinião
geral, pesquisando não achei absolutamente nenhuma recomendação da
comunidade internacional para o uso dos interpoladores.

  



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

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

Nesse exemplo, era pra ser o número exato das casas na esquina,
obtidos (supostamente) por inspeção.

No caso do conversor e da minha importação, esse número também poderia
ser algo proveniente de um registro legal ou oficial (possivelmente um
pouco desatualizado).

2013/7/25 Nelson A. de Oliveira nao...@gmail.com:
 2013/7/25 Fernando Trebien fernando.treb...@gmail.com:
 A minha questão é: o usuário busca por Rua A, 500 e esse valor cai
 perto do meio do cruzamento. Os números mais próximos nos
 interpoladores existentes são 496 e 512.

 496 e 512 seriam os números de casa que existem na realidade ou são
 valores aproximados?

 ___
 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

2013/7/25 Fernando Trebien fernando.treb...@gmail.com:
 Nesse exemplo, era pra ser o número exato das casas na esquina,
 obtidos (supostamente) por inspeção.

 No caso do conversor e da minha importação, esse número também poderia
 ser algo proveniente de um registro legal ou oficial (possivelmente um
 pouco desatualizado).

Se for exato eu não vejo necessidade de criar na interpolação números
que não existem (se não existe número 500 então também não deve
existir na interpolação).
Mas se há um mínimo de dúvida sobre a exatidão dos dados, também não
vejo mal em aumentar um pouco os valores para que não exista buracos
(o que praticamente cairia no mesmo caso de ter um único caminho para
a rua inteira com números interpolados).

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

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

Você poderia colocar um número de casa no nó central do cruzamento,
mas haveria um conflito se você tivesse que fazer isso para dois
interpoladores (um para cada rua do cruzamento).

Eu vinha mapeando passando pelo nó central mas colocando os números
pouco antes e pouco depois do cruzamento, assim:
http://www.openstreetmap.org/?lat=-30.050852lon=-51.224171zoom=18layers=M

Como fiz isso muito pouco (mais com o objetivo de testar o sistema
mesmo), não me importo de consertar. Desse jeito há 2 vantagens:
- a numeração é contínua (não há números faltando nos cruzamentos,
sempre se consegue uma posição aproximada)
- o roteamento é correto (mesmo os números no interior do cruzamento
são projetados na rua certa, já que o interpolador é mais próximo da
sua rua do que da outra que chega no cruzamento)

Se o interpolador passasse por cima da rua transversal, os números
próximos do cruzamento seriam projetados na rua errada. Se nesse local
as ruas fossem todas de sentido único (como costuma ser nas regiões
mais densas das cidades), isso poderia mudar drásticamente o
roteamento (no restante não mudaria muito).

Além do aspecto engraçado (repetindo esse padrão visual em X em cada
cruzamento :P), tem uma desvantagem em fazer do jeito que eu fiz (e
pode ter sido essa a razão para não ter funcionado pra você algumas
vezes). O Nominatim faz uma verificação de sanidade nos
interpoladores: se numa distância curta a diferença de numeração for
muito grande, ele descarta o interpolador. Então, se o interpolador
for feito em pedaços (como em Buenos Aires), a chance de algo ser
descartado é muito menor. Descobri isso (e inclusive abri um ticket no
TRAC do Nominatim pensando que era um erro) quando fui mapear a
Avenida Guaíba aqui em Porto Alegre: em um trecho de uma quadra, a
numeração saltava de 990 para 1300 entre os extremos. O Nominatim acha
improvável haver 400 casas nesse espaço curto, pensa que é um erro e
acaba não indexando essas casas. (Pelo que entendi o Nominatim não é
muito esperto, cada valor interpolado gera uma entrada no índice.
Softwares de GPS simplesmente calculam a posição interpolada ao invés
de armazenar a posição de cada número separadamente.)

Em lugares em que há tanto um interpolador quanto uma casa mapeada
separadamente com o seu próprio número, o Nominatim retorna as 2
posições, mas a que vem do interpolador sempre aparece como segundo
resultado, o primeiro é a própria casa.

2013/7/25 Roger C. Soares rogersoa...@gmail.com:
 A idéia seria continuar mapeando as construções e colocando o número exato
 nelas? Se a numeração for duplicada não vejo problema em considerar a
 interpolação como uma aproximação, inclusive seria até interessante que os
 nros na interpolação não batessem com o nro da construção para a busca não
 retornar 2 endereços repetidos. Tem a tag addr:inclusion pra dizer que o nro
 é aproximado e não o real.

 Eu tenho feito inspeções, e eu pego alguns números, na maioria eu tento
 pegar as pontas dos quarteirões. Mas nem sempre, então eu escolhi o modo
 mais fácil pra mim, eu ignoro os quarteirões, sendo o mais simples conectar
 as pontas das ruas, e alguns números no meio caso a rua faça alguma curva só
 para ficar mais bonito na renderização. E sempre coloco o nro exato. Se tem
 um POI mapeado com o mesmo nro eu adiciono no POI tb.

 Inclusive, eu acabei achando interessante conectar a rua inteira, tem
 algumas que são quebradas em alguma parte e continuam depois, a linha da
 interpolação me dá uma noção legal de continuidade do que deveria ser a rua,
 por exemplo:
 http://www.openstreetmap.org/?lat=-21.193062lon=-47.801154zoom=18layers=M

 O primeiro nro do quarteirão é 2210, mas se eu fosse guardar esse nro de
 cabeça eu iria buscar por 2200 ou 2000 (eu faço muito isso), e se a
 interpolação não estivesse conectada ela não retornaria nada. Com a
 interpolação contínua uma localização aproximada de onde eu quero ir deveria
 aparecer, mas pela minha experiência, nem sempre as interpolações funcionam
 no site do openstreetmap, já aconteceu dele ignorar o nro ou retornar em
 outra rua, e não entendi o pq na época...

 Eu li em algum lugar que a interpolação é uma forma rápida para mapear os
 nros, mas que a intenção ainda era colocar os nros exatos de cada
 construção, então eu comecei a considerar as interpolações como algo
 auxiliar/temporário. Mas como eu busco um tanto por nros redondos, não
 gostaria de perder as aproximações...

 Uma coisa que eu achei interessante em Porto Alegre, mas que não usei ainda
 foi:
 http://www.openstreetmap.org/?lat=-21.193062lon=-47.801154zoom=18layers=M

 A interpolação na rua General Câmara, entre a rua dos Andradas e Andrade
 Neves, ela tem o nro exato mas termina conectada com a rua. Talvez o nó da
 esquina poderia ter o nro intermediário...

 Atenciosamente,
 Roger.

 --
 Fernando Trebien escreveu:

 Pessoal,

 O Paulo Carvalho tem desenvolvido um conversor TrackSource  OSM e eu
 estou prestes a importar a numeração das casas em Porto Alegre via

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

2013-07-25 Thread Gerald Weber

Oi Pessoal

Ao pensar nesta idéia de interpolação: isto não deveria ser tarefa do
renderizador?

Quer dizer, faz sentido popular a base de dados com informações hipotéticas?

Abraços

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

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





Se colocar um nro no n central ele tb seria renderizado. Do jeito que
voc fez ficou melhor, teoricamente a interpolao poderia ter um n
vazio.

Quando eu percebi que algumas interpolaes no estavam funcionando eu
comecei a colocar addr:street nos ns, o que no fez diferena. Eu
achei que ele pegasse a rua aproximada apenas se o street no estivesse
definido, mas se ele est pegando a rua mais prxima da interpolao e
ignora o street no n, ento acho que faz sentido no funcionar, ainda
mais com essa "validao de sanidade". No wiki eles falam pra colocar o
street nos ns, eu sempre achei que deveria ser na interpolao...

Atenciosamente,
Roger.

--
Fernando Trebien escreveu:

  Voc poderia colocar um nmero de casa no n central do cruzamento,
mas haveria um conflito se voc tivesse que fazer isso para dois
interpoladores (um para cada rua do cruzamento).

Eu vinha mapeando passando pelo n central mas colocando os nmeros
pouco antes e pouco depois do cruzamento, assim:
http://www.openstreetmap.org/?lat=-30.050852lon=-51.224171zoom=18layers=M

Como fiz isso muito pouco (mais com o objetivo de testar o sistema
mesmo), no me importo de consertar. Desse jeito h 2 vantagens:
- a numerao  contnua (no h nmeros faltando nos cruzamentos,
sempre se consegue uma posio aproximada)
- o roteamento  correto (mesmo os nmeros no interior do cruzamento
so projetados na rua certa, j que o interpolador  mais prximo da
sua rua do que da outra que chega no cruzamento)

Se o interpolador passasse por cima da rua transversal, os nmeros
prximos do cruzamento seriam projetados na rua errada. Se nesse local
as ruas fossem todas de sentido nico (como costuma ser nas regies
mais densas das cidades), isso poderia mudar drsticamente o
roteamento (no restante no mudaria muito).

Alm do aspecto engraado (repetindo esse padro visual em X em cada
cruzamento :P), tem uma desvantagem em fazer do jeito que eu fiz (e
pode ter sido essa a razo para no ter funcionado pra voc algumas
vezes). O Nominatim faz uma verificao de "sanidade" nos
interpoladores: se numa distncia curta a diferena de numerao for
muito grande, ele descarta o interpolador. Ento, se o interpolador
for feito em pedaos (como em Buenos Aires), a chance de algo ser
descartado  muito menor. Descobri isso (e inclusive abri um ticket no
TRAC do Nominatim pensando que era um erro) quando fui mapear a
Avenida Guaba aqui em Porto Alegre: em um trecho de uma quadra, a
numerao saltava de 990 para 1300 entre os extremos. O Nominatim acha
improvvel haver 400 casas nesse espao curto, pensa que  um erro e
acaba no indexando essas casas. (Pelo que entendi o Nominatim no 
muito esperto, cada valor interpolado gera uma entrada no ndice.
Softwares de GPS simplesmente calculam a posio interpolada ao invs
de armazenar a posio de cada nmero separadamente.)

Em lugares em que h tanto um interpolador quanto uma casa mapeada
separadamente com o seu prprio nmero, o Nominatim retorna as 2
posies, mas a que vem do interpolador sempre aparece como segundo
resultado, o primeiro  a prpria casa.

2013/7/25 Roger C. Soares rogersoa...@gmail.com:
  
  
A idia seria continuar mapeando as construes e colocando o nmero exato
nelas? Se a numerao for duplicada no vejo problema em considerar a
interpolao como uma aproximao, inclusive seria at interessante que os
nros na interpolao no batessem com o nro da construo para a busca no
retornar 2 endereos repetidos. Tem a tag addr:inclusion pra dizer que o nro
 aproximado e no o real.

Eu tenho feito inspees, e eu pego alguns nmeros, na maioria eu tento
pegar as pontas dos quarteires. Mas nem sempre, ento eu escolhi o modo
mais fcil pra mim, eu ignoro os quarteires, sendo o mais simples conectar
as pontas das ruas, e alguns nmeros no meio caso a rua faa alguma curva s
para ficar mais bonito na renderizao. E sempre coloco o nro exato. Se tem
um POI mapeado com o mesmo nro eu adiciono no POI tb.

Inclusive, eu acabei achando interessante conectar a rua inteira, tem
algumas que so quebradas em alguma parte e continuam depois, a linha da
interpolao me d uma noo legal de continuidade do que deveria ser a rua,
por exemplo:
http://www.openstreetmap.org/?lat=-21.193062lon=-47.801154zoom=18layers=M

O primeiro nro do quarteiro  2210, mas se eu fosse guardar esse nro de
cabea eu iria buscar por 2200 ou 2000 (eu fao muito isso), e se a
interpolao no estivesse conectada ela no retornaria nada. Com a
interpolao contnua uma localizao aproximada de onde eu quero ir deveria
aparecer, mas pela minha experincia, nem sempre as interpolaes funcionam
no site do openstreetmap, j aconteceu dele ignorar o nro ou retornar em
outra rua, e no entendi o pq na poca...

Eu li em algum lugar que a interpolao  uma forma rpida para mapear os
nros, mas que a inteno ainda era colocar os nros exatos de cada
construo, ento eu comecei a considerar as interpolaes como algo
auxiliar/temporrio. Mas como eu busco um tanto por nros redondos, no
gostaria de perder as aproximaes...

Uma coisa que eu achei interessante em

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





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
  Ao pensar nesta idia de interpolao: isto no deveria ser tarefa
do renderizador?
   Quer dizer, faz sentido popular a base de dados com informaes
hipotticas?
  Abraos
  Gerald
  

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





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

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

2013-07-25 Thread Arlindo Pereira

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 forma mais correta, mas funciona. =)

[]s
Arlindo Nighto Pereira

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

 **
 Deveria. Na minha opinião não seria necessário 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 contém a rua, o
 país por exemplo.

 Mas o wiki define que interpolação tem que ter um way e talvez seja até pq
 a minha idéia não funcione para o mundo todo. A minha dúvida é: Como se
 mapeia a interpolação de forma contínua para a rua toda?

 Eu tenho colocado os nros conforme eu vou encontrando e ligando com
 addr:interpolation, me parece lógico. Segundo o comportamento do Nominatim
 descrito pelo Fernando, o que eu estou fazendo não funciona, e na prática
 realmente não funciona (sempre). Agora, isso é bug ou feature do Nominatim?
 Quem decide? Tem outro jeito correto para mapear? É correto manter a
 interpolação e tb numerar o contorno da construção? Muitas perguntas? :)

 Atenciosamente,
 Roger.

 --
 Gerald Weber escreveu:

 Oi Pessoal

 Ao pensar nesta idéia de interpolação: isto não deveria ser tarefa do
 renderizador?

 Quer dizer, faz sentido popular a base de dados com informações
 hipotéticas?

 Abraços

 Gerald

 --

 ___
 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] Endereçamento com interpoladores

2013/7/25 Roger C. Soares rogersoa...@gmail.com:
 Deveria. Na minha opinião não seria necessário 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 contém a rua, o
 país por exemplo.

Não deveria existir interpolação de números caso todos os prédios
estivessem mapeados e numerados de forma correta.
Como ainda não existe toda essa informação, faz-se necessário usar
aproximações/intercalações (é bem a definição de interpolação da
matemática mesmo http://pt.wikipedia.org/wiki/Interpolação).

 Mas o wiki define que interpolação tem que ter um way e talvez seja até pq a
 minha idéia não funcione para o mundo todo. A minha dúvida é: Como se mapeia
 a interpolação de forma contínua para a rua toda?

Uma via addr:interpolation=all para toda a rua, ou 2 vias (uma para
cada lado, even e odd), ou uma interpolação para cada quarteirão, ou
para apenas um trecho da rua/quarteirão.
No JOSM ele também cria nós individuais e interpolados (assim não se
utiliza nenhum caminho para os números das casas).
Todos são válidos.

 Eu tenho colocado os nros conforme eu vou encontrando e ligando com
 addr:interpolation, me parece lógico. Segundo o comportamento do Nominatim
 descrito pelo Fernando, o que eu estou fazendo não funciona, e na prática
 realmente não funciona (sempre). Agora, isso é bug ou feature do Nominatim?

Eu diria que bug. Os dados estão corretos (tanto é que muitos
aplicativos de GPS o utilizam de forma certa).

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

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





Esse  o caso que pra mim no funciona. Se algum me falar para ir no
nro 96 e eu no anotar, no outro dia eu vou lembrar que era 90 e pouco
e vou procurar por 90 ou 95. O 90 vai me mandar bem longe do local, o
95 est na interpolaa do outro lado, esse eu teria dado sorte.

Apesar de no ter casas com a numerao, os nros so vlidos, pq  a
distncia em metros do incio da rua, e o 90 deveria ter me levado a um
ponto prximo do 95.

Atenciosamente,
Roger.

--
Arlindo Pereira escreveu:

  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
  Ao pensar nesta idia de interpolao: isto no deveria ser
tarefa
do renderizador?
   Quer dizer, faz sentido popular a base de dados com
informaes
hipotticas?
  Abraos
  Gerald
  
  
  
___
Talk-br mailing list
Talk-br@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-br
  




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

  
  
  
  
  
  

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





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

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

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 forma mais correta, mas funciona. =)

 []s
 Arlindo Nighto Pereira

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

 Deveria. Na minha opinião não seria necessário 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 contém a rua, o
 país por exemplo.


 Mas o wiki define que interpolação tem que ter um way e talvez seja até pq
 a minha idéia não funcione para o mundo todo. A minha dúvida é: Como se
 mapeia a interpolação de forma contínua para a rua toda?

 Eu tenho colocado os nros conforme eu vou encontrando e ligando com
 addr:interpolation, me parece lógico. Segundo o comportamento do Nominatim
 descrito pelo Fernando, o que eu estou fazendo não funciona, e na prática
 realmente não funciona (sempre). Agora, isso é bug ou feature do Nominatim?
 Quem decide? Tem outro jeito correto para mapear? É correto manter a
 interpolação e tb numerar o contorno da construção? Muitas perguntas? :)

 Atenciosamente,
 Roger.

 --
 Gerald Weber escreveu:

 Oi Pessoal

 Ao pensar nesta idéia de interpolação: isto não deveria ser tarefa do
 renderizador?

 Quer dizer, faz sentido popular a base de dados com informações
 hipotéticas?

 Abraços

 Gerald

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




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



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




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

2013-07-25 Thread Arlindo Pereira

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 forma mais correta, mas funciona. =)
 
  []s
  Arlindo Nighto Pereira
 
  2013/7/25 Roger C. Soares rogersoa...@gmail.com
 
  Deveria. Na minha opinião não seria necessário 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 contém a
 rua, o
  país por exemplo.
 
 
  Mas o wiki define que interpolação tem que ter um way e talvez seja
 até pq
  a minha idéia não funcione para o mundo todo. A minha dúvida é: Como se
  mapeia a interpolação de forma contínua para a rua toda?
 
  Eu tenho colocado os nros conforme eu vou encontrando e ligando com
  addr:interpolation, me parece lógico. Segundo o comportamento do
 Nominatim
  descrito pelo Fernando, o que eu estou fazendo não funciona, e na
 prática
  realmente não funciona (sempre). Agora, isso é bug ou feature do
 Nominatim?
  Quem decide? Tem outro jeito correto para mapear? É correto manter a
  interpolação e tb numerar o contorno da construção? Muitas perguntas?
 :)
 
  Atenciosamente,
  Roger.
 
  --
  Gerald Weber escreveu:
 
  Oi Pessoal
 
  Ao pensar nesta idéia de interpolação: isto não deveria ser tarefa do
  renderizador?
 
  Quer dizer, faz sentido popular a base de dados com informações
  hipotéticas?
 
  Abraços
 
  Gerald
 
  
  ___
  Talk-br mailing list

[Talk-br] Nomes de rua abreviados

2013-07-25 Thread Arlindo Pereira

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

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

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

Eu utilizaria a segunda opção, sem introduzir dados que não existem. É
comum e normal haver buracos na numeração.

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

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

2013-07-25 Thread Wille



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 tenho uma opinião formada, mas tenho alguns comentários a fazer. 
Usando esse exemplo de Arlindo, da mesma forma que o número 76 não 
existe, nada garante que o número 68 ou 100 exista. Então, o resultado 
da busca em ambos os casos, poderia retornar uma informação não confiável.


Porém, se ele aproximasse o 72 para 84 e o 96 para 86, estaria inserindo 
informações imprecisas no sistema, dando a impressão que os números 
pares entre 72 e 96 existem de fato. Uma solução, por exemplo, seria 
quando o Nominatim não encontrar um número em um poi ou em uma 
interpolação, retornar o número mais próximo.


Em Buenos Aires creio que isso não é um problema pois lá a numeração é 
muito bem padronizada. Pelo menos na região mais central todas as 
quadras medem 100 metros de largura. Se você tá na Avenida de Mayo, 200 
e quer ir para o número 800, sabe que vai caminhar seis quadras. A única 
exceção são as avenidas diagonais.


Aqui no Brasil estamos longe de termos uma numeração bem feita, mas 
creio que vale a pena usar esse modelo de Buenos Aires em cidades onde a 
numeração é confiável. Aonde eu moro por exemplo, o número das casas 
raramente confere com a distância para o início da rua. O google maps 
usa interpolação e gera muitos resultados errados.


até mais,
wille




Não sei se é a forma mais correta, mas funciona. =)

[]s
Arlindo Nighto Pereira

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


Deveria. Na minha opinião não seria necessário 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
contém a rua, o país por exemplo.

Mas o wiki define que interpolação tem que ter um way e talvez
seja até pq a minha idéia não funcione para o mundo todo. A minha
dúvida é: Como se mapeia a interpolação de forma contínua para a
rua toda?

Eu tenho colocado os nros conforme eu vou encontrando e ligando
com addr:interpolation, me parece lógico. Segundo o comportamento
do Nominatim descrito pelo Fernando, o que eu estou fazendo não
funciona, e na prática realmente não funciona (sempre). Agora,
isso é bug ou feature do Nominatim? Quem decide? Tem outro jeito
correto para mapear? É correto manter a interpolação e tb numerar
o contorno da construção? Muitas perguntas? :)

Atenciosamente,
Roger.

--
Gerald Weber escreveu:


Oi Pessoal

Ao pensar nesta idéia de interpolação: isto não deveria ser
tarefa do renderizador?

Quer dizer, faz sentido popular a base de dados com informações
hipotéticas?

Abraços

Gerald


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



___
Talk-br mailing list
Talk-br@openstreetmap.org mailto: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-de] Hausnummernauswertung in einer ersten Version verfügbar

Genau, danke dass du fragst! die Kölner Stadtgrenze admin_level=6 und alle
angrenzenden boundaries müssen auf der (amtlichen) Außengrenze der
Stadtbezirke liegen (admin_level=9).

Mir ist keine Idee eingefallen, wie man dass automatisieren könnte. Im
Prinzip muss man die Ways der Außengrenze Stadtbezirke an den gleichen
Positionen trennen, wie die der Stadtgrenze. Dann müssen alle Ways die die
Stadtgrenze berühren mit der Stadtbezirksgrenze verbunden werden. Alle
Mitglieder der Stadtgrenze werden dann durch die der Bezirksgrenze ersetzt.
Bei den angrenzenden Relationen ebenfalls. Da ich mir aber nicht sicher
sein kann, ob ich die angrenzenden Relationen evtl kaputtmachen könnte,
musst man sich, glaub ich, die Relationen komplett nachladen. Es entsteht
ein wirklich große OSM-Datei. Und dann den Überblick zu behalten ist
schwierig.

Wahrscheinlich würde eine Einweg JOSM-Style helfen, der SOLL und IST und
Nachbar-Relationen unterschiedlich einfärbt oder so. Das ist das einzige
was mir einfällt.

Die Aufgabe aufzuteilen würde wahrscheinlich für ein großes Durcheinander
sorgen und bis zur Vollendung jede Menge kaputte admin-boundaries
hinterlassen und hinterher weiß keiner mehr, was denn eigentlich fertig und
was nicht ist.

Gruß Johannes

Am 25. Juli 2013 01:22 schrieb Dietmar ostr...@diesei.de:

Hallo Johannes,

das einfach reinkopiert war etwas salopp geschrieben, sorry.

Gilt die Stadtgrenze als die richtige und sind dementsprechend die
Sub-Admingrenzen an diese anzupassen?
Soll ich da mal mitmachen, die anzupassen oder machst Du das lieber bzw.
Ihr in Köln?

Viele Grüße

Dietmar

Am 25.07.2013 00:54, schrieb jotpe:

Hallo Dietmar,

ja du hast recht, Stadtgrenze Köln und die der Stadtbezirke Stadtteile
sind nicht diesselben...
Gerade heute habe ich mir mit der Overpass API die Stadtteilgrenzen
runtergeladen, damit bekommst du alle, wenn du Area Köln nimmst. Aber das
löst ja nicht das Problem der doppelten Grenzen.

Ich habe das nicht einfach reinkopiert. Das war ein Haufen Arbeit die
Shape-Dateien nachzubearbeiten (14 Stunden). Sobald es an die Kölner
Stadtgrenze geht, wirst du förmlich von anderen Relationen erschlagen und
das habe ich dann erstmal nach hinten geschoben. Vielleicht wärs jetzt
Zeit
dafür. Hatte auch schon etwas vorgearbeitet und Felder und Wiesen die
total
kompliziert mit der Außengrenze verbunden waren zu lösen.

Gruß Johannes

Am 24. Juli 2013 22:26 schrieb Dietmar ostr...@diesei.de:

Die Ursache liegt darin, das Du die unteren Admingrenzen einfach in OSM
reingebracht hast, Du hast aber an der Außengrenze der Stadt Köln nicht
die
Stadtgrenze mit den Stadtteilgrenzen zusammengebracht. Der
Dünnwald-Grenzverlauf ist in einigen außerhalb der Stadtgrenze, siehe
z.b.
den Knoten #2046493677.

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

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

Re: [Talk-de] Hausnummernauswertung in einer ersten Version verfügbar

Ich würde das schon ganz gerne machen...

Am 25. Juli 2013 01:22 schrieb Dietmar ostr...@diesei.de:

 oder machst Du das lieber
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Hausnummernauswertung in einer ersten Version verfügbar

Am 25. Juli 2013 08:26 schrieb jotpe jotpe@gmail.com:

 Mir ist keine Idee eingefallen, wie man dass automatisieren könnte. Im
 Prinzip muss man die Ways der Außengrenze Stadtbezirke an den gleichen
 Positionen trennen, wie die der Stadtgrenze. Dann müssen alle Ways die die
 Stadtgrenze berühren mit der Stadtbezirksgrenze verbunden werden. Alle
 Mitglieder der Stadtgrenze werden dann durch die der Bezirksgrenze ersetzt.



zunächst mal sollte man feststellen, welche der Grenzen stimmt.
Abweichungen im Falle, dass beides offizielle Grenzen sind, entstehen z.B.
durch Vereinfachungen (sowohl bei OSM als auch schon beim Amt, je nach
Maßstab und Verwendungszweck machen Vereinfachungen Sinn oder auch nicht,
in OSM sollten wir m.E. versuchen, die Grenzen so detailliert wie möglich
zu erfassen/vorzuhalten).

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

Re: [Talk-de] Hausnummernauswertung in einer ersten Version verfügbar

Am 25. Juli 2013 00:54 schrieb jotpe jotpe@gmail.com:

 Hatte auch schon etwas vorgearbeitet und Felder und Wiesen die total
 kompliziert mit der Außengrenze verbunden waren zu lösen.



wobei, wenn deren Grundstücksgrenze mit der Aussengrenze identisch ist, es
schon wünschenswert ist, dass es in OSM _ein_ way bleibt und nicht zwei
werden, die scheinbar zufällig in der Nähe liegen...

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

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-25 Thread Peter Wendorff

Am 25.07.2013 00:00, schrieb Martin Koppenhoefer:
 
 
 Am 24/lug/2013 um 23:02 schrieb Dirk Sohler s...@0x7be.de:
 
 Gerade wenn dieses Routing so
 unlogische, und unerwünschte Sachen wie gesplittete Bahnsteige oder
 Aufzüge als Weg gemappt verlangt.
 
 
 m.E. ist ein Aufzug als way logischer denn als node. :)
In einer 3D-Welt gebe ich dir recht, auf einer 2D-Karte halte ich das
für grenzwertig. Etliche QA-Tools beschweren sich - z.T. zu unrecht -
ohne weitere Prüfung über zwei nodes an der gleichen Position, du willst
auch noch einen way dazwischenlegen...
Das ist aus der Sicht des Graphen ideal, aber nicht notwendig, und aus
Sicht der Bearbeitung grausam mit allen bisher existierenden Editoren.

Nehmen wir an, der Aufzug ist als Node getagged.
a) Router berücksichtigt Aufzüge nicht:
   = Die Verbindung zu allen Wegen auf anderen Stockwerken bleibt
möglich; nur der Aufzug wird nicht genannt. Nicht ideal, weil vor allem
das Stockwerk vermutlich nicht angesagt wird, aber möglich.
b) Router berücksichtigt Aufzüge:
  = alles, was dazu notwendig ist, erfordert die Ansage des Aufzugs mit
from_level und to_level.

Wird der Aufzug dagegen als Way getagged, so muss das trotzdem
berücksichtigt werden beim Routing, denn sonst wird die
Navigationsansage oder -grafik unverständlich:
- Die berechnete Länge des Weges bei Annahme von 2D (das ist das
übliche) ist 0
- Die berechnete Richtung des Weges ist - undefiniert, aber jedenfalls
bestimmt nicht aufwärts oder abwärts, solange nicht Aufzüge
unterstützt werden, was dann auch den Node-Aufzug problemlos werden ließe.

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


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

Re: [Talk-de] Hausnummernauswertung in einer ersten Version verfügbar

2013-07-25 Thread Markus


Hallo Martin


Felder und Wiesen die total
kompliziert mit der Außengrenze verbunden waren zu lösen.


wobei, wenn deren Grundstücksgrenze mit der Aussengrenze identisch ist, es
schon wünschenswert ist, dass es in OSM _ein_ way bleibt


Die Herausforderung dabei ist es,
*unterschiedliche Klassen* zu unterscheiden:

a) Grenzen
Gründstückgrenzen, Verwaltungsgrenzen, Staatsgrenzen

b) Natur
Wiesen, Bäche, Flüsse, Seen, Wälder, etc

c) Nutzung
Industriegebiet, Wohngebiet, Mischgebiet, Strassen und Wege, 
Landwirtschaf, etc.


Auch dort wo a) und b) und/oder c) irgendwann mal übereinstimmten,
ändert sich das fortlaufend.

Wenn nun - weil es hübsch gerendert wird - a) und b) und c) auf 
derselben Linie durch verschiedene Attribute abgebildet werden,

Dann wird es unmöglich (bzw. zumindest sehr kompliziert und aufwändig),
Veränderungen abzubilden.

Inzwischen gibt es in OSM ganze Regionen mit solch hübschen 
Simplifizierungen der Realität.


Weil dort Editieren so schwierig ist,
werden Veränderungen nicht mehr eingepflegt.

Und weil es dort so hübsch aussieht, nehmen sich immer mehr neue OSMer 
diesen Stil als Vorbild.


Alle diese Effelte zusammen führen dazu, dass die Datenwualität 
zunehmend leidet :-(


Gruss, Markus

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

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

Am 25. Juli 2013 09:48 schrieb Peter Wendorff wendo...@uni-paderborn.de:

 In einer 3D-Welt gebe ich dir recht, auf einer 2D-Karte halte ich das
 für grenzwertig. Etliche QA-Tools beschweren sich - z.T. zu unrecht -
 ohne weitere Prüfung über zwei nodes an der gleichen Position, du willst
 auch noch einen way dazwischenlegen...



Beides hat in bestimmten (raren Ausnahme-)Situationen seine Berechtigung
(für 2 nodes übereinander wird aber wohl die überwiegende Mehrheit auf
schlecht durchgeführte Imports und Editorbugs bzw. Upload-Probleme
zurückzuführen sein, von daher ist es m.E. gut, dass QA-tools hier auf ein
potenzielles Problem hinweisen, vor allem, wenn die nodes keine Layer-tags
haben).



 Das ist aus der Sicht des Graphen ideal, aber nicht notwendig, und aus
 Sicht der Bearbeitung grausam mit allen bisher existierenden Editoren.



+1, mir ging es mehr ums unlogisch ;-)



 - Die berechnete Richtung des Weges ist - undefiniert, aber jedenfalls
 bestimmt nicht aufwärts oder abwärts, solange nicht Aufzüge
 unterstützt werden, was dann auch den Node-Aufzug problemlos werden ließe.



vermutlich doch, wenn der Router gut gemacht ist, die Topologie ist ja
durch die layer-tags der angeschlossenen Wege (und nodes) definiert.

Was das 2D/3D-Thema angeht: OSM ist prinzipiell als Rapresentation der
echten Welt 3D, auch wenn wir bisher eher 2,5 D mappen (2D und
Höhenangaben).


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

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-25 Thread rainerU

Am 24.07.2013 03:27, schrieb Tirkon:
 Hier kommt nun ein Problem zu Tage. Unsere Daten sind unter der freien
 Lizenz ODbL verfügbar. 
 http://opendatacommons.org/licenses/odbl/
 Damit das so bleibt, müsste das auch für die von Euch eingepflegten
 Daten gelten. 

Streng genommen reicht eine Zustimmung zur Nutzung dr Daten unter der ODbL nicht
aus. In Punkt 3 der Contributor Terms heißt es:

...or such other free and open licence (for example,
http://www.opendefinition.org/okd/) as may from time to time be chosen by a vote
of the OSMF membership and approved by at least a 2/3 majority vote of active
contributors.

Der Verkehrsbetrieb oder -verbund muss also auch damit einverstanden sein, dass
seine Daten nach einem eventuellen Wechsel zu einer anderen freien und offenen
Lizenz weiter in der OSM-Datenbank bleiben dürfen. Auf der sicheren Seite ist
man, wenn man das Einverständnis des Datenlieferanten hat, dass OSM die Daten
unter den Bedingungen der CT nutzen darf.

Da man dieses Einverständis so explizit meist nicht bekommt, halte ich die
Verfolgbarkeit der Daten für besonders wichtig. So kann man sie später notfalls
wieder löschen, wenn sich herausstellt, dass das alles nicht so gemeint war.

Gruß
Rainer


___
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-25 Thread Jan Kulhanek

Oder den name-tag.
So habe ich es bisher gesehen.



Michael Bemmerl osm-t...@mx-server.de schrieb:
Hallo Johannes,

jotpe schrieb:
 wie taggt man eine interne Gebäudenummer eines größeren Firmenareals,
die
 keine amtliche Hausnummer ist?

ich benutze für sowas den Key building:ref

Grüße,
Michael





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

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Hausnummernauswertung in einer ersten Version verfügbar

Hallo Markus

  Felder und Wiesen die total
 kompliziert mit der Außengrenze verbunden waren zu lösen.


 wobei, wenn deren Grundstücksgrenze mit der Aussengrenze identisch ist, es
 schon wünschenswert ist, dass es in OSM _ein_ way bleibt


 Die Herausforderung dabei ist es,
 *unterschiedliche Klassen* zu unterscheiden:

 a) Grenzen
 Gründstückgrenzen, Verwaltungsgrenzen, Staatsgrenzen

 b) Natur
 Wiesen, Bäche, Flüsse, Seen, Wälder, etc

 c) Nutzung
 Industriegebiet, Wohngebiet, Mischgebiet, Strassen und Wege,
 Landwirtschaf, etc.

 Auch dort wo a) und b) und/oder c) irgendwann mal übereinstimmten,
 ändert sich das fortlaufend.



das kommt ein bisschen drauf an. Nutzungsgrenzen sind wohl in praktisch
allen Fällen an Grundstücksgrenzen gekoppelt (zumindest sehe ich das so,
und es ist auch bewährte Planungs- bzw. Festlegungspraxis, das ergibt sich
daraus, wie Nutzungspläne und B-Pläne gemacht werden, die letzteren müssen
zwangsläufig parzellenscharf sein). Von daher macht es auch Sinn, dass die
Verwaltungsgrenze, sofern sie mit einer Grundstücksgrenze zusammenfällt
(also nicht z.B. die Straßenmitte oder Flussmitte ist), auch in OSM so
abgebildet werden. Dafür, dass sich das fortlaufend ändert, habe ich bisher
überhaupt keine Anhaltspunkte. Auch im Falle einer Flurbereinigung bzw.
Neuparzellierung (was nicht so häufig ist) bleiben die Aussengrenzen eines
Gebiets normalerweise bestehen.




 Wenn nun - weil es hübsch gerendert wird - a) und b) und c) auf
 derselben Linie durch verschiedene Attribute abgebildet werden,
 Dann wird es unmöglich (bzw. zumindest sehr kompliziert und aufwändig),
 Veränderungen abzubilden.



es geht nicht ums Renderergebnis sondern darum, dass was zusammengehört
auch so abgebildet wird. Es ist nicht zufällig, wenn Grundstücks und
Verwaltungsgrenzen zusammenfallen, es kommt AFAIK praktisch nie vor, dass
ein Grundstück zu mehreren Verwaltungseinheiten gehört (wahrscheinlich
findet jetzt jemand eine rare Ausnahme, wo aus irgendwelchen historischen
Gründen genau das vorkommt ;-) ).

Gruß Martin

PS: Meine persönliche Empfehlung für landuse mapping ist, das so
kleinteilig wie möglich zu machen, und grundstücksbezogene Nutzungen wie
industrial, residential, commercial, retail etc. nie um den öffentlichen
Straßenraum zu vergrößern, aus verschiedenen Gründen:
a) um Details einfacher nachmappen zu können
b) um Details nicht versehentlich zu unterschlagen
c) um die Realität besser abzubilden
d) weil man immer vom Detailreichen automatisch vereinfachen kann (mit
Regeln, die man dann genau definieren kann), während der umgekehrte Weg
nicht geht
e) weil es das Bearbeiten der Straßen erleichtert, wenn sie nicht mit
Nutzungsangaben der angrenzenden Grundstücke verquickt sind
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

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

2013-07-25 Thread 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
durchgeführt hat.


___
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-25 Thread Dirk Sohler

Tirkon schrieb:
 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? 

Ja und nein gleichermaßen. Ja, es ist richtig, dass SÄMTLICHE DATEN,
inklusive User-Metadaten komplett und vollumfänglich in der Datenbank
liegen, und von jedermann für alle Zwecke ausgelesen werden (können).

Und nein: Ich halte das nicht für richtig, da die Lizenz explizit die
Geodatenbank benennt, und damit implizit Geodaten und deren Metadaten
umfasst, und meiner Meinung nach nicht die Metadaten über die
Beitragenden.


 Es ist also die Rede von einer Karte und von Geodaten. Es ist
 nirgendwo die Rede von Daten über die zur Karte Beitragenden.

Genau so sehe ich das auch. Aber es scheint hier zwei „Lager“ zu geben,
die einen sehen von der Lizenz die Geodaten nebst deren Metadaten
abgedeckt, die anderen sehen von der Lizenz auch die Usermetadaten zur
freien Verwendung abgedeckt (und dann gibt es noch jene, die sich
dazwischenstellen, und jene, die sich darüber aufregen, das sich jemand
darüber aufregt, und jene, denen das egal ist, aber die drei Gruppen
sind hier gerade nicht relevant).


 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.

Zum Rausgeben, DEFINITIV, je eher, desto besser. Intern müssen die
Daten aber verknüpft bleiben, falls es Rückfragen oder Probleme gibt,
so dass der jeweilige Mapper kontaktiert werden kann. Aber ansonsten
sollten die Daten weder von der Lizenz abgedeckt werden, noch in der
Geodatenbank liegen. Aber da sind wir wieder bei den zwei Lagern.

So lange es keine Lizenzanpassung gibt, oder eine rechtlich saubere,
eindeutige Definition vorliegt, was genau abgedeckt wird, bleibt jede
Gruppe auf ihrem Standpunkt.


 Denn wenn diese Daten herausgegeben werden, dann könnte ja jede
 X-beliebige Person dieselben Analysen durchführen, die Pascal intern
 durchgeführt hat.

Er hat sie nicht „intern“ durchgeführt, sondern anhand der
Rausgegebenen User-Metadaten (deren genau Lizenz trotz seiner
anderslautenden Meinung definitiv uneindeutig ist)


Grüße,
Dirk

-- 
Local time :: Ortszeit :: DE-HH
2013-07-25T19:00:09+0200


signature.asc
Description: PGP signature
___
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?

Am 25. Juli 2013 18:51 schrieb Tirkon tirko...@yahoo.de:

 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.



es werden nicht Daten über den Beitragenden hochgeladen, sondern Daten
über die Bearbeitung, und dazu gehört neben den Änderungen an sich auch
Datum/Uhrzeit und der Nutzername/ID des in die Datenbank schreibenden
Mappers sowie alle anderen tags am changeset, die der Mapper oder sein
Editorprogramm dort eingetragen haben.

Auch in den wöchentlichen Planetextrakten sieht man die Version und den
zuletzt bearbeitenden Mapper für jedes enthaltene Objekt, im sog.
full-history-planet sieht man alle Versionen, aber AFAIK nicht die
Changeset metadaten, die gibts in einem extra Extrakt:
changesets-latest.osm.bz2http://planet.openstreetmap.org/planet/changesets-latest.osm.bz2

Gruß Martin





-- 
Martin Koppenhoefer (Dipl-Ing. Arch.)
Via del Santuario Regina degli Apostoli, 18

00145 Roma

|I|I|I|I|I|I|I|I|

Italia
N41.851, E12.4824

tel1: +39 06.916508070
tel2: +49 30 868708638
mobil: +39 392 3114712
mobil: +49 1577 7793740
m...@koppenhoefer.com
http://www.koppenhoefer.com


Hinweis:
Diese Nachricht wurde manuell erstellt. Wir bemühen uns um fehlerfreie
Korrespondenz, dennoch kann es in Ausnahmefällen vorkommen, dass bei der
manuellen Übertragung von Informationen in elektronische Medien die
übertragenen Informationen Fehler aufweisen. Wir bitten Sie, dies zu
entschuldigen.

Any views or opinions are solely those of the author and do not necessarily
represent those of koppenhoefer.com unless specifically stated.
This email and any files attached are confidential and intended solely for
the use of the individual or entity to which they are addressed.
If you have received this email in error, please notify
postmas...@koppenhoefer.com

Please note that to ensure regulatory compliance and for the protection of
our clients and business, we may monitor and read messages sent to and from
our systems.

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

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-25 Thread Tirkon

Henning Scholland o...@aighes.de wrote:

Am 24.07.2013 03:27, schrieb Tirkon:
 Zunächst einmal an die Community. Im Allgemeinen wünschen wir Quellen
 für Importe. Bezogen auf die geografischen Einordnung ist dies aber in
 diesem Falle möglicherweise schwierig, wenn diese Daten überhaupt erst
 mit Hilfe von OSM Werkzeugen erstmals im geografischen Umfeld erfasst
 werden. Wir haben hier möglicherweise eine bisher nie oder kaum
 dagewesene Situation, dass OSM die Erstveröffentlichungsquelle ist und
 damit eine andere Quelle nicht zur Verfügung steht. Dann müssten wir
 uns im Rahmen dieses Imports überlegen, wie die für Importe notwendige
 Zusicherung, diese Daten unter der OSM Lizenz veröffentlichen zu
 dürfen, bewirkt werden kann. Ich denke, hier sollten wir unsere
 Data-Working-Group mit ihren entsprechenden Erfahrungen mit größeren
 Importen um Mithilfe bitten.
Hallo,
die Erlaubnis dazu muss der Urheber der Daten geben, genauso wie bei 
jedem anderen Beitrag zu OSM auch. Oder wo siehst du hier etwas anders?

Nein, hatte ich im gleichen Beitrag weiter unten auch so geschrieben.
Zitat
Hier kommt nun ein Problem zu Tage. Unsere Daten sind unter der freien
Lizenz ODbL verfügbar. 
http://opendatacommons.org/licenses/odbl/
Damit das so bleibt, müsste das auch für die von Euch eingepflegten
Daten gelten. Sofern Daten selbst vor Ort erfasst werden, ist das kein
Problem. Anders ist es, wenn man sich dabei auf Daten Dritter stützt.
Dann müsste das offizielle Einverständnis des Datengebers vorliegen
und es kämen weitere Sonderregeln für Importe zum Tragen, die man hier
nachlesen kann:
http://wiki.openstreetmap.org/wiki/Import/Guidelines
Zitat Ende

(Im ersten Posting habe ich dies versehentlich nicht reinkopiert:)

Der feine Unterschied ist aber, dass OSM möglicherweise die
Erstveröffentlichungsquelle bezüglich der Verortung in der Umgebung
ist. Von daher könnte es dann keine Karte geben, die als Quelle
herangezogen werden kann. Der VRR könnte dann nicht ohne Weiteres
schreiben, dass er die Daten aus der Kartenquelle XY freigibt.

Denn bisher wurde immer die Quelle (Karte oder Datei) genannt, so dass
sich die Bestätigung darauf beziehen konnte. So konnte jeder OSM User
die Äquivalenz des Imports mit dem eingebrachten Datenmaterial und
damit die Richtigkeit der Lizenzfreigabe für dieses Material prüfen.
Wenn es solche Quellen aber nicht gibt, müsste diese Prüfung hier
anders vonstatten gehen. Ich hoffe, der feine Unterschied ist klar
geworden.

Und wie diese Prüfung dann funktionieren soll, sollte IMHO von der
Data Working Group besprochen werden. Wenn die Firma hier im Thread
ihre Quellenlage nicht kundtun möchte, wäre die DWG als offizieller
Vertreter der Foundation möglicherweise ein besserer Ansprechpartner.
Immerhin haben die Firmenmapper schon einen Gutteil in die Datenbank
eingetragen. Aus all diesen Gründen habe ich das hier thematisiert.

http://wiki.openstreetmap.org/wiki/Import_%C3%96PNV_Firma_Mentz_Datenverarbeitung_GmbH


___
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-25 Thread Walter Nordmann

Dirk Sohler wrote
 . Ja, es ist richtig, dass SÄMTLICHE DATEN,
 inklusive User-Metadaten komplett und vollumfänglich in der Datenbank
 liegen, und von jedermann für alle Zwecke ausgelesen werden (können).

Das kann ich nicht so stehen lassen: Es ist in den frei zugänglichen
OSM-Daten einzig und allein nur der Nickname des Anwenders und dessen
Seriennummer  enthalten.

Daraus läßt sich (von jedem)  feststellen, was dieser User wann, wo und wie
geändert hat - mehr nicht.

Könntest du bitte mal ein oder zwei Datenfelder benennen und anhand von
simulierten Beispielen zeigen, die bei dir unter den Begriff Metadaten
fallen?

Mir fällt da neben dem Passwort bzw. Authentifizierungskey als einziges
Datenfeld noch die persönliche Mail-Adresse ein, unter der der User
erreichbar ist - und die rückt OSM definitiv nicht raus.

Gruss
walter




-
[url=http://osm.wno-edv-service.de/residentials] Missing Residentials Map 
1.17[/url] [url=http://osm.wno-edv-service.de/plz] Postcode Map 2.0[/url]
--
View this message in context: 
http://gis.19327.n5.nabble.com/Gibt-OSM-auch-Daten-uber-die-Beitragenden-heraus-tp5771392p5771398.html
Sent from the Germany mailing list archive at Nabble.com.

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

Am 25. Juli 2013 20:01 schrieb Walter Nordmann pil...@hotmail.com:

 Mir fällt da neben dem Passwort bzw. Authentifizierungskey als einziges
 Datenfeld noch die persönliche Mail-Adresse ein, unter der der User
 erreichbar ist - und die rückt OSM definitiv nicht raus.


die Freunde ;-)

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

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

2013-07-25 Thread fly

On 25.07.2013 19:46, Tirkon wrote:
 Henning Scholland o...@aighes.de wrote:
 Am 24.07.2013 03:27, schrieb Tirkon:

 http://wiki.openstreetmap.org/wiki/Import_%C3%96PNV_Firma_Mentz_Datenverarbeitung_GmbH

Also wenn zumindest einer der User potlatch2 verwendet, wundert es mich
nicht mehr warum dabei relationen kaputt gehen !

Für solche Aufgaben, braucht mensch einen Editor, der auch mit
Relationen umgehen kann.

my 2 ct

fly

___
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-25 Thread Tirkon

Dirk Sohler s...@0x7be.de wrote:

 Denn wenn diese Daten herausgegeben werden, dann könnte ja jede
 X-beliebige Person dieselben Analysen durchführen, die Pascal intern
 durchgeführt hat.

Er hat sie nicht intern durchgeführt, sondern anhand der
Rausgegebenen User-Metadaten (deren genau Lizenz trotz seiner
anderslautenden Meinung definitiv uneindeutig ist)

Ich war bisher der Auffassung, dass Pascal vom Board die Erlaubnis
gehabt hätte, weil ich entsprechend der schon genannten OSM-Verpackung
geglaubt hatte, dass solche Daten nicht rausgegeben werden. 
  
Aber Pascal hat Alles richtig gemacht. Die Daten sind von OSM unter
freier Lizenz veröffentlicht und er hat sie entsprechend genutzt. Ich
bin ihm auch dankbar dafür, dass er gezeigt hat, was Externe mit
diesen Daten machen können, so dass man trotz Nickname am Ende dann
doch identifiziert werden kann und die Daten aus OSM einem Profil
hinzugefügt werden können.

Ich streue Asche auf mein Haupt, dass sich wegen mir Leute angemeldet
haben, die eigentlich Bedenken hatten.


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

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

2013-07-25 Thread fly

On 25.07.2013 20:21, fly wrote: On 25.07.2013 19:46, Tirkon wrote:
 Henning Scholland o...@aighes.de wrote:
 Am 24.07.2013 03:27, schrieb Tirkon:


http://wiki.openstreetmap.org/wiki/Import_%C3%96PNV_Firma_Mentz_Datenverarbeitung_GmbH

 Also wenn zumindest einer der User potlatch2 verwendet, wundert es mich
 nicht mehr warum dabei relationen kaputt gehen !

 Für solche Aufgaben, braucht mensch einen Editor, der auch mit
 Relationen umgehen kann.

und ich sehe auch, dass munter weiter editiert wird, kann ein Admin
bitte mal diese user blocken und auf die Import-Richtlinien hinweisen !

Ich finde mich fühle mich ganz schön an der Nase herumgeführt, wenn ich
hier versuche eine Lösung zu finden und etliche Personen auf die
Import-Richtlinien hingewiesen haben und jetzt einfach munter weiter
editiert wird.

So ein Verhalten irritiert mich doch sehr und passt nicht zur Community.

Zumindest ein user macht dabei so merkwürdige Edits, wie
motor_vehicle=yes and normal highways zu hängen. Hat das mit dem Import
zu tun ?


Danke

fly


___
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-25 Thread Tobias Knerr

Am 25.07.2013 19:10, schrieb Dirk Sohler:
 Ja, es ist richtig, dass SÄMTLICHE DATEN,
 inklusive User-Metadaten komplett und vollumfänglich in der Datenbank
 liegen, und von jedermann für alle Zwecke ausgelesen werden (können).

Es werden keineswegs sämtliche Daten, die in der Datenbank liegen,
veröffentlicht. Klassische Benutzerdaten (wie die Mailadresse) und
beispielsweise auch bestimmte als privat eingestellte GPS-Track-Infos
sind in den Extrakten nicht enthalten.

Neben Tracks sind die wichtigsten öffentlichen Datensätze:

* die Geodaten
* die Revisionsgeschichte dieser Geodaten

Bei beidem besteht ein Nutzerbezug nur insofern, als vermerkt wird,
welcher Benutzer (ID und Username) eine Bearbeitung durchgeführt hat.

Und bei beidem ist eine freie Veröffentlichung wichtig. Die Geodaten
sind unser Produkt, da ist das wohl klar. Aber die Revisionsgeschichte
muss ebenfalls öffentlich sein, da die (dezentral programmierten)
Auswertungen dieser Information unsere Grundlage für eine
funktionierende Zusammenarbeit sind. Zudem würde das Geheimhalten dieser
Daten Abspaltungen behindern - Stichwort Right to Fork.

Ich hätte nichts dagegen, wenn _Auswerter_ eine Opt-Out-Möglichkeit
bieten, und denke, dass das dem Konflikt einiges an Schärfe nehmen
könnte. Aber ich sehe keine Möglichkeit, die genannten Datensätze an
sich geheim zu halten, ohne an den Grundlagen unseres Projekts zu rütteln.

Gruß,
Tobias

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

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

Auch nicht verkehrt, aber es existieren Namen für die Gebäude...


Am 25. Juli 2013 12:21 schrieb Jan Kulhanek jan_kulha...@gedankensilo.de:

 Oder den name-tag.
 So habe ich es bisher gesehen.

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

Re: [Talk-de] Hausnummernauswertung in einer ersten Version verfügbar

Natürlich sollte man das checken welche Grenze die richtige. Für mich ist
die Sache jedoch klar. Nur die amtliche Grenze der Stadt Köln ist die
richtige, also die der Stadtbezirke und Stadtteile (admin_level=9  10). Du
kannst es dir bspw verdeutlichen an der Stelle zwischen Libur und Langel (
http://openstreetmap.org/?lat=50.84261lon=7.04106zoom=15layers=M ). Dort
verläuft die richtige Grenze der Stadtbezirke und Stadtteile (dünnere
Linie) sehr genau an den vorhandenen Wegen, die ältere Stadtaußengrenze
(dickere Linie) liegt fasst immer daneben.

Gruß Johannes

Am 25. Juli 2013 09:16 schrieb Martin Koppenhoefer dieterdre...@gmail.com:

 zunächst mal sollte man feststellen, welche der Grenzen stimmt.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Hausnummernauswertung in einer ersten Version verfügbar

Zunächst mal waren das nur 2 Fälle mit Wiesen und Wäldern, der Rest war
anderer Kram, Briefkästen oder so was. Wenn die Wiese mit der
Stadtaußengrenze endet, es sich aber herausstellt, dass die Stadtgrenze
 tatsächlich 30m weiter außen liegt, dann ist es bestimmt nicht sehr
sinnvoll die Wiese auch um diese 30m zur neuen Stadtgrenze auszudehnen.

Sollte irgendwo ein Flurstück enthalten sein, was aber nicht war, dann
könnte man dass tatsächlich ausdehnen.

Gruß Johannes


Am 25. Juli 2013 09:18 schrieb Martin Koppenhoefer dieterdre...@gmail.com:

 wobei, wenn deren Grundstücksgrenze mit der Aussengrenze identisch ist, es
 schon wünschenswert ist, dass es in OSM _ein_ way bleibt und nicht zwei
 werden, die scheinbar zufällig in der Nähe liegen...

___
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-25 Thread Tim Michelsen

  Denn wenn diese Daten herausgegeben werden, dann könnte ja jede
  X-beliebige Person dieselben Analysen durchführen, die Pascal intern
  durchgeführt hat.
 
 Er hat sie nicht „intern“ durchgeführt, sondern anhand der
 Rausgegebenen User-Metadaten (deren genau Lizenz trotz seiner
 anderslautenden Meinung definitiv uneindeutig ist)
 Ich war bisher der Auffassung, dass Pascal vom Board die Erlaubnis
 gehabt hätte, weil ich entsprechend der schon genannten OSM-Verpackung
 geglaubt hatte, dass solche Daten nicht rausgegeben werden.
Könntest Du einen Links schicken?
Welche Auswertungen meinst Du hier?

Danke vorab.


___
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-25 Thread Simon Poole


Am 25.07.2013 20:34, schrieb fly:

 und ich sehe auch, dass munter weiter editiert wird, kann ein Admin
 bitte mal diese user blocken und auf die Import-Richtlinien hinweisen !

Du solltest an d...@osmfoundation.org schreiben, admins lesen hier so
oder so keine mit. Frederik und Henning als Mitglieder der DWG vielleicht.

Simon

___
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-25 Thread Henning Scholland


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.


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.


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

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-it] waterway_layer

Ho notato sia in Veneto che in Friuli che nelle regole di importazione dei
 dati regionali è stato messo il layer -1 su tutti i tag waterway.


Purtroppo quando abbiamo importato questi dati in FVG non si era ancora
deciso com'era meglio e di conseguenza il wiki non riportava niente.

Comunque, con o senza layer=-1, bisogna spezzare le way in corrispondeza di
ponti e tunnel.

Ciao,

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

Grazie, è un tool utilissimo. conto di provarlo subito.

Ciao,

Stefano

P.S. grazie di avermi citato anche se il mio contributo è stato davvero
piccolo :-)


Il giorno 25 luglio 2013 00:31, Stefano Droghetti 
stefano.droghe...@gmail.com ha scritto:

 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/nuvihttp://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-ithttp://lists.openstreetmap.org/listinfo/talk-it

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

Re: [Talk-it] waterway_layer

2013/7/25 Stefano Salvador stefano.salva...@gmail.com

 Purtroppo quando abbiamo importato questi dati in FVG non si era ancora
 deciso com'era meglio e di conseguenza il wiki non riportava niente.



avete importato prima del 2/2008?
http://wiki.openstreetmap.org/w/index.php?title=Layeroldid=80595  ;-)



 Comunque, con o senza layer=-1, bisogna spezzare le way in corrispondeza
 di ponti e tunnel.



+1

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

Re: [Talk-it] waterway_layer


 Purtroppo quando abbiamo importato questi dati in FVG non si era ancora
 deciso com'era meglio e di conseguenza il wiki non riportava niente.



 avete importato prima del 2/2008?
 http://wiki.openstreetmap.org/w/index.php?title=Layeroldid=80595  ;-)



touché ;-) L'import è del 2010. La cosa interessante è che nell'import non
c'era il tag layer=-1, è stato aggiunto dopo a mano dagli utenti (anche
perché in ML c'erano varie scuole di pensiero). ad esempio:

http://www.openstreetmap.org/browse/way/51920795/history
___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it

[Talk-it] R: Re: waterway_layer

2013-07-25 Thread ale.bar...@alice.it

Per esempio ho notato che in questo gruppo di modifiche 
http://www.openstreetmap.org/browse/changeset/15833430 è stato aggiunto il 
layer=-1 a molti fossi.




Messaggio originale

Da: stefano.salva...@gmail.com

Data: 25-lug-2013 11.17

A: openstreetmap list - italianotalk-it@openstreetmap.org

Ogg: Re: [Talk-it] waterway_layer






 

Purtroppo quando abbiamo importato questi dati in FVG non si era ancora deciso 
com'era meglio e di conseguenza il wiki non riportava niente.





avete importato prima del 2/2008? 
http://wiki.openstreetmap.org/w/index.php?title=Layeramp;oldid=80595  ;-)


touché ;-) L'import è del 2010. La cosa interessante è che nell'import non 
c'era il tag layer=-1, è stato aggiunto dopo a mano dagli utenti (anche perché 
in ML c'erano varie scuole di pensiero). ad esempio:


http://www.openstreetmap.org/browse/way/51920795/history



 




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

Re: [Talk-it] waterway_layer

2013-07-25 Thread alessandro zardo

Io nella mia zona sto riportando le cose alla normalità inserendo ponti e 
tunnel e mettendo il layer corretto.



 Da: Stefano Salvador stefano.salva...@gmail.com
A: openstreetmap list - italiano talk-it@openstreetmap.org 
Inviato: Giovedì 25 Luglio 2013 9:49
Oggetto: Re: [Talk-it] waterway_layer
 







Ho notato sia in Veneto che in Friuli che nelle regole di importazione dei
dati regionali è stato messo il layer -1 su tutti i tag waterway.



Purtroppo quando abbiamo importato questi dati in FVG non si era ancora deciso 
com'era meglio e di conseguenza il wiki non riportava niente.


Comunque, con o senza layer=-1, bisogna spezzare le way in corrispondeza di 
ponti e tunnel.


Ciao,


Stefano


___
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] R: Re: waterway_layer

probabilmente per evitare di far tutto il lavoro di ponti e tunnel qualcuno
ha preferito mettere -1 così non si vede nemmeno l'errore in keepright se
qualcuno volesse fare il lavoro completo.



--
View this message in context: 
http://gis.19327.n5.nabble.com/R-Re-waterway-layer-tp5771331p5771340.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] waterway_layer

come mai però i tratti sotterranei dei corsi d'acqua vengono comunque
visualizzati come i tratti normali a celo aperto, non sarebbe meglio che
fossero invisibili o almeno tratteggiati, altrimenti ci si potrebbe
confondere nella lettura della carta.



--
View this message in context: 
http://gis.19327.n5.nabble.com/waterway-layer-tp5770579p5771341.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] OSMIT 2013 in arrivo: Rovereto (TN) 4-6 ottobre 2013

2013-07-25 Thread Cristian Consonni

Ciao a tutti,

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)


Cristian

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

Re: [Talk-it] waterway_layer

2013-07-25 Thread Salemme Guido

mettere layer -1 o non metterlo (equivale layer=0) non dovrebbe avere 
importanza


l'importante è che sia rispettato chi è sopra e chi è sotto

se ne è già parlato

molti usano mettere per i fiumi , fossi ecc layer -1

per esempio nella mia zona ho tracciato i numerosi canali di cui molti 
passano uno sotto l'altro e avevo messo i layer ai vari tunnel in modo 
da rispettare chi è sopra e chi è sotto a partire dai canali più sopra 
senza un layer specificato (layer=0) e i ponti delle strade layer=1


un utente poco attento ha cambiato tutti i layer dei canali a -1 
combinando un pasticcio!


il tag layer è relativo quindi non è detto che qualcosa sotto il livello 
del terreno deve essere per forza -1 serve solo a indicare che qualcosa 
sta sotto o sopra ad un'altra



Il 20/07/2013 14:29, Mario Pichetti ha scritto:

Ciao a tutti

Come mi ha fatto notare Bredy, non si usa layer -1 nei waterway.

Ho fatto un giro nei principali fiumi e nessuno lo usa.

http://www.openstreetmap.org/?lat=51.63822lon=10.48771zoom=16 (Oder)

http://www.openstreetmap.org/?lat=46.5108lon=8.69543zoom=15 (Ticino)

Ma anche Tamigi, Reno, ecc...

Mario.



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




--
Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP 
autenticato? GRATIS solo con Email.it http://www.email.it/f

Sponsor:
Soggiorna ALMENO 6 giorni fra il 27 luglio ed il 4 agosto e avrai un biglietto gratis a persona per un parco a scelta fra AQUAFAN e OLTREMARE valido 2 giorni!Sistemazione in hotel Tre Rose di Riccione 
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=12990d=25-7


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

Re: [Talk-it] waterway_layer



Am 25/lug/2013 um 13:59 schrieb bredy bredy...@yahoo.it:

 come mai però i tratti sotterranei dei corsi d'acqua vengono comunque
 visualizzati come i tratti normali a celo aperto, non sarebbe meglio che
 fossero invisibili o almeno tratteggiati, altrimenti ci si potrebbe
 confondere nella lettura della carta.

si, certo. Quale tag stai usando per indicare che sono sotterranei?

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

Re: [Talk-it] waterway_layer

2013-07-25 Thread marco bra

Hei, mannaggia, sono stato io, che ne dite di fare un revert sul changeset...?

mcheck



Il 25 luglio 2013 15:53, Martin Koppenhoefer dieterdre...@gmail.com
ha scritto:


 Am 25/lug/2013 um 13:59 schrieb bredy bredy...@yahoo.it:

 come mai però i tratti sotterranei dei corsi d'acqua vengono comunque
 visualizzati come i tratti normali a celo aperto, non sarebbe meglio che
 fossero invisibili o almeno tratteggiati, altrimenti ci si potrebbe
 confondere nella lettura della carta.

 si, certo. Quale tag stai usando per indicare che sono sotterranei?

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



-- 
Linux Infinite Freedom

I'm writing from this place:
http://www.openstreetmap.org/?lat=44.39945lon=8.6798zoom=15layers=M

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

Re: [Talk-it] waterway_layer

allora se passa su un tubo che passa sotto la strada applico alla waterway
tunnel=culvert e layer=-1 in quanto passa sotto, se invece passa su un
ponticello allora applico alla highway bridge=yes e layer=1

se non si imposta il layer su una delle due (highway o waterway) si ha un
errore perchè ci sono due percorsi che si incrociano, spero che nessuno
metta un incrocio tra highway e waterway, anche se l'ho visto (spero un
errore)



--
View this message in context: 
http://gis.19327.n5.nabble.com/waterway-layer-tp5770579p5771366.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] OSMIT 2013 in arrivo: Rovereto (TN) 4-6 ottobre 2013

2013-07-25 Thread Luca Delucchi

On Jul 25, 2013 2:53 PM, Cristian Consonni kikkocrist...@gmail.com
wrote:

 Ciao a tutti,


Ciao Cristian,

 Ho creato la pagina sul wiki:
 http://wiki.openstreetmap.org/wiki/IT:OSMit2013


Grazie, c'é solo una cosa che manca, come e quando sottomettere gli
abstract...


 Cristian


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

Re: [Talk-it] waterway_layer



Am 25/lug/2013 um 16:08 schrieb bredy bredy...@yahoo.it:

 spero che nessuno
 metta un incrocio tra highway e waterway, anche se l'ho visto (spero un
 errore)


al meno che non si tratta di un ford

ciao,
Martin

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

Re: [Talk-it] waterway_layer

allora se passa su un tubo che passa sotto la strada applico alla waterway
 tunnel=culvert e layer=-1 in quanto passa sotto, se invece passa su un
 ponticello allora applico alla highway bridge=yes e layer=1


A quanto ne so il tag tunnel=culvert non viene considerato dallo stile di
default di osm.org, funziona solo tunnel=yes. Credo esista anche un ticket
a riguardo. Comunque è giusto usare culvert sperando che prima o poi
sistemino.
___
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-25 Thread Cristian Consonni

Il 25 luglio 2013 16:10, Luca Delucchi lucadel...@gmail.com ha scritto:
 Grazie, c'é solo una cosa che manca, come e quando sottomettere gli
 abstract...

Hai ragione, indicazioni in proposito a breve.

Cristian

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

Re: [Talk-it] waterway_layer

2013/7/25 marco bra marcobra.ubu...@gmail.com

 Hei, mannaggia, sono stato io, che ne dite di fare un revert sul
 changeset...?



dipende quando l'hai fatto, se non è passato troppo tempo e quindi non sono
ancora stato modificato gli oggetti contenuti lo puoi fare, altrimenti ti
troverai davanti ad un mare di conflitti...

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

Re: [Talk-it] waterway_layer

2013/7/25 Stefano Salvador stefano.salva...@gmail.com

 A quanto ne so il tag tunnel=culvert non viene considerato dallo stile di
 default di osm.org, funziona solo tunnel=yes. Credo esista anche un
 ticket a riguardo. Comunque è giusto usare culvert sperando che prima o poi
 sistemino.




in questi giorni è stato messo il nuovo stile basato su carto (traduzione
fatta da Andy Allan) che sostituisce lo stile xml (visivamente dovrebbe
rimanere uguale). Forse adesso continua lo sviluppo dello stile
principale che è stato quasi fermo da oramai anni.

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

Re: [Talk-it] OSM su Windows Phone?

2013-07-25 Thread Vincenzo Galgano

Ciao, ieri mi è rientrato il telefono dall'assistenza.

Purtroppo la risposta è negativa. Quando visualizzi una zona e poi lo fai di
nuovo, ma senza rete dati (ho fatto la prova disattivandola) le tiles non le
visualizza bene, nel senso che alcune le carica ma altre no.

Buone escursioni cmq!

saluti
Vincenzo





--
View this message in context: 
http://gis.19327.n5.nabble.com/OSM-su-Windows-Phone-tp5769439p5771383.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-25 Thread Simone Cortesi

2013/7/22 bredy bredy...@yahoo.it:
 Come mai alcuni tag usati anche per l'uso del suolo tipo amenity di case di
 riposo o istituti per disabili non hanno una loro visualizzazione grafica su
 osm, non si riesce a capire quale sia l'area di queste strutture.

la cartografia presente su OSM.org da visibilità solo di alcuni dati
inseriti nel database. Pensaci, se tutto fosse visualizzato, non si
distinguerebbe molto della mappa.

-- 
-S

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

Re: [Talk-it] Grafica mancante

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



--
View this message in context: 
http://gis.19327.n5.nabble.com/Grafica-mancante-tp5770867p5771401.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] Convenzioni importazioni CTRN Veneto