Re: [Talk-hr] Po?tanski brojevi
On Wed, Jul 09, 2014 at 10:35:55PM +0200, hbogner wrote: Ima netko kakvih novosti? Našao sam i ovo pa ako je netko pitao nek pita i za ovo: http://www.posta.hr/pomoc-i-informacije/preuzimanje-podataka-o-postanskim-uredima Ne, nikad nisam uspio Valenta dobiti ni na mail, ni na listu. Biti ce da mu je preefikasan spam filter :) Nista, ako se na javi za tjedan dana da je nesto napravio, budem ja kontaktirao HP. -- Opinions above are GNU-copylefted. ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr
Re: [OSM-talk] Using osmdroid for an Android university course
How about osmand? On Mon, Jul 7, 2014 at 6:27 AM, Nick Whitelegg nick.whitel...@solent.ac.uk wrote: Hi, (not sure if this belongs in talk or dev) Next year I am running a university course on Android development. I am planning to include a section on location-aware apps and mapping, and naturally I want to use OSM. ;-) Mapsforge is one option, however IMV the new 0.4 API has a little too much complexity for what will be complete newcomers to Android development (they have Java experience though). So I'd like to use osmdroid, however I'm aware that apps that use raster tile sources can place a strain on tileservers. It looks like osmdroid will now talk to the MapQuest tileservers though. Will it be acceptable - particularly if I use MapQuest - to use osmdroid for this course? There will be 20 students max. Thanks, Nick ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] OpenStreetMap Foundation Corporate Members
Since February 2014 your company can support OpenStreetMap Foundation with a corporate membership. The first corporate members were announced today. https://blog.openstreetmap.org/2014/07/20/welcome-corporate-members/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-br] Exemplo de classificação ruim de rodovias
Feito. Levei 15 segundos pra fazer. ^_^ De fato, a avenida faz parte do sistema da rodovia e por isso pode ter a etiqueta ref. Mesmo que não tivesse, acho que não estaria correto rebaixar a classificação da via. Afinal, ela é pavimentada e é a via principal da cidade, como pode alguém pensar que não é uma arterial? 2014-07-20 10:17 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Acho que agora não será por isso que o roteamento vai quebrar, pois a classe está rigorosamente igual. Mas acho que a rua Guadalajara do exemplo deveria receber a tag ref=PI-255 para você declarar sua intenção de dar continuidade a uma rodovia, que integra uma região mais abrangente, caso contrário um mapeador posteriormente pode reduzir a classificação. []s e obrigado, Paulo Em 19 de julho de 2014 23:59, Fernando Trebien fernando.treb...@gmail.com escreveu: Que tal agora? On Sat, Jul 12, 2014 at 6:34 PM, Paulo Carvalho paulo.r.m.carva...@gmail.com wrote: http://www.openstreetmap.org/search?query=Parnagu%C3%A1#map=15/-10.2273/-44.6372 Isso é uma beleza para quebrar o roteamento... ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 Nullius in verba. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 Nullius in verba. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] A importância de não quebrar a hierarquia das vias dentro de cidades.
Temos um exemplo de um mapa Garmin que não está calculando uma rota entre o extremo sul do Brasil e um ponto no Ceará. A rota é calculada normalmente no Mapsource (computador) mas não no GPS (dipositivo móvel). O problema é justamente localizar onde está a interrupção ou alternância de classificação de vias nos mais de 3000km da rota. Em 20 de julho de 2014 12:05, Fernando Trebien fernando.treb...@gmail.com escreveu: Contraction hierarquies permite usar Dijkstra bidirecional + alguma heurística otimista em ambientes com restrições de memória e capacidade computacional sem remover qualquer via do cálculo. Isso tá lá nos papers referenciados no final daquele artigo da Wikipédia que você apontou. Era a isso que eu me referia ao julgar a inteligência do algoritmo, e por ser um fato (o algoritmo foi publicado e nada impede que seja implementado), não tem como ser arrogante. É uma escolha simples (bem, não tão simples) que o desenvolvedor da aplicação tem que fazer. E é uma escolha que é independente do mapa (que, novamente, serve a vários propósitos, não só ao roteamento, não só ao roteamento em ambientes com capacidades limitadas). Mas interromper uma motorway com um trecho de residential vai quebrar o roteamento em muitas aplicações. Pode dar um exemplo de aplicação e local? Apesar de solicitar esse exemplo, não conheço nenhum caso em que uma motorway/trunk precisaria ter um trecho classificado como residencial. Na pior das hipóteses, teria um trecho classificado como terciária por estar não-pavimentada - mas acho que nem no Brasil essa situação ocorre. Recentemente eu achei um exemplo em que uma trunk se intercala com uma primária [1], mas isso também não deve afetar esses sistemas que descartam vias a que você se refere. E claro, no caso particular, raro, e bizarro de uma classificação fiel produzir uma situação assim, podemos pensar em discutir com a comunidade sobre o que fazer. A idéia de não alternar demais a classificação da via poderia ser aplicada ser for só um trecho curto com características diferentes, e o motivo não seria só o roteamento. [1] http://www.openstreetmap.org/#map=12/-29.5385/-51.8998 2014-07-20 10:47 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Em 19 de julho de 2014 22:29, Fernando Trebien fernando.treb...@gmail.com escreveu: Sabendo que há trabalhos cientificos publicados descrevendo bons algoritmos para esses ambientes e que não descartam quaisquer vias (mesmo as de classe bem inferior), acho que não devemos fazer adaptações no mapa em favor de algoritmos menos inteligentes. (Isso seria mapear para a aplicação.) Menos inteligentes Desculpa, Fernando, esse seu comentário foi um tanto arrogante. Quando você tem restrição de recursos de hardware em dispositivos móveis você TEM que fazer otimização. Isso para mim é sinal de extrema inteligência. E só uma palavra sobre artigos científicos: poucas vezes tratam-se de ideias praticáveis. O algoritmo Dijkstra é um exemplo. Ninguém usa a forma tal como publicada pelo Dijkstra originalmente. A indústria sempre faz várias melhorias para o mundo real. Sei disso porque trabalho nos dois mundos e também porque estou escrevendo um artigo e não estou pensando em problemas de ordem prática. A teoria já dá trabalho suficiente. Isso não é pecado, é como o progresso funciona: cada especialista em sua área. Mas, ao mesmo tempo, acho que são muito raros os casos em que adaptações seriam necessárias para evitar problemas com esses algoritmos que descartam vias. A menos que eles estejam descartando até as vias primárias (arteriais urbanas), daí não tem como resolver mesmo. Não são raros não. Você tem que pensar em para que a maioria dos usuários precisa de um mapa de ruas (Street Map): a) Encontrar um lugar (geocoding); b) Navegar até um lugar (roteamento); c) Quase sempre em trânsito, com dispositivos móveis. Se essas coisas não estão funcionando bem, elas procurarão alternativas e aí seu mapa será o mais puro do mundo mas vazio de propósito. Se queres que o mapa se torne popular, TEM que pensar nas questões de ordem prática. Acho que dá para conciliar os princípios do OSM com as questões práticas. Mas interromper uma motorway com um trecho de residential vai quebrar o roteamento em muitas aplicações. Não digo colocar tudo igual, mas não deixar as classes tão contrastantes conforme já exemplificado. []s Paulo 2014-07-19 17:56 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com : E qual sua opinião sobre o descarte de vias de baixa prioridade nos roteamentos de longa distância em ambientes com baixa memória e processamento mais lento? Em 19 de julho de 2014 12:58, Fernando Trebien fernando.treb...@gmail.com escreveu: Li sim, há bastante tempo. Mas acho que estás confundindo as hierarquias do OSM com a hierarquia de atalhos emergente
Re: [Talk-br] A importância de não quebrar a hierarquia das vias dentro de cidades.
Eu poder testar no meu Nüvi, usando mapas do garmin.openstreetmap.nl Aun Johnsen Sent from my iPhone On 20. juli 2014, at 12:47, Paulo Carvalho paulo.r.m.carva...@gmail.com wrote: Temos um exemplo de um mapa Garmin que não está calculando uma rota entre o extremo sul do Brasil e um ponto no Ceará. A rota é calculada normalmente no Mapsource (computador) mas não no GPS (dipositivo móvel). O problema é justamente localizar onde está a interrupção ou alternância de classificação de vias nos mais de 3000km da rota. Em 20 de julho de 2014 12:05, Fernando Trebien fernando.treb...@gmail.com escreveu: Contraction hierarquies permite usar Dijkstra bidirecional + alguma heurística otimista em ambientes com restrições de memória e capacidade computacional sem remover qualquer via do cálculo. Isso tá lá nos papers referenciados no final daquele artigo da Wikipédia que você apontou. Era a isso que eu me referia ao julgar a inteligência do algoritmo, e por ser um fato (o algoritmo foi publicado e nada impede que seja implementado), não tem como ser arrogante. É uma escolha simples (bem, não tão simples) que o desenvolvedor da aplicação tem que fazer. E é uma escolha que é independente do mapa (que, novamente, serve a vários propósitos, não só ao roteamento, não só ao roteamento em ambientes com capacidades limitadas). Mas interromper uma motorway com um trecho de residential vai quebrar o roteamento em muitas aplicações. Pode dar um exemplo de aplicação e local? Apesar de solicitar esse exemplo, não conheço nenhum caso em que uma motorway/trunk precisaria ter um trecho classificado como residencial. Na pior das hipóteses, teria um trecho classificado como terciária por estar não-pavimentada - mas acho que nem no Brasil essa situação ocorre. Recentemente eu achei um exemplo em que uma trunk se intercala com uma primária [1], mas isso também não deve afetar esses sistemas que descartam vias a que você se refere. E claro, no caso particular, raro, e bizarro de uma classificação fiel produzir uma situação assim, podemos pensar em discutir com a comunidade sobre o que fazer. A idéia de não alternar demais a classificação da via poderia ser aplicada ser for só um trecho curto com características diferentes, e o motivo não seria só o roteamento. [1] http://www.openstreetmap.org/#map=12/-29.5385/-51.8998 2014-07-20 10:47 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Em 19 de julho de 2014 22:29, Fernando Trebien fernando.treb...@gmail.com escreveu: Sabendo que há trabalhos cientificos publicados descrevendo bons algoritmos para esses ambientes e que não descartam quaisquer vias (mesmo as de classe bem inferior), acho que não devemos fazer adaptações no mapa em favor de algoritmos menos inteligentes. (Isso seria mapear para a aplicação.) Menos inteligentes Desculpa, Fernando, esse seu comentário foi um tanto arrogante. Quando você tem restrição de recursos de hardware em dispositivos móveis você TEM que fazer otimização. Isso para mim é sinal de extrema inteligência. E só uma palavra sobre artigos científicos: poucas vezes tratam-se de ideias praticáveis. O algoritmo Dijkstra é um exemplo. Ninguém usa a forma tal como publicada pelo Dijkstra originalmente. A indústria sempre faz várias melhorias para o mundo real. Sei disso porque trabalho nos dois mundos e também porque estou escrevendo um artigo e não estou pensando em problemas de ordem prática. A teoria já dá trabalho suficiente. Isso não é pecado, é como o progresso funciona: cada especialista em sua área. Mas, ao mesmo tempo, acho que são muito raros os casos em que adaptações seriam necessárias para evitar problemas com esses algoritmos que descartam vias. A menos que eles estejam descartando até as vias primárias (arteriais urbanas), daí não tem como resolver mesmo. Não são raros não. Você tem que pensar em para que a maioria dos usuários precisa de um mapa de ruas (Street Map): a) Encontrar um lugar (geocoding); b) Navegar até um lugar (roteamento); c) Quase sempre em trânsito, com dispositivos móveis. Se essas coisas não estão funcionando bem, elas procurarão alternativas e aí seu mapa será o mais puro do mundo mas vazio de propósito. Se queres que o mapa se torne popular, TEM que pensar nas questões de ordem prática. Acho que dá para conciliar os princípios do OSM com as questões práticas. Mas interromper uma motorway com um trecho de residential vai quebrar o roteamento em muitas aplicações. Não digo colocar tudo igual, mas não deixar as classes tão contrastantes conforme já exemplificado. []s Paulo 2014-07-19 17:56 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: E qual sua opinião sobre o descarte de vias de baixa prioridade nos roteamentos de longa distância em ambientes com baixa memória e processamento mais lento? Em 19 de julho de
Re: [Talk-br] A importância de não quebrar a hierarquia das vias dentro de cidades.
Acho razoável se basear na rota do OSRM pra elencar um ponto mais ou menos mais ou menos no meio 2014-07-20 15:16 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Uma sugestão para diminuir o espaço de busca: dividir para conquistar. Ao invés de calcular uma rota tão longa, tente calcular a rota até metade do caminho, e depois da metade até o destino. (Não precisa ser exatamente a metade, qualquer ponto mais ou menos no meio serve.) O problema vai estar no trecho em que esse teste falhar. Daí você pega o trecho problemático e repete: testa a primeira metade dele, depois a segunda metade. Cada vez que você repete você diminui o espaço de busca. São 3000km, dividindo por 2 a cada vez você provavelmente vai chegar à raiz exata do problema em menos de 20 tentativas. Como saber onde fica a metade? Acho razoável se basear na rota do OSRM pra elencar um ponto mais ou menos: http://osrm.at/8yC Um complicador é que pode ter mais de um problema ao longo de toda essa rota. Se os dois trechos falharem, você vai ter que testar os dois trechos separadamente, ao invés de eliminar um deles. E se forem muitos os problemas, pode precisar de papel e caneta pra lembrar de quais trechos você já testou. É bem provável que isso seja de fato um erro de classificação que precisa ser corrigido no OSM - não com o objetivo específico de fazer o Garmin funcionar, mas sim com o objetivo de deixar a classificação correta. Sim, aplicações mais simples podem ser usadas (e normalmente são uma forma excelente) para detectar problemas com os dados que não interferem tanto com as aplicações mais modernas. E nesse caso específico tanto a comunidade do OSM (agnóstica aos dispositivos) quanto os usuários de Garmin saem ganhando. 2014-07-20 12:47 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Temos um exemplo de um mapa Garmin que não está calculando uma rota entre o extremo sul do Brasil e um ponto no Ceará. A rota é calculada normalmente no Mapsource (computador) mas não no GPS (dipositivo móvel). O problema é justamente localizar onde está a interrupção ou alternância de classificação de vias nos mais de 3000km da rota. Em 20 de julho de 2014 12:05, Fernando Trebien fernando.treb...@gmail.com escreveu: Contraction hierarquies permite usar Dijkstra bidirecional + alguma heurística otimista em ambientes com restrições de memória e capacidade computacional sem remover qualquer via do cálculo. Isso tá lá nos papers referenciados no final daquele artigo da Wikipédia que você apontou. Era a isso que eu me referia ao julgar a inteligência do algoritmo, e por ser um fato (o algoritmo foi publicado e nada impede que seja implementado), não tem como ser arrogante. É uma escolha simples (bem, não tão simples) que o desenvolvedor da aplicação tem que fazer. E é uma escolha que é independente do mapa (que, novamente, serve a vários propósitos, não só ao roteamento, não só ao roteamento em ambientes com capacidades limitadas). Mas interromper uma motorway com um trecho de residential vai quebrar o roteamento em muitas aplicações. Pode dar um exemplo de aplicação e local? Apesar de solicitar esse exemplo, não conheço nenhum caso em que uma motorway/trunk precisaria ter um trecho classificado como residencial. Na pior das hipóteses, teria um trecho classificado como terciária por estar não-pavimentada - mas acho que nem no Brasil essa situação ocorre. Recentemente eu achei um exemplo em que uma trunk se intercala com uma primária [1], mas isso também não deve afetar esses sistemas que descartam vias a que você se refere. E claro, no caso particular, raro, e bizarro de uma classificação fiel produzir uma situação assim, podemos pensar em discutir com a comunidade sobre o que fazer. A idéia de não alternar demais a classificação da via poderia ser aplicada ser for só um trecho curto com características diferentes, e o motivo não seria só o roteamento. [1] http://www.openstreetmap.org/#map=12/-29.5385/-51.8998 2014-07-20 10:47 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Em 19 de julho de 2014 22:29, Fernando Trebien fernando.treb...@gmail.com escreveu: Sabendo que há trabalhos cientificos publicados descrevendo bons algoritmos para esses ambientes e que não descartam quaisquer vias (mesmo as de classe bem inferior), acho que não devemos fazer adaptações no mapa em favor de algoritmos menos inteligentes. (Isso seria mapear para a aplicação.) Menos inteligentes Desculpa, Fernando, esse seu comentário foi um tanto arrogante. Quando você tem restrição de recursos de hardware em dispositivos móveis você TEM que fazer otimização. Isso para mim é sinal de extrema inteligência. E só uma palavra sobre artigos científicos: poucas vezes tratam-se de ideias praticáveis. O algoritmo Dijkstra é um exemplo. Ninguém usa a forma tal como publicada pelo Dijkstra originalmente. A indústria sempre faz várias melhorias
Re: [Talk-br] A importância de não quebrar a hierarquia das vias dentro de cidades.
Pessoal, O Aun se ofereceu pra ajudar testando com a compilação da garmin.openstreetmap.nl e pediu pra eu passar alguns endereços (pra ficar fácil de testar). Vou postar alguém aqui também caso queiram testar com outras compilações. Cruzamentos (requisito do geocoding do Garmin): 1. Chuí, RS: Rua Chile X Rua Palestina 2. Osório, RS: Rua Garibaldi X Rua Melvin Jones 3. Joinville, SC: Rua Nazareno X Rua Benjamin Constant 4. Atibaia, SP: Rua Belvedere X Rua Presidente Dutra 5. Belo Horizonte, MG: Rua Tom Jobim X Fua Ferreira 6. Teófilo Otoni, MG: Rua Coronel Ramos X Rua Dom Felipe 7. Vitória da Conquista, BA: Rua Nova X Rua Deusdete Amaral 8. Feira de Santana, BA: Rua Brumado X Rua Juazeiro 9. Brejo Santo, CE: Rua Marcelino Costa X Rua Joaquim Nicodemos 10. Fortaleza, CE: Rua Pentecoste X Rua Costa Barros Procedimento sugerido pra economizar trabalho testando: - testar rota de [1] a [10]; se funcionar é porque há algum problema com a compilação do mapa que não há na compilação do osm.nl - testar [1] a [6]; se não funcionar, testar [1] a [2], [2] a [3], etc. - se funcionar, testar [6] a [10]; se não funcionar, testar [6] a [7], [7] a [8], etc. Se identificarem o trecho em que o roteamento falha, me avisem que eu mando o próximo conjunto de pontos (que então deve nos levar ao ponto exato do problema). Não mandei agora porque senão teria que sugerir 100 pontos. 2014-07-20 20:05 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Ok, entendido. Obrigado pelas sugestões. []s Paulo Em 20 de julho de 2014 15:17, Fernando Trebien fernando.treb...@gmail.com escreveu: Acho razoável se basear na rota do OSRM pra elencar um ponto mais ou menos mais ou menos no meio 2014-07-20 15:16 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Uma sugestão para diminuir o espaço de busca: dividir para conquistar. Ao invés de calcular uma rota tão longa, tente calcular a rota até metade do caminho, e depois da metade até o destino. (Não precisa ser exatamente a metade, qualquer ponto mais ou menos no meio serve.) O problema vai estar no trecho em que esse teste falhar. Daí você pega o trecho problemático e repete: testa a primeira metade dele, depois a segunda metade. Cada vez que você repete você diminui o espaço de busca. São 3000km, dividindo por 2 a cada vez você provavelmente vai chegar à raiz exata do problema em menos de 20 tentativas. Como saber onde fica a metade? Acho razoável se basear na rota do OSRM pra elencar um ponto mais ou menos: http://osrm.at/8yC Um complicador é que pode ter mais de um problema ao longo de toda essa rota. Se os dois trechos falharem, você vai ter que testar os dois trechos separadamente, ao invés de eliminar um deles. E se forem muitos os problemas, pode precisar de papel e caneta pra lembrar de quais trechos você já testou. É bem provável que isso seja de fato um erro de classificação que precisa ser corrigido no OSM - não com o objetivo específico de fazer o Garmin funcionar, mas sim com o objetivo de deixar a classificação correta. Sim, aplicações mais simples podem ser usadas (e normalmente são uma forma excelente) para detectar problemas com os dados que não interferem tanto com as aplicações mais modernas. E nesse caso específico tanto a comunidade do OSM (agnóstica aos dispositivos) quanto os usuários de Garmin saem ganhando. 2014-07-20 12:47 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Temos um exemplo de um mapa Garmin que não está calculando uma rota entre o extremo sul do Brasil e um ponto no Ceará. A rota é calculada normalmente no Mapsource (computador) mas não no GPS (dipositivo móvel). O problema é justamente localizar onde está a interrupção ou alternância de classificação de vias nos mais de 3000km da rota. Em 20 de julho de 2014 12:05, Fernando Trebien fernando.treb...@gmail.com escreveu: Contraction hierarquies permite usar Dijkstra bidirecional + alguma heurística otimista em ambientes com restrições de memória e capacidade computacional sem remover qualquer via do cálculo. Isso tá lá nos papers referenciados no final daquele artigo da Wikipédia que você apontou. Era a isso que eu me referia ao julgar a inteligência do algoritmo, e por ser um fato (o algoritmo foi publicado e nada impede que seja implementado), não tem como ser arrogante. É uma escolha simples (bem, não tão simples) que o desenvolvedor da aplicação tem que fazer. E é uma escolha que é independente do mapa (que, novamente, serve a vários propósitos, não só ao roteamento, não só ao roteamento em ambientes com capacidades limitadas). Mas interromper uma motorway com um trecho de residential vai quebrar o roteamento em muitas aplicações. Pode dar um exemplo de aplicação e local? Apesar de solicitar esse exemplo, não conheço nenhum caso em que uma motorway/trunk precisaria ter um trecho classificado como residencial. Na pior das hipóteses,
Re: [Talk-br] A importância de não quebrar a hierarquia das vias dentro de cidades.
*Rua Ferreira :P 2014-07-20 22:00 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Pessoal, O Aun se ofereceu pra ajudar testando com a compilação da garmin.openstreetmap.nl e pediu pra eu passar alguns endereços (pra ficar fácil de testar). Vou postar alguém aqui também caso queiram testar com outras compilações. Cruzamentos (requisito do geocoding do Garmin): 1. Chuí, RS: Rua Chile X Rua Palestina 2. Osório, RS: Rua Garibaldi X Rua Melvin Jones 3. Joinville, SC: Rua Nazareno X Rua Benjamin Constant 4. Atibaia, SP: Rua Belvedere X Rua Presidente Dutra 5. Belo Horizonte, MG: Rua Tom Jobim X Fua Ferreira 6. Teófilo Otoni, MG: Rua Coronel Ramos X Rua Dom Felipe 7. Vitória da Conquista, BA: Rua Nova X Rua Deusdete Amaral 8. Feira de Santana, BA: Rua Brumado X Rua Juazeiro 9. Brejo Santo, CE: Rua Marcelino Costa X Rua Joaquim Nicodemos 10. Fortaleza, CE: Rua Pentecoste X Rua Costa Barros Procedimento sugerido pra economizar trabalho testando: - testar rota de [1] a [10]; se funcionar é porque há algum problema com a compilação do mapa que não há na compilação do osm.nl - testar [1] a [6]; se não funcionar, testar [1] a [2], [2] a [3], etc. - se funcionar, testar [6] a [10]; se não funcionar, testar [6] a [7], [7] a [8], etc. Se identificarem o trecho em que o roteamento falha, me avisem que eu mando o próximo conjunto de pontos (que então deve nos levar ao ponto exato do problema). Não mandei agora porque senão teria que sugerir 100 pontos. 2014-07-20 20:05 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Ok, entendido. Obrigado pelas sugestões. []s Paulo Em 20 de julho de 2014 15:17, Fernando Trebien fernando.treb...@gmail.com escreveu: Acho razoável se basear na rota do OSRM pra elencar um ponto mais ou menos mais ou menos no meio 2014-07-20 15:16 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Uma sugestão para diminuir o espaço de busca: dividir para conquistar. Ao invés de calcular uma rota tão longa, tente calcular a rota até metade do caminho, e depois da metade até o destino. (Não precisa ser exatamente a metade, qualquer ponto mais ou menos no meio serve.) O problema vai estar no trecho em que esse teste falhar. Daí você pega o trecho problemático e repete: testa a primeira metade dele, depois a segunda metade. Cada vez que você repete você diminui o espaço de busca. São 3000km, dividindo por 2 a cada vez você provavelmente vai chegar à raiz exata do problema em menos de 20 tentativas. Como saber onde fica a metade? Acho razoável se basear na rota do OSRM pra elencar um ponto mais ou menos: http://osrm.at/8yC Um complicador é que pode ter mais de um problema ao longo de toda essa rota. Se os dois trechos falharem, você vai ter que testar os dois trechos separadamente, ao invés de eliminar um deles. E se forem muitos os problemas, pode precisar de papel e caneta pra lembrar de quais trechos você já testou. É bem provável que isso seja de fato um erro de classificação que precisa ser corrigido no OSM - não com o objetivo específico de fazer o Garmin funcionar, mas sim com o objetivo de deixar a classificação correta. Sim, aplicações mais simples podem ser usadas (e normalmente são uma forma excelente) para detectar problemas com os dados que não interferem tanto com as aplicações mais modernas. E nesse caso específico tanto a comunidade do OSM (agnóstica aos dispositivos) quanto os usuários de Garmin saem ganhando. 2014-07-20 12:47 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Temos um exemplo de um mapa Garmin que não está calculando uma rota entre o extremo sul do Brasil e um ponto no Ceará. A rota é calculada normalmente no Mapsource (computador) mas não no GPS (dipositivo móvel). O problema é justamente localizar onde está a interrupção ou alternância de classificação de vias nos mais de 3000km da rota. Em 20 de julho de 2014 12:05, Fernando Trebien fernando.treb...@gmail.com escreveu: Contraction hierarquies permite usar Dijkstra bidirecional + alguma heurística otimista em ambientes com restrições de memória e capacidade computacional sem remover qualquer via do cálculo. Isso tá lá nos papers referenciados no final daquele artigo da Wikipédia que você apontou. Era a isso que eu me referia ao julgar a inteligência do algoritmo, e por ser um fato (o algoritmo foi publicado e nada impede que seja implementado), não tem como ser arrogante. É uma escolha simples (bem, não tão simples) que o desenvolvedor da aplicação tem que fazer. E é uma escolha que é independente do mapa (que, novamente, serve a vários propósitos, não só ao roteamento, não só ao roteamento em ambientes com capacidades limitadas). Mas interromper uma motorway com um trecho de residential vai quebrar o roteamento em muitas aplicações. Pode dar um exemplo de aplicação e local? Apesar de solicitar esse exemplo, não conheço nenhum
Re: [Talk-de] Grillfleisch-Automat
vending=food food:bbq=yes Ich grabe das hier noch einmal aus. Was haltet ihr davon bei Essen Trinken erst eine grobe Gliederung zu machen z.B. nach diese Liste wie hier https://de.wikipedia.org/wiki/Lebensmittel#Lebensmittelgruppen Dann wäre es vending=meat + food:bbq=yes. Dadurch würde man die vending= tags in Grenzen halten, aber könnte schon einmal grob sehen, ob es an einem Automaten Gemüse oder Snacks gibt. __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Place-nodes von Großgemeinden wurden gelöscht
Am 20. Juli 2014 01:32 schrieb Andreas Goss andi...@t-online.de: ich denke, dass Großgemeinden keinen place-node bekommen sollten. place=* beschreibt eine Ansiedlung bestimmter Größe. Eine Großgemeinde ist ein administrativer Zusammenschluss mehrerer solcher Ansiedlungen. Das ist dann eine Sache für boundary-Relationen. Mit der Logik müsste man dann auch Bayern usw. rausnehmen http://www.openstreetmap.org/node/473848012 Nein, place=state ist ja definiert für A high-level sub-national political entity. Der Bayern-Node hat also keine falschen Attribute. Redundant ist das ganze natürlich schon. Tirkon scheint es aber wohl eher um Gemeinden zu gehen, die keine entsprechende Siedlung haben, wie z.B. Krummhörn http://www.openstreetmap.org/node/240114463 die aber trotzdem mit place=town in der Pampa getaggt sind. Das ist aber falsch, da place=village/town/city/hamlet nur für Siedlungen benutzt werden soll. http://wiki.openstreetmap.org/wiki/DE:Key:place Ich habe ja schon im Ursprungsposting gesagt, dass ich mich dieser Argumentation nicht entziehe. Wie aber bekommen wir dann die Diskrepanz aus der osm.org Karte, dass der Name von Kleinstgemeinden gerendert wird aber diejenige von Großgemeinden nicht und somit die Orientierung erschwert bis verunmöglicht? Es gibt role=label http://wiki.openstreetmap.org/wiki/Relation:boundary was im Moment aber nicht wirklich unterstützt bzw. wohl nur zusammen mit place nodes? Man bräuchte dann wohl etwas wie place=label oder label=yes Von dem rauslöschen halte ich nichts. Derjenige sollte sich vorher erst einmal um einer alternative Lösung kümmern, zumal es eben das gängige tagging ist. Wenn man den Node erhalten will dann aber bitte richtig taggen mit place=municipality, das stört dann auch keine Auswerter (man stelle sich vor ich frage alle Städte ab mit place=town und bekomme dann auch Großgemeinden etc. ausgegeben). Auf github findet man schon ein issue zum Thema Rendering von boundary=administrative: https://github.com/gravitystorm/openstreetmap-carto/issues/104 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Place-nodes von Großgemeinden wurden gelöscht
Archer arc...@gulli.com wrote: Wenn man den Node erhalten will dann aber bitte richtig taggen mit place=municipality, das stört dann auch keine Auswerter (man stelle sich vor ich frage alle Städte ab mit place=town und bekomme dann auch Großgemeinden etc. ausgegeben). Es geht hier nicht um den bedingungslosen Erhalt von Nodes, sondern um ein sinnvolles Tagging, das auch von osm.org nachvollzogen wird, so dass die Karte eine Grundorientierung über die gerenderten Namen der Kommunen bietet. Ich bin ja gerade dabei, den Komplex Gemeinden zu klären. Ich habe auch place=municipality probiert. Die auf diesen Wert gesetzten Orte werden aber in keiner Zoomstufe auf osm.org gerendert und es gibt ihn bisher in Deutschland nur 30 Mal. Daher habe ich dies schon in einem früheren Thread thematisiert, ohne dass sich jemand place=municipality für Gemeinden angeschlossen hätte. place=village fand man nur angemessen, wenn es sich um ein bescheidenes Dorf handelt, von denen solche Gemeinden zehn bis zwanzig haben. town ist also zu groß und village zu klein. Letztendlich wird letztzeres aber das unbefriedigende Mittel der Wahl sein müssen, solange boundary-Relationen nicht funktionieren und die Diskussion keine andere funktionierende Möglichkeit aufzeigt. Krummhörn ... place=town Am Beispiel von Krummhörn kann man sehen, dass ein höherwertiges Value ein für die Orientierung wesentlich besseres Rendering hervorbringt. (Den Sandkasten für solche Beispiele haben wir nicht.) Wenn sich place=municipality im Unterschied zu place=village (für Dörfer) als ein zu place=town analoges Tag für Großgemeinden erweisen und zudem auch auf osm.org gerendert würde, wäre das tatsächlich eine gute Lösung. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Place-nodes von Großgemeinden wurden gelöscht
Am 20/lug/2014 um 00:27 schrieb Tirkon tirko...@yahoo.de: Was also tun? Die place-nodes wieder einfügen? auf die Gefahr, mich zu wiederholen: Großgemeinden gehören für mich nach Admin und nicht nach place. Wie und ob das gerendert wird regelt der entsp. Style-maintainer /-Entwickler Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Place-nodes von Großgemeinden wurden gelöscht
Am 20/lug/2014 um 01:05 schrieb Henning Scholland o...@aighes.de: place=* beschreibt eine Ansiedlung bestimmter Größe. auch nicht ganz, place wird auch noch für anderes wie Inseln verwendet (leider, weil ohne Logik ist das System prinzipiell schwächer und schwieriger zu lernen und zu erweitern) Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Place-nodes von Großgemeinden wurden gelöscht
Am 20/lug/2014 um 01:15 schrieb Tirkon tirko...@yahoo.de: dass der Name von Kleinstgemeinden gerendert wird aber diejenige von Großgemeinden nicht und somit die Orientierung erschwert bis verunmöglicht? Gemeinde trifft es nicht, wenn es place ist, vermutlich werden Ansiedlungen gleichen Namens gerendert, und das kann ggf. fehlinterpretiert werden. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Place-nodes von Großgemeinden wurden gelöscht
Am 20/lug/2014 um 11:54 schrieb Archer arc...@gulli.com: Nein, place=state ist ja definiert für A high-level sub-national political entity. Der Bayern-Node hat also keine falschen Attribute. Redundant ist das ganze natürlich schon. Das ist ganz simples taggen für den Renderer (Label-dropping) aus der Anfangszeit, als wir noch keine Grenzen hatten, bzw. als Fall-forward weil die Grenzen unzuverlässig sind Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Place-nodes von Großgemeinden wurden gelöscht
Martin Koppenhoefer dieterdre...@gmail.com wrote: Am 20/lug/2014 um 00:27 schrieb Tirkon tirko...@yahoo.de: Was also tun? Die place-nodes wieder einfügen? auf die Gefahr, mich zu wiederholen: Großgemeinden gehören für mich nach Admin und nicht nach place. Wie und ob das gerendert wird regelt der entsp. Style-maintainer /-Entwickler Ich habe schon gesagt, dass ich es vom Datenmodell als die richtigere Lösung betrachte. Zudem heißt es auch: Wir taggen nicht für den Renderer (die Anwendungen). In dieser kompromisslosen Form halte ich den Satz für falsch. Wenn es keinen Renderer, keine Navigationsprogramm oder anderen Geo-Anwendungen gäbe, dann hätten wir auch kein OSM. Die Datenbank ist also schon Mittel zum Zweck. Und an diesem Punkt hakt mein energischer Widerspruch ein. Wenn es nach 10 Jahren OSM keine osm.org-Karte gibt, auf der sich Mapper anhand von Ortsnamen vernünftig orientieren können, dann läuft etwas quer. Wenn es den am Rendern der Karte beteiligten Personen nicht möglich ist, die places in eine orientiertaugliche Form zu bringen, dann hat es keinen Zweck ein neues Fass mit der nächsten Stufe der Datenevolution aufzumachen und das korrekte Verarbeiten der boundary Relationen vorauszusetzen. Es gibt aber noch einen weiteren Grund für den Widerspruch: Es muss einem Mapper möglich sein, seinen Freunden nach zehn Jahren OSM eine ordentliche Karte des von ihm gemappten Gebietes vorzuzeigen. Wenn dann eine Basisfunktion wie das Anzeigen der größten Orte insbesondere auf dem Land (dort wo wir noch Mapper nötig haben) nach zehn Jahren immer noch nicht funktioniert, wird das sicherlich seine Begeisterung nicht in die Höhe schnellen lassen. Im Gegenteil ist es ein guter Weg, zu frusten und um die weitere Mitarbeit zu vermiesen. Denn jede andere Karte im Web kann das besser - und diejenigen auf Papier sogar schon ein paar Jahrhunderte. Ergo sollten die Eigenschaften der Datenbank mit den Fähigkeiten der Anwendungen wachsen und auf Symbiose ausgerichtet sein. Eine Optimierung der Datenstruktur hat keinen Sinn, solange die Anwendungen nicht einmal die Vorstufe davon im Griff haben. Aus einer Antwort von Andy Allen auf eine entsprechende Frage auf dem seinem Workshop der SOTM-EU ging hervor, dass man zur Zeit nur die places auf dem Schirm hat. Also lasst den Kollegen von der osm.org-Karte die Zeit, um places ordentlich zu rendern. Die Bevölkerungszahlen und die Hauptstadt Angaben im capital-key der Kommunen könnten dabei hilfreich sein. Mit derselben Begründung wie bei den Landgemeinden könnte man auch das Löschen von Großstadtteil-places begründen. Denn hier handelt es sich nicht um baulich geschlossene Siedlungen, sondern aus dieser Sicht um willkürliche Unterteilungen eine geschlossenen Baumasse. Im Ruhrgebiet gilt das sogar für ganze Städte. Ich frage mich, was passiert, wenn deren places verschwinden und folglich die Namen auf osm.org und vielen anderen Karten nicht mehr gerendert werden. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Place-nodes von Großgemeinden wurden gelöscht
2014-07-20 11:54 GMT+02:00 Archer arc...@gulli.com Am 20. Juli 2014 01:32 schrieb Andreas Goss andi...@t-online.de: ich denke, dass Großgemeinden keinen place-node bekommen sollten. place=* beschreibt eine Ansiedlung bestimmter Größe. Eine Großgemeinde ist ein administrativer Zusammenschluss mehrerer solcher Ansiedlungen. Das ist dann eine Sache für boundary-Relationen. Mit der Logik müsste man dann auch Bayern usw. rausnehmen http://www.openstreetmap.org/node/473848012 Nein, place=state ist ja definiert für A high-level sub-national political entity. Der Bayern-Node hat also keine falschen Attribute. Redundant ist das ganze natürlich schon. Tirkon scheint es aber wohl eher um Gemeinden zu gehen, die keine entsprechende Siedlung haben, wie z.B. Krummhörn http://www.openstreetmap.org/node/240114463 die aber trotzdem mit place=town in der Pampa getaggt sind. Das ist aber falsch, da place=village/town/city/hamlet nur für Siedlungen benutzt werden soll. Und wer sagt, dass eine Pampa nicht ein Teil einer Siedlung sein kann? ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Place-nodes von Großgemeinden wurden gelöscht
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In der Tat hast du Recht. Ich habe nur an die Tags gedacht, die ich so verwende und das sind nur die Ansiedlungen. Der Rest ist für mich schon länger nicht mehr sinnvoll. Henning Am 20.07.2014 14:13, schrieb Martin Koppenhoefer: Am 20/lug/2014 um 01:05 schrieb Henning Scholland o...@aighes.de: place=* beschreibt eine Ansiedlung bestimmter Größe. auch nicht ganz, place wird auch noch für anderes wie Inseln verwendet (leider, weil ohne Logik ist das System prinzipiell schwächer und schwieriger zu lernen und zu erweitern) Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTy9ZnAAoJEKXggIeC16WPEM4IAKDxUl0POf+xZ1BrQP7cqzP6 KvReL5vjiZlF8JDzeV7gmwlWd1K7J67ACHBkWasAC8v2dUc65t/NUmsLhZzuUSdK uzgzp5LlG6K6Shz1RxZ966m/2Ta7/UfFdUpSH1hHLW84d5DIrxpRPcDV+ZgyEHbr KzslM8blBvIgQgG40nibRzOnxWdH0qwYqyAi1TH1EccO2kaKVXGURMdWUSSOYBAR W4CCjDNrPT4H36QdhmcOg5tObGgIoup8bWVhZ46xL7a9scw4SXC99KUf8AURhH9R sJL6Rsgq03S4YXoeweqfkCxdg9H4ZgbuKljms2PaQAO1eaqfvg5yH+92xMH/lVw= =6xnn -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Place-nodes von Großgemeinden wurden gelöscht
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo, das mit dem Renderer ist ein Henne-Ei-Problem. Wenn die Daten keine Änderung erfordern, warum sollte der Renderer dann besser werden. Solange die ganzen Nodes mit dem Namen in den Daten sind wird der Renderer einen Teufel tun und sich die Namen aufwändig suchen. Ich stimme dir aber auch zu, dass es Kontraproduktiv sein kann, wenn man den Renderer vor vollendete Tatsachen stellt und ihm die Nodes weg löscht. Im Prinzip müsste es eine deadline geben ala: Renderer, wir haben uns entschieden, in Deutschland die überflüssigen place-nodes zu entfernen, bitte nutze doch die labels aus den Grenzrelationen. Am besten noch mit einem Zeitrahmen. Henning -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTy9g0AAoJEKXggIeC16WP0E4IAMBkOq7qHLG2tKhxEL5naPKc oXcEDVDEsfnnfg+3sFps5wgxeMmb20af1GRI7AGxb31Um1v/0kNL6Dh1ShbdjpKX ICeLDepV7sEuOhGsFPFFO5+IeM1dpOf4WGC28mVmJ5CgN8WF0Luz0T/WagMrwty+ zJSzYmKvoLSjaJnnrhNDCjOUhXkauLS3/bNXh2QDzCKcVpoHE0jPIRy2rSSHyuDQ JpqWyxDHsUalKyev37zseaII+WlyJVagFlTba7ihcRBeFtDo5T5geEljp+HcUhcD /qYqVsW361lGbQrqfFbtsmVOQXoCsSOpDo+wU7B9Xq/bD3CH0g/r1cLdXxVSgsM= =LodR -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Place-nodes von Großgemeinden wurden gelöscht
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo, kannst du dafür ein Beispiel bringen? Die angesprochen place-Tags beschreiben eine mehr oder weniger zusammenhängende Siedlungsfläche. 10 Siedlungsflächen jeweils im Abstand mehrerer Kilometer, die zwar administrativ zusammengefasst sind, sind noch lange keine zusammenhängende Siedlungsfläche. Henning Am 20.07.2014 16:41, schrieb Butrus Damaskus: Und wer sagt, dass eine Pampa nicht ein Teil einer Siedlung sein kann? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTy9lyAAoJEKXggIeC16WPcMUH/10lLJh+kLZRKDkP1R+rmWFH HLtT7U9QSVm3dil3xh0kC4rWmlpOCpjb5GtuFNCRSHDJAIlTjA0wBSRIYYjpHFwa K7Q6sB8b/YRLi+hvAKPJHnhRSdDhwMAhup6BUP0jja5cXhWzHpyXQjbICP3RJWPw +eRUXFpUt+5dPN++KbZ1qG8DP5YHt8ZL+hFkWHzpW8xaPShMWk2I3i0PmX23eij7 yAookbWh3VbiAzFQndO2MsqHiEkaqVnQSP+yeff3DtuqzUeD3LCLGy9vwIURy1Yd yGWjvRtm0fxUINxv9xn186fZ8euALCSmypEM2Ob2c5nI6mxnucTaVsmSDM58dmM= =l4DO -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eine politisch korrektere Version des deutschen Kartenstils
Max Berger m...@dianacht.de wrote: Ausserdem müsste man eine Schriftart finden, die alle möglichen exotischen Schriften und lateinische Buchstaben schön darstellt... Die Betonung liegt auf eine, weil man ja dann in einem Label Lateinische schrift _und_ irgendwas anderes hätte. Gruss Sven -- Whenever there is a conflict between human rights and property rights, human rights must prevail. (Abraham Lincoln) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Place-nodes von Großgemeinden wurden gelöscht
Henning Scholland o...@aighes.de wrote: Ich stimme dir aber auch zu, dass es Kontraproduktiv sein kann, wenn man den Renderer vor vollendete Tatsachen stellt und ihm die Nodes weg löscht. Im Prinzip müsste es eine deadline geben ala: Renderer, wir haben uns entschieden, in Deutschland die überflüssigen place-nodes zu entfernen, bitte nutze doch die labels aus den Grenzrelationen. Am besten noch mit einem Zeitrahmen. Für die Sache eines orientierungsfördernden Renderns wäre das natürlich der beste Weg. Die Suche nach Bezeichnungen wie bei den Places für verschiedene Levels wäre obsolet. Im Admin Level findet alles seine Berücksichtung, z.B. kreisfreie Städte. Man könnte Kommunen, die Staats-, Landeshaupt-, Kreisstädte darstellen bzw. Stadtteile mit Rathausstandort (capital=yes), bei Konkurrenz im gleichen Admin Level immer verdrängend rendern und mit einem Sternchen versehen. Ansonsten geht es innerhalb des Admin Level nach Bevölkerungszahl. Es könnten auch beim Hereinzoomen die jetzt gähnend leeren ländlichen Gebiete mit Ortsnamen gefüllt werden. Wenn nach dem Abarbeiten eines Admin Levels noch Platz ist, nimmmt man eben den nächsten. Möglicherweise veröffentlicht man das Ergebnis auch als Dump. Ob das harte Vorgehen OSM-DB vs OSM-Renderer aus Community-Sicht so sinnvoll ist, ist da schon fraglicher. Wir wollen ja auch dort nicht demotivieren - zumal Andy Allen hier auf der SOTM-EU um Hilfe gebeten hat, nachdem ich das bevorzugte Rendern großer Kommunen thematisiert hatte. Möglicherweise wäre eine dringende Bitte ohne Termin im Vorfeld da günstiger. So wie Du es formulierst, soll sich dieses Anliegen von den üblichen Feature Requests abheben. Die Frage bleibt, wer mit der offiziellen Mitteilung/Bitte an die Renderer Commmunity von OSM Carto herantritt - die Data Working Group? ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Place-nodes von Großgemeinden wurden gelöscht
Am 20.07.2014 18:27, schrieb Tirkon: Henning Scholland o...@aighes.de wrote: Ich stimme dir aber auch zu, dass es Kontraproduktiv sein kann, wenn man den Renderer vor vollendete Tatsachen stellt und ihm die Nodes weg löscht. Im Prinzip müsste es eine deadline geben ala: Renderer, wir haben uns entschieden, in Deutschland die überflüssigen place-nodes zu entfernen, bitte nutze doch die labels aus den Grenzrelationen. Am besten noch mit einem Zeitrahmen. Für die Sache eines orientierungsfördernden Renderns wäre das natürlich der beste Weg. Die Suche nach Bezeichnungen wie bei den Places für verschiedene Levels wäre obsolet. Im Admin Level findet alles seine Berücksichtung, z.B. kreisfreie Städte. Man könnte Kommunen, die Staats-, Landeshaupt-, Kreisstädte darstellen bzw. Stadtteile mit Rathausstandort (capital=yes), bei Konkurrenz im gleichen Admin Level immer verdrängend rendern und mit einem Sternchen versehen. Ansonsten geht es innerhalb des Admin Level nach Bevölkerungszahl. Es könnten auch beim Hereinzoomen die jetzt gähnend leeren ländlichen Gebiete mit Ortsnamen gefüllt werden. Wenn nach dem Abarbeiten eines Admin Levels noch Platz ist, nimmmt man eben den nächsten. Möglicherweise veröffentlicht man das Ergebnis auch als Dump. Ob das harte Vorgehen OSM-DB vs OSM-Renderer aus Community-Sicht so sinnvoll ist, ist da schon fraglicher. Wir wollen ja auch dort nicht demotivieren - zumal Andy Allen hier auf der SOTM-EU um Hilfe gebeten hat, nachdem ich das bevorzugte Rendern großer Kommunen thematisiert hatte. Möglicherweise wäre eine dringende Bitte ohne Termin im Vorfeld da günstiger. So wie Du es formulierst, soll sich dieses Anliegen von den üblichen Feature Requests abheben. Die Frage bleibt, wer mit der offiziellen Mitteilung/Bitte an die Renderer Commmunity von OSM Carto herantritt - die Data Working Group? Zumal ja auch darüber diskutiert wird, welchen Zweck diese offizielle Kartendarstellung hat. Vorsicht mit capital=yes: 1. Weder Standort der Legislative noch der der Exekutive muss Capital sein. 2. entweder hier oder auf tagging@ oder talk@ würde der capital=* tag vor kurzem diskutiert. Ergebnis waren die zusätzliche Rolle capital für den entsprechenden place Punkt, wenn dieser place nicht auch einziger admin_centre ist. Persönlich habe ich mit dem aktuellen Rendern schon meine Schwierigkeiten beider zu schwachen Unterscheidung im kleinsten Abschnitt (hamlet,isolated_dwelling,locality) und das der Renderer nur Punkte mit place=* ordentlich darstellt nicht aber Polygone. Ich finde auch immer wieder Täler als Ortsnamen oft unterhalb von village aber eben nicht zusammenhängende Ortschaft (hamlet). Wie tagge ich das korrekt ? place=valley ? cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Place-nodes von Großgemeinden wurden gelöscht
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo, nein, es soll lediglich ein allgemeiner Hinweis an die Auswerter von (in diesem Fall der deutschen) Comunity sein, dass sich XYZ ändern wird. Jedem Renderer steht es frei die Daten so zu nutzen, wie der Maintainer es für richtig hält. Es steht natürlich jedem frei einen Patch für seinen Lieblingsrenderer zu schreiben ;) Es kann aber auch nicht sein, dass im Datenmodell Krücken gebaut werden, damit die Karte so aussieht, wie man es gerne hätte. Ankündigungen ohne Termin sind wertlos. Da fangen dann die eifrigen Mapper gleich an und die Renderer denken, kann ich auch im nächsten Winter machen. Da ist dann nichts gewonnen. Den aktuellen Stand, dass wir ewigalte Tagging Schemas mitschleppen müssen und quasi alles kompatibel sein muss ist jedenfalls eine Situation, die wir uns nicht mehr allzu lange leisten können. Oder das Chaos aus neuen Schema und altem Ballast lähmt alles. Henning Am 20.07.2014 18:27, schrieb Tirkon: Ob das harte Vorgehen OSM-DB vs OSM-Renderer aus Community-Sicht so sinnvoll ist, ist da schon fraglicher. Wir wollen ja auch dort nicht demotivieren - zumal Andy Allen hier auf der SOTM-EU um Hilfe gebeten hat, nachdem ich das bevorzugte Rendern großer Kommunen thematisiert hatte. Möglicherweise wäre eine dringende Bitte ohne Termin im Vorfeld da günstiger. So wie Du es formulierst, soll sich dieses Anliegen von den üblichen Feature Requests abheben. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTzDCjAAoJEKXggIeC16WPdDAH/3n3DWmu0PQ8J1KusKlY4PJj x+Wao5rptkMmZUdyVgl9AkmfrEN0F2epYSua/OY1O+P6muVpukcVBxFzzP7rmgFJ 5h0+hPdq8cTQL76UrNeD3usd+CcEc9Vkw5CSpfUCuvTywXO1xSsRHUjCvuBgye/B wSwfikg1lRTowr2zuJw2Jp8QfBlRvPmo44bENOIkkTRln5eMqNDSmXzIX6gUQ38u Cxr1hivmJ615A16Kjdqe3TNHTq60YxcSnfP1FNZGcFIegYwgYTuIfSNmPhbPWhZV yeaubIBprVQef+tsKYovK9IGoYCQ3oPTOL94+IUmpGb3Abp+evHL4IZbl5/Erck= =pgRS -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Place-nodes von Großgemeinden wurden gelöscht
Am 20/lug/2014 um 22:40 schrieb fly lowfligh...@googlemail.com: place=valley ? klingt vernünftig, wo taggst Du das dran? Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Place-nodes von Großgemeinden wurden gelöscht
Am 21.07.2014 00:58, schrieb Martin Koppenhoefer: Am 20/lug/2014 um 22:40 schrieb fly lowfligh...@googlemail.com: place=valley ? klingt vernünftig, wo taggst Du das dran? Bisher nur an Punkte, da ich sowas nicht so einfach als Flächen einzeichnen läßt und wohl eher subjektiv ist. Allerdings bin ich damit nicht zu frieden, da es ja eher auch Dorfteile bzw Quartiere sind, allerdings eben nicht zusammenhängend. Heute haben die einzelnen Höfe halt Hausnummern und eine zugeordnete Straße, früher waren die Täler auch Teil der Adresse. Nur auf die Topologie bezogen ist wohl eher natural=valley angesagt. Wobei bei island ja auch beides existiert. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] Aiuto:lettera da inviare a comune siciliano per l'apertura dei dati
Ciao Aury, 2014-07-19 16:32 GMT+02:00 Aury88 [via GIS] ml-node+s19327n5812022...@n5.nabble.com: Volevo chiedere se disponete dei file in formato originale delle mappe presenti sul sito del Comune di Gela che possano essere importati su OSM così da migliorarne l'attuale livello di mappatura e permetterne una migliore e più completa fruizione. questa è l'unica frase che mi stona un po'. Te ne scrivo un'alternativa, ma non mi piace nemmeno la mia *Le cartografie che avete prodotto per il Comune di Gela arricchirebbero molto la mappa di OSM e vorrei importale in questa. Vi chiedo quindi di fornirmi i file cartografici originali e di autorizzarmi a realizzare questo processo.* Poi valuterei di mettere uno screenshot di un luogo italiano dove si veda quanto sia ricca e bella una base OSM; e magari per confronto uno del territorio di Gela. E anche un paio di link a qualcosa di significativo. Non darei per scontato che nessuno faccia click su un URL e che non sappiano leggere un'immagine allegata. In ultimo, scriverei di una disponibilità ad un incontro. Non so se verrai in Sicilia d'estate ma, se la cosa procede, un incontro fisico è forse la cosa migliore per chiudere la faccenda con la soddisfazione di tutte le parti. Buona domenica, a -- Andrea Borruso website: http://blog.spaziogis.it GEO+ geomatica in Italia http://bit.ly/GEOplus http://bit.ly/GEOplus 38° 7' 48 N, 13° 21' 9 E, EPSG:4326 -- cercare e saper riconoscere chi e cosa, in mezzo all’inferno, non è inferno, e farlo durare, e dargli spazio Italo Calvino - Andrea Borruso email: aborr...@tin.it website: http://blog.spaziogis.it my 2.0 life: http://aborruso.spaziogis.it feed: http://feeds2.feedburner.com/Tanto 38° 7' 48 N, 13° 21' 9 E -- View this message in context: http://gis.19327.n5.nabble.com/Re-Aiuto-lettera-da-inviare-a-comune-siciliano-per-l-apertura-dei-dati-tp5812082.html Sent from the Italy General mailing list archive at Nabble.com.___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Aiuto:lettera da inviare a comune siciliano per l'apertura dei dati
aborruso wrote In ultimo, scriverei di una disponibilità ad un incontro. Non so se verrai in Sicilia d'estate ma, se la cosa procede, un incontro fisico è forse la cosa migliore per chiudere la faccenda con la soddisfazione di tutte le parti. Ciao Andrea Purtroppo al momento escludo tornerò in sicilia entro fine anno; considera anche che di solito torno nel periodi vacanzieri quindi quando gli uffici o sono chiusi o lavorano a regime ridotto. Per quanto riguarda l'immagine o il link di un luogo ben mappato penso che l'esempio migliore da mostrare per far vedere le potenzialità della mappa potrebbe essere proprio Gela...in particolare la zona da me mappata di persona lo scorso natale e quindi coperta anche con la numerazione civica (anche se è un area molto piccola[1]) altrimenti una città che possa essere d'esempio per la condivisione dei dati e quindi con edifici e numerazione civica frutto di import da db della PA (per esempio Pavia ma se fosse un posto Sicilia sarebbe ancora meglio). Vedo come posso modificare quella frase. [1]http://www.openstreetmap.org/#map=18/37.07420/14.22555 - Ciao, Aury -- View this message in context: http://gis.19327.n5.nabble.com/Re-Aiuto-lettera-da-inviare-a-comune-siciliano-per-l-apertura-dei-dati-tp5812082p5812099.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Civici Ferrara: importabile?
2014-07-20 16:36 GMT+02:00 Stefano Droghetti stefano.droghe...@gmail.com: Il Comune di Ferrara ha pubblicato qui l'elenco dei civici: http://www.comune.fe.it/index.phtml?id=3513 La licenza è IODL 2.0, come potete vedere. la licenza è compatibile con OSM, ora bisogna guardare i dati, se sono buoni. -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Civici Ferrara: importabile?
2014-07-20 17:19 GMT+02:00 Stefano Droghetti stefano.droghe...@gmail.com: la licenza è compatibile con OSM, ora bisogna guardare i dati, se sono buoni. Dice che sono georeferenziati, ma nel file CSV io vedo solo un elenco di vie con rispettivi civici. :-( Voi ci vedete qualcos'altro? Perché c'è scritto georeferenziati? hai ragione, non ci sono coordinate. indago... -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Civici Ferrara: importabile?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Il 20/07/2014 17:26, Simone Cortesi ha scritto: 2014-07-20 17:19 GMT+02:00 Stefano Droghetti stefano.droghe...@gmail.com: la licenza è compatibile con OSM, ora bisogna guardare i dati, se sono buoni. Dice che sono georeferenziati, ma nel file CSV io vedo solo un elenco di vie con rispettivi civici. :-( Voi ci vedete qualcos'altro? Perché c'è scritto georeferenziati? hai ragione, non ci sono coordinate. indago... Però ci sono le vie... :D - -- Simone Girardelli -BEGIN PGP SIGNATURE- Version: GnuPG v1 iF4EAREIAAYFAlPL4AsACgkQoVS0hKoD3PO0IwD/a6bO4zEnItVAAe55TDIYTY3y pPJ5K5nPDJQFKCi6ImIA+QGQjiOHeACwWxQAYc8Bfe7tFJVRkPAbCwtY6cuIL7Vc =Va30 -END PGP SIGNATURE- ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-ro] sorein
Pe 15.07.2014 03:29, Serge Wroclawski emac...@gmail.com a scris: Dear Romanian Community, I appologize in advance if this mail sounds strange. I do not speak Romanian and I am using a translation program to translate this email (the original is at the bottom of this mail). After a long deliberation, the Data Working Group has decided to place an indefinite block on user sorein: http://www.openstreetmap.org/user_blocks/493 The full explanation for this ban is located on the ban message, so I will not repeat what we have written there. Hi Serge, I have read the full document, I understand your difficulty and appreciate not taking lightly such matters. This is not something that the DWG takes lightly, but we felt it was necessary in this case. If anyone has any questions about this, you can ask me in this thread, or ask d...@osmfoundation.org I have no question regarding this, just some comments. 1. I myself am disappointed that Sorin's behavior has forced you to take this decision. 2. I have had my share of contributions to the map around year 2009 and back then there was a group of active mappers who tried to make some decisions to have unified conventions for the entire Romanian map. The discussions involved whoever wanted to participate, but Sorin was not involved initially on the discussions (he was either not interested in joining the list, the discussion or was not aware). After the participating members made proposals, debated them, took a vote and started applying them, Sorin reverted all such changes in the Iasi area and other areas. 3. He has a history of having good intentions but only accepting responses which match his own opinion 100%. 4. Some of his technical points merit some open, respectful and friendly discussions in the community. 5. Thank you Thank you, Serge on behalf of the DWG Original Message ___ Talk-ro mailing list Talk-ro@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ro ___ Talk-ro mailing list Talk-ro@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ro
[Talk-ca] OpenStreetMap Foundation Corporate Members
Since February 2014 your company can support OpenStreetMap Foundation with a corporate membership. The first corporate members were announced today. https://blog.openstreetmap.org/2014/07/20/welcome-corporate-members/ ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
[Talk-cz] LPIS import
Ahoj! V priloze je skript na import zemedelske pudy z LPIS. Bohuzel, tak jak to je, tak jsou data posunuta cca o 100 metru. Netusite nekdo, cim by to mohlo byt? (Na druhou stranu, asi nebude problem posunout to zpet pokud je posun tak nejak konstantni...) Mejte se, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] LPIS import
On Sun 2014-07-20 23:53:26, Pavel Machek wrote:
Ahoj!
V priloze je skript na import zemedelske pudy z LPIS.
A ted ten skript.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
#!/usr/bin/python
import shapefile
from pyproj import *
print ?xml version='1.0' encoding='UTF-8'?
print osm version='0.6' generator='pyshp'
#p1 = Proj(init='my:2065')
p1 = Proj(init='esri:102067')
#p1 = Proj(init='EPSG:4326')
p2 = Proj(init='EPSG:4326')
sf = shapefile.Reader(PLPIS_223941_KU_KOD_631035)
global field
field = {}
def a_field(num, name):
global field
i1, i2, i3, i4 = sf.fields[num]
if name != i1:
print 'Unexpected field name ', name
field[name] = num
a_field(1, 'ID_FB')
a_field(3, 'NKODFB')
a_field(6, 'PLATNYOD')
a_field(7, 'VYMERAM')
a_field(8, 'KULTURA')
a_field(9, 'KULTURA_KL')
a_field(10, 'KULTURAOD')
a_field(11, 'EKO')
a_field(21, 'VYSKA')
a_field(22, 'SVAZITOST')
a_field(26, 'KU_KOD')
global nodeid
nodeid = 0
def convert(point):
lon, lat = point
lon, lat = transform(p1, p2, lon, lat)
return lon, lat
def write_point(point):
global nodeid
lon, lat = convert(point)
tags = 'tag k=created_by v=shpupload/'
tags += 'tag k=source v=lpis/'
nodeid -= 1
print 'node id=%d lon=%f lat=%f\%s/node' % ( nodeid, lon, lat,
tags )
return nodeid
def attr(shrec, name):
return shrec.record[field[name]]
for shrec in sf.shapeRecords():
shape = shrec.shape
pts = []
for point in shape.points:
pts += [ write_point(point) ]
nodeid -= 1
print 'way id=%d' % nodeid
print ' tag k=created_by v=pyshp/'
print ' tag k=id_fb v=%s/' % attr(shrec, 'ID_FB')
print ' tag k=source v=lpis/'
kul = attr(shrec, 'KULTURA')
if kul == 2:print ' tag k=landuse v=farmland/'
elif kul == 3: print ' tag k=landuse v=hop_field/'
elif kul == 30: print ' tag k=landuse v=hop_field/'
elif kul == 31: print ' tag k=landuse v=hop_field/tag k=crop
v=hop/'
elif kul == 41: print ' tag k=landuse v=vineyard/tag k=barrier
v=fence/'
elif kul == 61: print ' tag k=landuse v=orchard/tag k=barrier
v=fence/'
elif kul == 62: print ' tag k=landuse v=orchard/'
elif kul == 7: print ' tag k=landuse v=meadow/'
elif kul == 71: print ' tag k=landuse v=meadow/tag k=barrier
v=fence/'
elif kul == 72: print ' tag k=landuse v=meadow/'
elif kul == 91: print ' tag k=landuse v=forest/tag k=barrier
v=fence/'
elif kul == 92: print ' tag k=landuse v=farm/tag k=crop
v=vegetables/'
elif kul == 97: print ' tag k=landuse v=reservoir/'
elif kul == 98: print ' tag k=landuse v=forest/tag k=note
v=rychle rostouci dreviny/'
elif kul == 99: print ' tag k=landuse v=forest/'
else: print ' tag k=landuse v=unknown_farmland_%d/' % kul
for pt in pts:
print ' nd ref=%d/' % pt
print '/way'
print '/osm'
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] LPIS import
Ahoj!
A ted ten skript.
Tak dobra zprava, ten web to umi dat we wgs-84.
Spatna je, ze to posila mailem, dle cisla katastralniho uzemi. Aha, a
ty cisla katastralnich uzemi jde dokonce vykoukat z osm, jako ref u
boundary=administrative, admin_level=10. Bohuzel jsou to maly uzemi.
:-), normálka ;). Landuse je opravdu hodně potřeba. Vždycky tak trochu
závidím karviňákům tu jejich barevnou mapu. Přemýšlel jsem o možnosti
využít
parcely z RUIAN. Tam je nejen zemědělská půda, ale i leccos ostatního -
zastavěná plocha, silnice, dálnice a co já vím, co ještě. Zemědělská půda tam
určitě není tak podrobně jako v eagri/lpis.
Máš představu, nakolik jsou údaje trvanlivé, t.j. zda příští rok ještě budou
platit? Jak aktualizovat? Jak to spojit s jiným landuse, neb nejen
zemědělskou
půdou povrch naší matičky pokryt jest.
Maji tam klic podle kteryho to pujde aktualizovat, a normalne
zemedelska puda relativne trvanliva je. Spojit s jinym landusem --
spis radej ne, ne? Maji to docela podrobny, tj pole zacina na kraji cesty.
Dle právě provedeného výpočtu má v RUIAN digitální mapu 64 procent území
republiky, takže sice dobré, ale ne dost.
Určitě najdeme spoustu míst, kde podle RUIAN je sídliště a podle EAGRI louka
či pole (po zkušenostech s importem adres ;-)).
No, tohle bude krasne videt na bingu :-).
Nakolik budeme která data brát jako referenční či jak se rozhodneme, co
převezmeme. Možná existují i další zdroje pro landuse.?
Co budeme dělat se stávajícími polygony landuse. Dělat díry v polygonech z
EAGRI?
No, asi zalezi co bude lepsi. V oblastech, co jsem mapoval ja, je LPIS
lepsi nez rucni trasovani z ortofota... Takze pekne vymazat a nahrat
znova.
A ted.. umel by nekdo automaticky z mbox souboru s mailama vytahnout
zip-ovy prilohy?
Pavel
(Aktualni verse importeru v priloze).
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
#!/usr/bin/python
# http://www.lpis.cz/index.html
# Mapa:
# http://eagri.cz/public/app/lpisext/lpis/verejny/
# Vyzadat data na:
# http://eagri.cz/public/app/lpisext/lpis/verejny/exportDat.html
# Vyzadat: Pudni bloky
# Souradny systrem: wgs-84
# Aha, a ty cisla katastralnich uzemi jde dokonce vykoukat z osm, jako ref u
boundary=administrative, admin_level=10
# A... nefunguje jim dobre captcha, takze jde stahnout vic uzemi jednim
formularem.
# doubek: 631035
# babice: 600601
# for A in *.zip; do unzip $A; done
import sys
import shapefile
from pyproj import *
print ?xml version='1.0' encoding='UTF-8'?
print osm version='0.6' generator='pyshp'
#p1 = Proj(init='esri:102067')
p1 = Proj(init='EPSG:4326')
p2 = Proj(init='EPSG:4326')
sf = shapefile.Reader(sys.argv[1])
global field
field = {}
def a_field(num, name):
global field
i1, i2, i3, i4 = sf.fields[num]
if name != i1:
print 'Unexpected field name ', name
field[name] = num
a_field(1, 'ID_FB')
a_field(3, 'NKODFB')
a_field(6, 'PLATNYOD')
a_field(7, 'VYMERAM')
a_field(8, 'KULTURA')
a_field(9, 'KULTURA_KL')
a_field(10, 'KULTURAOD')
a_field(11, 'EKO')
a_field(21, 'VYSKA')
a_field(22, 'SVAZITOST')
a_field(26, 'KU_KOD')
global nodeid
nodeid = 0
def convert(point):
lon, lat = point
lon, lat = transform(p1, p2, lon, lat)
#lat += 50.013082018919185-50.013834
#lon += 14.748617781670555-14.749757
return lon, lat
def write_point(point):
global nodeid
lon, lat = convert(point)
tags = 'tag k=created_by v=shpupload/'
tags += 'tag k=source v=lpis/'
nodeid -= 1
print 'node id=%d lon=%f lat=%f\%s/node' % ( nodeid, lon, lat,
tags )
return nodeid
def attr(shrec, name):
return shrec.record[field[name]]
for shrec in sf.shapeRecords():
shape = shrec.shape
pts = []
for point in shape.points:
pts += [ write_point(point) ]
nodeid -= 1
print 'way id=%d' % nodeid
print ' tag k=created_by v=pyshp/'
print ' tag k=id_fb v=%s/' % attr(shrec, 'ID_FB')
print ' tag k=source v=lpis/'
print ' tag k=lpis:kultura v=%d/' % attr(shrec, 'KULTURA')
kul = attr(shrec, 'KULTURA')
if kul == 2:print ' tag k=landuse v=farmland/'
elif kul == 3: print ' tag k=landuse v=hop_field/'
elif kul == 30: print ' tag k=landuse v=hop_field/'
elif kul == 31: print ' tag k=landuse v=hop_field/tag k=crop
v=hop/'
elif kul == 41: print ' tag k=landuse v=vineyard/tag k=barrier
v=fence/'
elif kul == 61: print ' tag k=landuse v=orchard/tag k=barrier
v=fence/'
elif kul == 62: print ' tag k=landuse v=orchard/'
elif kul == 7: print ' tag k=landuse v=meadow/tag k=meadow
v=agricultural/'
elif kul == 71: print ' tag k=landuse v=meadow/tag k=meadow
v=agricultural/tag k=barrier v=fence/'
elif kul == 72: print ' tag k=landuse v=meadow/tag k=meadow
v=agricultural/'
elif kul == 91: print ' tag k=landuse v=forest/tag
Re: [Talk-cz] LPIS import
Ahoj! A ted.. umel by nekdo automaticky z mbox souboru s mailama vytahnout zip-ovy prilohy? Dalsi vec co by se hodila.. vytahnout nejakym xapi seznam vsech ref od boundary=administrative, admin_level=10 . To se potom zadava do jejich webu... Ja bych na to asi casem prisel, ale pro dnesek bylo dost programovani... Dobrou noc, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] LPIS import
Ahoj, Dne Po 21. července 2014 01:10:53, Pavel Machek napsal(a): A ted.. umel by nekdo automaticky z mbox souboru s mailama vytahnout zip-ovy prilohy? ano, ripmime, celé roky jsem si takhle posílal mailem data z meteostanice na zahradě. Na server přišel od meteostanice mail s přílohou, server předhodil mail ripmime, ten to rozbalil a nahrál do Postgresu. Není třeba to tahat z mboxu, ale mailer (v mém případě sendmail/procmail, nesmějte se, no) to rovnou předhodí ripmime a rovnou dál, tedy zpracování okamžitě. Dalsi vec co by se hodila.. vytahnout nejakym xapi seznam vsech ref od boundary=administrative, admin_level=10 . To se potom zadava do jejich webu... Originál je v RUIAN, seznam katastrálních území, je jich něco přes 13 tisíc. Je to totéž, co admin-level 10. Není problém. Dobrou noc, Brou! -- Petr ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] LPIS import
Ahoj, Dne Po 21. července 2014 01:00:19, Pavel Machek napsal(a): Maji tam klic podle kteryho to pujde aktualizovat, a normalne zemedelska puda relativne trvanliva je. Spojit s jinym landusem -- spis radej ne, ne? Maji to docela podrobny, tj pole zacina na kraji cesty. no to asi jo, kde je pole, tam bude pole, dokud nějaký developer neuplatí úředníky a nepostaví tam mrakodrapy. Myslel jsem spíš proměny pěstovaných plodin,ale to asi do OSM dávat nebudeme. Prostě pole je pole a hotovo. Spojovat s jiným landuse - no vlastně to, co navrhuješ, t.j. jen zemědělskou půdu, to není špatné řešení.. Nač si komplikovat život. Asi už je opravdu čas, abych udělal TMS vrstvu landuse z dat z RUIAN. Jen tak si to vizualizovat a teprve uvidíme podle obrázků, zda by to k něčemu mohlo být dobré. Určitě najdeme spoustu míst, kde podle RUIAN je sídliště a podle EAGRI louka či pole (po zkušenostech s importem adres ;-)). No, tohle bude krasne videt na bingu :-). Zná vůbec někdo zpoždění Bingu? T.j. zda lze zjistit datum snímků? Možná je to triviální, ale teď nevím. Nakolik budeme která data brát jako referenční či jak se rozhodneme, co převezmeme. Možná existují i další zdroje pro landuse.? Co budeme dělat se stávajícími polygony landuse. Dělat díry v polygonech z EAGRI? No, asi zalezi co bude lepsi. V oblastech, co jsem mapoval ja, je LPIS lepsi nez rucni trasovani z ortofota... Takze pekne vymazat a nahrat znova. No tady narazíme na to, že ne vše je zemědělská půda. Myslíš vymazat landuse=residential či industrial? Asi ne. -- Petr ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [OSM-talk-fr] vending_machine=yes in France
Le 13/07/2014 21:31, Frédéric Rodrigo a écrit : Le 13/07/2014 21:02, Andreas Goss a écrit : 1. amenity=bicycle_rental The good tag is vending=yes, rent process not available at all station. It's more clear in french translation http://wiki.openstreetmap.org/wiki/FR:Tag:amenity=bicycle_rental I don't speak French so this is what google gives me: yes for stations that have a possibility of payment and ticket printer (registration shortest possible time in these stations). First of all I don't understand why this tag covers payment, when we have payment= which can be used in many ways. Yes, you right. Then I assume you always need some kind of ticket for the bike? No. You register for a subscription (from 1 day to 1 years). In fact there is no a physical automaton vending machine. The machine sell subscription, no physical objects. It's not just a payment point. So then it depends if you just want to set payment:ticket (or something like that) on the station or do you include the vending machine, because then you might as well just set payment:cash=yes (I mean if I got to a cinema I also don't tagg it with vending=yes, because i can get the ticket right there and pay with cash). The stations where you can't do this are then different, because payment:cash=no. Maybe we should then consider a new value for payment like only and then you set payment:vcub_ticket=only. At least I think that is the direction this should be going. So vending=subscription payment:debit_cards=yes and no vending_machine key I change the key in OSM and the configuration of this data integration into the tool Osmose QA. Nevertheless there is still an other vending_machine=true in Bordeaux. By the way, after flower and milk, I just add yesterday a vending=ink_cartridge in Bordeaux. Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] vending_machine=yes in France
and milk The food and drink tags are the one I didn't really touch yet or let's say later realized it was pretty complicated. The problem is that if you look in taginfo you see a lot of different vending machines for some kind of food/drink products. This would result in a lot of different vending= tags. So the question is do we really want this or do we use vending=drinks + drink:milk=yes, obviously this means that you also need dink:soft_drink=yes instead of just assuming it like now. I honestly not a huge fan of that, but on the other hand I also don't want half of the vending= tags to be for different kind of foods from asparagus, tomatoes over potatos to cheese and eggs. Maybe meet somwhere in the middle and use vending=vegetables + food:... __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] ajout des entêtes cors http://api.openstreetmap.fr/api
Le 18/07/2014 17:56, Christian Quest a écrit : Oui, d'autres reçoivent des doublons (pas moi) et l'analyse des entêtes a permis de confirmer que ça venait d'un serveur SMTP de makina-corpus. Bonjour, Je viens de supprimer des septuplons de messages déjà reçus auparavant de Jean-François. Tous les jours je dois en supprimer un certains nombre. Ne m'y connaissant pas suffisemment je suis incapable d'aider à la résolution de ce problème qui est spécifique aux envois de ce dernier. Amitiés -- Yannick VOYEAUD Nul n'a droit au superflu tant que chacun n'a pas son nécessaire (Camille JOUFFRAY 1841-1924, maire de Vienne) http://www.voyeaud.org Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/ Journées du Logiciel Libre: http://jdll.org signature.asc Description: OpenPGP digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] ajout des entêtes cors http://api.openstreetmap.fr/api
Alors moi c'est Jean-Michel et pas Jean-François mais vous êtes pardonnés car pas les seul à pas faire attention. J'ai rapporté le problème à nos administrateurs système dès que j'ai eu votre analyse des entêtes et je reste sans réponse pour le moment. J'attends des nouvelles de nos admins et je reste désolé du problème rencontré. Cordialement, Jean-Michel. Le 20/07/2014 13:07, Yannick VOYEAUD a écrit : Le 18/07/2014 17:56, Christian Quest a écrit : Oui, d'autres reçoivent des doublons (pas moi) et l'analyse des entêtes a permis de confirmer que ça venait d'un serveur SMTP de makina-corpus. Bonjour, Je viens de supprimer des septuplons de messages déjà reçus auparavant de Jean-François. Tous les jours je dois en supprimer un certains nombre. Ne m'y connaissant pas suffisemment je suis incapable d'aider à la résolution de ce problème qui est spécifique aux envois de ce dernier. Amitiés ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] ajout des entêtes cors http://api.openstreetmap.fr/api
Bonjour, Pour ceux qui en ont marre de recevoir ces messages, je conseille comme solution **provisoire** de filtrer les messages de Jean-François, pour les envoyer dans la corbeille. Testé avec Thunderbird, ça marche très bien. Librement, -- Jean-Marc Gailis Président de ViaNET Les Voies de l'Internet FAI Associatif 0xB76A9DF4.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Geocaching - JT France 2
Une apparition furtive du rendu osm sur une application mobile, dans ce reportage, à 29'25 http://www.francetvinfo.fr/geocaching-la-chasse-au-tresor-geante_651363.html l'appli en question se retrouve ici : http://www.tresorsdehautebretagne.fr/ -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus, Nadja ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] ajout des entêtes cors http://api.openstreetmap.fr/api
Le 20/07/2014 13:23, JeanMichel FRANCOIS a écrit : Alors moi c'est Jean-Michel et pas Jean-François mais vous êtes pardonnés car pas les seul à pas faire attention. Oupsss Oui toutes mes excuses. Je ne doutes pas que vous cherchiez la réponse à ce problème assez bizarre et que vous êtes le seul à poser sur toutes les listes que je suis. Amitiés -- Yannick VOYEAUD Nul n'a droit au superflu tant que chacun n'a pas son nécessaire (Camille JOUFFRAY 1841-1924, maire de Vienne) http://www.voyeaud.org Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/ Journées du Logiciel Libre: http://jdll.org signature.asc Description: OpenPGP digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] ajout des entêtes cors http://api.openstreetmap.fr/api
Bonjour, Le 20/07/2014 13:51, Jean-Marc Gailis - Jānis-Marks Gailis a écrit : Pour ceux qui en ont marre de recevoir ces messages, je conseille comme solution **provisoire** de filtrer les messages de Jean-François, pour les envoyer dans la corbeille. C'est Jean-Michel François et non Jean-François ;-) Et puis oui, y en a un peu ras le bol de ce flot ininterrompu. Hop, expéditeur blacklisté. -- Jean-Francois Nifenecker, Bordeaux ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmose/Pharmacies/changement massifs
+1, et expliquer la différence entre para pharma et pharma sur le wiki serait super ... Personnellement je connais pas Le 19 juil. 2014 22:31, Vincent Pottier vpott...@gmail.com a écrit : Le 19/07/2014 22:15, Art Penteur a écrit : Cela m'inspire les réflexions suivantes C'est bien de réfléchir :-) D'une part, ce changement est-il nécessaire ? La page wiki anglaise dit The default value is country specific. Ne vaudrait-il pas mieux documenter partout que, en France, le défaut est yes ? (pour partout, on peut commencer par les pages wiki EN, FR et DE). Moi, je suis favorable à l'ajout. Si tout devient relatif au pays, ça devient difficile d'avoir une base mondiale. Ça n'est pas compliqué d'ajouter le dispensing=yes. Et le jour où les mexicains ou les néo-zélandais utiliseront les données de la France, ils n'auront pas besoin de se référer à des données par défaut. C'est plutôt les sets de tags dans JOSM et iD qui devraient avoir des valeurs par défaut selon le pays. D'autre part, espérer que les corrections se fassent petit à petit sur toute la France grâce à Osmose est, à mon avis, une hérésie. Savez-vous qu'on a inventé des machine à traiter de l'information ? Si la communauté pense qu'il vaut mieux ajouter dispensing = yes, je veux bien essayer de le faire systématiquement et automatiquement sur toute la France (do-o-cratie), mais pour des raisons pratiques, ce sera après le 27/07. Ouais, voila une proposition qu'elle est bonne ! Art. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmose/Pharmacies/changement massifs
Le 20/07/2014 16:07, Jean-Baptiste Holcroft a écrit : +1, et expliquer la différence entre para pharma et pharma sur le wiki serait super ... Personnellement je connais pas Une pharmacie vend des médicaments, un produit qui contient des substances actives qui ont des effets sur l'organisme. Conçu pour soigner, ils peuvent être dangereux s'il sont mal utilisés et sont donc prescrit par un médecin ou un pharmacien. http://www.sante.gouv.fr/definition-d-un-medicament.html Une parapharmacie ne vend pas de *médicaments*, elle se limite aux produits de soins dermatologiques, cosmétiques et capillaires, diététique... https://fr.wikipedia.org/wiki/Parapharmacie Ce sont des rayons que l'on voit fleurir dans les supermarchés, ou des boutiques sur Internet. Je ne crois pas qu'il existe en france beaucoup de boutiques physiques qui fasse uniquement parapharmacie. Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmose/Pharmacies/changement massifs
Certains hypermarchés Leclerc (ex : Landerneau dans le Finistère) font la parapharmacie mais ils ne sont pas autorisés à vendre les produits pharmaceutiques. Existe-t-il des pharmacies qui ne font pas de parapharmacie, j'en doute ? Le 20 juillet 2014 19:04, Christophe Merlet red...@redfoxcenter.org a écrit : Le 20/07/2014 16:07, Jean-Baptiste Holcroft a écrit : +1, et expliquer la différence entre para pharma et pharma sur le wiki serait super ... Personnellement je connais pas Une pharmacie vend des médicaments, un produit qui contient des substances actives qui ont des effets sur l'organisme. Conçu pour soigner, ils peuvent être dangereux s'il sont mal utilisés et sont donc prescrit par un médecin ou un pharmacien. http://www.sante.gouv.fr/definition-d-un-medicament.html Une parapharmacie ne vend pas de *médicaments*, elle se limite aux produits de soins dermatologiques, cosmétiques et capillaires, diététique... https://fr.wikipedia.org/wiki/Parapharmacie Ce sont des rayons que l'on voit fleurir dans les supermarchés, ou des boutiques sur Internet. Je ne crois pas qu'il existe en france beaucoup de boutiques physiques qui fasse uniquement parapharmacie. Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Doublon de mail Was: Edition des relations pour les transports en commun (ville de Nantes) (JeanMichel FRANCOIS)
Ces entêtes démontrent que c'est bien un problème local à un agent relai interne de makina-corpus.com Received: from localhost (localhost.localdomain [127.0.0.1]) by mxrelay.makina-corpus.com (Postfix) with ESMTP id 104228131D C'est bien cet agent interne (localhost, on ne sait pas où il est précisément) qui reçoit le message avec le même id 104228131D et le réexpédie plusieurs fois vers un autre agent interne de ce domaine qui lui se connecte aux serveurs de cette liste. Cet id 104228131D ne peut cependant pas être vérifié par les agents suivants car l'agent sortant ( mxrelay.makina-corpus.com ([212.129.7.19]:49405) insère ses propres ids et vient dupliquer. Il semble que l'agent sortant a des difficultés intermittentes à communiquer avec l'agent de cette liste, et gère mal les erreurs de connexion intermittentes, et ensuite ne s'arrête plus de vouloir réessayer même si les nouvelles tentatives réussissent (il gère mal sa propre file d'attente interne, ce qui peut aussi être un signe d'une corruption de sa propre base de données locale pour gérer la file d'attente; ou un bogue de son propre logiciel sur son serveur). Mais je ne comprend toujours pas pourquoi certains ici recoivent des doublons et pas d'autres. Normalement j'aurais du recevoir les deux messages aussi, je n'ai reçu que le premier (et rien non plus dans les boites indésirables, aussi bien chez Wanadoo que Gmail qui reçoit tout le courrier non filtré par Wanadoo). Cela veut dire que c'est cette liste ici qui n'envoie pas les doublons à tout le monde ou s'arrête à un moment d'en envoyer suite à un dépassement de quota d'émission ou un autre problème. Dans tout ça, Jean-François ne semble pas la cause, c'est un problème technique quelquepart dans la chaine d'agents intermédiaires. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmose/Pharmacies/changement massifs
Bonjour Le 20/07/2014 19:18, Cyrille DERORY a écrit : Certains hypermarchés Leclerc (ex : Landerneau dans le Finistère) font la parapharmacie Oui, il (enseigne Leclerc) essaie de développer des parapharmacies en dehors des rayonnages avec des personnels dédiés à ces boutiques, dans l'attente probable (ou improbable) de devenir des pharmacies (monopoles des pharmaciens ?) Cordialement -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Doublon de mail Was: Edition des relations pour les transports en commun (ville de Nantes) (JeanMichel FRANCOIS)
Bonjour Le 20/07/2014 19:57, Philippe Verdy a écrit : c'est un problème technique quelquepart dans la chaine d'agents intermédiaires. Un gros bouton rouge peut améliorer le problème :-) Cordialement -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Doublon de mail Was: Edition des relations pour les transports en commun (ville de Nantes) (JeanMichel FRANCOIS)
Le 20/07/2014 19:57, Philippe Verdy a écrit : Ces entêtes démontrent que c'est bien un problème local à un agent relai interne de makina-corpus.com http://makina-corpus.com Received: from localhost (localhost.localdomain [127.0.0.1]) by mxrelay.makina-corpus.com http://mxrelay.makina-corpus.com (Postfix) with ESMTP id 104228131D C'est bien cet agent interne (localhost, on ne sait pas où il est précisément) qui reçoit le message avec le même id 104228131D et le réexpédie plusieurs fois vers un autre agent interne de ce domaine qui lui se connecte aux serveurs de cette liste. Cet id 104228131D ne peut cependant pas être vérifié par les agents suivants car l'agent sortant (mxrelay.makina-corpus.com http://mxrelay.makina-corpus.com ([212.129.7.19]:49405) insère ses propres ids et vient dupliquer. Il semble que l'agent sortant a des difficultés intermittentes à communiquer avec l'agent de cette liste, et gère mal les erreurs de connexion intermittentes, et ensuite ne s'arrête plus de vouloir réessayer même si les nouvelles tentatives réussissent (il gère mal sa propre file d'attente interne, ce qui peut aussi être un signe d'une corruption de sa propre base de données locale pour gérer la file d'attente; ou un bogue de son propre logiciel sur son serveur). Mais je ne comprend toujours pas pourquoi certains ici recoivent des doublons et pas d'autres. Normalement j'aurais du recevoir les deux messages aussi, je n'ai reçu que le premier (et rien non plus dans les boites indésirables, aussi bien chez Wanadoo que Gmail qui reçoit tout le courrier non filtré par Wanadoo). Cela veut dire que c'est cette liste ici qui n'envoie pas les doublons à tout le monde ou s'arrête à un moment d'en envoyer suite à un dépassement de quota d'émission ou un autre problème. Dans tout ça, Jean-François ne semble pas la cause, c'est un problème technique quelquepart dans la chaine d'agents intermédiaires. Bonsoir Si ça peut aider : Je récupère dans thunderbird mes messages sans les supprimer chez Orange (suppression automatique au bout de 15 jours) Les messages de Jean Michel réapparaissent très régulièrement (plus de 200 répétitions de messages depuis samedi matin). en revanche sur le webmail d'orange, les messages n'apparaissent qu'une fois. C'est comme si le message n'était pas marqué comme téléchargé contrairement aux autres messages. @+ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Doublon de mail Was: Edition des relations pour les transports en commun (ville de Nantes) (JeanMichel FRANCOIS)
Peut-etre mais en atendant Jean-Michel François peut changer de fournisseur pour l'envoi de ses emails à cette liste, sans transiter par Makina-Corpus qui a des problèmes techniques internes (et qui risque fort de se retrouver blacklisté pendant un temps à divers endroits, si le bogue est lié à une contamination de ses systèmes par un malware, ou par un défaut d'administration). On ne peut pas corriger ça pour lui, c'est à lui d'agir en joignant s'il le peut les administrateurs de ce domaine. Il le peut d'autant plus facilement que son adresse courriel de contact n'est pas directement sur ce domaine. S'il l'utilise pour gérer une archive en ligne ou une boute plus grande, il y a d'autres services en ligne qui le font bien (c'est pour ça aussi que j'utilise Gmail maintenant car j'ai abandonné tout stockage local, pas pratique quand on a plusieurs machines ou qu'on doit en changer, et pas pratique en mobilité). D'autres utilisent les services de Yahoo, Microsoft, etc... Mais je reproche à Microsoft son manque de permanence et le fait qu'il efface sans prévenir les boites mail souscrites (je n'utilise les comptes Hotmail que pour des utilisations provisoires où je me fiche pas mal que le compte disparaisse tout seul au bout de 2 mois, comme Microsoft me l'a fait sur un compte Hotmail pendant un séjour de 3 semaines à l'étranger où je ne m'y étais pas connecté par un moyen habituel). Il peut aussi voir à La Poste. Dans tous les cas il vaut mieux pas lier sa messagerie à son abonnement internet fixe ou mobile (au risque de tout perdre du jour au lendemain ou de se priver de la liberté de changer d'opérateur), pas même un compte internet prépayé (qui disparait aussi au bout de 2 mois sans renouvellement par achat de ticket d'unités), et il vaut mieux éviter aussi le compte internet de son école, ou son employeur (qu'on va être amené aussi à quitter et avec qui on n'a pas envie de rester lié ou avoir un droit de regard sur les échanges) pour autre chose que l'activité de cette école ou cet employeur. Chez les fournisseurs Internet français, seuls Orange et Free proposent des boites à lettre à vie sans aucun engagement et sans paiement mensuel ni facture (paiement seulement à l'utilisation de leur accès libre qu'on n'a aucune obligation d'utiliser: il ne faut pas résilier leurs abonnements mais changer d'offre vers l'accès libre gratuit et ça suffit pour maintenir l'adresse même si on ne stocke plus ou ne consulte plus les messages chez eux par leur webmail), et avec un stockage en ligne confortable et accessible de partout pour l'instant je ne connais pas beaucoup mieux que de découpler aussi l'adresse email de contact, de celle du compte de stockage/consultation; et permettant aussi des envois faciles avec une interface webmail (doublée d'une application mobile) aussi pratique, disponible et fiable que Gmail. Le 20 juillet 2014 20:34, David Crochet david.croc...@free.fr a écrit : Bonjour Le 20/07/2014 19:57, Philippe Verdy a écrit : c'est un problème technique quelquepart dans la chaine d'agents intermédiaires. Un gros bouton rouge peut améliorer le problème :-) Cordialement -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Doublon de mail Was: Edition des relations pour les transports en commun (ville de Nantes) (JeanMichel FRANCOIS)
Je reçois les messages de cette liste par mon adresse Wanadoo (Orange). Visiblement Orange évite ces doublons. En revanche j'ai réglé Orange pour qu'il fasse un forward direct vers mon compte Gmail, autrement dit, Orange ne les garde pas, aucun n'est marqué comme non téléchargé, le transfert est automatique et fonctionne bien (cela n'ajoute que quelques secondes de délai de transmission, c'est invisible en pratique sauf si on consulte les entêtes MIME). Il semble que makina-corpus.com http://mxrelay.makina-corpus.com/ gère mal certaines options du protocole ESMTP (notamment pour les listes de diffusion, ou pour les messages à destinataires multiples; ou les options de type forwarded for) et qu'il se plante en interprétant incorrectement les entêtes ou en modifiant leur ordre quand il est signifiant. Le bogue ne semble pas concerner ses serveurs POP ou Webmail. Pourtant il indique des logiciels assez communs (Postfix en réception, quelle version? et Exim 4.76 en émission). A mon avis c'est un bidouillage incorrect de scripts pour Postfix qui semble casser l'identification de l'état des messages en transit. Entre les deux il y a un logiciel peu commun pour lier à un antivirus (amavisd-new) qui peut être la cause du problème. Il y a une doc là: http://infos-reseau.com/postfix-amavis-couple-avec-spamassassin-et-clamav/ mais le paramétrage est passablement compliqué à faire... Le 20 juillet 2014 21:31, Régis Bouguin regis.boug...@wanadoo.fr a écrit : Le 20/07/2014 19:57, Philippe Verdy a écrit : Ces entêtes démontrent que c'est bien un problème local à un agent relai interne de makina-corpus.com Received: from localhost (localhost.localdomain [127.0.0.1]) by mxrelay.makina-corpus.com (Postfix) with ESMTP id 104228131D C'est bien cet agent interne (localhost, on ne sait pas où il est précisément) qui reçoit le message avec le même id 104228131D et le réexpédie plusieurs fois vers un autre agent interne de ce domaine qui lui se connecte aux serveurs de cette liste. Cet id 104228131D ne peut cependant pas être vérifié par les agents suivants car l'agent sortant ( mxrelay.makina-corpus.com ([212.129.7.19]:49405) insère ses propres ids et vient dupliquer. Il semble que l'agent sortant a des difficultés intermittentes à communiquer avec l'agent de cette liste, et gère mal les erreurs de connexion intermittentes, et ensuite ne s'arrête plus de vouloir réessayer même si les nouvelles tentatives réussissent (il gère mal sa propre file d'attente interne, ce qui peut aussi être un signe d'une corruption de sa propre base de données locale pour gérer la file d'attente; ou un bogue de son propre logiciel sur son serveur). Mais je ne comprend toujours pas pourquoi certains ici recoivent des doublons et pas d'autres. Normalement j'aurais du recevoir les deux messages aussi, je n'ai reçu que le premier (et rien non plus dans les boites indésirables, aussi bien chez Wanadoo que Gmail qui reçoit tout le courrier non filtré par Wanadoo). Cela veut dire que c'est cette liste ici qui n'envoie pas les doublons à tout le monde ou s'arrête à un moment d'en envoyer suite à un dépassement de quota d'émission ou un autre problème. Dans tout ça, Jean-François ne semble pas la cause, c'est un problème technique quelquepart dans la chaine d'agents intermédiaires. Bonsoir Si ça peut aider : Je récupère dans thunderbird mes messages sans les supprimer chez Orange (suppression automatique au bout de 15 jours) Les messages de Jean Michel réapparaissent très régulièrement (plus de 200 répétitions de messages depuis samedi matin). en revanche sur le webmail d'orange, les messages n'apparaissent qu'une fois. C'est comme si le message n'était pas marqué comme téléchargé contrairement aux autres messages. @+ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Doublon de mail Was: Edition des relations pour les transports en commun (ville de Nantes) (JeanMichel FRANCOIS)
Le 20 juillet 2014 21:31, Régis Bouguin regis.boug...@wanadoo.fr a écrit : Je récupère dans thunderbird mes messages sans les supprimer chez Orange (suppression automatique au bout de 15 jours) Les messages de Jean Michel réapparaissent très régulièrement (plus de 200 répétitions de messages depuis samedi matin). en revanche sur le webmail d'orange, les messages n'apparaissent qu'une fois. C'est comme si le message n'était pas marqué comme téléchargé contrairement aux autres messages. Certains serveurs (et surtout les webmail) s'appuient sur message-id unique et créé par le premier serveur pour faire le dédoublonnage. Ceci explique pourquoi certains reçoivent les doublons et pas d'autres... bien qu'ils soient envoyés :( -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmose/Pharmacies/changement massifs
Le 20 juillet 2014 19:04, Christophe Merlet red...@redfoxcenter.org a écrit : Je ne crois pas qu'il existe en france beaucoup de boutiques physiques qui fasse uniquement parapharmacie. Si justement ! Des boutiques qui ne s'affichent pas comme des pharmacies et où il n'y a aucun pharmacien, aucun conseil, des rayons où on se sert et une caisse... Assez courant dans les galeries marchandes (et pas toujours à l'enseigne du supermarché/hypermarché), on y trouve des cosmétiques, shampooings, dentifrices, savons parfumés, couches bébé, parfums, crèmes solaires, huiles et sels de bain parfumés, déodirants, même des bougies et parfums d'ambiance pour intérieur ou pour voiture, des serviettes et mouchoirs en papier, toutes sortes de compléments alimentaires (vitamines, minéraux), des pastilles de désinfection de l'eau pour campeurs, des répulsifs contre moustiques, de la petite pharmacie pour bobologie en vente libre (y compris aspirine et aspartam alors que ce sont encore des médicaments, et pas toujours vendus sous des formes à petite dose), limes à ongle, liquides pour lentilles de vision, préservatifs, pansements, des pseudo-produits pour régimes minceur, des poudres hyperprotéinées (à base de farine animale, beurk, on n'en donne même plus pour engraisser le bétail!), des laits en poudre pour bébé, parfois des petits pots, des stimulants plus ou moins naturels ou des épices (gingseng...), souvent aussi des produits vétérinaires en vente libre (vermifuges, antitiques, etc...), des accessoires (peignes, brosses, rasoirs, parfois aussi des piercings) parfois aussi du linge de toilette (avec des logos pour faire monter les prix). Mais la cosmétique et la parfumerie (bon marché) a le plus grand nombre de références et tous les prix. Même les chaines connues de parfumerie s'y mettent (Sephora, etc.) car ça se vend beaucoup et souvent, et le stock tourne facilement (et ce sont aussi des produits d'appel pour vendre d'autres produits plus chers et des marques, avec des produits souvent bas de gamme vendus pourtant avec des marges plus confortables que les grandes marques qui dépensent des fortunes en communication). La parapharmacie n'a jamais eu autant de références ni autant de clients (et aucune pharmacie ne peut s'en passer, les pharmaciens n'aiment pas du tout que des produits passent en vente libre en parapharmacie alors qu'il y a peu ils étaient encore prescrits, comme les suppléments alimentaires, vitamines et minéraux, ou la plupart des antalgiques; c'est pourtant le cas de tous les médicaments déremboursés, même quand ils sont efficaces et potentiellement dangereux si les dosages ne sont pas respectés ou si leur usage est prolongé, notamment les antalgiques et antibiotiques locaux et même les vitamines) Il y a largement de quoi remplir et bien faire vivre une boutique avec uniquement la parapharmacie, même si encore les pharmaciens bien implantés (sauf dans les grandes surfaces) tiennent encore une bonne partie de ce secteur qui fait la plus grande partie de leurs chiffres de ventes et de leurs marges (et d'ailleurs ils n'hésitent pas à vous proposer des produits de parapharmacie à la place de la pharmacie réglementée ou en complément de celle-ci). Le nombre et la répartition des pharmacies est contingenté en France, au contraire des parapharmacies qui sont en plain secteur concurrentiel (en ville comme sur Internet). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Ajouter OSM France aux couches d'OSM?
Jo-2 wrote Essayes avec openlinkmap.org. Surtout les arrêts de bus dans le nord de la Belgique... Il faudrait que ça soit implémenté dans OSM par défaut, puisque c'est le site que les non-initiés consultent. À mon avis, OSM devrait afficher 1) une carte de base, 2) une liste d'objets statistiquements les plus demandés (supermarchés, etc.), et 3) rendre ces objets cliquables pour afficher leurs tags à la Google Maps. -- View this message in context: http://gis.19327.n5.nabble.com/Ajouter-OSM-France-aux-couches-d-OSM-tp5811725p5812147.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Doublon de mail Was: Edition des relations pour les transports en commun (ville de Nantes) (JeanMichel FRANCOIS)
Le 20/07/2014 21:59, Christian Quest a écrit : Le 20 juillet 2014 21:31, Régis Bouguin regis.boug...@wanadoo.fr mailto:regis.boug...@wanadoo.fr a écrit : Je récupère dans thunderbird mes messages sans les supprimer chez Orange (suppression automatique au bout de 15 jours) Les messages de Jean Michel réapparaissent très régulièrement (plus de 200 répétitions de messages depuis samedi matin). en revanche sur le webmail d'orange, les messages n'apparaissent qu'une fois. C'est comme si le message n'était pas marqué comme téléchargé contrairement aux autres messages. Certains serveurs (et surtout les webmail) s'appuient sur message-id unique et créé par le premier serveur pour faire le dédoublonnage. Ceci explique pourquoi certains reçoivent les doublons et pas d'autres... bien qu'ils soient envoyés :( Ça commence à bien faire cette blague ! Je suggère de vérifier sur le serveur d'OSM si on reçoit bien les messages de makina en doublons. Si oui, on blacklist makina. Si non, on purge la queue du serveur de messagerie ! Qu'on arrête de spammer les abonnés de la liste ! Mon serveur reçoit aussi les message en multiple exemplaire. Plus de 400 doublons depuis le 15. Par chance mon serveur imap les détecte et les virent avant de me les mettre dans ma boite mail. Les logs d'un doublon de son arrivée à sa suppression sur mon serveur : Jul 20 08:24:57 vs-mail postfix/smtpd[27891]: connect from shenron.openstreetmap.org[212.110.172.32] Jul 20 08:24:58 vs-mail postfix/smtpd[27891]: Anonymous TLS connection established from shenron.openstreetmap.org[212.110.172.32]: TLSv1 with cipher AES256-SHA (256/256 bits) Jul 20 08:24:59 vs-mail postfix/policy-spf[27896]: Policy action=PREPEND Received-SPF: pass (openstreetmap.org: 212.110.172.32 is authorized to use 'talk-fr-boun...@openstreetmap.org' in 'mfrom' identity (mechanism 'ip4:212.110.172.32' matched)) receiver=redfoxcenter.org; identity=mailfrom; envelope-from=talk-fr-boun...@openstreetmap.org; helo=shenron.openstreetmap.org; client-ip=212.110.172.32 Jul 20 08:24:59 vs-mail postfix/smtpd[27891]: 9291776001: client=shenron.openstreetmap.org[212.110.172.32] Jul 20 08:24:59 vs-mail postfix/cleanup[27899]: 9291776001: hold: header Received: from shenron.openstreetmap.org (shenron.openstreetmap.org [212.110.172.32])??by mail.redfoxcenter.org (Postfix) with ESMTPS id 9291776001??for red...@redfoxcenter.org; Sun, 20 Jul 2014 08: from shenron.openstreetmap.org[212.110.172.32]; from=talk-fr-boun...@openstreetmap.org to=red...@redfoxcenter.org proto=ESMTP helo=shenron.openstreetmap.org Jul 20 08:24:59 vs-mail postfix/cleanup[27899]: 9291776001: message-id=53c81b39.2020...@makina-corpus.com Jul 20 08:24:59 vs-mail postfix/smtpd[27891]: disconnect from shenron.openstreetmap.org[212.110.172.32] Jul 20 08:25:02 vs-mail MailScanner[27762]: New Batch: Scanning 1 messages, 19863 bytes Jul 20 08:25:02 vs-mail MailScanner[27762]: Virus and Content Scanning: Starting Jul 20 08:25:46 vs-mail MailScanner[27762]: Expired 3 records from the SpamAssassin cache Jul 20 08:25:46 vs-mail MailScanner[27762]: Whitelist refresh time reached Jul 20 08:25:46 vs-mail MailScanner[27762]: Starting up SQL Whitelist Jul 20 08:25:47 vs-mail MailScanner[27762]: Read 0 whitelist entries Jul 20 08:25:47 vs-mail MailScanner[27762]: Blacklist refresh time reached Jul 20 08:25:47 vs-mail MailScanner[27762]: Starting up SQL Blacklist Jul 20 08:25:47 vs-mail MailScanner[27762]: Read 0 blacklist entries Jul 20 08:25:54 vs-mail MailScanner[27762]: Requeue: 9291776001.AB0B9 to A7C7976002 Jul 20 08:25:54 vs-mail MailScanner[27762]: Uninfected: Delivered 1 messages Jul 20 08:25:54 vs-mail postfix/qmgr[1096]: A7C7976002: from=talk-fr-boun...@openstreetmap.org, size=19093, nrcpt=1 (queue active) Jul 20 08:25:54 vs-mail MailScanner[27762]: Deleted 1 messages from processing-database Jul 20 08:25:54 vs-mail MailScanner[27762]: Logging message 9291776001.AB0B9 to SQL Jul 20 08:25:54 vs-mail MailScanner[27766]: 9291776001.AB0B9: Logged to MailWatch SQL Jul 20 08:25:55 vs-mail cyrus/master[27909]: about to exec /usr/lib/cyrus/bin/lmtpd Jul 20 08:25:55 vs-mail cyrus/lmtp[27909]: executed Jul 20 08:25:55 vs-mail cyrus/lmtp[27909]: accepted connection Jul 20 08:25:55 vs-mail cyrus/lmtp[27909]: connection from vs-mail.redfoxcenter.org [192.168.10.106] Jul 20 08:25:55 vs-mail cyrus/lmtp[27909]: login: vs-mail.redfoxcenter.org [192.168.10.106] lmtp PLAIN User logged in Jul 20 08:25:55 vs-mail cyrus/lmtp[27909]: WARNING: sieve script /var/spool/sieve/domain/r/redfoxcenter.org/r/redfox/defaultbc doesn't exist: No such file or directory Jul 20 08:25:56 vs-mail cyrus/lmtp[27909]: dupelim: eliminated duplicate message to redfoxcenter.org!user.redfox id 53c81b39.2020...@makina-corpus.com date Thu, 17 Jul 2014 20:51:37 +0200 (delivery) Jul 20 08:25:56 vs-mail cyrus/lmtp[27909]: USAGE redfox user: 0.024001 sys: 0.020001 Jul 20 08:25:56 vs-mail postfix/lmtp[27908]: A7C7976002:
Re: [OSM-talk-fr] Ajouter OSM France aux couches d'OSM?
Eternel débat sur ce que doit être ou ne pas être osm.org D'un côté le besoin de montrer les données, ce qu'on peut éventuellement en faire, les services qu'on peut mettre en place grâce à elles. De l'autre... se concentrer sur le coeur du projet, c'est à dire la data, son édition, son amélioration. Plus on va du côté des services, plus on va devoir gérer une qualité de service, augmenter l'infrastructure (matériel, bande passante), l'équipe qui est derrière, s'adapter aux usages locaux... et aussi se retrouver en concurrence avec le développement d'un écosystème autour d'OSM. Jusqu'à maintenant le choix a plutôt été fait sur la deuxième option, ce que je comprends tout à fait. Le 21 juillet 2014 01:08, Shohreh codecompl...@free.fr a écrit : Jo-2 wrote Essayes avec openlinkmap.org. Surtout les arrêts de bus dans le nord de la Belgique... Il faudrait que ça soit implémenté dans OSM par défaut, puisque c'est le site que les non-initiés consultent. À mon avis, OSM devrait afficher 1) une carte de base, 2) une liste d'objets statistiquements les plus demandés (supermarchés, etc.), et 3) rendre ces objets cliquables pour afficher leurs tags à la Google Maps. -- View this message in context: http://gis.19327.n5.nabble.com/Ajouter-OSM-France-aux-couches-d-OSM-tp5811725p5812147.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-ja] オストメイト対応トイレのタグ付けはどうしたらいいでしょうか?
野方です。 みなさま、ありがとうございます。 バリアフリートイレの調査が始まったのですが、調査票には、扉や便座の形、 ベッド(ベビーベッドではなくて大人用)、手すりの縦横など、施設の細かなと ころまで調査項目に入ってました。 名古屋のバリアフリーマップのスレッドも気になるけど、その辺もどう反映さ せたらいいか、まとめたいなぁ。 さて いいださん、三浦さん 英語だと部所によっても言い方も変わりますが、実際にはオストミーですよね。 日本では全部ひっくるめて「オストメイト」と言ってますが。 で、タグとしたら ostomy_irrigation toilets:ostomy で、トイレの施設的には toilets:ostomy がしっくり来るのかなぁ。ううむ…。 大和田さん ostomateですか。 自分も最初に思ったのですが、その表現って日本だけっぽいんですよね。 それでタグ付けはどうしたらと思ったのがきっかけでした。 なおやさん 情報ありがとうございます。「Multi-Purpose Room」だとそのまま多目的部屋っ てイメージが大きい気がしますね。 海外では車いすとか全部ひっくるめて対応トイレは、「Accessible toilet」と 呼ばれてるみたいです。 Accessible toilet - Wikipedia, the free encyclopedia: http://en.wikipedia.org/wiki/Accessible_toilet On 2014年07月20日 08:07, なおや wrote: こんにちは、なおや＠浜松です。 こんな記事見つけました。 新幹線ではMulti-Purpose Roomと表示されているようです。 多分、オスメイトだけではなくて幼児とか車いすとかすべて対応しているからで しょうけど。 http://www.takahashi-office.jp/column/igaku-yakujishinsei/30.htm ご参考まで。 2014年7月20日 2:23 大和田健一 ml.ohw...@gmail.com mailto:ml.ohw...@gmail.com: 参考までに。 鯖江市のトイレ情報では ostomate というタグが使われています。 独自タグなので、一般的ではないかも、 http://www.city.sabae.fukui.jp/pageview.html?id=11592 日本語 dbpedia では、オストメイト (ostomate) で、対応しているトイレ のある場所が検索可能になっています。 まだまだ少ないですが。 http://ja.dbpedia.org/page/%E3%82%AA%E3%82%B9%E3%83%88%E3%83%A1%E3%82%A4%E3%83%88 英語 dbpedia では、該当するものが見つからなかったです。 --- 大和田健一 ml.ohw...@gmail.com mailto:ml.ohw...@gmail.com いいだです。 英語のTagging MLに投稿してみましたが、 特に応答はなく (^^; 用語としては ostomy なのだろうな、と考えると、 toilets:ostomy なんでしょうかね。 ostomy_careとかいろいろ考えたのですが、 ちゃんとドキュメント化がされていれば、 このへんの細かい語句の違いはあまり問題にならない気がしています。 P.S. 以前相談をうけたときに toilets:ostomate じゃないか、って答えたよ うな記憶があるので、 ちょっと前言撤回気味ですが。 2014年6月30日 8:28 Satoshi IIDA nyamp...@gmail.com mailto:nyamp...@gmail.com: いいだです。 以前に調べたことがあるのですが、どうも適切なタグが無いようです。 tagging mlに持ち込んだほうがよいかも。 2014/06/30 2:08 Hiroshi Miura(@osmf) miur...@osmf.jp mailto:miur...@osmf.jp: 三浦です On 2014年06月29日 18:55, Jun NOGATA wrote: こんにちは。野方です。 最近、とあることから姫路市とボランティアグループが制作 する、車いす バリアフリー/トイレマップ制作に関わるようになったので すが、トイレ の対応施設一覧の中に「オストメイト対応」というの見つけ ました。 （略） もう少し調べてみると、函館の方で toilets:ostomate=yes/no というタ グを使われてる方がいらっしゃいました。 - OpenStreetMap | ウェイ: 函館市中央図書館 (261020513): http://www.openstreetmap.org/way/261020513 - toilets:ostomate | Keys | OpenStreetMap Taginfo: http://taginfo.openstreetmap.org/keys/toilets%3Aostomate これがいいような気もしたのですが、オストメイトの名称は 海外ではあま り使われていないようなので、これがいいのか悪いのか ちょっと分かりま せんでした。 米国オストミー協会とか、国際オストミー協会とか、有るよう なので、見てみたら、 http://www.ostomy.org/ Ostomateという名称も使われているようです。 日本のように整備されていない、という事かもしれません。 ということで、オストメイト対応トイレは、どうタグ付けす ればいいので しょうか? ひとつ気になるのは、ostomateは、ostomyを装着した人、とい う意味になリます。 wheelchair=yes とは、意味合いがちがいますよね。 装置が有る、という表現にしたいので、たとえば ostomy_irrigation = yes のような表現（irrigationは医療用語で洗浄）が好ましい気が します。 ちなみに、waterwayのタグにirrigationがあり、これは灌漑用水を 意味します。 三浦 ___ Talk-ja mailing list Talk-ja@openstreetmap.org mailto:Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja -- Satoshi IIDA mail: nyamp...@gmail.com mailto:nyamp...@gmail.com twitter: @nyampire ___ Talk-ja mailing list Talk-ja@openstreetmap.org mailto:Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org mailto:Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja -- /---@_@---/ なおや NISHINO Naoya Twitter http://twitter.com/naoya_24 ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja -- 野方 純 (NOGATA,Jun) - mail: noga...@gmail.com - web: http://www.nofuture.tv/diary/
[OSM-ja] 8月9日淡路島でマッピングパーティを開催します
OSM関西とtalk-jaダブルポストで重複して受け取った人はごめんなさい。 野方です。 夏休みに入りましたね。夏の予定は立てられましたか? さて、8月下旬に兵庫県の淡路島にて、Code for Awajiの一環で「AwajiCAMP!〜 CivicTechで地域活性を考える〜」ハッカソンが開催されるのですが、それに先 立ち8月9日、プレイベントとして淡路島でマッピングパーティを行います。 - 日時: 8月9日(土) 10:00 - 17:00 - 場所: のじまスコーラ(兵庫県淡路市野島地区) - http://www.nojima-scuola.com/ - 公共機関で移動は明石からジェノバライン(船)と無料のシャトルバスを使うといいそうです。 - http://www.jenova-line.co.jp/ で、忘れてはいけないのがマッピングパーティをおこなう野島地区には、阪神・ 淡路大震災の「野島断層」もあります。 - 野島断層 - Wikipedia: http://ja.wikipedia.org/wiki/%E9%87%8E%E5%B3%B6%E6%96%AD%E5%B1%A4 ということで、夏休みのレジャー、自由研究、AwajiCampハッカソンのネタ探し などなど、興味のあるかたは、とりあえず予定だけ空けておいてください。 申し込みページや詳しい案内は、もうすぐ用意できると思うので、 しばらくお待ちください。 -- 野方 純 (NOGATA,Jun) - mail: noga...@gmail.com - web: http://www.nofuture.tv/diary/ ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] 8月9日淡路島でマッピングパーティを開催します
いいだです。 ちょうどOSMの誕生日ですね！(/･ω･)/ 2014年7月21日 13:42 Jun NOGATA noga...@gmail.com: OSM関西とtalk-jaダブルポストで重複して受け取った人はごめんなさい。 野方です。 夏休みに入りましたね。夏の予定は立てられましたか? さて、8月下旬に兵庫県の淡路島にて、Code for Awajiの一環で「AwajiCAMP!～ CivicTechで地域活性を考える～」ハッカソンが開催されるのですが、それに先 立ち8月9日、プレイベントとして淡路島でマッピングパーティを行います。 - 日時: 8月9日(土) 10:00 - 17:00 - 場所: のじまスコーラ(兵庫県淡路市野島地区) - http://www.nojima-scuola.com/ - 公共機関で移動は明石からジェノバライン(船)と無料のシャトルバスを使うといいそうです。 - http://www.jenova-line.co.jp/ で、忘れてはいけないのがマッピングパーティをおこなう野島地区には、阪神・ 淡路大震災の「野島断層」もあります。 - 野島断層 - Wikipedia: http://ja.wikipedia.org/wiki/%E9%87%8E%E5%B3%B6%E6%96%AD%E5%B1%A4 ということで、夏休みのレジャー、自由研究、AwajiCampハッカソンのネタ探し などなど、興味のあるかたは、とりあえず予定だけ空けておいてください。 申し込みページや詳しい案内は、もうすぐ用意できると思うので、 しばらくお待ちください。 -- 野方 純 (NOGATA,Jun) - mail: noga...@gmail.com - web: http://www.nofuture.tv/diary/ ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
[OSM-ja] グッドデザイン賞とマップと地名について
三浦です。
昨年１１月に、GoogleMapｓがグッドデザイン賞で大賞受賞内定していたが、
政府が同意しなかったため、特別賞になったという話題がありました。
この時は、紛争地域の国境等の、各国政府による地名等が
食い違う地物に対する表現について、
日本国政府が要求する内容ではない場合がある、ことで
推奨されないような意見がついた、と報道（＊１）されています。
まとまった報告等をしていなかったので、
現状のOSMの取り組み状況を一般に共有しようと思いました。
Wikiに書いたほうがいいと思ったので、
http://wiki.openstreetmap.org/wiki/JA:Government_policy_and_OSM
書きました。もう少し綺麗に整形できるといいなぁ。
数年前、学会の研究会で、筑波の国土交通省の研究所の
某会議室で発表した時も、同様の指摘というか質問をいただいていましたので、
それへの回答ともなります。
１） わたしの開発する地図タイル配信ソフトウエアTileMan（＊２）では、
次のように取り組んでいます。
OSMを背景地図として情報システム等を運用する利用者は、
TileManを使用して、自分自身のアプリケーションの背景地図の
タイルをOSMを用いて配信できる。
この時、大規模な利用を行う利用者は、
*.tile.openstreetmap.orgでの配信をそのまま
使うのではなく、利用者がTilex、mod_tile, mapnik等を利用して
サーバを立てることが推奨される。
そうでない場合でも、利用者は、TileManを使うことができる。
*.tile.openstreetmap.orgでの配信を使いつつ、一部のタイルを
差し替えることができる。
これは、利用者が例えば、自治体や府省だったりして、その情報システムを
納品するシステム開発会社が利用するケースを考えてみてください。
自治体や各府省は、内閣官房等からの通知により、
地名等の取り扱いに留意することが要求されているそうです。
（＊3）
そこで、（＊3）で指摘されているような問題や、利用者の意向によって
問題と思われるタイルを置き換えることが可能となっています。
TileManでは、参考として、置き換え用のLiancourt Rock/竹島の
タイル画像データ（＊４）を添付しています。
https://github.com/osmfj/tileman/tree/master/data
ちょっとプログラムを変えれば、静的な置き換えタイルを用いず、
たとえば電子国土Webが配信する地図タイルで差し替えることも
可能です。
やや高度な技術知識（LUA、GIS）が要求されますが、
このようなシステムをつくる事業者ならば問題ないでしょう。
カナダ在住の中国人のOSM利活用者が、同様に中国とインド等の国境紛争地帯についての
タイル配信問題でこまっていて、本ソリューションについて、大いに興味をもっていました。
昨年のSotM13で講演したところ、このような話が有りました。
2) OpenStreetMap の編集合戦についてのルール等
OpenStreetMapの活動たる地理情報データベースの整備では
編集合戦等が有る場合があります。
OpenStreetMap FounationのDWGやLegal WGで、いろいろ
ポリシーが議論されています。（＊５）（＊６）
日本国政府が各府省や自治体等に通知したこととしては、
電子地図を背景地図として利用するときに、その表記がどうなっているか、
を調整して、それぞれの方針にしたがったレンダリングや配信をしてもらえば
いいので、マッパーの活動に対しては関係ない、です。
従って、切り離して考えたいと思います。
３）OpenStreetMap Japanホームページ及びOSMFJの配信するタイル
これらについては、現在、TileManを使っていて、サンプルの竹島のタイル画像も
サーバにインストールされています。
日本国内のタイルマップの利用者に対しては地図タイル配信で、
竹島のタイルについて、日本語表記を行う動作をさせています。（＊７）（＊８）
DBからストレートにレンダリングされる結果をマッパーとして確認したい場合は
他のレンダリング配信を利用されるといいでしょう。
４）利用者ガイドライン
重ねて言いますが、OSMFJのタイルサーバの配信は、 各府省、自治体の
システムで利用することを推奨するものではありません。
（ガイドラインの整備は、まだできてないです）
納入や運用する事業者等が、適切にシステム構成して、OSMの利用にあたって
利用者の方針等に適合するようにしてもらえればと思います。
具体的には、VMをひとつ用意し、LinuxとTileManを導入して、
竹島タイルをデータ領域に展開します。サーバ設定は、試験のためならば
プロキシーとして使う用のTileManサンプル設定を使うといいでしょう。
背景地図としてOSMを使うシステムは、TileManの導入されたサーバを
タイルサーバとして指定します。
すると、竹島について不都合の少ない表示になって、府省や自治体への
納入について、課題が減ることでしょう。
リファレンス
（＊１）GoogleMapsとG賞の報道
http://www.itmedia.co.jp/news/articles/1311/07/news111.html
（＊２） TileMan
http://osmfj.github.io/tileman/
https://github.com/osmfj/tileman
(*3) 片山さつき氏 ブログ
http://satsuki-katayama.livedoor.biz/archives/7855139.html
(*4) 置き換えようのデータ
https://github.com/osmfj/tileman/tree/master/data
（＊５）編集合戦についてのブログ
http://blog.emacsen.net/blog/2014/01/17/edit-wars-in-openstreetmap/
（＊６）OSMFのポリシー
http://wiki.osmfoundation.org/w/images/d/d8/DisputedTerritoriesInformation.pdf
（＊７）OSM Japanホームページ
https://openstreetmap.jp/map
（＊８）竹島あたり
https://openstreetmap.jp/map#zoom=14lat=37.24421lon=131.86673layers=B00
(*9) OSMFJ Tileサーバ
http(s)://tile.openstreetmap.jp/{zoom}/{x}/{y}.png
仕様は、*.tile.openstreetmap.org を使う時と同じ。
WordPressやDrupalなどで使うときに、URLを置き換えることでOK.
LeafLet.jsやOpenLayersでの利用がおすすめ。
（＊１０）OSM Japanサイトの開発用VMの再現ソース
https://github.com/osmfj/vagrant-drupal
同様のサイトを実現するときの参考になる。
以上
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja
[OSM-ja] 8/9 OSM誕生会の開催
三浦です。 ８月９日（土）のOSMの１０周年の誕生日にあわせて、 都内で誕生会Partyを当日午後or夕方に計画しています。 今日、現在では、日付しか決まっていないですが。 早急に内容を決めないと、あっというまに当日になっちゃいますね〜 アイディア等、どうでしょうか。 日本の活動がはじまった、2008年には、板橋にて ケーキを食べたことを思い出します。 https://lists.openstreetmap.org/pipermail/talk-ja/2008-July/000496.html [OSM-ja] OSM の誕生日を祝いませんか？ 三浦 ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] 8月9日淡路島でマッピングパーティを開催します
野方です。 On 2014年07月21日 13:46, Satoshi IIDA wrote: いいだです。 ちょうどOSMの誕生日ですね！(/・ω・)/ ですです。 # 相談の話し合いでネタがあったのに告知に忘れてた orz なので、来られる人は一緒にお祝いしましょう On 2014年07月21日 13:46, Satoshi IIDA wrote: いいだです。 ちょうどOSMの誕生日ですね！(/・ω・)/ 2014年7月21日 13:42 Jun NOGATA noga...@gmail.com mailto:noga...@gmail.com: OSM関西とtalk-jaダブルポストで重複して受け取った人はごめんなさい。 野方です。 夏休みに入りましたね。夏の予定は立てられましたか? さて、8月下旬に兵庫県の淡路島にて、Code for Awajiの一環で「AwajiCAMP!〜 CivicTechで地域活性を考える〜」ハッカソンが開催されるのですが、それに先 立ち8月9日、プレイベントとして淡路島でマッピングパーティを行います。 - 日時: 8月9日(土) 10:00 - 17:00 - 場所: のじまスコーラ(兵庫県淡路市野島地区) - http://www.nojima-scuola.com/ - 公共機関で移動は明石からジェノバライン(船)と無料のシャトルバス を使うといいそうです。 - http://www.jenova-line.co.jp/ で、忘れてはいけないのがマッピングパーティをおこなう野島地区には、阪神・ 淡路大震災の「野島断層」もあります。 - 野島断層 - Wikipedia: http://ja.wikipedia.org/wiki/%E9%87%8E%E5%B3%B6%E6%96%AD%E5%B1%A4 ということで、夏休みのレジャー、自由研究、AwajiCampハッカソンのネタ探し などなど、興味のあるかたは、とりあえず予定だけ空けておいてください。 申し込みページや詳しい案内は、もうすぐ用意できると思うので、 しばらくお待ちください。 -- 野方 純 (NOGATA,Jun) - mail: noga...@gmail.com mailto:noga...@gmail.com - web: http://www.nofuture.tv/diary/ ___ Talk-ja mailing list Talk-ja@openstreetmap.org mailto:Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja -- Satoshi IIDA mail: nyamp...@gmail.com mailto:nyamp...@gmail.com twitter: @nyampire ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja -- 野方 純 (NOGATA,Jun) - mail: noga...@gmail.com - web: http://www.nofuture.tv/diary/ ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] 8/9 OSM誕生会の開催
野方です。 On 2014年07月21日 13:56, Hiroshi Miura(@osmf) wrote: 三浦です。 早急に内容を決めないと、あっというまに当日になっちゃいますね〜 アイディア等、どうでしょうか。 淡路島のマッピングパーティが8/9なので東京や他のところと中継などで つなげられると面白かもですね。 On 2014年07月21日 13:56, Hiroshi Miura(@osmf) wrote: 三浦です。 ８月９日（土）のOSMの１０周年の誕生日にあわせて、 都内で誕生会Partyを当日午後or夕方に計画しています。 今日、現在では、日付しか決まっていないですが。 早急に内容を決めないと、あっというまに当日になっちゃいますね〜 アイディア等、どうでしょうか。 日本の活動がはじまった、2008年には、板橋にて ケーキを食べたことを思い出します。 https://lists.openstreetmap.org/pipermail/talk-ja/2008-July/000496.html [OSM-ja] OSM の誕生日を祝いませんか？ 三浦 ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja -- 野方 純 (NOGATA,Jun) - mail: noga...@gmail.com - web: http://www.nofuture.tv/diary/ ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] 8/9 OSM誕生会の開催
Tomです。 愛知県の一宮市でも、8/9に、中学生を交えてマッピングパーティーを計画中です。 で。懇親会で、ケーキを食べようかとか、検討中。 3元中継出来ないかな・・・。 2014年7月21日 14:15 Jun NOGATA noga...@gmail.com: 野方です。 On 2014年07月21日 13:56, Hiroshi Miura(@osmf) wrote: 三浦です。 早急に内容を決めないと、あっというまに当日になっちゃいますね〜 アイディア等、どうでしょうか。 淡路島のマッピングパーティが8/9なので東京や他のところと中継などで つなげられると面白かもですね。 On 2014年07月21日 13:56, Hiroshi Miura(@osmf) wrote: 三浦です。 ８月９日（土）のOSMの１０周年の誕生日にあわせて、 都内で誕生会Partyを当日午後or夕方に計画しています。 今日、現在では、日付しか決まっていないですが。 早急に内容を決めないと、あっというまに当日になっちゃいますね〜 アイディア等、どうでしょうか。 日本の活動がはじまった、2008年には、板橋にて ケーキを食べたことを思い出します。 https://lists.openstreetmap.org/pipermail/talk-ja/2008-July/000496.html [OSM-ja] OSM の誕生日を祝いませんか？ 三浦 ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja -- 野方 純 (NOGATA,Jun) - mail: noga...@gmail.com - web: http://www.nofuture.tv/diary/ ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 早川知道 (Tomomichi Hayakawa) tom.hayak...@gmail.com うえこみ春日井小牧 - http://www.kasugai-komaki.jp/ Malaika System - http://malaika-system.com/ blog - close to you - http://malaika.air-nifty.com/ OSM Tokai - http://groups.google.com/group/OSM-Tokai XOOPS Cube TOKAI - http://xc-tokai.net/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
[Talk-GB] Strictly off-topic: Birdsong
A quick note to congratulate Dan Stowell on an impressive achievement : http://www.bbc.co.uk/news/science-environment-28358123. Jerry ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-us] USBRS WikiProject seeks volunteer mappers
Likewise, I'm in favor of heirarchies similar to road relations for cyclists (ie, Portland area network=lcn becomes US:OR:Multnomah:Portland or US:OR:Metro or US:OR:Multnomah; Tulsa's LCNs would become US:OK:Tulsa:Riverparks or US:OK:INCOG or US:OK:Tulsa or US:OK:Tulsa:Tusla or US:OK:Tulsa:Broken Arrow...etc ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] More road name expansion thoughts
On 2014-07-19 14:46, Mike N wrote: St / Saint on a prefix can be so specialized that only a local could sort it out. I suspect that most of the unusual cases would be too complicated for MapRoulette because of the need to consult with a governmental reference. Or a historian. In the Midwest, St. Clair could either refer to the saint or to Arthur St. Clair, whose name wasn't Arthur Saint Clair. (See [1].) I often put the Saint misspelling in alt_name, since the etymology isn't always clear to people searching the map. Unfortunately, that still leaves an ambiguous name for text-to-speech. Too bad there isn't software support for name:pronunciation or name:ipa. [1] https://en.wikipedia.org/wiki/Sinclair_%28surname%29 -- m...@nguyen.cincinnati.oh.us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] USBRS WikiProject seeks volunteer mappers
On 2014-07-19 23:29, Paul Johnson wrote: Likewise, I'm in favor of heirarchies similar to road relations for cyclists (ie, Portland area network=lcn becomes US:OR:Multnomah:Portland or US:OR:Metro or US:OR:Multnomah; Tulsa's LCNs would become US:OK:Tulsa:Riverparks or US:OK:INCOG or US:OK:Tulsa or US:OK:Tulsa:Tusla or US:OK:Tulsa:Broken Arrow...etc http://wiki.openstreetmap.org/wiki/Key:cycle_network http://taginfo.openstreetmap.org/keys/cycle_network#values -- m...@nguyen.cincinnati.oh.us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] USBRS WikiProject seeks volunteer mappers
On Sun, Jul 20, 2014 at 2:17 AM, Minh Nguyen m...@nguyen.cincinnati.oh.us wrote: On 2014-07-19 23:29, Paul Johnson wrote: Likewise, I'm in favor of heirarchies similar to road relations for cyclists (ie, Portland area network=lcn becomes US:OR:Multnomah:Portland or US:OR:Metro or US:OR:Multnomah; Tulsa's LCNs would become US:OK:Tulsa:Riverparks or US:OK:INCOG or US:OK:Tulsa or US:OK:Tulsa:Tusla or US:OK:Tulsa:Broken Arrow...etc http://wiki.openstreetmap.org/wiki/Key:cycle_network http://taginfo.openstreetmap.org/keys/cycle_network#values Nice! OK, so apparently I'm not the first person to think this. Also explains why a vast majority of cycleways, particularly in the areas that taginfo suggests have migrated, aren't rendering on the cyclemap layer. Wonder if we can get Andy Allen to update the style to make use of this scheme. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] OpenStreetMap Foundation Corporate Membership
Since February 2014 your company can support OpenStreetMap Foundation with a corporate membership. The first corporate members were announced today. https://blog.openstreetmap.org/2014/07/20/welcome-corporate-members/ ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-ht] Liste hot-francophone
Bonjour, La liste hot at openstretmap.org est la liste qui permet d'échanger sur le thème d'OSM dans le cadre de l'humanitaire et du développement. Comme la liste talk général, la langue utilisée est l'anglais, ce qui limite la participation des francophones dont la maîtrise de l'anglais est nulle ou limitée ou et difficile l'expression détaillée, riche et nuancée de leurs pensées sur les objets en discussion sur la liste de langue anglaise. Jusqu'à présent, pour informer les francophones sur ces thématiques et les projets en cours, des emails informatifs étaient parfois envoyés à un ensemble de listes talk francophones, ce qui n'est pas idéal pour le suivi des conversations et qui conduit à des duplications de message dans chacun des historiques. Pour y remédier, une liste OSM hot-francophone vient d'être créée permettant aux contributeurs OSM francophones, quelle que soit leur nationalité, de pouvoir échanger en français sur les usages d'OSM dans les champs de l'humanitaire et du développement au nord et au sud Comme pour les listes talk-pays ou dev-quelquechose, elle ne vise pas à concurrencer la liste principale, mais à permettre les échanges au sein d'une communauté de langue et de culture spécifique, et aura un dialogue continu avec la liste anglophone existante. Les hispanophones semblent intéressés pour disposer également d'une telle liste. Pour vous inscrire : https://lists.openstreetmap.org/listinfo/hot-francophone Excellente journée à tous/toutes, Nicolas -- Nicolas Chavent Projet OpenStreetMap (OMS) Projet Humanitarian OpenStreetMap Team (HOT) Projet Espace OSM Francophone (EOF) Mobile (FRA): +33 (0)6 52 40 78 20 nicolas.chav...@hotosm.org Email: nicolas.chav...@gmail.com Skype: c_nicolas Twitter: nicolas_chavent ___ Talk-ht mailing list Talk-ht@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ht Notez! Vous pouvez utiliser Google Translate (http://translate.google.com) pour traduire les messages.
Re: [Talk-ht] Images drone de Saint Marc, et Université de Limonade
Bonjour, On a pu comparer avec Jean G le calage de l'image avec la campagne GPS differentiel de 2012. L'image est bien calée ( - de 3m ) de façon homogene et sans GCP. Les images UAV viennent avec un bon calage et l'image est tres nette. Du coup il y a un gros travail de mise a jour de la cartographie et de controle qualité, Ne pas hésiter à faire des retours, Merci bien FredM ___ Talk-ht mailing list Talk-ht@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ht Notez! Vous pouvez utiliser Google Translate (http://translate.google.com) pour traduire les messages.
