Re: [Talk-br] Digest Talk-br, volume 44, assunto 5
Ola Arlete e D4RK-L3G10N, Como eu ja havia dito, o Cadastro Nacional de Enderecos Fins Estatisticos (CNEFE) tem um total de 81,5 milhões endereços para todo o Brasil. Entre eles, 9,7 milhões endereços sao georeferenciados com um valor Latitude e Longitude. Todos os outros endereços nao tem esta informação, so se sabe a que setor censitário eles pertencem. Os setores censitários tem a classificação: Situação do setor (1=urbano, 2=rural). Approx. 98% dos endereços georeferenciados estão localisados dentro de setores censitários rurais. No RS, Porto Alegre não tem nenhum endereço georeferenciado, Novo Hamburgo tambem não tem. Entre os endereços georeferenciados tem duplicatas no sentido que endereços semelhantes vem com as mesmas coordenadas geogr áficas. Depois de eliminar essas duplicatas (distância mínima entre as coordenadas: ~10 metros), encontrei os seguintes números de endereços: Município 3550308 SÃO PAULO: 6092 Município 3541406 PRESIDENTE PRUDENTE: 1954 Como varias pessoas estão interessados nos dados de endereços georeferenciados: o melhor seria de concordar sobre - o formato mais adequado (kml, osm, shp, gpx, ...) - tamanhos razoáveis (divisão em estados, municípios, ...) - eliminar coordenadas duplicatas ou não - a seleção mais adequada de atributos - onde publicar os dados Para meu próprio uso, só preciso de alguns municípios do RS. Decidi de eliminar essas duplicatas e transformar os endereços restantes em formato kml, que posso usar como background layer, no Potlatch2 editor. Eu só uso o atributo Logradouro (como Placemark name) e Localidade - Identificação estabelecimento (como Placemark description). Não uso JOSM e tambem não sei se o JOSM tem alguma função para usar background vector files. Mas o JOSM não é o irmão grande do Potlatch? Então deve haver alguma função/plugin para isso. Um abraço, Hermann On 05/05/2012 00:46, Arlete Meneguette wrote: Hermann Minha área de estudo é Presidente Prudente, SP. Você pode me ajudar? Grata. Arlete Em 04/05/2012 19:26, D4RK-L3G10N d4rkl3g...@yahoo.com mailto:d4rkl3g...@yahoo.com escreveu: Olá Hermann, Eu tenho interesse na geração de um arquivo para a região metropolitana de São Paulo somente, mas se for muito trabalho pra você restringir para uma área menor, pode ser de todo o estado também, o que for mais fácil para você. :) Uma pergunta: esses arquivos podem ser lidos pelo JOSM? É o programa que eu uso. Muito obrigado! D4RK-L3G10N *From:* talk-br-requ...@openstreetmap.org mailto:talk-br-requ...@openstreetmap.org talk-br-requ...@openstreetmap.org mailto:talk-br-requ...@openstreetmap.org *To:* talk-br@openstreetmap.org mailto:talk-br@openstreetmap.org *Sent:* Friday, May 4, 2012 8:00 AM *Subject:* Digest Talk-br, volume 44, assunto 5 Enviar submissões para a lista de discussão Talk-br para talk-br@openstreetmap.org mailto:talk-br@openstreetmap.org Para se cadastrar ou descadastrar via WWW, visite o endereço http://lists.openstreetmap.org/listinfo/talk-br ou, via email, envie uma mensagem com a palavra 'help' no assunto ou corpo da mensagem para talk-br-requ...@openstreetmap.org mailto:talk-br-requ...@openstreetmap.org Você poderá entrar em contato com a pessoa que gerencia a lista pelo endereço talk-br-ow...@openstreetmap.org mailto:talk-br-ow...@openstreetmap.org Quando responder, por favor edite sua linha Assunto assim ela será mais específica que Re: Contents of Talk-br digest... Tópicos de Hoje: 1. Re: Street name data (Hermann Peifer) 2. Re: Street name data (vitor) -- Message: 1 Date: Thu, 03 May 2012 21:16:39 +0200 From: Hermann Peifer pei...@gmx.eu mailto:pei...@gmx.eu To: OSM talk-br talk-br@openstreetmap.org mailto:talk-br@openstreetmap.org Subject: Re: [Talk-br] Street name data Message-ID: 4fa2d997.7040...@gmx.eu mailto:4fa2d997.7040...@gmx.eu Content-Type: text/plain; charset=windows-1252; format=flowed Se alguem quiser: posso gerar arquivos kml (ou shp, ...) para todos os municipios (ou estados) do Brasil. Nao custa muito. Ja fiz os ~500 municipios do RS (em approx. 1 hora). Veja abaixo um exemplo de um Placemark [1]. Minha maneira de processar os dados era: 0) wget -r ftp://ftp.ibge.gov.br/Censos/Censo_Demografico_2010/... 1) unzip 2) awk -f coordinates.awk ibge_file.txt out_file.csv 3) ogr2ogr -f kml out_file.kml out_file.csv Abs, Hermann [1] Placemark nameESTRADA PARIS PINHEIRO MACHADO 0SN/name ExtendedData SchemaData schemaUrl=#Enderecos_IBGE SimpleData name=NameESTRADA PARIS PINHEIRO MACHADO 0SN/SimpleData SimpleData name=Setor43026590514/SimpleData SimpleData
Re: [Talk-br] Digest Talk-br, volume 44, assunto 5
Aqui uma captura do Google Earth com os dados de São Paulo e Presidente Prudente: https://docs.google.com/open?id=0B7wH21aRzMT_MlBxWEFEb2U5NkU Hermann On 05/05/2012 10:22, Hermann Peifer wrote: Ola Arlete e D4RK-L3G10N, Como eu ja havia dito, o Cadastro Nacional de Enderecos Fins Estatisticos (CNEFE) tem um total de 81,5 milhões endereços para todo o Brasil. Entre eles, 9,7 milhões endereços sao georeferenciados com um valor Latitude e Longitude. Todos os outros endereços nao tem esta informação, so se sabe a que setor censitário eles pertencem. Os setores censitários tem a classificação: Situação do setor (1=urbano, 2=rural). Approx. 98% dos endereços georeferenciados estão localisados dentro de setores censitários rurais. No RS, Porto Alegre não tem nenhum endereço georeferenciado, Novo Hamburgo tambem não tem. Entre os endereços georeferenciados tem duplicatas no sentido que endereços semelhantes vem com as mesmas coordenadas geogr áficas. Depois de eliminar essas duplicatas (distância mínima entre as coordenadas: ~10 metros), encontrei os seguintes números de endereços: Município 3550308 SÃO PAULO: 6092 Município 3541406 PRESIDENTE PRUDENTE: 1954 Como varias pessoas estão interessados nos dados de endereços georeferenciados: o melhor seria de concordar sobre - o formato mais adequado (kml, osm, shp, gpx, ...) - tamanhos razoáveis (divisão em estados, municípios, ...) - eliminar coordenadas duplicatas ou não - a seleção mais adequada de atributos - onde publicar os dados Para meu próprio uso, só preciso de alguns municípios do RS. Decidi de eliminar essas duplicatas e transformar os endereços restantes em formato kml, que posso usar como background layer, no Potlatch2 editor. Eu só uso o atributo Logradouro (como Placemark name) e Localidade - Identificação estabelecimento (como Placemark description). Não uso JOSM e tambem não sei se o JOSM tem alguma função para usar background vector files. Mas o JOSM não é o irmão grande do Potlatch? Então deve haver alguma função/plugin para isso. Um abraço, Hermann ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Digest Talk-br, volume 44, assunto 5
Bom dia a todos Estou respondendo com Cc para o Prof. Dr. Edilson Flores, meu colega na Unesp - Campus de Presidente Prudente. Ele também tem interesse nos dados do CNEFE e com certeza poderá colaborar conosco na definição dos atributos, formatos etc. Uma novidade: teremos uma sessão OSM no MundoGEO#Connect LatinAmerica 2012. Em breve as informações estarão disponíveis em http://mundogeoconnect.com/2012/grade/ O Eduardo (MundoGEO) está copiado nesta msg. Finalmente poderemos nos encontrar pessoalmente em São Paulo Arlete Em 5 de maio de 2012 05:22, Hermann Peifer pei...@gmx.eu escreveu: Ola Arlete e D4RK-L3G10N, Como eu ja havia dito, o Cadastro Nacional de Enderecos Fins Estatisticos (CNEFE) tem um total de 81,5 milhões endereços para todo o Brasil. Entre eles, 9,7 milhões endereços sao georeferenciados com um valor Latitude e Longitude. Todos os outros endereços nao tem esta informação, so se sabe a que setor censitário eles pertencem. Os setores censitários tem a classificação: Situação do setor (1=urbano, 2=rural). Approx. 98% dos endereços georeferenciados estão localisados dentro de setores censitários rurais. No RS, Porto Alegre não tem nenhum endereço georeferenciado, Novo Hamburgo tambem não tem. Entre os endereços georeferenciados tem duplicatas no sentido que endereços semelhantes vem com as mesmas coordenadas geogr áficas. Depois de eliminar essas duplicatas (distância mínima entre as coordenadas: ~10 metros), encontrei os seguintes números de endereços: Município 3550308 SÃO PAULO: 6092 Município 3541406 PRESIDENTE PRUDENTE: 1954 Como varias pessoas estão interessados nos dados de endereços georeferenciados: o melhor seria de concordar sobre - o formato mais adequado (kml, osm, shp, gpx, ...) - tamanhos razoáveis (divisão em estados, municípios, ...) - eliminar coordenadas duplicatas ou não - a seleção mais adequada de atributos - onde publicar os dados Para meu próprio uso, só preciso de alguns municípios do RS. Decidi de eliminar essas duplicatas e transformar os endereços restantes em formato kml, que posso usar como background layer, no Potlatch2 editor. Eu só uso o atributo Logradouro (como Placemark name) e Localidade - Identificação estabelecimento (como Placemark description). Não uso JOSM e tambem não sei se o JOSM tem alguma função para usar background vector files. Mas o JOSM não é o irmão grande do Potlatch? Então deve haver alguma função/plugin para isso. Um abraço, Hermann On 05/05/2012 00:46, Arlete Meneguette wrote: Hermann Minha área de estudo é Presidente Prudente, SP. Você pode me ajudar? Grata. Arlete Em 04/05/2012 19:26, D4RK-L3G10N d4rkl3g...@yahoo.com mailto:d4rkl3g...@yahoo.com escreveu: Olá Hermann, Eu tenho interesse na geração de um arquivo para a região metropolitana de São Paulo somente, mas se for muito trabalho pra você restringir para uma área menor, pode ser de todo o estado também, o que for mais fácil para você. :) Uma pergunta: esses arquivos podem ser lidos pelo JOSM? É o programa que eu uso. Muito obrigado! D4RK-L3G10N *From:* talk-br-requ...@openstreetmap.org mailto:talk-br-requ...@openstreetmap.org talk-br-requ...@openstreetmap.org mailto:talk-br-requ...@openstreetmap.org *To:* talk-br@openstreetmap.org mailto:talk-br@openstreetmap.org *Sent:* Friday, May 4, 2012 8:00 AM *Subject:* Digest Talk-br, volume 44, assunto 5 Enviar submissões para a lista de discussão Talk-br para talk-br@openstreetmap.org mailto:talk-br@openstreetmap.org Para se cadastrar ou descadastrar via WWW, visite o endereço http://lists.openstreetmap.org/listinfo/talk-br ou, via email, envie uma mensagem com a palavra 'help' no assunto ou corpo da mensagem para talk-br-requ...@openstreetmap.org mailto:talk-br-requ...@openstreetmap.org Você poderá entrar em contato com a pessoa que gerencia a lista pelo endereço talk-br-ow...@openstreetmap.org mailto:talk-br-ow...@openstreetmap.org Quando responder, por favor edite sua linha Assunto assim ela será mais específica que Re: Contents of Talk-br digest... Tópicos de Hoje: 1. Re: Street name data (Hermann Peifer) 2. Re: Street name data (vitor) -- Message: 1 Date: Thu, 03 May 2012 21:16:39 +0200 From: Hermann Peifer pei...@gmx.eu mailto:pei...@gmx.eu To: OSM talk-br talk-br@openstreetmap.org mailto:talk-br@openstreetmap.org Subject: Re: [Talk-br] Street name data Message-ID: 4fa2d997.7040...@gmx.eu mailto:4fa2d997.7040...@gmx.eu Content-Type: text/plain; charset=windows-1252; format=flowed Se alguem quiser: posso gerar arquivos kml (ou shp, ...) para todos os municipios (ou estados) do Brasil. Nao custa muito. Ja fiz os ~500
Re: [Talk-br] Digest Talk-br, volume 44, assunto 5
Oi Arlete, Boa tarde da Dinamarca. Em relação às variáveis: tem um total de 19 variáveis, segundo o arquivo 'Layouts.csv' [1]. Eu fiz um kml com todos endereços georeferenciados de Presidente Prudente (2506 pontos), com todas variáveis [2]. Mais não tem no cadastro. Tambem tem que verificar a qualidade dos dados CNEFE. Eu vi numa estrada rural em Ivoti, RS que os endereços de um lado tem como Logradouro: RUA SAO JOAO, no outro lado: ESTRADA PICADA SCHNEIDER [3]. Isto não é muito provável. Talvez tem mais problemas nos dados. Um abraço, Hermann [1] ftp.ibge.gov.br/Censos/Censo_Demografico_2010/Cadastro_Nacional_de_Enderecos_Fins_Estatisticos/Layouts.csv Layouts.csv (com algumas correções) --- snip --- # # Variável;Tamanho;Categorias # 1 Código da UF;2; # 2 Código do município;5; # 3 Código do distrito;2; # 4 Código do subdistrito;2; # 5 Código do setor;4; # 6 Situação do setor;1; #;;1=urbano #;;2=rural # 7 Logradouro;110; # 8 Número no logradouro;15; # 9 Complemento;180; # 10 Latitude;15; # 11 Longitude;15; # 12 Localidade;120; # 13 Espécie de endereço;2; #;;01=domicílio particular #;;02=domicílio coletivo #;;03=estabeleciemento agropecuário #;;04=estabelecimento de ensino #;;05=estabelecimento de saúde #;;06=estabeleciemento de outras finalidades #;;07=edificação em construção # 14 Identificação estabelecimento;40; # 15 Indicador de endereço;1; #;;1=único #;;2=múltiplo # 16 identificação domicílio coletivo;30; # 17 Número da quadra (*);3; # 18 Número da face;3; # 19 CEP;8; --- snip --- [2] https://docs.google.com/open?id=0B7wH21aRzMT_eDdJMWRQZ0Q2Q1k [3] https://docs.google.com/open?id=0B7wH21aRzMT_VHYzd2h2VkJNT00 On 05/05/2012 13:01, Arlete Meneguette wrote: Bom dia a todos Estou respondendo com Cc para o Prof. Dr. Edilson Flores, meu colega na Unesp - Campus de Presidente Prudente. Ele também tem interesse nos dados do CNEFE e com certeza poderá colaborar conosco na definição dos atributos, formatos etc. Uma novidade: teremos uma sessão OSM no MundoGEO#Connect LatinAmerica 2012. Em breve as informações estarão disponíveis em http://mundogeoconnect.com/2012/grade/ O Eduardo (MundoGEO) está copiado nesta msg. Finalmente poderemos nos encontrar pessoalmente em São Paulo Arlete Em 5 de maio de 2012 05:22, Hermann Peiferpei...@gmx.eu escreveu: Ola Arlete e D4RK-L3G10N, Como eu ja havia dito, o Cadastro Nacional de Enderecos Fins Estatisticos (CNEFE) tem um total de 81,5 milhões endereços para todo o Brasil. Entre eles, 9,7 milhões endereços sao georeferenciados com um valor Latitude e Longitude. Todos os outros endereços nao tem esta informação, so se sabe a que setor censitário eles pertencem. Os setores censitários tem a classificação: Situação do setor (1=urbano, 2=rural). Approx. 98% dos endereços georeferenciados estão localisados dentro de setores censitários rurais. No RS, Porto Alegre não tem nenhum endereço georeferenciado, Novo Hamburgo tambem não tem. Entre os endereços georeferenciados tem duplicatas no sentido que endereços semelhantes vem com as mesmas coordenadas geogr áficas. Depois de eliminar essas duplicatas (distância mínima entre as coordenadas: ~10 metros), encontrei os seguintes números de endereços: Município 3550308 SÃO PAULO: 6092 Município 3541406 PRESIDENTE PRUDENTE: 1954 Como varias pessoas estão interessados nos dados de endereços georeferenciados: o melhor seria de concordar sobre - o formato mais adequado (kml, osm, shp, gpx, ...) - tamanhos razoáveis (divisão em estados, municípios, ...) - eliminar coordenadas duplicatas ou não - a seleção mais adequada de atributos - onde publicar os dados Para meu próprio uso, só preciso de alguns municípios do RS. Decidi de eliminar essas duplicatas e transformar os endereços restantes em formato kml, que posso usar como background layer, no Potlatch2 editor. Eu só uso o atributo Logradouro (como Placemark name) e Localidade - Identificação estabelecimento (como Placemark description). Não uso JOSM e tambem não sei se o JOSM tem alguma função para usar background vector files. Mas o JOSM não é o irmão grande do Potlatch? Então deve haver alguma função/plugin para isso. Um abraço, Hermann On 05/05/2012 00:46, Arlete Meneguette wrote: Hermann Minha área de estudo é Presidente Prudente, SP. Você pode me ajudar? Grata. Arlete Em 04/05/2012 19:26, D4RK-L3G10Nd4rkl3g...@yahoo.com mailto:d4rkl3g...@yahoo.com escreveu: Olá Hermann, Eu tenho interesse na geração de um arquivo para a região metropolitana de São Paulo somente, mas se for muito trabalho pra você restringir para uma área menor, pode ser de todo o estado também, o que for mais fácil para você. :) Uma pergunta: esses arquivos podem ser lidos pelo JOSM? É o programa que eu uso. Muito obrigado! D4RK-L3G10N ___ Talk-br mailing list Talk-br@openstreetmap.org
Re: [Talk-br] Street name data
Gostei :) mas de onde vem o programa ogr2ogr? A sintaxe parece do gpsbabel... abraço Gerald Minha maneira de processar os dados era: 0) wget -r ftp://ftp.ibge.gov.br/Censos/Censo_Demografico_2010/... 1) unzip 2) awk -f coordinates.awk ibge_file.txt out_file.csv 3) ogr2ogr -f kml out_file.kml out_file.csv ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Street name data
On 05/05/2012 16:43, Gerald Weber wrote: Gostei :) mas de onde vem o programa ogr2ogr? A sintaxe parece do gpsbabel... ogr2ogr: a commandline tool providing read (and sometimes write) access to a variety of vector file formats... http://www.gdal.org/ogr2ogr.html http://www.gdal.org/ogr/ogr_formats.html Um abraco, Hermann ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Street name data
Ola Hermann Tentei gerar um kml usando os comandos que você mostrou, mas não entendi de onde veio o arquivo coordinates.awk. É um arquivo de parâmetros criados por você? abçs, wille On 03-05-2012 16:16, Hermann Peifer wrote: Se alguem quiser: posso gerar arquivos kml (ou shp, ...) para todos os municipios (ou estados) do Brasil. Nao custa muito. Ja fiz os ~500 municipios do RS (em approx. 1 hora). Veja abaixo um exemplo de um Placemark [1]. Minha maneira de processar os dados era: 0) wget -r ftp://ftp.ibge.gov.br/Censos/Censo_Demografico_2010/... 1) unzip 2) awk -f coordinates.awk ibge_file.txt out_file.csv 3) ogr2ogr -f kml out_file.kml out_file.csv Abs, Hermann [1] Placemark nameESTRADA PARIS PINHEIRO MACHADO 0SN/name ExtendedData SchemaData schemaUrl=#Enderecos_IBGE SimpleData name=NameESTRADA PARIS PINHEIRO MACHADO 0SN/SimpleData SimpleData name=Setor43026590514/SimpleData SimpleData name=SituacaoSetor2/SimpleData SimpleData name=LogradouroESTRADA PARIS PINHEIRO MACHADO/SimpleData SimpleData name=NumeroLogradouro0SN/SimpleData SimpleData name=Complemento/ SimpleData name=Latitude-29.496827/SimpleData SimpleData name=Longitude-51.647645/SimpleData SimpleData name=LocalidadeNOVO PARIS/SimpleData SimpleData name=EspecieEndereco06/SimpleData SimpleData name=EstabelecimentoCEMITERIO EVANGELICO NOVO PARIS/SimpleData SimpleData name=IndicadorEndereco1/SimpleData SimpleData name=DomicilioColetivo/ SimpleData name=NumeroQuadra000/SimpleData SimpleData name=NumeroFace000/SimpleData SimpleData name=CEP9579/SimpleData /SchemaData /ExtendedData Point coordinates-51.647645,-29.496827/coordinates /Point /Placemark On 03/05/2012 17:47, Rodrigo Avila wrote: Oi Hermann, pode ensinar como faz isso? A cidade onde moro é mais rural que urbana, então... -- Rodrigo de Avila Analista de Desenvolvimento rodr...@avila.net.br mailto:rodr...@avila.net.br• www.avila.net.br http://www.avila.net.br Em 3 de maio de 2012 12:42, Hermann Peifer pei...@gmx.eu mailto:pei...@gmx.eu escreveu: On 02/05/2012 16:20, Arlindo Pereira wrote: Hermann: seu português está melhor do que o de muitos brasileiros ;-) Vitor: sabe informar a licença desses dados do IBGE? Tem muita rua aqui no Rio traçada a partir das imagens do Bing que ainda está sem nome. Ontem baxei todos os dados do Cadastro Nacional de Endereços Fins Estatisticos [1]. São 10903 arquivos com um total de 81+ M endereços. Entre eles, achei ~ 9 M endereços georeferenciadas. Quase todos eles estão situados nos setores rurais, normalmente perto das estradas principais. Aqui um exemplo de Ivoti, Rio Grande do Sul [2]. Infelizmente, não achei nemhuma informaçao sobre a licença desses dados do IBGE :-( Abs, Hermann [1] ftp://ftp.ibge.gov.br/Censos/__Censo_Demografico_2010/__Cadastro_Nacional_de___Enderecos_Fins_Estatisticos ftp://ftp.ibge.gov.br/Censos/Censo_Demografico_2010/Cadastro_Nacional_de_Enderecos_Fins_Estatisticos [2] https://docs.google.com/open?__id=0B7wH21aRzMT___bmpDU3hGMTQ0SkE https://docs.google.com/open?id=0B7wH21aRzMT_bmpDU3hGMTQ0SkE _ Talk-br mailing list Talk-br@openstreetmap.org mailto:Talk-br@openstreetmap.org http://lists.openstreetmap.__org/listinfo/talk-br http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-de] Hausnummern auf Gebäudeumriss ?!
On 11-11-18 15:03, Martin Koppenhoefer wrote: +0.5, eigentlich gehört die Hausnummer ans Grundstück, zumindest wenn es wie z.B. in Berlin Grundstücksnummern sind (das ist je nach Bundesland oder evtl. sogar Komune ggf. anders). Solange kein Grundstück gemappt ist, halte ich das Haus auch für eine brauchbare Annäherung. Das beantwortet vielleicht die Frage, ob unbebaute Grundstücke Haus-Nummern haben oder nicht. Wie sehen dazu hier die Meinungen aus? Beispielsweise habe ich bei der letzten Prüfung Einträge gefunden, wo der Mapper es vorzog, die Hausnummern dort in Klammern zu setzen. Schönen Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern auf Gebäudeumriss ?!
Hallo. Am 05.05.2012 08:54, schrieb Martin Trautmann: Das beantwortet vielleicht die Frage, ob unbebaute Grundstücke Haus-Nummern haben oder nicht. Wie sehen dazu hier die Meinungen aus? Das hat Martin doch in dem Teil den du zitiert hast beantwortet: Das ist je nach Land oder Kommune unterschiedlich. Bei uns kenne ich das so, dass Hausnummern mit dem Bebauungsplan vergeben werden. Wird also ein Baugebiet ausgewiesen, werden dafür Hausnummern vergeben. Baut jemand auf ein Grundstück das nicht vorher als Baugebiet ausgewiesen wurde (z.B. privilegierter Bau als Landwirtschaft am Ortsrand), dann wird im Zuge der Baugenehmigung eine Hausnummer vergeben. Es haben sicherlich nicht alle Grundstücke auf der grünen Wiese Hausnummern, aber diejenigen innerorts die einem Bebauungsplan unterliegen haben (zumindest bei uns) im Vorfeld bereits Hausnummern. Beispielsweise habe ich bei der letzten Prüfung Einträge gefunden, wo der Mapper es vorzog, die Hausnummern dort in Klammern zu setzen. Eine interessante Idee aber der Mehrwert erschließt sich mir nicht so richtig. Gruß, Bernd -- Von all den Dingen, die mir verloren gegangen sind, habe ich am meisten an meinem Verstand gehangen. - Ozzy Osbourne (engl. Schauspieler und Musiker) signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern auf Gebäudeumriss ?!
On 12-05-05 9:02, Bernd Wurst wrote: Hallo. Am 05.05.2012 08:54, schrieb Martin Trautmann: Das beantwortet vielleicht die Frage, ob unbebaute Grundstücke Haus-Nummern haben oder nicht. Wie sehen dazu hier die Meinungen aus? Das hat Martin doch in dem Teil den du zitiert hast beantwortet: Das ist je nach Land oder Kommune unterschiedlich. Heisst das folglich, dass man hier den Kommunal- bzw. Landesvorgaben folgen soll oder gibt es eine pauschal gültige Empfehlung für den deutschsprachigen Raum? Ich gehe hier von der grundsätzlichen Vorgehensweise aus, dass Nummern in einer Straße fortlaufend vergeben werden - also entweder auf der einen Seite die geraden, gegenüber die ungeraden, oder auf einer Seite fortlaufend. Aber selbst bei der Vergabe in chronologischer oder sonstwie anderer Reihenfolge kann man die Hausnummer noch vor jeglichem Baubeginn dem Grundstück zuweisen, soweit bekannt. Bei uns kenne ich das so, dass Hausnummern mit dem Bebauungsplan vergeben werden. Wird also ein Baugebiet ausgewiesen, werden dafür Hausnummern vergeben. Baut jemand auf ein Grundstück das nicht vorher als Baugebiet ausgewiesen wurde (z.B. privilegierter Bau als Landwirtschaft am Ortsrand), dann wird im Zuge der Baugenehmigung eine Hausnummer vergeben. Es haben sicherlich nicht alle Grundstücke auf der grünen Wiese Hausnummern, aber diejenigen innerorts die einem Bebauungsplan unterliegen haben (zumindest bei uns) im Vorfeld bereits Hausnummern. Beispielsweise habe ich bei der letzten Prüfung Einträge gefunden, wo der Mapper es vorzog, die Hausnummern dort in Klammern zu setzen. Eine interessante Idee aber der Mehrwert erschließt sich mir nicht so richtig. Ja, ich kann da auch keinerlei Vorteil darin erkennen, zwischen den bebauten Grundstücken 11 und 15 das unbebaute Grundstück dazwischen mit (13) zu markieren. Hypothetische Übertreibung: sonst könnte ich jedem hinreichend großen Grundstück auch noch die potentiellen Hausnummern (11a;11b;11c) hinzufügen. Die Hausnummer ist z.B. für's Routing interessant. Ich kenne die Algorithmen nicht, kann aber keinen Nährwert darin erkennen, die Hausnummern zu modifizieren, statt die Hausnummer selbst anzugeben. Randfrage dazu: gibt es in JOSM oder sonstwo ein Tool, mit dem ich Properties eines einzelnen Nodes direkt auf das Building-Polygon übertragen könnte? Nach Studium des Wiki scheint das die empfohlenere Vorgehensweise zu sein. copy/paste von mehreren Properties scheint in JOSM nicht vorgesehen zu sein? Schönen Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern auf Gebäudeumriss ?!
Am 05.05.2012 08:54, schrieb Martin Trautmann: On 11-11-18 15:03, Martin Koppenhoefer wrote: +0.5, eigentlich gehört die Hausnummer ans Grundstück, zumindest wenn es wie z.B. in Berlin Grundstücksnummern sind (das ist je nach Bundesland oder evtl. sogar Komune ggf. anders). Solange kein Grundstück gemappt ist, halte ich das Haus auch für eine brauchbare Annäherung. Das beantwortet vielleicht die Frage, ob unbebaute Grundstücke Haus-Nummern haben oder nicht. Wie sehen dazu hier die Meinungen aus? Beispielsweise habe ich bei der letzten Prüfung Einträge gefunden, wo der Mapper es vorzog, die Hausnummern dort in Klammern zu setzen. Schönen Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Im städtischen und dicht besiedelten Gebiet vielleicht noch möglich. Wenn man aber aufs Land geht und dort nach einem Haus sucht, kann es sein, dass der Mittelpunkt der Fläche weit ab des Hauses ist. Ich für mich suche mit der Hausnummer das Haus und kein Grundstück. Unbebaute Grundstücke haben meist keine Hausnummer, führt dann auch manchmal dazu dass es 3...5a...5b5c5d7 usw gibt. Wenn zwischen zwei Häusern Hausnummern frei gelassen wurden, dann würde ich interpolierte Adressen nehmen. Falls mal dort gebaut wird und keine die Daten wartet, werden die Ergebnisse trotzdem halbwegs korrekt sein. LG Jimmy ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern auf Gebäudeumriss ?!
Hallo, meine Empfehlung wäre nur die Infos zu mappen, bei denen du mehr oder weniger sicher sagen kannst, dass sie stimmen. Je sicherer sollte man sein, desto schwieriger sie auffallen. Wenn man mal eine Straße statt living_street mit residential gemappt hat, ist das sicher unschön, aber der Fehler fällt jedem Mapper auf, der da lang kommt. Wenn an der Straße eine oder mehrere Hausnummern falsch sind, fällt das wohl kaum jemanden auf, der nicht gerade besonders drauf achtet. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern auf Gebäudeumriss ?!
On 12-05-05 9:26, Jimmy_K wrote: Im städtischen und dicht besiedelten Gebiet vielleicht noch möglich. Nun, dort steht der Großteil der Häuser, die für Navis relevant sind. Wenn man aber aufs Land geht und dort nach einem Haus sucht, kann es sein, dass der Mittelpunkt der Fläche weit ab des Hauses ist. Ich für mich suche mit der Hausnummer das Haus und kein Grundstück. Du vermischst hier mehrere Dinge: A) Grundstück B) Haus C) Eingang zum Haus D) Eingang zum Grundstück Wenn ich irgendwo hin will, dann suche ich als erstes D, als nächstes C, wahlweise auch umgekehrt bei getrennten Zugängen zu Grundstück und Haus. Bei der Frage hier ging es aber um Grundstücke, für die bereits eine Hausnummer zugewiesen ist, aber noch keine Bebauung existiert. Damit entfällt also deine Argumentation oben, da B und C überhaupt noch nicht existieren. Solltest du auf dem Grundstück etwas zu suchen haben, dann dürfte dich speziell D interessieren. Die Haus-Nummer gehört dann sinnvollerweise zum gesamten Grundstück, der entrance kann separat markiert werden. Unbebaute Grundstücke haben meist keine Hausnummer, Du lehnst dich mit dem meist weit aus dem Fenster. Richtig ist, dass dort kein Haus steht, auf dem ein Hausnummernschild hängen würde. Richtig ist aber auch, dass im Bebauungsplan diese Hausnummern oft, wenn nicht meist schon vorgesehen sind. Wer sein Haus zwischen 11 und 15 baut, der wird sich nicht einfach die 99 als Hausnummer aussuchen dürfen. führt dann auch manchmal dazu dass es 3...5a...5b5c5d7 usw gibt. Nachverdichtung über den ursprünglichen Bebauungsplan hinaus. Wenn zwischen zwei Häusern Hausnummern frei gelassen wurden, dann würde ich interpolierte Adressen nehmen. Falls mal dort gebaut wird und keine die Daten wartet, werden die Ergebnisse trotzdem halbwegs korrekt sein. Ich kenne es hier so, dass die Hausnummern schon fest den Grundstücken zugeordnet ist. Wer also auf dem ehemaligen Teilgrundstück von Hausnummer 15 baut, der wird die 15 a o.ä. bekommen, auch wenn die 13 noch nicht genutzt wird - weil die schon für das Nachbargrundstück reserviert ist. Schönen Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern auf Gebäudeumriss ?!
On 12-05-05 9:30, aighes wrote: Hallo, meine Empfehlung wäre nur die Infos zu mappen, bei denen du mehr oder weniger sicher sagen kannst, dass sie stimmen. Je sicherer sollte man sein, desto schwieriger sie auffallen. Wenn man mal eine Straße statt living_street mit residential gemappt hat, ist das sicher unschön, aber der Fehler fällt jedem Mapper auf, der da lang kommt. Wenn an der Straße eine oder mehrere Hausnummern falsch sind, fällt das wohl kaum jemanden auf, der nicht gerade besonders drauf achtet. Hallo Henning, der Teilaspekt ist völlig richtig. Meine Frage bezieht sich aber auf den Dualismus, dass Gebäudeumriss wie auch Hausnummern-Knoten bereits existieren. Da hat also schon jemand vorab die Entscheidung getroffen, welche Hausnummer dort zu liegen hat. Bei der aktuellen Qualität der Daten sieht es auch so aus, als hätten in manchen Gegengen Daten zur Verfügung gestanden, die mittels OCR übersetzt und als Knoten eingespielt wurden. Ob das Haus mit Umriss zu dem Zeitpunkt dort schon stand oder erst später hinzugefügt wurde spielt für mich keine Rolle: Wenn der Knoten innerhalb des Gebäudes liegt, dann ist sehr wahrscheinlich, dass diese Information dem Building zugeordnet werden kann. Etwas aufwändiger ist es z.B. bei Doppelhaushälften, die zwei getrennte Hausnummern-Nodes haben. Da ziehe ich es vor. das Polygon erst mal aufzutrennen und jeder Hälfte die Nausnummern-Info zuzuordnen - auf die Gefahr hin, dass diese Gebäude in der Realität vielleicht nicht 50:50, sondern tatsächlich vielleicht sogar 80:20 aufgeteilt wären. Praktische Erfahrung zeigt, dass der 50:50-Ansatz meist funktioniert - selbst wenn Doppelhäuser z.B. etagenweise fusioniert werden und z.B. das EG zu 5a gehört, das OG zu 5b. Solche umso problematischeren Fälle sind mit Kartenmaterial ohnehin nicht auflösbar, da braucht's Grundbuch und 3D-Daten. Das Grundbuch hat obendrein auch noch als vierte Dimension die Zeitachse drin, was wann wohin gehörte. Von daher nochmals die Frage: Was ist der einfachste Weg, um Infos von einem isolierten Hausnummern-Knoten auf das Gebäude zu übertragen? Die Redundanz-Frage lasse ich erst mal aussen vor: Wenn der Knoten mit Stadt und Land daher kommt darf das das Gebäude gerne auch bekommen, auch wenn diese Daten durch die angrenzende Straße usw. mir persönlich als redundant erscheinen. Schönen Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern auf Gebäudeumriss ?!
Am 05.05.2012 09:22, schrieb Martin Trautmann: Randfrage dazu: gibt es in JOSM oder sonstwo ein Tool, mit dem ich Properties eines einzelnen Nodes direkt auf das Building-Polygon übertragen könnte? Nach Studium des Wiki scheint das die empfohlenere Vorgehensweise zu sein. copy/paste von mehreren Properties scheint in JOSM nicht vorgesehen zu sein? Doch, aber ist etwas versteckt. Du kopierst einfach das Objekt (also in diesem Falle den Node), wählst das Zielobjekt (in diesem Fall das Gebäude-Polygon) aus, und wählst dann im Menü Bearbeiten/Merkmale einfügen (oder so ähnlich, hab josm grad nicht offen). Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern auf Gebäudeumriss ?!
Am 05.05.2012 09:22, schrieb Martin Trautmann: Heisst das folglich, dass man hier den Kommunal- bzw. Landesvorgaben folgen soll oder gibt es eine pauschal gültige Empfehlung für den deutschsprachigen Raum? Ich gehe hier von der grundsätzlichen Vorgehensweise aus, dass Nummern in einer Straße fortlaufend vergeben werden - also entweder auf der einen Seite die geraden, gegenüber die ungeraden, oder auf einer Seite fortlaufend. Aber selbst bei der Vergabe in chronologischer oder sonstwie anderer Reihenfolge kann man die Hausnummer noch vor jeglichem Baubeginn dem Grundstück zuweisen, soweit bekannt. Ich kann mir noch vorstellen (hab aber kein Beispiel zur Hand gerade), dass bei breiten Straßen, die z.B. mal aus Plätzen hervorgegangen sind, rundherum nummeriert wird. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern auf Gebäudeumriss ?!
On 05.05.2012 10:37, Peter Wendorff wrote: Du kopierst einfach das Objekt (also in diesem Falle den Node), wählst das Zielobjekt (in diesem Fall das Gebäude-Polygon) aus, und wählst dann im Menü Bearbeiten/Merkmale einfügen (oder so ähnlich, hab josm grad nicht offen). oder auch ohne Menüs mit Ctrl-C kopieren und mit Shift-Ctrl-C die kopierten Properties zum neu ausgewählten Objekt hinzufügen -- hartmut ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern auf Gebäudeumriss ?!
Am 05.05.2012 10:11, schrieb Martin Trautmann: On 12-05-05 9:26, Jimmy_K wrote: Im städtischen und dicht besiedelten Gebiet vielleicht noch möglich. Nun, dort steht der Großteil der Häuser, die für Navis relevant sind. -1 In der Stadt reicht mir die Straße und ungefähr die Lage darin (bei langen Straßen) dann ist es auch kein Problem, zweihundert Meter in die eine oder andere Richtung weiterlaufen oder fahren zu müssen. Liegt auf dem Land das nächste Haus aber blöderweise 3 km weiter weg, wär ich besser an der nächsten Bushaltestelle ausgestiegen oder hätte darauf verzichtet, von 70 auf 25 abzubremsen, um bei schlechter Beleuchtung abends die Hausnummern zu beobachten. Wenn man aber aufs Land geht und dort nach einem Haus sucht, kann es sein, dass der Mittelpunkt der Fläche weit ab des Hauses ist. Ich für mich suche mit der Hausnummer das Haus und kein Grundstück. Du vermischst hier mehrere Dinge: A) Grundstück B) Haus C) Eingang zum Haus D) Eingang zum Grundstück Wenn ich irgendwo hin will, dann suche ich als erstes D, als nächstes C, wahlweise auch umgekehrt bei getrennten Zugängen zu Grundstück und Haus. Bei der Frage hier ging es aber um Grundstücke, für die bereits eine Hausnummer zugewiesen ist, aber noch keine Bebauung existiert. Damit entfällt also deine Argumentation oben, da B und C überhaupt noch nicht existieren. Solltest du auf dem Grundstück etwas zu suchen haben, dann dürfte dich speziell D interessieren. Die Haus-Nummer gehört dann sinnvollerweise zum gesamten Grundstück, der entrance kann separat markiert werden. Ich halte es prinzipiell für durchaus sinnvoll, auch das Grundstück mit der Nummer zu versehen, ich halte es aber - trotz der vielleicht offiziell so korrekten Bezeichnung - für falsch, das als HAUSnummer zu bezeichnen, und würde das deshalb auch gerne getrennt halten, denn wofür werden Hausnummern genutzt? - zum routing: ja, aber normalerweise nur zu Adressen, und eine Adresse hat ein unbebautes Grundstück eigentlich nicht. - zur Kontaktaufnahme oder zu statistischen Zwecken: ja, aber dann für unbebaute Grundstücke auch nicht brauchbar - ... ich sehe jedenfalls (korrigiert mich, wenn ich falsch liege) keinen Anwendungsfall, unbebaute Grunstücke mit bebauten Grundstücken im Bereich der Adresse (addr:*) gleichzusetzen. Zumindest sollte es dann ein Unterscheidungsmerkmal geben. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche nach Elbufer, Bad Schandau
Sorry Sven, mir ist entgangen, dass Du in diesem Thread schon einmal Deine Anpassung von osm.de erwähnt hast. Ansonsten hätte ich Dich direkt angesprochen. @Sarah: Vielen Dank, dass Du meine Frage präzisiert hast. Genau dies habe ich gemeint. Denn wenn man nach z.B. einen Ort sucht und als Ergebnis eine Liste erhält, deren Inhalt sich kaum unterscheidet, dann ist es manchmal schwierig zu erkennen, ob der jeweilige Link auf das Stadtgebiet, den Kreis oder die Stadt verweist. Bei osm.org und auch bei JOSM ist dies besser gelöst. Gruss hike39 Am 04.05.2012 13:33, schrieb Sven Geggus: hike39 ho...@hike.de wrote: nachdem auf diese Fragestellung sich niemand von den osm.de Machern angesprochen gefühlt hat, möchte ich diese Frage irgendjemanden aus dieser Truppe zukommen lassen. Was soll das jetzt? Ich habe die Nominatim Suche auf osm.de postwendend dem Vorschlag von Sarah angepasst, das ist auf dieser Liste nachzulesen! Gruss Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] kein Tracks hochladen
Michael Kugelmann wrote: wie gesagt: ich habe mehrere Gründe * Datenschutz Und ich habe geschrieben, dass ich extra für OSM rausfahre und logge. Datenschutz gilt hier nicht, da es sich um eine extra für OSM-Zwecke durchgeführte Fahrt handelt. * ich vertraue nicht auf fremde Daten (verwende quasi nie fremde Tracks) Das steht dir frei. Wenn ich allerdings die gleiche Strecke fahre und mein Log daneben liegt, dann bleibt mir nichts anderes übrig als die Wege auf meinen Track zu ziehen, da mir dein Track zum Vergleich und ggf. Ausmitteln fehlt. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern auf Gebäudeumriss ?!
On 05/05/12 10:40, Hartmut Holzgraefe wrote: On 05.05.2012 10:37, Peter Wendorff wrote: Du kopierst einfach das Objekt (also in diesem Falle den Node), wählst das Zielobjekt (in diesem Fall das Gebäude-Polygon) aus, und wählst dann im Menü Bearbeiten/Merkmale einfügen (oder so ähnlich, hab josm grad nicht offen). oder auch ohne Menüs mit Ctrl-C kopieren und mit Shift-Ctrl-C die kopierten Properties zum neu ausgewählten Objekt hinzufügen Um noch einen Schritt weiter zu gehen: 1. utilsplugin2 bietet auch einen Befehl um Relationen zu kopieren und den ReplaceObject-Befehl (habe ich noch nicht mit Punkt auf Weg getestet. 2. Ganz neu ist das Conflation-Plugin, welches wahrscheinlich das Tool ist, welches Du suchst. Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Potlatch: direktere Edits
On 05/05/12 02:08, Martin Trautmann wrote: On 12-05-04 20:39, Martin Trautmann wrote: On 12-05-04 20:17, fly wrote: Du zittierst ein Ticket was schon seit Jahren gefixed ist und laut 7. unter [1] sollten auch die Tastenkombinationen funktionieren. Vielleicht ist das durch das Überarbeiten/Umstellen des Tastenkombinationssystems entstanden. Es hat schon mal funktioniert? Von EvanE kam der entscheidende Tipp: Preferences Display Settings Look and Feel: Mac OS X ... dann hängt das Menu wieder am screen, cmd-c / cmd-f funktionieren nun so wie erwartet, nur die Menus sind oft noch etwas ohne Funktion. Dann sollte dass wohl die Standart-Einstellung für OS X sein und wir sollten in diese Richtung arbeiten. Als erstes wäre es vielleicht hilfreich Deine Erfahrungen im OSM- bzw JOSM-Wiki festzuhalten und auf das andere zu verweisen. Danke und viel Spaß mit JOSM fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern auf Gebäudeumriss ?!
Am 5. Mai 2012 10:48 schrieb Peter Wendorff wendo...@uni-paderborn.de: Wenn man aber aufs Land geht und dort nach einem Haus sucht, kann es sein, dass der Mittelpunkt der Fläche weit ab des Hauses ist. Ich für mich suche mit der Hausnummer das Haus und kein Grundstück. Ich halte es prinzipiell für durchaus sinnvoll, auch das Grundstück mit der Nummer zu versehen, ich halte es aber - trotz der vielleicht offiziell so korrekten Bezeichnung - für falsch, das als HAUSnummer zu bezeichnen, und würde das deshalb auch gerne getrennt halten, denn wofür werden Hausnummern genutzt? Die Dinger heissen dann wohl auch (zumindest teilweise) Grundstücknummer, anstatt Hausnummer. Ich würde in OSM trotzdem addr:housenumber verwenden, da es im Falle von Grundstücksnummern keine zusätzlichen Hausnummern geben dürfte (Grundstücksnummer hier als Adress-bestandteil, nicht als Katasternummer oder Parzellennummer, die ggf. zusätzlich auftreten können). - zum routing: ja, aber normalerweise nur zu Adressen, und eine Adresse hat ein unbebautes Grundstück eigentlich nicht. wieso nicht? Wenn es eine Adresse hat (gibt es durchaus, evtl. oft)... ich sehe jedenfalls (korrigiert mich, wenn ich falsch liege) keinen Anwendungsfall, unbebaute Grunstücke mit bebauten Grundstücken im Bereich der Adresse (addr:*) gleichzusetzen. Zumindest sollte es dann ein Unterscheidungsmerkmal geben. Es gibt ja ein Unterscheidungsmerkmal: im einen Fall sind dort Gebäude (building=*) im anderen nicht. Für Navigationszwecke macht es m.E. keinen Unterschied: wenn man zu einer bestimmten Adresse will, dann möchte man möglichst Straße und Hausnummer in der Karte haben, völlig unabhängig davon, ob dort dann ein oder mehrere Gebäude stehen oder nicht. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern auf Gebäudeumriss ?!
Am 05.05.2012 14:20, schrieb Martin Koppenhoefer: Am 5. Mai 2012 10:48 schrieb Peter Wendorffwendo...@uni-paderborn.de: Wenn man aber aufs Land geht und dort nach einem Haus sucht, kann es sein, dass der Mittelpunkt der Fläche weit ab des Hauses ist. Ich für mich suche mit der Hausnummer das Haus und kein Grundstück. Ich halte es prinzipiell für durchaus sinnvoll, auch das Grundstück mit der Nummer zu versehen, ich halte es aber - trotz der vielleicht offiziell so korrekten Bezeichnung - für falsch, das als HAUSnummer zu bezeichnen, und würde das deshalb auch gerne getrennt halten, denn wofür werden Hausnummern genutzt? Die Dinger heissen dann wohl auch (zumindest teilweise) Grundstücknummer, anstatt Hausnummer. Ich würde in OSM trotzdem addr:housenumber verwenden, da es im Falle von Grundstücksnummern keine zusätzlichen Hausnummern geben dürfte (Grundstücksnummer hier als Adress-bestandteil, nicht als Katasternummer oder Parzellennummer, die ggf. zusätzlich auftreten können). - zum routing: ja, aber normalerweise nur zu Adressen, und eine Adresse hat ein unbebautes Grundstück eigentlich nicht. wieso nicht? Wenn es eine Adresse hat (gibt es durchaus, evtl. oft)... ich sehe jedenfalls (korrigiert mich, wenn ich falsch liege) keinen Anwendungsfall, unbebaute Grunstücke mit bebauten Grundstücken im Bereich der Adresse (addr:*) gleichzusetzen. Zumindest sollte es dann ein Unterscheidungsmerkmal geben. Es gibt ja ein Unterscheidungsmerkmal: im einen Fall sind dort Gebäude (building=*) im anderen nicht. Damit setzt du aber voraus, dass alle Adressen in OSM auch als Gebäude eingetragen wären - davon sind wir nun noch sehr weit entfernt, oft sind immer noch Nodes mit puren Adressen die Regel. Für Navigationszwecke macht es m.E. keinen Unterschied: wenn man zu einer bestimmten Adresse will, dann möchte man möglichst Straße und Hausnummer in der Karte haben, völlig unabhängig davon, ob dort dann ein oder mehrere Gebäude stehen oder nicht. Aber warum willst du das auf den Navigationszweck und genauer das NavigationsZIEL begrenzen? Ich weiß, dass wir hier dann wieder möglicherweise in die Diskussion um ungenaue Tagdefinitionen zurückschliddern, und die ist gefährlich, aber: Ich hätte mich (bisher) bei einer Adresse darauf verlassen, dass ich sie einem Benutzer auch als Orientierungsmerkmal darreichen kann, also biegen Sie ab in den Fußweg nach Hausnummer 42 rechts. Das setzt aber voraus, dass Hausnummer 42 auch erkennbar ist. Bei einer HAUSNUMMER kann ich üblicherweise davon ausgehen, bei einer zukünftigen Hausnummer, die einem unbebauten Grundstück zugeordnet ist, ist das aber unmöglich. Wenn ich Fußwege in Wohngebieten betrachte, von denen es z.T. etliche nebeneinander gibt, die sich optisch nicht unterscheiden und keine Wegnamen tragen, dann halte ich das sogar in dem von dir bevorzugten Anwendungsfall Routing für eine wichtige Eigenschaft - auch wenn sie von bisher verfügbaren Routern nicht unterstützt wird. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern auf Gebäudeumriss ?!
On 12-05-05 14:31, Peter Wendorff wrote: Das setzt aber voraus, dass Hausnummer 42 auch erkennbar ist. Das setzt voraus, dass Hausnummern überhaupt erkennbar sind. Eine gesetzliche Vorschrift gibt es dazu nicht. Ich kenne hier genug Häuser ganz ohne Hausnummer, und sehr viele, die ab der Dämmerung nicht mehr erkennbar sind. Es gibt durchaus Grundstücke, die als Hausnummern existieren - oder auch Grundstücke, die über Hausnummern identifziert werden, die womöglich nicht mal die eigen ist. Wo liegen z.B. die Kleingartenanlagen in Berlin, wie KGA Friedrich-Engels-Str. 102 KGA Friedrich-Engels-Str. 114 KGA Friedrich-Engels-Str. 169 Oder es gibt Firmengelände mit vielen unterschiedlichen Hausnummern, von aussen aber erreichbar über eine einzige - und einer Unterscheidung der inneren Gebäudenummern. Bei einer HAUSNUMMER kann ich üblicherweise davon ausgehen, bei einer zukünftigen Hausnummer, die einem unbebauten Grundstück zugeordnet ist, ist das aber unmöglich. Bei einer Hausnummer kann man grundsätzlich mal davon ausgehen, dass es dort ein Haus gibt. Genauso wie das Haus aktuell aber unbewohnt sein kann und dir keiner auf's Klingeln öffnet kann auch sein, dass auf dem Grundstück noch kein Haus steht. Solltest du die Notwendigkeit haben, zu einem Grundstück zu fahren, auf dem noch kein Haus steht, so wäre es für dich sicherlich einfacher, eine dem Grundstück zugeordnete Nummer zu verwenden. Wenn du nicht dorthin willst stört sie nicht. Von daher verstehe ich dein Problem nicht. Wenn ich Fußwege in Wohngebieten betrachte, von denen es z.T. etliche nebeneinander gibt, die sich optisch nicht unterscheiden und keine Wegnamen tragen, dann halte ich das sogar in dem von dir bevorzugten Anwendungsfall Routing für eine wichtige Eigenschaft - auch wenn sie von bisher verfügbaren Routern nicht unterstützt wird. Ja, da hilft's, wenn das der Weg zwischen Grundstück 11 und 13 ist, nicht aber der Parallelweg zwischen Grundstück 17 und Haus 19 - wo bisher nur Haus 15 und 19 fertiggestellt sind. Schönen Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern auf Gebäudeumriss ?!
Am 5. Mai 2012 14:31 schrieb Peter Wendorff wendo...@uni-paderborn.de: Am 05.05.2012 14:20, schrieb Martin Koppenhoefer: Für Navigationszwecke macht es m.E. keinen Unterschied: wenn man zu einer bestimmten Adresse will, dann möchte man möglichst Straße und Hausnummer in der Karte haben, völlig unabhängig davon, ob dort dann ein oder mehrere Gebäude stehen oder nicht. Aber warum willst du das auf den Navigationszweck und genauer das NavigationsZIEL begrenzen? Ich weiß, dass wir hier dann wieder möglicherweise in die Diskussion um ungenaue Tagdefinitionen zurückschliddern, und die ist gefährlich, aber: Ich hätte mich (bisher) bei einer Adresse darauf verlassen, dass ich sie einem Benutzer auch als Orientierungsmerkmal darreichen kann, also biegen Sie ab in den Fußweg nach Hausnummer 42 rechts. Das setzt aber voraus, dass Hausnummer 42 auch erkennbar ist. Bei einer HAUSNUMMER kann ich üblicherweise davon ausgehen, bei einer zukünftigen Hausnummer, die einem unbebauten Grundstück zugeordnet ist, ist das aber unmöglich. wieso? unbebaute Grundstücke können doch genauso eine Hausnummer tragen, das habe ich schon oft gesehen (die Nummer ist dann am Zaun oder ggf. Eingangstor). Ich glaube, wir reden hier aneinander vorbei. Dir geht es darum, dass dort vor Ort die Hausnummer erkennbar ist, und das hattest Du mit bebaut assoziiert. Würdest Du denn im Umkehrschluss, d.h. bebaut aber Hausnummer nicht erkennbar (z.B: vandalisiert oder zugewachsen), keine Hausnummer taggen? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern auf Gebäudeumriss ?!
Am 5. Mai 2012 15:24 schrieb Martin Trautmann tr...@gmx.de: On 12-05-05 14:31, Peter Wendorff wrote: Das setzt voraus, dass Hausnummern überhaupt erkennbar sind. +1 Eine gesetzliche Vorschrift gibt es dazu nicht. doch gibt es, zumindest in einigen Teilen Deutschlands (da das wie wiederholt geschrieben unterschiedlich geregelt ist). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Toolchain Mapnik2 in einfach
fly lowfligh...@googlemail.com wrote: Das wäre ja auch schlimm. Ich freue mich über jeden befreiten Rechner ! Wie wäre es mit einem Repository ? Nicht jeder hat Gentoo am laufen. osm2pgsql installiere nicht mal ich als Paket und ich mache das normalerweise fast mit jeder Software. Na ja, mich wundert es schon das make gefunden wurde. Ist bei Debian nur optional und mit der passenden Hardware (ohne dkms) ist das nicht installiert. build-essential? Sven -- Dynamische IP-Nummern sind Security-Homöopathie. (Kristian Köhntopp) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern auf Gebäudeumriss ?!
Am Sa, 5.05.2012, 10:40, schrieb Hartmut Holzgraefe: On 05.05.2012 10:37, Peter Wendorff wrote: Du kopierst einfach das Objekt (also in diesem Falle den Node), wählst das Zielobjekt (in diesem Fall das Gebäude-Polygon) aus, und wählst dann im Menü Bearbeiten/Merkmale einfügen (oder so ähnlich, hab josm grad nicht offen). oder auch ohne Menüs mit Ctrl-C kopieren und mit Shift-Ctrl-C die kopierten Properties zum neu ausgewählten Objekt hinzufügen da dürfte sich ein kleiner Tippfehler eingeschlichen haben: mit Ctrl-C kopieren und mit Shift-Ctrl-V die Eigenschaften einem bestehenden Objekt übergeben. (in JOSM) Gruß Günther ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern auf Gebäudeumriss ?!
Am 05.05.2012 16:05, schrieb Martin Koppenhoefer: wieso? unbebaute Grundstücke können doch genauso eine Hausnummer tragen, das habe ich schon oft gesehen (die Nummer ist dann am Zaun oder ggf. Eingangstor). Ich glaube, wir reden hier aneinander vorbei. Dir geht es darum, dass dort vor Ort die Hausnummer erkennbar ist, und das hattest Du mit bebaut assoziiert. Würdest Du denn im Umkehrschluss, d.h. bebaut aber Hausnummer nicht erkennbar (z.B: vandalisiert oder zugewachsen), keine Hausnummer taggen? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Solange das Grundstück noch nicht bebaut ist, dann macht eine Hausnummer am Grundstück für mich auch Sinn. Aber woher nehmen, wenn noch keine am Zaun hängt? Für den Fall, dass kein Schild sichtbar ist, trage zumindest ich keine ein, denn Raten ist für mich keine ausreichende sichere Quelle. In meiner Nachbarschaft gibt es ein Wohngebäude mit der Adresse Mustermannstraße, welches aber nicht über die Mustermannstraße zu erreichen ist. Angenommen das hätte keine Hausnummernschild und ich würde raten, dass die Adresse zwischen den beiden der Nachbargebäude (Maxstraße) liegt, hätte ich mich grob verraten. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-it] Numeri civici
Salve, vorrei iniziare ad inserire i numeri civici nella mia città ma ho visto approcci discordanti cercando con Google. Chi suggerisce di usare addr: housenumber e addr:street, altri propongono le relazioni. Premesso che sono uno alle prime armi con JOSM, come mi consigliate di procedere? Stefano ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Talk-it] Progetto Occhi sulle Colline
Il giorno 02 maggio 2012 09:08, Luca Delucchi lucadel...@gmail.com ha scritto: Il 30 aprile 2012 22:33, Fabrizio Carrai fabrizio.car...@gmail.com ha scritto: Volevo annunciarvi che il 6 Maggio 2012 si terrà l'evento inaugurale del progetto Occhi Sulle Colline. [] Potrete trovare ulteriori informazioni sul sito http://www.occhisullecolline.it (ancora in fase di sviluppo). molto in sviluppo :-P Il progetto coinvolge molte associazioni, e questo genera una naturale inerzia: confido nel vincerla ;-) Vi terremo informati per gli aspetti inerenti ad OSM. ottimo, ricordatevi di aggiungere tutti i vari eventi legati ad osm anche sul wiki nella sezione degli eventi Certo. Purtroppo l'evento inaugurale di domani è stato rimandato a causa del maltempo (ovviamente previsto solo per domani...). La Provincia di Livorno ha invitato alcuni rappresentanti del progetto per Lunedì 7 Maggio prossimo. Si dovrebbe parlare anche di OSM e del suo utilizzo per il progetto. Vi terrò informati su eventuali sviluppi. A presto! Fabrizio ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Primo accesso.
Salve, sono Christian di Bolzano, questo è il mio primo accesso come avrete immaginato. Conosco OSM da vari anni ma solo ora ho iniziato a parteciparvi. Se c'è qualcuno delle mie zone per aiutarmi si faccia sentire. Un saluto a tutti/e. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Problemi PCN?
Avevo lo stesso problema, ma usando il link qua sotto ho risolto.
Grazie!
F.
Il giorno 23 aprile 2012 14:10, morsi mo...@inwind.it ha scritto:
Inserendo l'indirizzo
wms:
http://wms.pcn.minambiente.it/ogc?map=/ms_ogc/WMS_v1.3/raster/ortofoto_colore_06.mapFORMAT=image/jpegVERSION=1.1.1SERVICE=WMSREQUEST=GetMapLayers=OI.ORTOIMMAGINI.2006.33,OI.ORTOIMMAGINI.2006.32STYLES=SRS={proj}WIDTH={width}HEIGHT={height}BBOX={bbox}
mi scarica un paio di tasselli in un tempo infinito...
Allora ho provato ad attivare il 2008 e mi scarica solo il logo del PCN...
Che fare? c'è qualcosa che blocca lo scarico delle foto?
--
View this message in context:
http://gis.19327.n5.nabble.com/Problemi-PCN-tp5603363p5659248.html
Sent from the Italy General mailing list archive at Nabble.com.
___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it
___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Numeri civici
Mi associo alla richiesta. Anch'io vorrei farlo ma non capisco bene come gestire le relazioni tra vie e numeri (type=associatedstreet?) Il 05/05/2012 08:56, stefano.fracc...@libero.it ha scritto: Salve, vorrei iniziare ad inserire i numeri civici nella mia città ma ho visto approcci discordanti cercando con Google. Chi suggerisce di usare addr: housenumber e addr:street, altri propongono le relazioni. Premesso che sono uno alle prime armi con JOSM, come mi consigliate di procedere? Stefano ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it - ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Numeri civici
Il 05 maggio 2012 08:56, stefano.fracc...@libero.it stefano.fracc...@libero.it ha scritto: Salve, vorrei iniziare ad inserire i numeri civici nella mia città ma ho visto approcci discordanti cercando con Google. Chi suggerisce di usare addr: housenumber e addr:street, altri propongono le relazioni. Premesso che sono uno alle prime armi con JOSM, come mi consigliate di procedere? Stefano Visto che successivamente hai intenzione di modificare i dati della zona anche in un progetto scolastico, che coinvolgerà quindi molte persone inesperte, io ti consiglierei l'approccio più semplice e, al momento, diffuso. Aggiungere un nodo sul poligono dell'edificio in corrispondenza del punto in cui è posta la scritta con il numero civico (es. l'entrata principale) e taggarlo con: addr:housenumber = numerocivico addr:street = nomedellavia Il metodo alternativo, l'uso di una relazione, ha dei pro e contro. I secondi risiedono principalmente nel fatto che, nonostante i progressi di JOSM e Potlatch 2, per un nuovo utente è ancora difficile capire che ha modificato una relazione esistente e, soprattutto, i cambiamenti che sta causando. A volte, non si può rispondere Si mappa così perché ci sono approcci differenti. In questi casi, per fare una scelta bisogna affidarsi ad un principio. Il mio è di usare le relazioni solo quando è necessario: svolte obbligate, confini amministrativi, percorsi di mezzi pubblici, itinerari ufficiali, multipoligoni (ad es. un lago con un isola all'interno)... Quando l'uso delle relazioni sarà ancora più semplice, i numeri civici presenti sulla mappa potranno essere convertiti facilmente ad un sistema più avanzato. Ciao, Groppo ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Giro d'Italia e OSM (reprise)
Buongiorno a tutti, oggi, come ogni anno, ho comprato la Gazzetta con lo speciale di Sport Week sul Giro d'Italia. Come già sappiamo da un thread di qualche tempo fa, le mappe sono ricavate da dati OSM dal bravissimo Stefano di Santo (che credo ci segua ancora qui in lista). L'attribuzione dei dati è perfetta, quindi colgo l'occasione per fare nuovamente i complimenti a Stefano e, per tutti gli altri, l'appuntamento con le nostre mappe è su sportweek. Stefano Pallicca ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Giro d'Italia e OSM (reprise)
Il 05/05/2012 11:49, Stefano Pallicca ha scritto: L'attribuzione dei dati è perfetta, quindi colgo l'occasione per fare nuovamente i complimenti a Stefano e, per tutti gli altri, l'appuntamento con le nostre mappe è su sportweek. Ottimo! Cercherò di recuperare una copia. Avrei una curiosità: sarebbe possibile conoscere il processo seguito per produrre le mappe? Complimenti anche da parte mia! :) Carlo -- .' `. | Registered Linux User #443882 |a_a | | http://counter.li.org/ .''`. \_)__/ +--- : :' : /( )\ ---+ `. `'` |\`/\ Registered Debian User #9 | `- \_|=='|_/ http://debiancounter.altervista.org/ | ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Apple iPhoto usa OSM
Il 05/05/2012 08:28, emmexx ha scritto: Il 03/08/2012 08:50 AM, Simone Cortesi scrisse: Ciao, pare che iphoto di apple usi dati osm. Date un occhiata qui: http://ivan.sanchezortega.es/leaflet-apple.php Apple ha aggiunto l'attribuzione ad OSM in iPhoto, articolo su wired: http://www.webmonkey.com/2012/05/apple-credits-openstreetmap-for-iphoto-map-data/ Ottima notizia! Era ora. Carlo -- .' `. | Registered Linux User #443882 |a_a | | http://counter.li.org/ .''`. \_)__/ +--- : :' : /( )\ ---+ `. `'` |\`/\ Registered Debian User #9 | `- \_|=='|_/ http://debiancounter.altervista.org/ | ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Giro d'Italia e OSM (reprise)
Il giorno 05/mag/2012 11:50, Stefano Pallicca palli...@gmail.com ha scritto: colgo l'occasione per fare nuovamente i complimenti a Stefano +1 Bravo Stefano! ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Numeri civici
2012/5/5 Groppo O grop...@gmail.com: Il 05 maggio 2012 08:56, stefano.fracc...@libero.it stefano.fracc...@libero.it ha scritto: Visto che successivamente hai intenzione di modificare i dati della zona anche in un progetto scolastico, che coinvolgerà quindi molte persone inesperte, io ti consiglierei l'approccio più semplice e, al momento, diffuso. +1 Aggiungere un nodo sul poligono dell'edificio in corrispondenza del punto in cui è posta la scritta con il numero civico (es. l'entrata principale) e taggarlo con: addr:housenumber = numerocivico addr:street = nomedellavia Se ci sono già gli edifici sarebbe ancora più semplice di aggiungere gli stessi tags (del indirizzo) direttamente sul poligono del edificio. E' alle volte approssimativo (rispetto al vero confine del indirizzo), ma ha dei vantaggi (rispetto ad un nodo): quando metti poi un nodo per un evventuale negozio dentro questo poligono, non dovresti più aggiungere il civico a questo nodo. Invece con un nodo a canto ad un altro nodo non si è mai sicuro se sono nello stesso oggetto (casa/civico) o vicini. A volte, non si può rispondere Si mappa così perché ci sono approcci differenti. In questi casi, per fare una scelta bisogna affidarsi ad un principio. Il mio è di usare le relazioni solo quando è necessario: svolte obbligate, confini amministrativi, percorsi di mezzi pubblici, itinerari ufficiali, multipoligoni (ad es. un lago con un isola all'interno)... Quando l'uso delle relazioni sarà ancora più semplice, i numeri civici presenti sulla mappa potranno essere convertiti facilmente ad un sistema più avanzato. concordo pienamente. Anche adesso con civici mappati come nodi chi vuole utilizzare poi questi civici dentro un applicazione (per esempio di geocoding) può trasformare senza grandi problemi i nodi del database ufficiale in un schema più elegante con relazioni (foreign key per la strada) nel suo locale. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] OpenStreetMap @ istituti superiori
Di danni li han fatti tutti alle prime armi ahimè (io in primis) poi comunque usando JOSM ti avverte se c'è qualcosa che non va di tecnico:) si può far inserire i dati e al limite poi controllarli di nascosto una volta postati senza farsi vedere per darli fiducia C'è anche una consistente fetta di lavoro che possono fare con in walking papers http://walking-papers.org/, compreso nei plug-in disponibili per JOSM *ti consiglio di postare anche nella lista regionale me l'hanno appena indicata... non sapevo che esistesse una lista regionale scusate, dov'è la lista regionale veneto? http://lists.openstreetmap.org/pipermail/talk-it-veneto mi da not found. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] OpenStreetMap @ istituti superiori
scusate, dov'è la lista regionale veneto? http://lists.openstreetmap.org/pipermail/talk-it-veneto mi da not found. http://wiki.openstreetmap.org/wiki/Veneto http://liste.remixtj.net/listinfo/osmveneto ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Primo accesso.
Il 05 maggio 2012 09:32, saxe...@libero.it saxe...@libero.it ha scritto: Salve, sono Christian di Bolzano, questo è il mio primo accesso come avrete immaginato. ciao Conosco OSM da vari anni ma solo ora ho iniziato a parteciparvi. Se c'è qualcuno delle mie zone per aiutarmi si faccia sentire. io sono residente a san michele all'adige, se vuoi fare un passo qui ti spiego volentieri come contribuire... intanto ti consiglio di leggerti questi due manualetti, sono molto utili per iniziare http://www.learnosm.org/files/beginners-guide/Beginning_OSM_it_v1.pdf http://svn.openstreetmap.org/misc/pr_material/italy_miniguida/tutorial.pdf Un saluto a tutti/e. -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] OpenStreetMap @ istituti superiori
bene molto bene, alcuni annifa con tre classi prima, seconda e terza media abbiamo messo su un po' delle strade di bezzeccain val di ledro trento. certo qualche errore (piccolo) è stato fatto, ma poi è statso corretto, e volete mettere la diffuzsione 76 alunni hanno lavorato su OSM, hanno (un po') imparato che c'è un altro modo di creare conoscenze e di condividere il sapere, anche le famiglie sono state coinvolte, poi purtroppo come capita scpesso ho cambiato scuola. ciao matteo PS non smetterò mai di ringraziare chi allora mi aiutò in modod sotanziale Napo e Luca de Lucchi ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Qualcuno conosce OSMapTuner
Ciao, stavo provando OSMapTuner dal mio cellulare come applicazione per modificare alcuni dati delle mappe (tipo numero civico per edifici già esistenti o limiti di velocità). Purtroppo il programma mi dice che ha aggiornato il limite di velocità ma su JOSM e Potlatch non vedo la modifica. Qualcuno ha già usato questo software in passato? Stefano ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] OpenStreetMap @ istituti superiori
Rimango dell'idea che riuscire a rendere appetibile openstreetmap agli studenti di una classe, non e' banale. Di esperienze ce ne sono diverse. Dopo serie di attivita' che ho avuto con diversi docenti, penso che la soluzione migliore sia quella di partire da cose piccole. Per la maggiore, a molti insegnanti, interessa avere una mappa con sopra delle icone che al clic mostrano informazioni. Cosa che ha poco a che vedere con OpenStreetMap e che puo' essere fatta con molta piu' semplicita' con Google Maps. Fra le soluzioni che ho elaborato segnalo: - sensibilizzare ad un progetto di raccolta di dati tematici che offrono, a loro volta, un servizio di visualizzazione basasto su openstreetmap o integrato. Ad esempio: wheelmap oppure openplaques - se non si riesce ad avere soluzioni di tale tipo, allora deciderne uno con il docente e poi fare uso di ushahidi. Se ci sono problemi di installazione si ricorre a crowdmap (che non e' altro che ushahidi nel cloud). Di fatto si viene incontro ad una esigenza di base (= raccolta di punti di interessi con una finestrella che mostra le informazioni), ma si puo' organizzare, all'interno della classe, un gruppo di studenti scelto che si occupa di riempire la mappa di openstreetmap li' dove manca. Questo da l'ulteriore vantaggio di superare gmaps - Stimolare alla creazione di rendering diversi. Con software come maperitive o tilemill diventa facile fare questo lavoro e, fra gli studenti, potrebbe nascere l'esigenza di inserire anche nuove informazioni. L'esempio di mape furlane http://www.mapefurlane.eu/ e' ottimo per dare stimolo in questo senso. Al convegno didattica aperta avevo usato queste slide http://www.slideshare.net/napo/didattica-aperta-gis Fra i vari tool per stimolare gli studenti segnalo anche maposmatic.org my 2 cents ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-es] Bloqueo de catastro_pontevedra
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hola: Visto que la gente ya empezó a subir datos del catastro a OSM, decidí subir los datos de Pontecesures, un ayuntamiento pequeño al norte de Pontevedra (6,7 km2, http://osm.org/go/b9LyoEg~- ). Eran como unos 89500 objetos que dejé subiendo a eso de las 12 de la noche (calculé unas 8-9 horas para que completase). Los datos eran completos, es decir, hice un cat2osm.jar -jar config, sin más argumentos, y sólo corregí warnings (no había errores). Hoy por la mañana me encontré un aviso de error en josm, que me remitía a la bandeja de entrada del usuario catastro_pontevedra, donde leía esto: - --- Hello, I noticed you were importing Spanish Cadastre data in http://www.openstreetmap.org/browse/changeset/11502848 and http://www.openstreetmap.org/browse/changeset/11503887 There are a few problems with this. The first is that the problems with many multipolygons appear to have not been fixed. These problems were that too many multipolygons were being generated for what was a simple geometry. The second problem is that you are importing features other than highways and leisure=park. Although the tags have not yet been uploaded, this is evident from where the nodes are. As pointed out http://lists.openstreetmap.org/pipermail/imports/2012-March/001313.html only those features were consulted on with the imports@ list. If you want import more data you need to propose a new import. This block is set to last until you log on to read the message. When you have done that, please revert your imports. If you do not feel able to revert your import let me know and I can do it for you. If you have questions please contact me via a message or the DWG at d...@osmfoundation.org Paul Norman For the Data Working Group - Es evidente que algo está fallando con este proceso de subir datos a OSM, o yo entendí mal cuando se decía que se podían subir ya los datos, cuando es obvio que no. Creo que sería necesario explicitar qué se puede hacer y que no, y hacerlo claramente, sin suponer conocimientos previos que uno a lo mejor no tiene. Yo no soy programador, sólo soy un simple profesor de secundaria. Vosotros diréis. Yo por lo pronto dejo todo esto del cat2osm en standby. En todo caso, creo que, visto la complejidad del tema, igual no soy la persona más idónea para encargarme de provincias de Pontevedra y Ourense, por lo que si lo estimáis oportuno, podéis asignar esas provincias a alguien más preparado. Ahora mismo contestaré a Paul Norman para pedirle disculpas, y que no volveré a subir datos de catastro hasta que esté 100% seguro de lo que estoy haciendo, de ahí que os pida claridad en todo este asunto, pues fallar una vez no tiene importancia, pero fallar dos veces sería un poco vergonzoso. Un saludo, Rafael Ávila Coya. - -- - Por favor, non me envíe documentos con extensións .doc, .docx, .xls, .xlsx, .ppt, .pptx, aínda podendoo facer, non os abro. Atendendo á lexislación vixente, empregue formatos estándares e abertos. http://es.wikipedia.org/wiki/OpenDocument#Tipos_de_ficheros -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPpQAuAAoJEB3niTly2pPQoNAQAIOmOe5R+yFQIVtClwjMKwtb d8dNAPXl7H8LB3G2l6OnHxScPbqDWtVlI/varKlnq2+l//dQLDpqlU6nj6H4iXf2 cUGS1U8d6RoRoTMm3iYo8Rjjmf6OcXxLFN8QSpdbKjCnGGuzhqZSwiwQg/AmY0RV PbfiEvvL/qM8S8EqpeWRgzxw+3bh6HPWiD45FGsMRC6fi8ZkJD77JAENgbmE7OQT mxlinfzgFBnT6o34iG/tYdSCqNrXw+RqWZVuf//5ji6Oi3ZegYdH/CMUeLAWKzBw +GJ3WV6wyCt2iFy/DQmqUidcwEjddJ/HOzxz1pkMTq4JTzVxPHdyanfO8qtyqtRG vmOeMWAzepjaRjwwtw1ftox0wwAf2eApG0ykYYrjjV46KKxZR0wso9hoQG6D11RG IcLnBB1Faus3qE9LcXJnhqyhtHCMsjq54Gy5/Tx+47WpScIH12OKLDStEbHqZ6c/ X1BthCWbjw6HVZZb6qT/wSD0Im5dKeEPKuRWpkWct39v2CWCgltE5uTktsBp/oBi oSUX4nB1D40SgT6ZVzRiXGIreh5eturB0S4SEg2xfu1Sb6z1D6zqWtuG9rT+XBjK lhFTHZAscaMwPdiYMFa+JUi4rG02/r5HpF6NMfzQUJkEAETIvrF7prrEi2tKMjuO rP7zHPn0Pp+tfhR7/VSU =ifam -END PGP SIGNATURE- ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Bloqueo de catastro_pontevedra
Como te han comentado sólo nos habían dado permiso para subir carreteras y zonas verdes. Sigue sin gustarles algo de lo que sale porque genera muchos multipolígonos. ¿Has subido el .osm a la wiki para que le echemos un vistazo? Por lo que comentan, no creo que nos dejen subir las parcelas de rústico sin antes juntar geometrías. De urbano habría que volver a consultar a ver que dicen. Más no se puede simplificar sin eliminanar las separaciones entre casas con lo cual nos restringiríamos a lo que en catastro se llama masas y el resto de mortales conocemos por manzanas... ¿Alguien se ofrece voluntario a ejecutar el cat2osm solo con los shapefiles de urbano, arreglar los errors y warnings y probar a ver que dicen en imports? Con renombrar el directorio con los shapes de rustico y el cat rústico debería valer. Lo ideal sería enviar la conflación con lo que hay subido para que se vea el resultado final. PD: menudo control que nos tienen :S Hola: Visto que la gente ya empezó a subir datos del catastro a OSM, decidí subir los datos de Pontecesures, un ayuntamiento pequeño al norte de Pontevedra (6,7 km2, http://osm.org/go/b9LyoEg~- ). Eran como unos 89500 objetos que dejé subiendo a eso de las 12 de la noche (calculé unas 8-9 horas para que completase). Los datos eran completos, es decir, hice un cat2osm.jar -jar config, sin más argumentos, y sólo corregí warnings (no había errores). Hoy por la mañana me encontré un aviso de error en josm, que me remitía a la bandeja de entrada del usuario catastro_pontevedra, donde leía esto: - --- Hello, I noticed you were importing Spanish Cadastre data in http://www.openstreetmap.org/browse/changeset/11502848 and http://www.openstreetmap.org/browse/changeset/11503887 There are a few problems with this. The first is that the problems with many multipolygons appear to have not been fixed. These problems were that too many multipolygons were being generated for what was a simple geometry. The second problem is that you are importing features other than highways and leisure=park. Although the tags have not yet been uploaded, this is evident from where the nodes are. As pointed out http://lists.openstreetmap.org/pipermail/imports/2012-March/001313.html only those features were consulted on with the imports@ list. If you want import more data you need to propose a new import. This block is set to last until you log on to read the message. When you have done that, please revert your imports. If you do not feel able to revert your import let me know and I can do it for you. If you have questions please contact me via a message or the DWG at d...@osmfoundation.org Paul Norman For the Data Working Group - Es evidente que algo está fallando con este proceso de subir datos a OSM, o yo entendí mal cuando se decía que se podían subir ya los datos, cuando es obvio que no. Creo que sería necesario explicitar qué se puede hacer y que no, y hacerlo claramente, sin suponer conocimientos previos que uno a lo mejor no tiene. Yo no soy programador, sólo soy un simple profesor de secundaria. Vosotros diréis. Yo por lo pronto dejo todo esto del cat2osm en standby. En todo caso, creo que, visto la complejidad del tema, igual no soy la persona más idónea para encargarme de provincias de Pontevedra y Ourense, por lo que si lo estimáis oportuno, podéis asignar esas provincias a alguien más preparado. Ahora mismo contestaré a Paul Norman para pedirle disculpas, y que no volveré a subir datos de catastro hasta que esté 100% seguro de lo que estoy haciendo, de ahí que os pida claridad en todo este asunto, pues fallar una vez no tiene importancia, pero fallar dos veces sería un poco vergonzoso. Un saludo, Rafael Ávila Coya. ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Bloqueo de catastro_pontevedra
El 05/05/12 12:26, Rafael Avila Coya escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hola: Visto que la gente ya empezó a subir datos del catastro a OSM, decidí subir los datos de Pontecesures, un ayuntamiento pequeño al norte de Pontevedra (6,7 km2, http://osm.org/go/b9LyoEg~- ). Eran como unos 89500 objetos que dejé subiendo a eso de las 12 de la noche (calculé unas 8-9 horas para que completase). Los datos eran completos, es decir, hice un cat2osm.jar -jar config, sin más argumentos, y sólo corregí warnings (no había errores). Hoy por la mañana me encontré un aviso de error en josm, que me remitía a la bandeja de entrada del usuario catastro_pontevedra, donde leía esto: - --- Hello, I noticed you were importing Spanish Cadastre data in http://www.openstreetmap.org/browse/changeset/11502848 and http://www.openstreetmap.org/browse/changeset/11503887 There are a few problems with this. The first is that the problems with many multipolygons appear to have not been fixed. These problems were that too many multipolygons were being generated for what was a simple geometry. The second problem is that you are importing features other than highways and leisure=park. Although the tags have not yet been uploaded, this is evident from where the nodes are. As pointed out http://lists.openstreetmap.org/pipermail/imports/2012-March/001313.html only those features were consulted on with the imports@ list. If you want import more data you need to propose a new import. This block is set to last until you log on to read the message. When you have done that, please revert your imports. If you do not feel able to revert your import let me know and I can do it for you. If you have questions please contact me via a message or the DWG at d...@osmfoundation.org Paul Norman For the Data Working Group - Es evidente que algo está fallando con este proceso de subir datos a OSM, o yo entendí mal cuando se decía que se podían subir ya los datos, cuando es obvio que no. Creo que sería necesario explicitar qué se puede hacer y que no, y hacerlo claramente, sin suponer conocimientos previos que uno a lo mejor no tiene. Yo no soy programador, sólo soy un simple profesor de secundaria. Vosotros diréis. Yo por lo pronto dejo todo esto del cat2osm en standby. En todo caso, creo que, visto la complejidad del tema, igual no soy la persona más idónea para encargarme de provincias de Pontevedra y Ourense, por lo que si lo estimáis oportuno, podéis asignar esas provincias a alguien más preparado. Ahora mismo contestaré a Paul Norman para pedirle disculpas, y que no volveré a subir datos de catastro hasta que esté 100% seguro de lo que estoy haciendo, de ahí que os pida claridad en todo este asunto, pues fallar una vez no tiene importancia, pero fallar dos veces sería un poco vergonzoso. Un saludo, Rafael Ávila Coya. Hasta ahora en la lista de imports sólo han dado conformidad para importar los ejes de catastro, que es lo que viene a decirte Paul Norman en su mensaje. Por lo tanto todo lo demás todavía no se puede subir. No es un tema de tener más o menos conocimientos técnicos, es simplemente que no quieren que se suban los datos tal como se ha propuesto hasta ahora en imports. ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Bloqueo de catastro_pontevedra
Por cierto, no os olvideis que hay que revertir esos cambios. El día 5 de mayo de 2012 12:45, Carlos Dávila cdavi...@orangecorreo.es escribió: El 05/05/12 12:26, Rafael Avila Coya escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hola: Visto que la gente ya empezó a subir datos del catastro a OSM, decidí subir los datos de Pontecesures, un ayuntamiento pequeño al norte de Pontevedra (6,7 km2, http://osm.org/go/b9LyoEg~- ). Eran como unos 89500 objetos que dejé subiendo a eso de las 12 de la noche (calculé unas 8-9 horas para que completase). Los datos eran completos, es decir, hice un cat2osm.jar -jar config, sin más argumentos, y sólo corregí warnings (no había errores). Hoy por la mañana me encontré un aviso de error en josm, que me remitía a la bandeja de entrada del usuario catastro_pontevedra, donde leía esto: - --- Hello, I noticed you were importing Spanish Cadastre data in http://www.openstreetmap.org/browse/changeset/11502848 and http://www.openstreetmap.org/browse/changeset/11503887 There are a few problems with this. The first is that the problems with many multipolygons appear to have not been fixed. These problems were that too many multipolygons were being generated for what was a simple geometry. The second problem is that you are importing features other than highways and leisure=park. Although the tags have not yet been uploaded, this is evident from where the nodes are. As pointed out http://lists.openstreetmap.org/pipermail/imports/2012-March/001313.html only those features were consulted on with the imports@ list. If you want import more data you need to propose a new import. This block is set to last until you log on to read the message. When you have done that, please revert your imports. If you do not feel able to revert your import let me know and I can do it for you. If you have questions please contact me via a message or the DWG at d...@osmfoundation.org Paul Norman For the Data Working Group - Es evidente que algo está fallando con este proceso de subir datos a OSM, o yo entendí mal cuando se decía que se podían subir ya los datos, cuando es obvio que no. Creo que sería necesario explicitar qué se puede hacer y que no, y hacerlo claramente, sin suponer conocimientos previos que uno a lo mejor no tiene. Yo no soy programador, sólo soy un simple profesor de secundaria. Vosotros diréis. Yo por lo pronto dejo todo esto del cat2osm en standby. En todo caso, creo que, visto la complejidad del tema, igual no soy la persona más idónea para encargarme de provincias de Pontevedra y Ourense, por lo que si lo estimáis oportuno, podéis asignar esas provincias a alguien más preparado. Ahora mismo contestaré a Paul Norman para pedirle disculpas, y que no volveré a subir datos de catastro hasta que esté 100% seguro de lo que estoy haciendo, de ahí que os pida claridad en todo este asunto, pues fallar una vez no tiene importancia, pero fallar dos veces sería un poco vergonzoso. Un saludo, Rafael Ávila Coya. Hasta ahora en la lista de imports sólo han dado conformidad para importar los ejes de catastro, que es lo que viene a decirte Paul Norman en su mensaje. Por lo tanto todo lo demás todavía no se puede subir. No es un tema de tener más o menos conocimientos técnicos, es simplemente que no quieren que se suban los datos tal como se ha propuesto hasta ahora en imports. ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es -- Cruz Enrique Borges Hernández Email: cruz.bor...@deusto.es DeustoTech Energy Telefono: 944139000 ext.2052 Avda. Universidades, 24 48007 Bilbao, Spain ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Bloqueo de catastro_pontevedra
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ya le dije a Paul Norman que yo no sé como hacerlo. Como él se había ofrecido a hacerlo por mí en caso de que no supiese hacerlo, pues supongo que lo hará él mismo en breve. Rafael Ávila Coya. On 05/05/12 12:46, Cruz Enrique Borges Hernández wrote: Por cierto, no os olvideis que hay que revertir esos cambios. El día 5 de mayo de 2012 12:45, Carlos Dávila cdavi...@orangecorreo.es escribió: El 05/05/12 12:26, Rafael Avila Coya escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hola: Visto que la gente ya empezó a subir datos del catastro a OSM, decidí subir los datos de Pontecesures, un ayuntamiento pequeño al norte de Pontevedra (6,7 km2, http://osm.org/go/b9LyoEg~- ). Eran como unos 89500 objetos que dejé subiendo a eso de las 12 de la noche (calculé unas 8-9 horas para que completase). Los datos eran completos, es decir, hice un cat2osm.jar -jar config, sin más argumentos, y sólo corregí warnings (no había errores). Hoy por la mañana me encontré un aviso de error en josm, que me remitía a la bandeja de entrada del usuario catastro_pontevedra, donde leía esto: - --- Hello, I noticed you were importing Spanish Cadastre data in http://www.openstreetmap.org/browse/changeset/11502848 and http://www.openstreetmap.org/browse/changeset/11503887 There are a few problems with this. The first is that the problems with many multipolygons appear to have not been fixed. These problems were that too many multipolygons were being generated for what was a simple geometry. The second problem is that you are importing features other than highways and leisure=park. Although the tags have not yet been uploaded, this is evident from where the nodes are. As pointed out http://lists.openstreetmap.org/pipermail/imports/2012-March/001313.html only those features were consulted on with the imports@ list. If you want import more data you need to propose a new import. This block is set to last until you log on to read the message. When you have done that, please revert your imports. If you do not feel able to revert your import let me know and I can do it for you. If you have questions please contact me via a message or the DWG at d...@osmfoundation.org Paul Norman For the Data Working Group - Es evidente que algo está fallando con este proceso de subir datos a OSM, o yo entendí mal cuando se decía que se podían subir ya los datos, cuando es obvio que no. Creo que sería necesario explicitar qué se puede hacer y que no, y hacerlo claramente, sin suponer conocimientos previos que uno a lo mejor no tiene. Yo no soy programador, sólo soy un simple profesor de secundaria. Vosotros diréis. Yo por lo pronto dejo todo esto del cat2osm en standby. En todo caso, creo que, visto la complejidad del tema, igual no soy la persona más idónea para encargarme de provincias de Pontevedra y Ourense, por lo que si lo estimáis oportuno, podéis asignar esas provincias a alguien más preparado. Ahora mismo contestaré a Paul Norman para pedirle disculpas, y que no volveré a subir datos de catastro hasta que esté 100% seguro de lo que estoy haciendo, de ahí que os pida claridad en todo este asunto, pues fallar una vez no tiene importancia, pero fallar dos veces sería un poco vergonzoso. Un saludo, Rafael Ávila Coya. Hasta ahora en la lista de imports sólo han dado conformidad para importar los ejes de catastro, que es lo que viene a decirte Paul Norman en su mensaje. Por lo tanto todo lo demás todavía no se puede subir. No es un tema de tener más o menos conocimientos técnicos, es simplemente que no quieren que se suban los datos tal como se ha propuesto hasta ahora en imports. ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es - -- - Por favor, non me envíe documentos con extensións .doc, .docx, .xls, .xlsx, .ppt, .pptx, aínda podendoo facer, non os abro. Atendendo á lexislación vixente, empregue formatos estándares e abertos. http://es.wikipedia.org/wiki/OpenDocument#Tipos_de_ficheros -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPpRAZAAoJEB3niTly2pPQAL8QAJ5OYFvZVj5C3j1B+GnyANqq aVMKDVaoexvcRuBZRzMoZtiMJB0RgTVGphv8VbzbQ+DSnKzSheWnm25cihp6dQMO 8Au23BGGZRyTr3N3d4st50HGvYpdwCVEIqdEnE2aEqvKORapVbyBpgNRK66zEh85 1v0rMitfXCK3SswXnAMJc2MKh+lKuSTOuL/nbOSyx+zR9SGDLWpmSR0a1ocOGfV0 vI+yRFYARCv3HFfyP0ARbhhlkRpK3Yl+XhtJGwuK04ewYkZa8Wx6966HXcNGAojV RRiuxPp1Xps+6vegUGjypWAM96L3xvaauBDoLqyHfXqVVFEOHJZsfv3ybBDpCAAH KcGBTGNrkhi/5GUuHxKt2x8TJgl715hSfelUvPwJT87iJdFb3TXXet5epjlAYK1m /TIpRK/xEwKeSPyLffZqECIqLwJXNmROPXNuKtyZ61NExVsApBKFggqmqAAdufXh VvNyfd8iWaVmbAiwt7Ta9WpbIALAXdBKX6oQG1c6z09WTP4xS6Pe62ggPWJBKCtp
Re: [Talk-es] Bloqueo de catastro_pontevedra
Hola: No sé cómo subir el .osm a la wiki, ni a qué wiki te refieres. Te envío el .osm a tu correo, y luego si tal lo suber tú. Perfecto. La wiki que me refiero es: http://wiki.openstreetmap.org/wiki/Spanish_Cadastre/results/Pontevedra Un saludo, Rafael Ávila Coya. ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Instituto de la Universidad de Zaragoza dona servidores...
Por cierto, teneis espacio para ir subiendo los .osm que salgan del cat2osm?¿?¿? el render lo podríais hacer sobre estos ficheros también :) El día 5 de mayo de 2012 00:41, Javier Briz alg...@gmail.com escribió: El 05/05/2012 00:17, Iván Sánchez Ortega i...@sanchezortega.es escribió: On Viernes, 4 de mayo de 2012 18:28:13 Jaime Crespo escribió: ... a la asociación local de software libre para su uso en el proyecto OpenStreetMap. http://www.unizar.es/actualidad/vernoticia.php?id=8026idh=2627 Eso serán 20-40 cat2osm concurrentes. :-) ¡Oé! ¿Todo se va a destinar a correr cat2osm? No, la idea es montar algún servicio más y dedicar las máquinas restantes ( casi todas) al cat. ¿Hay potencia como para lanzar un render de mapnik worldwide? No se si de worldwide.. Lo que no hay, ni de coña, es disco. Vamos a montar uno de españa. Cuando tengamos red para el rack os vamos comentando como usarlo. -- -- Iván Sánchez Ortega i...@sanchezortega.es i...@geonerd.org http://ivan.sanchezortega.es Proudly running Debian Linux with 3.2.0-2-amd64 kernel, KDE , and PHP 5.4.1RC1 generating this signature. Uptime: 00:16:29 up 10:54, 4 users, load average: 0,22, 0,16, 0,11 ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es -- Cruz Enrique Borges Hernández Email: cruz.bor...@deusto.es DeustoTech Energy Telefono: 944139000 ext.2052 Avda. Universidades, 24 48007 Bilbao, Spain ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Bloqueo de catastro_pontevedra
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hola: Lo de eliminar las separaciones entre edificios sería en mi opinión absurdo, pues es un dato bien importante saber dónde acaba un edificio y dónde empieza otro. Además sería contradictorio. Por poner un ejemplo, la importación del catastro francés se hizo así, mostrando cada bloque separado del siguiente. Podéis verlo en París, por ejemplo: http://osm.org/go/0BOdwT6zu-- O si queréis, yo llevo un par de años haciendo esto a mano, a los pocos, en varios ayuntamientos, por ejemplo en Noia ( http://osm.org/go/b9LZ4u6Gn-- ), y nunca recibí ningún bloqueo por esto. La pregunta sería: ¿porqué consideran válida la separación de edificios en importación de catastro en Francia o en mappeo a mano en España (caso de Noia y muchos otros), y en cambio no lo es con cat2osm? Los datos de edificios, además, incluyen en muchos casos la altura y otros datos que los diferencian. Los datos de altura pueden ser usados en renderizaciones 3D, como por ejemplo éstas: http://www.osm-3d.org Tampoco entiendo lo de las parcelas, aunque sea algo menos importante que los edificios. Aún sin saber las razones que dan, pienso que sería un gran error renunciar a divisiones entre edificios consecutivos, un error que en el futuro sería muy difícil de revertir... Un saludo. On 05/05/12 12:47, Cruz Enrique Borges Hernandez wrote: Como te han comentado sólo nos habían dado permiso para subir carreteras y zonas verdes. Sigue sin gustarles algo de lo que sale porque genera muchos multipolígonos. ¿Has subido el .osm a la wiki para que le echemos un vistazo? Por lo que comentan, no creo que nos dejen subir las parcelas de rústico sin antes juntar geometrías. De urbano habría que volver a consultar a ver que dicen. Más no se puede simplificar sin eliminanar las separaciones entre casas con lo cual nos restringiríamos a lo que en catastro se llama masas y el resto de mortales conocemos por manzanas... ¿Alguien se ofrece voluntario a ejecutar el cat2osm solo con los shapefiles de urbano, arreglar los errors y warnings y probar a ver que dicen en imports? Con renombrar el directorio con los shapes de rustico y el cat rústico debería valer. Lo ideal sería enviar la conflación con lo que hay subido para que se vea el resultado final. PD: menudo control que nos tienen :S Hola: Visto que la gente ya empezó a subir datos del catastro a OSM, decidí subir los datos de Pontecesures, un ayuntamiento pequeño al norte de Pontevedra (6,7 km2, http://osm.org/go/b9LyoEg~- ). Eran como unos 89500 objetos que dejé subiendo a eso de las 12 de la noche (calculé unas 8-9 horas para que completase). Los datos eran completos, es decir, hice un cat2osm.jar -jar config, sin más argumentos, y sólo corregí warnings (no había errores). Hoy por la mañana me encontré un aviso de error en josm, que me remitía a la bandeja de entrada del usuario catastro_pontevedra, donde leía esto: - --- Hello, I noticed you were importing Spanish Cadastre data in http://www.openstreetmap.org/browse/changeset/11502848 and http://www.openstreetmap.org/browse/changeset/11503887 There are a few problems with this. The first is that the problems with many multipolygons appear to have not been fixed. These problems were that too many multipolygons were being generated for what was a simple geometry. The second problem is that you are importing features other than highways and leisure=park. Although the tags have not yet been uploaded, this is evident from where the nodes are. As pointed out http://lists.openstreetmap.org/pipermail/imports/2012-March/001313.html only those features were consulted on with the imports@ list. If you want import more data you need to propose a new import. This block is set to last until you log on to read the message. When you have done that, please revert your imports. If you do not feel able to revert your import let me know and I can do it for you. If you have questions please contact me via a message or the DWG at d...@osmfoundation.org Paul Norman For the Data Working Group - Es evidente que algo está fallando con este proceso de subir datos a OSM, o yo entendí mal cuando se decía que se podían subir ya los datos, cuando es obvio que no. Creo que sería necesario explicitar qué se puede hacer y que no, y hacerlo claramente, sin suponer conocimientos previos que uno a lo mejor no tiene. Yo no soy programador, sólo soy un simple profesor de secundaria. Vosotros diréis. Yo por lo pronto dejo todo esto del cat2osm en standby. En todo caso, creo que, visto la complejidad del tema, igual no soy la persona más idónea para encargarme de provincias de Pontevedra y Ourense, por lo que si lo estimáis oportuno, podéis asignar esas provincias a alguien más preparado. Ahora mismo contestaré a Paul Norman para pedirle disculpas, y que no volveré a
Re: [Talk-es] Bloqueo de catastro_pontevedra
Hola: Lo de eliminar las separaciones entre edificios sería en mi opinión absurdo, pues es un dato bien importante saber dónde acaba un edificio y dónde empieza otro. Además sería contradictorio. Por poner un ejemplo, la importación del catastro francés se hizo así, mostrando cada bloque separado del siguiente. Podéis verlo en París, por ejemplo: http://osm.org/go/0BOdwT6zu-- O si queréis, yo llevo un par de años haciendo esto a mano, a los pocos, en varios ayuntamientos, por ejemplo en Noia ( http://osm.org/go/b9LZ4u6Gn-- ), y nunca recibí ningún bloqueo por esto. O.o lo han hecho a base de ways, no de relaciones. Esto tengo que hablarlo con Ander... De todas formas, los expertos direis, ?¿?¿? es mejor hacer las geometrias compartidas como un relacion (como lo hacemos nosotros) o con ways (como se hizo en París)?¿?¿?¿?¿?¿? Más editable es lo de París, pero no estoy seguro de su correctitud. De todas fornas, creo que los tiros van más por el parcelario rústico, que por otra cosa. La gran pega que dan es que luego sería muy difícil editar dichos datos con las herramientas actuales. Sobre todo por la barbaridad de relaciones que generamos. Tampoco se entiende que se generen tantas parcelas con datos infignificantes (nótese las comillas de ironía), supongo que no han volado por encima de España nunca y flipado con el minifundismo salvaje del norte de España. Aún sin saber las razones que dan, pienso que sería un gran error renunciar a divisiones entre edificios consecutivos, un error que en el futuro sería muy difícil de revertir... Un saludo. ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Instituto de la Universidad de Zaragoza dona servidores...
Algo de espacio si tenemos (yo creo que para montar un repositorio de .osm habrá, en cuanto nos conecten la red). En cada máquina tenemos un disco de 160GB (160x10) a parte de lo que vamos montando en alguna máquina en particular. Podemos pensar en montar algún tipo de interfaz web sube tu propio .osm El tema es que estamos teniendo problemas con las fuentes de alimentación, cuando nos donaron el armario había 3 que no tiraban y acaba de caer una más. Si a alguien le sobra alguna fuente de unos 650W... ;) 2012/5/5 Cruz Enrique Borges Hernández cruz.bor...@deusto.es: Por cierto, teneis espacio para ir subiendo los .osm que salgan del cat2osm?¿?¿? el render lo podríais hacer sobre estos ficheros también :) El día 5 de mayo de 2012 00:41, Javier Briz alg...@gmail.com escribió: El 05/05/2012 00:17, Iván Sánchez Ortega i...@sanchezortega.es escribió: On Viernes, 4 de mayo de 2012 18:28:13 Jaime Crespo escribió: ... a la asociación local de software libre para su uso en el proyecto OpenStreetMap. http://www.unizar.es/actualidad/vernoticia.php?id=8026idh=2627 Eso serán 20-40 cat2osm concurrentes. :-) ¡Oé! ¿Todo se va a destinar a correr cat2osm? No, la idea es montar algún servicio más y dedicar las máquinas restantes ( casi todas) al cat. ¿Hay potencia como para lanzar un render de mapnik worldwide? No se si de worldwide.. Lo que no hay, ni de coña, es disco. Vamos a montar uno de españa. Cuando tengamos red para el rack os vamos comentando como usarlo. -- -- Iván Sánchez Ortega i...@sanchezortega.es i...@geonerd.org http://ivan.sanchezortega.es Proudly running Debian Linux with 3.2.0-2-amd64 kernel, KDE , and PHP 5.4.1RC1 generating this signature. Uptime: 00:16:29 up 10:54, 4 users, load average: 0,22, 0,16, 0,11 ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es -- Cruz Enrique Borges Hernández Email: cruz.bor...@deusto.es DeustoTech Energy Telefono: 944139000 ext.2052 Avda. Universidades, 24 48007 Bilbao, Spain ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Instituto de la Universidad de Zaragoza dona servidores...
On Sábado, 5 de mayo de 2012 17:33:55 Javier Briz escribió: Algo de espacio si tenemos (yo creo que para montar un repositorio de .osm habrá, en cuanto nos conecten la red). En cada máquina tenemos un disco de 160GB (160x10) a parte de lo que vamos montando en alguna máquina en particular. Podemos pensar en montar algún tipo de interfaz web sube tu propio .osm En uno de esos caben sobrado todos los osm comprimidos y descomprimidos casi que también. ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Instituto de la Universidad de Zaragoza dona servidores...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A mi me vendría de perlas, porque no tengo casi donde guardarlos. Y además, lo bueno es que podríamos compartirlos, hacer referencia a ellos en las discusiones por e-mail, etc. On 05/05/12 17:40, Cruz Enrique Borges Hernandez wrote: On Sábado, 5 de mayo de 2012 17:33:55 Javier Briz escribió: Algo de espacio si tenemos (yo creo que para montar un repositorio de .osm habrá, en cuanto nos conecten la red). En cada máquina tenemos un disco de 160GB (160x10) a parte de lo que vamos montando en alguna máquina en particular. Podemos pensar en montar algún tipo de interfaz web sube tu propio .osm En uno de esos caben sobrado todos los osm comprimidos y descomprimidos casi que también. ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es - -- - Por favor, non me envíe documentos con extensións .doc, .docx, .xls, .xlsx, .ppt, .pptx, aínda podendoo facer, non os abro. Atendendo á lexislación vixente, empregue formatos estándares e abertos. http://es.wikipedia.org/wiki/OpenDocument#Tipos_de_ficheros -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPpVIUAAoJEB3niTly2pPQ+coP/2yJjBhyO45SV66xxYeLz0qX IpEChNeZZbjJvMyCvxH9C02CbEKlW+gNaJQraF5kEMFbksMaWGoSsa6jy3dZsOzn f+gWE/90j5z/BGiIpx/8FdZs1RIQ7ZnhAycvegh+N4TM18JzfhGkcXgjVToL71bz 6+ldFLF/8SPiVo+98RHjtZOYMVRY3E7lr5/Nce+hwOYfKhtc7uCqW9yQVSklX1qe uuef/hIOc09Ja7xF63psSXXT20qoGE5ocVQrOT3kkInZ9q396BOC8j6LNZ9Edmvx gOKvemFPVYLqBS0maqL5u+AYJ9+Uhp5zgIqcAsOCKaeE7uSAgmrN4PRDlc5CQLDQ I8zJyjj2CAYfu6I78KwaQuRDccYN/ZSzwyvCKS4lTUdiV+s78EBqOjnzmvwKVW7i KRJseAIF+rW9vKe+Irvse6n4mTWQHfGSnWUJPOPocUYhvyCcyyM72rtNVJLRpCmm kKjZlDWbRk17EdTGLNWcAAyTBNTSZROPQOdlvvAW8K5/fA7SY7952IDeAz+1Cu// heLpRllzgbzgcnN9DtlYKtVgN/OH6HCOqfuRE0N3EhC3HhJ6oZMMIi3v2HMxPLE6 Nfs1zvpWwKM0ntk5/AUc/f7lc861OrVVdZkQCT6BI3KS/QtXDgOCb4Ntnen9IJ3P M0ndeA1TYVbGtls+JpgS =4kRY -END PGP SIGNATURE- ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Bloqueo de catastro_pontevedra
Bueno, yo lo de los edificios y los landuses los hago con relaciones (sólo al principio, cuando no dominaba las relaciones, lo hacía con ways). Podéis ver en Noia (por ejemplo) como lo hago así (el casco viejo, por lo menos, está íntegramente hecho con relaciones multipolygon). Así que, como ya he dicho antes, sería una contradicción que se pudiesen generar esas relaciones a mano, y no se pudiesen, en cambio, hacer por medio de un script! Estoy de acuerdo. En mi opinión, yo creo que queda mucho mejor con relaciones que con ways. En todo caso, inspeccionando los datos con detenimiento, veo que son bastante comunes multipolígonos que tienen nodos dentro de un mismo segmento recto y que podríamos, por lo tanto, eliminar. Esto sería interesante. JOSM tiene una utilidad para esto, podríamos robar ese código y usarlo en el proceso de simplificación de vías. Voy a anotarlo en el tracker de cosas pendientes de hacer. https://github.com/AnderPijoan/cat2osm/issues/22 Como ejemplo, para el municipio de Porto do Son hice un cat2osm de construcciones sólo, donde se pueden ver muchos edificios que aparecen con montón de nodos en medio de segmento recto. Como no puedo enviar fichero de PortoDoSonCONSTRU.osm (22Mbytes) por correo, HINT: los ficheros .osm se comprimen una barbaridad. Si los comprimes con winzip o winrar ocupan alrededor de la décima parte. También, quizás, se podría simplificar lo de separar lo que parece son detalles menores (aleros...) dentro de un mismo edificio. En este mismo fichero un ejemplo serían los edificios que hay debajo (al sur) del edificio grande. https://github.com/AnderPijoan/cat2osm/issues/23 -- Cruz Enrique Borges Hernández Email: cruz.bor...@deusto.es DeustoTech Energy Telefono: 944139000 ext.2052 Avda. Universidades, 24 48007 Bilbao, Spain ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Bloqueo de catastro_pontevedra
El día 5 de mayo de 2012 12:26, Rafael Avila Coya ravilac...@gmail.com escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hola: Visto que la gente ya empezó a subir datos del catastro a OSM, decidí subir los datos de Pontecesures, un ayuntamiento pequeño al norte de Al que suba ahora datos del catastro, le quitaría el acceso a la cuenta por incumplir las recomendaciones (y pediría su bloqueo y reversión inmediata si lo hace con otra cuenta). Ya avisé que esto pasaría. -- Jaime Crespo ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Instituto de la Universidad de Zaragoza dona servidores...
¿Y qué municipios pondréis primero a generar? ¿Sólo los de Zaragoza o pensáis ir generando toda España poco a poco? ¿Se puede proponer alguno? El 5 de mayo de 2012 18:15, Rafael Avila Coya ravilac...@gmail.comescribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A mi me vendría de perlas, porque no tengo casi donde guardarlos. Y además, lo bueno es que podríamos compartirlos, hacer referencia a ellos en las discusiones por e-mail, etc. On 05/05/12 17:40, Cruz Enrique Borges Hernandez wrote: On Sábado, 5 de mayo de 2012 17:33:55 Javier Briz escribió: Algo de espacio si tenemos (yo creo que para montar un repositorio de .osm habrá, en cuanto nos conecten la red). En cada máquina tenemos un disco de 160GB (160x10) a parte de lo que vamos montando en alguna máquina en particular. Podemos pensar en montar algún tipo de interfaz web sube tu propio .osm En uno de esos caben sobrado todos los osm comprimidos y descomprimidos casi que también. ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es - -- - Por favor, non me envíe documentos con extensións .doc, .docx, .xls, .xlsx, .ppt, .pptx, aínda podendoo facer, non os abro. Atendendo á lexislación vixente, empregue formatos estándares e abertos. http://es.wikipedia.org/wiki/OpenDocument#Tipos_de_ficheros -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPpVIUAAoJEB3niTly2pPQ+coP/2yJjBhyO45SV66xxYeLz0qX IpEChNeZZbjJvMyCvxH9C02CbEKlW+gNaJQraF5kEMFbksMaWGoSsa6jy3dZsOzn f+gWE/90j5z/BGiIpx/8FdZs1RIQ7ZnhAycvegh+N4TM18JzfhGkcXgjVToL71bz 6+ldFLF/8SPiVo+98RHjtZOYMVRY3E7lr5/Nce+hwOYfKhtc7uCqW9yQVSklX1qe uuef/hIOc09Ja7xF63psSXXT20qoGE5ocVQrOT3kkInZ9q396BOC8j6LNZ9Edmvx gOKvemFPVYLqBS0maqL5u+AYJ9+Uhp5zgIqcAsOCKaeE7uSAgmrN4PRDlc5CQLDQ I8zJyjj2CAYfu6I78KwaQuRDccYN/ZSzwyvCKS4lTUdiV+s78EBqOjnzmvwKVW7i KRJseAIF+rW9vKe+Irvse6n4mTWQHfGSnWUJPOPocUYhvyCcyyM72rtNVJLRpCmm kKjZlDWbRk17EdTGLNWcAAyTBNTSZROPQOdlvvAW8K5/fA7SY7952IDeAz+1Cu// heLpRllzgbzgcnN9DtlYKtVgN/OH6HCOqfuRE0N3EhC3HhJ6oZMMIi3v2HMxPLE6 Nfs1zvpWwKM0ntk5/AUc/f7lc861OrVVdZkQCT6BI3KS/QtXDgOCb4Ntnen9IJ3P M0ndeA1TYVbGtls+JpgS =4kRY -END PGP SIGNATURE- ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es -- Saludos ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Bloqueo de catastro_pontevedra
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Subí datos porque así se estaba diciendo en la lista. Repasa los correos y lo verás. Existe vandalismo intencionado, algo que no casa, ni de lejos, con esto de lo que hablamos ( http://wiki.openstreetmap.org/wiki/Vandalism ). Si es un error (vandalismo no intencionado), lo que hay que hacer es ponerse en contacto con el usuario que lo hizo y luego se le comunica que se va a revertir el conjunto de cambios o bien que lo haga él. En Kiribati, por ejemplo, por un error de tagging en la línea de costa de la isla de Kiritimati ( http://osm.org/go/QgRGlVA- ), ésta estuvo inundada durante bastante tiempo (meses para algunos niveles de zoom), debido a que la costa renderiza con mayor lentitud que resto de objetos. Quién se puso en contacto conmigo no lo hizo hablando en 3ª persona. Simplemente me envió un mensaje interno por la interfaz web de osm, yo le contesté dándole cuenta del error (humano, no intencionado) que cometí. Cambiamos los tags correspondientes y listo. Estamos aquí para mejorar el mapa, no para tomar medidas represivas así como así. Dudo muchísimo que subir los datos del catastro con otra cuenta sea motivo de bloqueo, de reversión de changeset o de nada. ¿En base a qué decidiría nadie eso? ¿Cómo puedes demostrar siquiera que los datos que sube alguien no los generó con otro programa (bastaría cambiarle una línea de código a cat2osm para que fuese otro programa, cosa bien fácil con la licencia que tiene, o podría generarlos con catastreitor)?. Podría incluso generarlos a mano (como llevo haciendo yo hace un par de años...). ¿También revertirías los datos y bloquearías al usuario correspondiente? Pues ya puedes comenzar conmigo: http://osm.org/go/b9LZ6RC9f- , http://osm.org/go/b8f3vMpFD-- , ... Y conste que me parece muy buena idea hacerlo con las cuentas creadas expresamente, y que yo así lo voy a hacer. No creo que esta forma de solventar problemas, proponiendo bloqueos y reversión inmediata de usuarios que están aportando al proyecto, sea muy recomendable cuando se trabaja en comunidad. Y menos hacerlo sin hablar primero con el responsable del changeset. En este correo-e no veo que estés hablando directamente conmigo usando formas como al que suba datos En fin, tú mismo. Un saludo. On 05/05/12 20:18, Jaime Crespo wrote: El día 5 de mayo de 2012 12:26, Rafael Avila Coya ravilac...@gmail.com escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hola: Visto que la gente ya empezó a subir datos del catastro a OSM, decidí subir los datos de Pontecesures, un ayuntamiento pequeño al norte de Al que suba ahora datos del catastro, le quitaría el acceso a la cuenta por incumplir las recomendaciones (y pediría su bloqueo y reversión inmediata si lo hace con otra cuenta). Ya avisé que esto pasaría. - -- - Por favor, non me envíe documentos con extensións .doc, .docx, .xls, .xlsx, .ppt, .pptx, aínda podendoo facer, non os abro. Atendendo á lexislación vixente, empregue formatos estándares e abertos. http://es.wikipedia.org/wiki/OpenDocument#Tipos_de_ficheros -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPpXt4AAoJEB3niTly2pPQ86kP/2RhMZKhgWlkyV1dByPAt3Y7 stlDntC/8NGhvIpCzrpWA5QLIyYMdJA6Z5pRbTDKyLrq/39lLQ4mrG3sfxOUWeUs PJKbwQAfAjke4oNoU+Yvkgu+jS3BSWsGOjqD/+dYp8EL5U8g4p2SEwTFtT2qjMaY 3vwJpZE3a6ekosSZxAoRMGGqouijtcBOkwemXdus1h9xh+7NEVs5cvG9LF7tzARR unP823lVLy7imxqhfW1GJPpwW7/udYWfjoR5I2yDv+T1aga2E1VbUPqWzz+KfQm0 +j1TpezGvXlwEGruuu6pGCIPmnRcydoNImBn8aowUqPB5HKtEMZw44MrZF5olzSf /dbnBqikpPwITesaWqbl22s1KZfnhITVk4xNzdV+1JHJmR4SdTCobAV7VGS2Pfjx stNXwLvCbQa7xFUXyGeF8FyEaSWSaIjOvH5GOFJFxfq5oo/qfb2wHaB5MoqC2h3G rOLhHtU+7uXkGA1Uqft8gM7h5mNlmpkRUPRblu1McXm8px8ylIZ295Y8AG6otwRx IoOnt/5R2zO113Q3Qxr+yJLTRRYQLiWJzMaTsK1ks3wZQGJTEa1mBGfZoLE+Yapn Z94eI9Utng9ZnmJPZkSXThhst8+CEPZw8oN9lePLnc15a5qc0J95eQcoo/BUKDDG AWxYq8LHHm9BYWj7FHTp =4Gey -END PGP SIGNATURE- ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Bloqueo de catastro_pontevedra
El 05/05/12 21:12, Rafael Avila Coya escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Subí datos porque así se estaba diciendo en la lista. Repasa los correos y lo verás. Que yo recuerde (me puede fallar la memoria) el único que ha comentado hasta ahora que había subido datos de catastro he sido yo y si lees mi mensaje [1] verás que sólo hago referencia a ejes, que es lo que nos han dejado por ahora. (Aparte de otros datos subidos por Konfrare Albert que también se revirtieron en su momento). [1] http://lists.openstreetmap.org/pipermail/talk-es/2012-April/010098.html ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Bloqueo de catastro_pontevedra
El día 5 de mayo de 2012 21:12, Rafael Avila Coya ravilac...@gmail.com escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Subí datos porque así se estaba diciendo en la lista. Repasa los correos y lo verás. Y si hubiera sido otro usuario hubiera respondido igual. Existe vandalismo intencionado, algo que no casa, ni de lejos, con esto de lo que hablamos ( http://wiki.openstreetmap.org/wiki/Vandalism ). Si es un error (vandalismo no intencionado), lo que hay que hacer es ponerse en contacto con el usuario que lo hizo y luego se le comunica que se va a revertir el conjunto de cambios o bien que lo haga él. No he dicho que no lo haría. En Kiribati, por ejemplo, por un error de tagging en la línea de costa de la isla de Kiritimati ( http://osm.org/go/QgRGlVA- ), ésta estuvo inundada durante bastante tiempo (meses para algunos niveles de zoom), debido a que la costa renderiza con mayor lentitud que resto de objetos. Quién se puso en contacto conmigo no lo hizo hablando en 3ª persona. Simplemente me envió un mensaje interno por la interfaz web de osm, yo le contesté dándole cuenta del error (humano, no intencionado) que cometí. Cambiamos los tags correspondientes y listo. Estamos aquí para mejorar el mapa, no para tomar medidas represivas así como así. Nadie ha dicho que yo no haría lo mismo. Dudo muchísimo que subir los datos del catastro con otra cuenta sea motivo de bloqueo, de reversión de changeset o de nada. ¿En base a qué decidiría nadie eso? ¿Cómo puedes demostrar siquiera que los datos que sube alguien no los generó con otro programa (bastaría cambiarle una línea de código a cat2osm para que fuese otro programa, cosa bien fácil con la licencia que tiene, o podría generarlos con catastreitor)?. Pones en mi boca palabras que no he dicho. Podría incluso generarlos a mano (como llevo haciendo yo hace un par de años...). ¿También revertirías los datos y bloquearías al usuario correspondiente? Pues ya puedes comenzar conmigo: http://osm.org/go/b9LZ6RC9f- , http://osm.org/go/b8f3vMpFD-- , ... No. Y conste que me parece muy buena idea hacerlo con las cuentas creadas expresamente, y que yo así lo voy a hacer. No creo que esta forma de solventar problemas, proponiendo bloqueos y reversión inmediata de usuarios que están aportando al proyecto, sea muy recomendable cuando se trabaja en comunidad. Y menos hacerlo sin hablar primero con el responsable del changeset. En este correo-e no veo que estés hablando directamente conmigo usando formas como al que suba datos En fin, tú mismo. Es que no me refería a tu caso. Si te das por aludido... Me vuelvo a recitar: Al que suba ahora datos del catastro, le quitaría el acceso a la cuenta por incumplir las recomendaciones. Explicación: Yo no se lo quitaría, se lo quitaría el responsable de la cuenta *temporalmente* por incumplir las recomendaciones de la wiki y las de la lista imports. (y pediría su bloqueo y reversión inmediata si lo hace con otra cuenta). Explicación: Si alguien sube datos con su cuenta del catastro con su cuenta, habiendo sido advertido de que con la cuenta así designada no lo puede hacer todavía, eso es mala fe, pues ya ha sido advertido. Además, está violando la licencia del catastro pues no lo atribuye adecuadamente, así que los datos deben ser borrados (revertidos). -- Jaime Crespo ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Bloqueo de catastro_pontevedra
El 5 de mayo de 2012 21:12, Rafael Avila Coya ravilac...@gmail.comescribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Subí datos porque así se estaba diciendo en la lista. Repasa los correos y lo verás. En la lista si no me equivoco solo se dijo hace cosa de mes o mes y medio una persona que subio algo sin sabe que no se podia y luego hace poco se a comentado alguna subida de ejes que si esta permitido pero subida de todos los datos completos creo que no habido ninguna. Existe vandalismo intencionado, algo que no casa, ni de lejos, con esto de lo que hablamos ( http://wiki.openstreetmap.org/wiki/Vandalism ). Si es un error (vandalismo no intencionado), lo que hay que hacer es ponerse en contacto con el usuario que lo hizo y luego se le comunica que se va a revertir el conjunto de cambios o bien que lo haga él. En Kiribati, por ejemplo, por un error de tagging en la línea de costa de la isla de Kiritimati ( http://osm.org/go/QgRGlVA- ), ésta estuvo inundada durante bastante tiempo (meses para algunos niveles de zoom), debido a que la costa renderiza con mayor lentitud que resto de objetos. Quién se puso en contacto conmigo no lo hizo hablando en 3ª persona. Simplemente me envió un mensaje interno por la interfaz web de osm, yo le contesté dándole cuenta del error (humano, no intencionado) que cometí. Cambiamos los tags correspondientes y listo. Estamos aquí para mejorar el mapa, no para tomar medidas represivas así como así. Dudo muchísimo que subir los datos del catastro con otra cuenta sea motivo de bloqueo, de reversión de changeset o de nada. ¿En base a qué decidiría nadie eso? ¿Cómo puedes demostrar siquiera que los datos que sube alguien no los generó con otro programa (bastaría cambiarle una línea de código a cat2osm para que fuese otro programa, cosa bien fácil con la licencia que tiene, o podría generarlos con catastreitor)?. Que alguien cambie una linea de código no significa que no se sepa que se a usado este programa. Facilmente se puede ver que el resultado es exactamente el mismo. Ademas una importación de datos sea con el programa que sea hay que comunicarla así que igualmente no se podría hacer y habría motivo de revertir el changeset Podría incluso generarlos a mano (como llevo haciendo yo hace un par de años...). ¿También revertirías los datos y bloquearías al usuario correspondiente? Pues ya puedes comenzar conmigo: http://osm.org/go/b9LZ6RC9f- , http://osm.org/go/b8f3vMpFD-- , ... No tiene que ver el meter datos a mano con una importación. Así que no viene al caso. Y conste que me parece muy buena idea hacerlo con las cuentas creadas expresamente, y que yo así lo voy a hacer. No creo que esta forma de solventar problemas, proponiendo bloqueos y reversión inmediata de usuarios que están aportando al proyecto, sea muy recomendable cuando se trabaja en comunidad. Y menos hacerlo sin hablar primero con el responsable del changeset. En este correo-e no veo que estés hablando directamente conmigo usando formas como al que suba datos En fin, tú mismo. Es para evitar males mayores. Una cosa es que se puedan subir datos libremente y otra cosa es que no exista ningún control. Hay que hablarlo con quien lo a hecho y en eso estoy de acuerdo pero tambien hay que poner un aviso de lo que puede pasar que es lo que creo que a hecho Jaime. Creo que a sido un error que has tenido sin querer al subirlos y ya esta. Se habla se soluciona. Un saludo. On 05/05/12 20:18, Jaime Crespo wrote: El día 5 de mayo de 2012 12:26, Rafael Avila Coya ravilac...@gmail.com escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hola: Visto que la gente ya empezó a subir datos del catastro a OSM, decidí subir los datos de Pontecesures, un ayuntamiento pequeño al norte de Al que suba ahora datos del catastro, le quitaría el acceso a la cuenta por incumplir las recomendaciones (y pediría su bloqueo y reversión inmediata si lo hace con otra cuenta). Ya avisé que esto pasaría. - -- - Por favor, non me envíe documentos con extensións .doc, .docx, .xls, .xlsx, .ppt, .pptx, aínda podendoo facer, non os abro. Atendendo á lexislación vixente, empregue formatos estándares e abertos. http://es.wikipedia.org/wiki/OpenDocument#Tipos_de_ficheros -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPpXt4AAoJEB3niTly2pPQ86kP/2RhMZKhgWlkyV1dByPAt3Y7 stlDntC/8NGhvIpCzrpWA5QLIyYMdJA6Z5pRbTDKyLrq/39lLQ4mrG3sfxOUWeUs PJKbwQAfAjke4oNoU+Yvkgu+jS3BSWsGOjqD/+dYp8EL5U8g4p2SEwTFtT2qjMaY 3vwJpZE3a6ekosSZxAoRMGGqouijtcBOkwemXdus1h9xh+7NEVs5cvG9LF7tzARR unP823lVLy7imxqhfW1GJPpwW7/udYWfjoR5I2yDv+T1aga2E1VbUPqWzz+KfQm0 +j1TpezGvXlwEGruuu6pGCIPmnRcydoNImBn8aowUqPB5HKtEMZw44MrZF5olzSf /dbnBqikpPwITesaWqbl22s1KZfnhITVk4xNzdV+1JHJmR4SdTCobAV7VGS2Pfjx stNXwLvCbQa7xFUXyGeF8FyEaSWSaIjOvH5GOFJFxfq5oo/qfb2wHaB5MoqC2h3G
Re: [Talk-es] Bloqueo de catastro_pontevedra
El día 5 de mayo de 2012 21:29, Carlos Dávila cdavi...@orangecorreo.es escribió: El 05/05/12 21:12, Rafael Avila Coya escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Subí datos porque así se estaba diciendo en la lista. Repasa los correos y lo verás. Que yo recuerde (me puede fallar la memoria) el único que ha comentado hasta ahora que había subido datos de catastro he sido yo y si lees mi mensaje [1] verás que sólo hago referencia a ejes, que es lo que nos han dejado por ahora. (Aparte de otros datos subidos por Konfrare Albert que también se revirtieron en su momento). [1] http://lists.openstreetmap.org/pipermail/talk-es/2012-April/010098.html Ciertamente, de los ejes tenemos permiso, pero esos para mí no son datos del catastro, por no ser problemáticos. El problema son las construcciones y las parcelas. -- Jaime Crespo ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Bloqueo de catastro_la_coruna
Buenas, Pues como veo hemos empezado con buen pie en Galicia. El otro día subí para probar datos revisados de construcciones de Vilasantar (proceso ya revertido) y la cuenta ha sido bloqueada. Sigo la lista y había entendido que ya se podía empezar a ir subiendo cosas revisadas, mea culpa. El lado positivo de esto es que me he enterado de las limitaciones a la hora de importar los datos de cat2osm y de que se está discutiendo el tema en la lista de imports. No voy a entrar en discusiones, si se ha decidido que se suban sólo ciertas partes, así sea. Seguiré las listas e intentaré ser más cuidadoso la próxima vez. Mientras tanto pongo mi cargo de responsable de la cuenta 'catastro_la_coruna' en manos de la comunidad para que haga lo que crea conveniente. Saludos, -- Aitor Freire Astray ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Bloqueo de catastro_pontevedra
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/05/12 21:29, Jaime Crespo wrote: El día 5 de mayo de 2012 21:12, Rafael Avila Coya ravilac...@gmail.com escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Subí datos porque así se estaba diciendo en la lista. Repasa los correos y lo verás. Y si hubiera sido otro usuario hubiera respondido igual. Lo que no sé es qué tal le parecería... Existe vandalismo intencionado, algo que no casa, ni de lejos, con esto de lo que hablamos ( http://wiki.openstreetmap.org/wiki/Vandalism ). Si es un error (vandalismo no intencionado), lo que hay que hacer es ponerse en contacto con el usuario que lo hizo y luego se le comunica que se va a revertir el conjunto de cambios o bien que lo haga él. No he dicho que no lo haría. Pero no lo hiciste. Es cuestión de formas. En Kiribati, por ejemplo, por un error de tagging en la línea de costa de la isla de Kiritimati ( http://osm.org/go/QgRGlVA- ), ésta estuvo inundada durante bastante tiempo (meses para algunos niveles de zoom), debido a que la costa renderiza con mayor lentitud que resto de objetos. Quién se puso en contacto conmigo no lo hizo hablando en 3ª persona. Simplemente me envió un mensaje interno por la interfaz web de osm, yo le contesté dándole cuenta del error (humano, no intencionado) que cometí. Cambiamos los tags correspondientes y listo. Estamos aquí para mejorar el mapa, no para tomar medidas represivas así como así. Nadie ha dicho que yo no haría lo mismo. Era un ejemplo. Dudo muchísimo que subir los datos del catastro con otra cuenta sea motivo de bloqueo, de reversión de changeset o de nada. ¿En base a qué decidiría nadie eso? ¿Cómo puedes demostrar siquiera que los datos que sube alguien no los generó con otro programa (bastaría cambiarle una línea de código a cat2osm para que fuese otro programa, cosa bien fácil con la licencia que tiene, o podría generarlos con catastreitor)?. Pones en mi boca palabras que no he dicho. Qué palabras??? Podría incluso generarlos a mano (como llevo haciendo yo hace un par de años...). ¿También revertirías los datos y bloquearías al usuario correspondiente? Pues ya puedes comenzar conmigo: http://osm.org/go/b9LZ6RC9f- , http://osm.org/go/b8f3vMpFD-- , ... No. Aquí dices que no, pero en caso de hacerlo con cat2osm propondrías bloqueo. Pues ya me dirás cuál es la diferencia, excepto que es muchísimo más lento hacerlo a mano que con cat2osm o cualquier otro programa que se pueda diseñar para esto. Pero el resultado es el mismo. Ni siquiera (y corrígeme si me equivoco) veo que aparezca ninguna referencia (tag createdby) en ningún objeto generado con cat2osm a que haya sido generado con cat2osm. Y conste que me parece muy buena idea hacerlo con las cuentas creadas expresamente, y que yo así lo voy a hacer. No creo que esta forma de solventar problemas, proponiendo bloqueos y reversión inmediata de usuarios que están aportando al proyecto, sea muy recomendable cuando se trabaja en comunidad. Y menos hacerlo sin hablar primero con el responsable del changeset. En este correo-e no veo que estés hablando directamente conmigo usando formas como al que suba datos En fin, tú mismo. Es que no me refería a tu caso. Si te das por aludido... No puedo no darme por aludido, cuando estás contestando a un thread creado por mí, sobre algo que me pasó a mí! Me vuelvo a recitar: Al que suba ahora datos del catastro, le quitaría el acceso a la cuenta por incumplir las recomendaciones. Si son recomendaciones, no son obligaciones. Y si fuesen obligaciones, ¿quién obliga? Sólo pregunto. Explicación: Yo no se lo quitaría, se lo quitaría el responsable de la cuenta *temporalmente* por incumplir las recomendaciones de la wiki y las de la lista imports. (y pediría su bloqueo y reversión inmediata si lo hace con otra cuenta). Explicación: Si alguien sube datos con su cuenta del catastro con su cuenta, habiendo sido advertido de que con la cuenta así designada no lo puede hacer todavía, eso es mala fe, pues ya ha sido advertido. Además, está violando la licencia del catastro pues no lo atribuye adecuadamente, así que los datos deben ser borrados (revertidos). Los datos que se meten en catastro no están atribuídos porque los suba el usuario pepito o el usuario catastro_pontevedra. Están atribuídos en el tag source. Por ejemplo, los datos que edito a mano siempre los acompaño del tag source (Bing, PNOA, catastro, GPS, local_knowledge, etc.). Siempre, desde hace al menos 2 años. Los datos de edificios, entre otros muchos, los edito con capa de catastro. Siguiendo tu razonamiento, al no hacerlo con usuario catastro_xxx estaría incumpliendo los términos, no? Repito. El programa cat2osm se puede modificar mínimamente y usar luego cualquiera, y no hay ninguna razón, en principio, para que no lo pueda usar por su cuenta y subir con su nombre de usuario particular. Creo que es mala
Re: [Talk-es] Bloqueo de catastro_la_coruna
El día 5 de mayo de 2012 21:54, Aitor Freire Astray aitor.fre...@gmail.com escribió: Buenas, Pues como veo hemos empezado con buen pie en Galicia. El otro día subí para probar datos revisados de construcciones de Vilasantar (proceso ya revertido) y la cuenta ha sido bloqueada. Sigo la lista y había entendido que ya se podía empezar a ir subiendo cosas revisadas, mea culpa. El lado positivo de esto es que me he enterado de las limitaciones a la hora de importar los datos de cat2osm y de que se está discutiendo el tema en la lista de imports. No voy a entrar en discusiones, si se ha decidido que se suban sólo ciertas partes, así sea. Seguiré las listas e intentaré ser más cuidadoso la próxima vez. Mientras tanto pongo mi cargo de responsable de la cuenta 'catastro_la_coruna' en manos de la comunidad para que haga lo que crea conveniente. Saludos, Esto no se trata de cortar cabezas. Se trata de hacer las cosas bien... Habrá cosas que (incluso a mí) no me gusten, pero no sólo decidimos nosotros, hay más gente en el proyecto ahí fuera con la que tenemos que contar: administradores de sistemas, usuarios de otros países, usuarios con pocos conocimientos, etc. -- Jaime Crespo ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Bloqueo de catastro_pontevedra
On 05/05/12 21:30, Jorge Sanz Sanfructuoso wrote: El 5 de mayo de 2012 21:12, Rafael Avila Coya ravilac...@gmail.com mailto:ravilac...@gmail.com escribió: Subí datos porque así se estaba diciendo en la lista. Repasa los correos y lo verás. En la lista si no me equivoco solo se dijo hace cosa de mes o mes y medio una persona que subio algo sin sabe que no se podia y luego hace poco se a comentado alguna subida de ejes que si esta permitido pero subida de todos los datos completos creo que no habido ninguna. Existe vandalismo intencionado, algo que no casa, ni de lejos, con esto de lo que hablamos ( http://wiki.openstreetmap.org/wiki/Vandalism ). Si es un error (vandalismo no intencionado), lo que hay que hacer es ponerse en contacto con el usuario que lo hizo y luego se le comunica que se va a revertir el conjunto de cambios o bien que lo haga él. En Kiribati, por ejemplo, por un error de tagging en la línea de costa de la isla de Kiritimati ( http://osm.org/go/QgRGlVA- ), ésta estuvo inundada durante bastante tiempo (meses para algunos niveles de zoom), debido a que la costa renderiza con mayor lentitud que resto de objetos. Quién se puso en contacto conmigo no lo hizo hablando en 3ª persona. Simplemente me envió un mensaje interno por la interfaz web de osm, yo le contesté dándole cuenta del error (humano, no intencionado) que cometí. Cambiamos los tags correspondientes y listo. Estamos aquí para mejorar el mapa, no para tomar medidas represivas así como así. Dudo muchísimo que subir los datos del catastro con otra cuenta sea motivo de bloqueo, de reversión de changeset o de nada. ¿En base a qué decidiría nadie eso? ¿Cómo puedes demostrar siquiera que los datos que sube alguien no los generó con otro programa (bastaría cambiarle una línea de código a cat2osm para que fuese otro programa, cosa bien fácil con la licencia que tiene, o podría generarlos con catastreitor)?. Que alguien cambie una linea de código no significa que no se sepa que se a usado este programa. Facilmente se puede ver que el resultado es exactamente el mismo. Ademas una importación de datos sea con el programa que sea hay que comunicarla así que igualmente no se podría hacer y habría motivo de revertir el changeset Podría incluso generarlos a mano (como llevo haciendo yo hace un par de años...). ¿También revertirías los datos y bloquearías al usuario correspondiente? Pues ya puedes comenzar conmigo: http://osm.org/go/b9LZ6RC9f- , http://osm.org/go/b8f3vMpFD-- , ... No tiene que ver el meter datos a mano con una importación. Así que no viene al caso. Y conste que me parece muy buena idea hacerlo con las cuentas creadas expresamente, y que yo así lo voy a hacer. No creo que esta forma de solventar problemas, proponiendo bloqueos y reversión inmediata de usuarios que están aportando al proyecto, sea muy recomendable cuando se trabaja en comunidad. Y menos hacerlo sin hablar primero con el responsable del changeset. En este correo-e no veo que estés hablando directamente conmigo usando formas como al que suba datos En fin, tú mismo. Es para evitar males mayores. Una cosa es que se puedan subir datos libremente y otra cosa es que no exista ningún control. Hay que hablarlo con quien lo a hecho y en eso estoy de acuerdo pero tambien hay que poner un aviso de lo que puede pasar que es lo que creo que a hecho Jaime. Creo que a sido un error que has tenido sin querer al subirlos y ya esta. Se habla se soluciona. Es de cajón que fue un error. De hecho, la conversación derivó sobre lo que se puede mejorar en cat2osm para que sus resultados sean aceptables por la comunidad osm a nivel global (lista imports). Algunos lleváis más tiempo hablando de esto, otros acabamos de llegar. Pueden haber malentendidos y errores. Afortunadamente, como bien dices, se habla y se soluciona, que para eso osm funciona como wiki (los cambios se pueden revertir en caso de error). Un saludo, Rafael Ávila Coya. Un saludo. On 05/05/12 20:18, Jaime Crespo wrote: El día 5 de mayo de 2012 12:26, Rafael Avila Coya ravilac...@gmail.com mailto:ravilac...@gmail.com escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hola: Visto que la gente ya empezó a subir datos del catastro a OSM, decidí subir los datos de Pontecesures, un ayuntamiento pequeño al norte de Al que suba ahora datos del catastro, le quitaría el acceso a la cuenta por incumplir las recomendaciones (y pediría su bloqueo y reversión inmediata si lo hace con otra cuenta). Ya avisé que esto pasaría. ___ Talk-es mailing list Talk-es@openstreetmap.org mailto:Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es -- Jorge Sanz Sanfructuoso - Sanchi Blog http://blog.jorgesanzs.com/ ___ Talk-es mailing list Talk-es@openstreetmap.org
[Talk-es] Presentación en la lista
Hola, Aunque conocía el proyecto hace tiempo, hasta ahora no me había decidido a aportar un poco de tiempo para ir revisando mapas. El otro día acabé (no recuerdo como) llegando a OpenStreetMap, viendo el mapa de Talavera de la Reina (Toledo), que es de donde soy y viendo que andaba un poco 'en pañales', con lo que me decidí a instalar el JOSM y empezar a editar ciertas cosillas que he visto (una urbanización y un pueblo cercano, mi usuario es 'Itrio'). La cosa es que no tengo claro si lo estoy haciendo correctamente y si hay que coordinarse de alguna forma. He intentado buscar información por la wiki, pero no sé si yo soy muy torpe o es que no he buscado donde debo, porque no me he aclarado. ¿Hay algún responsable de 'Toledo' o 'Castilla la Mancha' al que tenga que avisar de los cambios? Estoy viendo también mensajes sobre importar datos del catastro, yo estoy usando de base para los cambios las ortofotos del SIGPAC (que leí en la wiki que se podían usar). Voy a empezar a corregir calles de Talavera y me gustaría saber si estas ediciones manuales podrían entrar en conflicto luego con los datos importados del catastro. Lo digo más por no hacer trabajo a lo tonto ;-) Un saludo, -- Antonio Navarro mailto:anto...@hunos.net ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Bloqueo de catastro_pontevedra
A la vista de este bloqueo lanzo una pregunta para los más veteranos, que ya habéis visto alguna importación. Si empezamos a facilitar el importar masivamente edificios y ejes (estoy hablando del rack en Zaragoza del que se habla en otro hilo) no nos echarán para atrás también la importación de esos elementos? 2012/5/5 Rafael Avila Coya ravilac...@gmail.com: On 05/05/12 21:30, Jorge Sanz Sanfructuoso wrote: El 5 de mayo de 2012 21:12, Rafael Avila Coya ravilac...@gmail.com mailto:ravilac...@gmail.com escribió: Subí datos porque así se estaba diciendo en la lista. Repasa los correos y lo verás. En la lista si no me equivoco solo se dijo hace cosa de mes o mes y medio una persona que subio algo sin sabe que no se podia y luego hace poco se a comentado alguna subida de ejes que si esta permitido pero subida de todos los datos completos creo que no habido ninguna. Existe vandalismo intencionado, algo que no casa, ni de lejos, con esto de lo que hablamos ( http://wiki.openstreetmap.org/wiki/Vandalism ). Si es un error (vandalismo no intencionado), lo que hay que hacer es ponerse en contacto con el usuario que lo hizo y luego se le comunica que se va a revertir el conjunto de cambios o bien que lo haga él. En Kiribati, por ejemplo, por un error de tagging en la línea de costa de la isla de Kiritimati ( http://osm.org/go/QgRGlVA- ), ésta estuvo inundada durante bastante tiempo (meses para algunos niveles de zoom), debido a que la costa renderiza con mayor lentitud que resto de objetos. Quién se puso en contacto conmigo no lo hizo hablando en 3ª persona. Simplemente me envió un mensaje interno por la interfaz web de osm, yo le contesté dándole cuenta del error (humano, no intencionado) que cometí. Cambiamos los tags correspondientes y listo. Estamos aquí para mejorar el mapa, no para tomar medidas represivas así como así. Dudo muchísimo que subir los datos del catastro con otra cuenta sea motivo de bloqueo, de reversión de changeset o de nada. ¿En base a qué decidiría nadie eso? ¿Cómo puedes demostrar siquiera que los datos que sube alguien no los generó con otro programa (bastaría cambiarle una línea de código a cat2osm para que fuese otro programa, cosa bien fácil con la licencia que tiene, o podría generarlos con catastreitor)?. Que alguien cambie una linea de código no significa que no se sepa que se a usado este programa. Facilmente se puede ver que el resultado es exactamente el mismo. Ademas una importación de datos sea con el programa que sea hay que comunicarla así que igualmente no se podría hacer y habría motivo de revertir el changeset Podría incluso generarlos a mano (como llevo haciendo yo hace un par de años...). ¿También revertirías los datos y bloquearías al usuario correspondiente? Pues ya puedes comenzar conmigo: http://osm.org/go/b9LZ6RC9f- , http://osm.org/go/b8f3vMpFD-- , ... No tiene que ver el meter datos a mano con una importación. Así que no viene al caso. Y conste que me parece muy buena idea hacerlo con las cuentas creadas expresamente, y que yo así lo voy a hacer. No creo que esta forma de solventar problemas, proponiendo bloqueos y reversión inmediata de usuarios que están aportando al proyecto, sea muy recomendable cuando se trabaja en comunidad. Y menos hacerlo sin hablar primero con el responsable del changeset. En este correo-e no veo que estés hablando directamente conmigo usando formas como al que suba datos En fin, tú mismo. Es para evitar males mayores. Una cosa es que se puedan subir datos libremente y otra cosa es que no exista ningún control. Hay que hablarlo con quien lo a hecho y en eso estoy de acuerdo pero tambien hay que poner un aviso de lo que puede pasar que es lo que creo que a hecho Jaime. Creo que a sido un error que has tenido sin querer al subirlos y ya esta. Se habla se soluciona. Es de cajón que fue un error. De hecho, la conversación derivó sobre lo que se puede mejorar en cat2osm para que sus resultados sean aceptables por la comunidad osm a nivel global (lista imports). Algunos lleváis más tiempo hablando de esto, otros acabamos de llegar. Pueden haber malentendidos y errores. Afortunadamente, como bien dices, se habla y se soluciona, que para eso osm funciona como wiki (los cambios se pueden revertir en caso de error). Un saludo, Rafael Ávila Coya. Un saludo. On 05/05/12 20:18, Jaime Crespo wrote: El día 5 de mayo de 2012 12:26, Rafael Avila Coya ravilac...@gmail.com mailto:ravilac...@gmail.com escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hola: Visto que la gente ya empezó a subir datos del catastro a OSM, decidí subir los datos de Pontecesures, un ayuntamiento pequeño al norte de Al que suba ahora datos del catastro, le quitaría el acceso a la cuenta por incumplir las recomendaciones (y pediría su bloqueo y reversión inmediata si lo hace con otra cuenta). Ya avisé que esto pasaría.
Re: [Talk-es] Bloqueo de catastro_pontevedra
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/05/12 22:27, Jaime Crespo wrote: El día 5 de mayo de 2012 21:55, Rafael Avila Coya ravilac...@gmail.com escribió: Si son recomendaciones, no son obligaciones. Y si fuesen obligaciones, ¿quién obliga? Sólo pregunto. Te aseguro que para que se tenga que poner en contacto contigo la comisión de datos de OSM, uno la tiene que prigar, y mucho. Esos son los que obligan. Por encima sólo está la board de la fundación internacional. Si alguien, después de varios avisos continúa ignorando las las simples recomendaciones, él mismo. Yo no sólo no impediré sus actos, sino que informaré de ello. Los datos que se meten en catastro no están atribuídos porque los suba el usuario pepito o el usuario catastro_pontevedra. Están atribuídos en el tag source. Por ejemplo, los datos que edito a mano siempre los acompaño del tag source (Bing, PNOA, catastro, GPS, local_knowledge, etc.). Siempre, desde hace al menos 2 años. Los datos de edificios, entre otros muchos, los edito con capa de catastro. Siguiendo tu Estás violando la licencia del WMS del catastro. Revisaré tus changesets y revertiré adecuadamente. Qué es eso de que la capa WMS del catastro no se puede usar? En Spain Potential Datasources ( http://wiki.openstreetmap.org/wiki/Spain_Potential_Datasources#Uso_del_servicio_WMS ) se dice esto desde hace ya varios años: - --- Uso del servicio WMS En la web del Catastro dicen: La Dirección General del Catastro ofrece como servicio WMS la Cartografía Catastral de forma libre y gratuita. LIMITACIONES DEL SERVICIO: El servicio WMS es libre y gratuito, con la única limitación de no realizar descargas masivas de porciones de Cartografía. Es decir, usted puede consultar la cartografía actualizada siempre que la necesite pero no puede ejecutar un programa que se descargue una porción de cartografía haciendo sucesivas peticiones al servidor. La D.G. del Catastro se reserva el derecho de restricción del servicio por abuso del mismo, y podrá emprender acciones legales en el caso de que el abuso cause un perjuicio económico. - Dónde está que usar la capa WMS del catastro sea ilegal? Espero que no hagas ninguna reversión de los datos que subí, horas y horas diarias, durante los últimos años, si no estás seguro de lo que haces. razonamiento, al no hacerlo con usuario catastro_xxx estaría incumpliendo los términos, no? Estarías incumpliendo la normativa respecto a importaciones masivas. Consecuencias: las que ya has sufrido. Arriba me remito. Es más fácil atribuir mediante changesets y/o usuarios que mediante tags. Las tags se pueden borrar. Hay unas normas claras, por favor, síguelas. Repito. El programa cat2osm se puede modificar mínimamente y usar luego cualquiera, y no hay ninguna razón, en principio, para que no lo pueda usar por su cuenta y subir con su nombre de usuario particular. Creo que es mala idea, pero puede pasar. No creo que en ese caso sea bueno proponer el bloqueo de ese usuario ni menos revertir los Mi opinión: bloqueo preventivo. Puedes tirar abajo OSM. Obviamente hay medidas de seguridad, por eso el bloqueo termina aplicándose después de detectarse por los administradores de sistemas que monitorizan la cola de renderizado de mapnik. cambios, que a lo mejor le costaron varios días de trabajo. Quizás mejor sería ponerse en contacto con él, y si no quiere unirse, pedirle por lo menos que facilite los números de changesets correspondientes, para seguir haciendo un seguimiento. Tal y como te han hecho, así que estaría bien que ayudaras con la reversión. Como pone en la normativa de importación, si no sabes deshacer lo que importas, tal vez no debas importar en primer lugar. Eso va por todo el mundo, así que ya estáis aprendiendo a revertir. ;-) - -- - Por favor, non me envíe documentos con extensións .doc, .docx, .xls, .xlsx, .ppt, .pptx, aínda podendoo facer, non os abro. Atendendo á lexislación vixente, empregue formatos estándares e abertos. http://es.wikipedia.org/wiki/OpenDocument#Tipos_de_ficheros -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPpZCdAAoJEB3niTly2pPQnLgP/RXIfAFqE95BMwXZo2MmpMCc SNUtbliq/ULipsTK7rwwxKINOng/bg11ntdH3fR0VDNRKoJXCa3ReOD7hlpcV5No qacSdKCcjsaquVh0YzsC9dgMG839dCtH9KtpjJ7pQd0dULkMWCgFZ2fAadnPnGSD KK+yQJ+HFMEIlI9i8tsFjNoif6y+r5MC9tlZzkvxus0IfW2snNprkOFPkoQT9cph y1R5PDER/nAv9Kp2sXFyAK7hWVmK85jsD1HiJSV7Myf0Wr33kSmPPN6QVaymTiS/ z78d707dKpLdRTyUPpJhJOuDloKx7rx/ByKHwHhtguMXkxQ+NVuaVowekgSM9j6A SMbekkCqfDbhe4GhMq52PMKsn9NWmkq9Bx0lXSbn9eCe1ag4G2IwSygwap4ha8Ku AO6oCt+yiUQNP/J4bSZYI24/dXaylcNf+6d2NTbrhFM/fIXFuX9k5JcuITwWX58B 5D8AQeg1AsYD89Rv6ilSzQE8uhzEaVQpnB3AQVgjOCDXn1ACf3ds7qYPBl6MtRfw xn5CfOPKBaoQKlcGwvQayFMjogySLXXdPeBdhAGGWVxJOnVqsUvuVGsxncldZnZO
Re: [Talk-es] Bloqueo de catastro_pontevedra
A la vista de este bloqueo lanzo una pregunta para los más veteranos, que ya habéis visto alguna importación. Si empezamos a facilitar el importar masivamente edificios y ejes (estoy hablando del rack en Zaragoza del que se habla en otro hilo) no nos echarán para atrás también la importación de esos elementos? Con alta probabilidad, salvo que se solucionen a mano algunas cosas. Además puede servir de testing. De todas formas, voy a ver si la semana que viene sacamos el jueves o el viernes un rato para implementar un par de cosas (la reducción del número de nodos en vías y las envolturas de los edificios) para intentar de nuevo que nos acepten la capa urbana. Por cierto, si hacemos las envolturas de los edificios es lo mismo que perder la capa 3D ¿alguien sabe como ha quedado la cosa? -- Cruz Enrique Borges Hernández Email: cruz.bor...@deusto.es DeustoTech Energy Telefono: 944139000 ext.2052 Avda. Universidades, 24 48007 Bilbao, Spain ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Presentación en la lista
El día 5 de mayo de 2012 22:35, Antonio Navarro anto...@hunos.net escribió: Hola, Bienvenido, Antonio. Y gracias por contribuir a este proyecto Aunque conocía el proyecto hace tiempo, hasta ahora no me había decidido a aportar un poco de tiempo para ir revisando mapas. El otro día acabé (no recuerdo como) llegando a OpenStreetMap, viendo el mapa de Talavera de la Reina (Toledo), que es de donde soy y viendo que andaba un poco 'en pañales', con lo que me decidí a instalar el JOSM y empezar a editar ciertas cosillas que he visto (una urbanización y un pueblo cercano, mi usuario es 'Itrio'). Con tu nombre de usuario, alguien de aquí puede echarle un vistazo. Tu mismo puedes ver tus ediciones en: http://www.openstreetmap.org/user/Itrio/edits Pero no tengas miedo, OSM funciona estilo wiki: edita sin miedo siempre que no borres o que no desmejores lo ya existente. Un consejo es que, al principio, sigas haciéndolo como hasta ahora: haciendo ediciones pequeñas y aplicando los cambios cada poco tiempo. La cosa es que no tengo claro si lo estoy haciendo correctamente y si hay que coordinarse de alguna forma. He intentado buscar información por la wiki, pero no sé si yo soy muy torpe o es que no he buscado donde debo, porque no me he aclarado. ¿Hay algún responsable de 'Toledo' o 'Castilla la Mancha' al que tenga que avisar de los cambios? Probablemente la confusión sea por un conjunto de mensajes referentes a la importación de determinadas cosas del Catastro de España, del que recientemente conseguimos permiso. Mi consejo sería que, de momento, ignoraras esos mensajes ya que se tratan aparte (son ediciones masivas y sí están sometidas a unos controles de calidad más estrictos). No existen responsables de zonas. Estoy viendo también mensajes sobre importar datos del catastro, yo estoy usando de base para los cambios las ortofotos del SIGPAC (que leí en la wiki que se podían usar). Voy a empezar a corregir calles de Talavera y me gustaría saber si estas ediciones manuales podrían entrar en conflicto luego con los datos importados del catastro. Lo digo más por no hacer trabajo a lo tonto ;-) Te aconsejaría usar JOSM como programa, ya que permite cargar el sigpac como capa base y, aunque es un poco más difícil de aprender a usar, con el tiempo es más fácil de editar (en mi opinión). Antes de meterte en temas del catastro, te recomendaría pasar un tiempo con ediciones manuales. Nada debería ser borrado, pero te aconsejaría que te centraras en calles, carreteras, comercios, etc. pues construcciones y números de portal ya existen en el catastro. @Cruz: No me líes a los usuarios nuevos... -- Jaime Crespo ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Presentación en la lista
@Cruz: No me líes a los usuarios nuevos... Vaale. -- Cruz Enrique Borges Hernández Email: cruz.bor...@deusto.es DeustoTech Energy Telefono: 944139000 ext.2052 Avda. Universidades, 24 48007 Bilbao, Spain ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-at] Hands-On Nachmittag
Machen wir mal einen Arbeits-Nachmittag (hands-on), bei dem wir gewisse Dinge besprechen und ggf. umsetzen? Ev. könnten wir auch Gruppen aufteilen, die sich mit verschiedenen Themen beschäftigen... Da bin ich auch mit dabei. LG, Christian ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Hands-On Nachmittag
On 04.05.12 15:38, Boris Cornet wrote: Ich hätte Lust, aber werde deswegen sicher nicht nach Wien fahren. Wäre skype denkbar? Glaub', wir müssen dieses Wochenend-Treffen in Tirol doch mal machen... ;) /al ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Open Time Table (war: Öffnungszeiten)
On 04.05.12 22:38, Rainer Fügenstein wrote: wie wärs mit einem open time table projekt? Mein Gefühl ist, dass Fahrplandaten (und vielleicht mal live-Daten) irgendwann OpenData werden (werden müssen). Der Weg ist allerdings noch steinig, wenn man sich die ersten Reaktionen der Wiener Linien ansieht... Steve sollte sowas ja mal anleiern, wirklich was draus geworden ist AFAIK nicht. /al ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk-fr] Problème insoluble de géométrie.
Je confirme que ton ficher OSM ne marche pas : il correspond EXACTEMENT à ce que j'avais mis juste avant de scinder le nœud commun en 4 (regarde l'historique). Ton fichier ne lève pas du tout l'ambiguité de la façon d'interconnecter les 4 segments limités par ce point commun, osm2gis les connecte ensemble de la mauvaise façon dans tous les cas, que ces segments soient séparés dans des ways distincts ou non, et quelque soit le rôle (inner ou outer) attribué à ces ways. Et ici, osm2gis cherche toujours à connecter le maximum de segments : quand il a fait le tour d'un des deux polygones fermés, il voit encore avant et après ce point deux autres segments (ceux de l'autre polygone), il crée donc une double boucle qui s'entrecroise sur elle-même et ne sait même pas non plus lesquels coisir pour éviter cet entrecroisement : c'est au petit bonheur la chance selon on critère non défini clairement (visiblement c'est la première paire trouvée de segments jointifs qui est choisie sans tenir compte d'aucun autre critère pour savoir s'il sont connectables ou non). Il n'y a actuellement aucun moyen (fiable et documenté) de distinguer clairement les ring de chaque polygone : - les rôles communs attribués aux ways devraient servir à ça pour qu'osm2gis ne se trompe pas et ne fasse pas confiance au seul hasard de ce qu'il trouve quand il énumère les listes de segments (note osm2gis convertit tous les ways en listes de segments rectilignes et unitaires, il finit donc par ignorer même le groupement des segments en ways, et ne garde pas trace non plus des rôles qui ont été attribués aux ways membres pour les attribuer aux segments unitaires : cela se passe bien avant même le tri des segments puis la recherche exhaustive de toutes les paires de segments interconnectés, d'où il déduit ensuite les lignes polygonales fermées traduites en polygones, et les lignes ouvertes converties alors en polylignes). - le tri initial des ways membres dans la relation est lui aussi totalement ignoré. - de même osm2gis ignore aussi la distinction des nœuds OSM ayant des id différents (une solution que j'ai testée aussi pour tenter de résoudre le problème et qui n'a pas marché non plus) : il unifie tous les nœuds superposés à la même position en un seul, dès le début lorsqu'il découpe les ways en listes de segments unitaires. - tout segment qui en touche en autre formera une ligne polygonale chaque fois que possible par extension maximale : tant qu'il peut prolonger la polyligne par un segment non encore utilisé par un des polylignes en cours de génération, osm2gis le fait (la conversion des polylignes en polygones tient compte sulement du test final de la polyligne pour savoir sir les deux noeuds d'extrémité sont aux mêmes positions ou non). En résumé, osm2gis ne semble avoir strictement aucun critère de choix quand il y a plusieurs segments candidats à l'interconnexion dans une même polyligne à partir d'un même point GIS (peu importe le nœud OSM d'origine de ce point GIS puisque la distinction des nœuds OSM est aussi perdue et n'est plus un critère distinctif pour former la géométrie). En revanche osm2gis sait éliminer les paires de segments communs (sans tenir compte de leur orientation initiale dans le way où ce segment était présent), pour simplifier les géométries GIS obtenues (ce qui a pour effet bénéfique de joindre automatiquement les surfaces mitoyennes en une seule): - on ne devrait pas être obligé de faire ce nettoyage dans une représentation par frontières si on utilisait les relations filles pour former des relations pour des surfaces plus grandes, puisqu'il pourrait par ce procédé les joindre automatiquement aussi en éliminant les frontières communes (forcément partagées par paires de segments communs) : - on doit lui prémâcher le travail (ce qui lui évite aussi des tonnes de sous-requetes pour aller chercher les relations membres) en détaillant à sa place uniquement les ways externes et internes de don coutour mais c'est très pénible à éditer : des collections de polygones fermés dans des sous-collections feraient aussi bien le travail. Autrement dit, - on modélise dans la base OSM en fonction d'osm2gis, malgré ses bogues/limitations, - mais on omet dans la base OSM des infos dont il aurait besoin pour faire correctement le travail de génération des géométries : cela demanderait des modifications dans osm2gis, mais aussi de documenter mieux la façon de taguer les multipolygones qui se touchent - les rôles des membres ont un rôle décisif (et plus utile) à jouer pour les ways (ou relations) membres d'une relation avec ce système, il ne serait même plus nécessaire de trier les membres qui deviendraient des listes non ordonnées de ways ou relations munies d'un rôle, chaque rôle mentionné dans la relation formant une collection elle aussi non ordonnée ; d'où un gain de stockage dans la base OSM pour les relations puisqu'on peut alors éliminer les indices de tri des membres dont osm2gis ne tient finalement aucun compte - le
Re: [OSM-talk-fr] Problème insoluble de géométrie.
Le 04/05/2012 22:31, sly (sylvain letuffe) a écrit : Le vendredi 4 mai 2012 22:22:55, DH a écrit : Cet espace est une espèce de trou noir si j'ai bien compris le schéma. Quelle dimension pour le supertuyau afin de canaliser le superflux ? PVCompatible ? ça va ? c'est de la bonne ? oui c'est de la bonne ; je l'ai acheté dans la même boutique où tu as trouvé ton dictionnaire. Self-Ring Intersection ? http://workshops.opengeo.org/postgis-intro/validity.html Non, je ne m'engagerai pas plus avant. Cette liste n'est pas ni dimensionnée ni opportune pour faire cela. C'est un peu facile, tu réponds, maintenant t'assume le retour ;-) Certes c'est technique, mais c'est directement une question de comment (ne pas) mapper une relation multipolygone et en ça, ça n'est pas une question de dev donc dev-fr ne me semble pas la liste la plus adaptée, mais je peux me tromper. Il me semble que le problème se situe au niveau de l'interprétation d'un osm2pg (ou autre) et donc plutôt dev. Mais je peux me tromper. Modifier la manière de tracer des figures complexes (mais valides) est un pis-aller pour éviter des problèmes de conversion en SQL/OGC. Ton lien est très bien et j'étais déjà tombé dessus mais il parle de la primitive POLYGON de l'OGC pas de la primitive MULTIPOLYGON dont il est question ici, qui elle autorise que deux polygons distinct se touchent au sein d'une primite MULTIPOLYGON Exact. Pour un multipolygon ça ne le rend pas invalide. Comment se prend la décision de passer un way en polygone ou en multipolygone (hors cas faciles) ? Si les bordures constitutives de la commune sont transformées en polygon, il y une erreur de validité de la figure. Si les bordures dont converties en multipolygon, ça passera sans souçi. Denis ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Problème insoluble de géométrie.
Le 5 mai 2012 10:23, DH dhel...@free.fr a écrit : Ton lien est très bien et j'étais déjà tombé dessus mais il parle de la primitive POLYGON de l'OGC pas de la primitive MULTIPOLYGON dont il est question ici, qui elle autorise que deux polygons distinct se touchent au sein d'une primite MULTIPOLYGON Exact. Pour un multipolygon ça ne le rend pas invalide. Comment se prend la décision de passer un way en polygone ou en multipolygone (hors cas faciles) Le problème n'est pas celui de la validité (selon le modèle OSM actuel) mais vient de l'ambiguité d'interprétation du modèle OSM, parce que le cas que j'ai donné n'ai pas clairement documenté et défini pour que la conversion OSMGIS puisse se faire sans difficulté. Une présupposition non décritedu modèle Multipolygone d'OSM s'avère fausse et c'est bien là le problème. Et ce n'est pas non plus un bogue à proprement parler d'osm2gis puisqu'il fait de son mieux pour interpréter ce que lui indiquent les données OSM, afin de savoir quoi générer : un ou plusieurs plolygnes fermés ou non, selon les connexions de segments qu'il trouve dans la base. Si les bordures constitutives de la commune sont transformées en polygon, il y une erreur de validité de la figure. Si les bordures dont converties en multipolygon, ça passera sans souçi. Si un noeud est utilisé par 4 segments (donc utilisés par au moins 2 ways différents), osm2gis ne sait pas comment joindre les segments car il n'a pour l'instant encore strictement aucun de critère défini (et documenté) Il connecte tout ce qu'il peut (et pas dans l'ordre qui serait approprié) puisqu'il ne tient pas compte (et ne peut PAS ENCORE tenir compte) des rôles des membres d'une relation ni de leur ordre relatif dans la relation, à cause des différentes façons de créer des multipolygones (avec des rôles incohérents, avec ou sans tri, il doit se débrouiller pour reconnecter le tout, et si ça marche pour les cas simples et les plus fréquents où les polygones ne se touchent pas entre eux, l'algo ne PEUT PAS fonctionner si ces polygones se touchent). Sans ces critères clairement défini, les multipolygones d'OSM ne peuvent pas gérer correctement les polygones qui se touchent (alors qu'ils sont nécessaires et standards dans les modèles GIS, même pour le profil Simple Features). Moi je propose une solution simple : le critère de choix pour les connexion c'est le **rôle** (sans même lui attribuer une signification outer ou inner, c'est un simple nom symbolique permettant d'identifier et séparer les polygones distincts). Si on fait ça correctement, et si on le documente il devrait alors être possible de modifier osm2gis pour qu'il en tienne compte au lieu de connecter n'importe quelle paire de segments. Pour la compatibilité, il faut toutefois que le rôle anonyme et les rôles outer et exclave soient reconnus comme équivalentsau seul rôle étiqueté outer (mais en continuant à ignorer leur signification en tant que contour externe ou interne, car osm2gis le déterminera tout seul), et de même pour les rôles enclave et inner. Et d'autres rôles de la forme outer:* ou 'inner:* devraient être acceptés, mais distingués pour permettre la séparation des polygones qui ne doivent pas s'interconnecter. En revanche l'ordre des membres dans la relation ne doit jouer strictement aucun rôle (cet ordre des membres dans la relation ne sert strictement à rien, on pourrait même éviter de le stocker dans la base OSM, ce qui lui éviterait aussi de passer du temps et de l'espace disque temporaire dans les tris pendant les requêtes de chargement ou pour mettre à jour un index si le tri est précalculé et stocké dans l'index). L'ordre des membres dans la liste n'est qu'une facilité de présentation dans les éditeurs, mais les éditeurs peuvent trier ces listes eux-mêmes automatiquement, et soumettre les listes dans n'importe quel ordre (le serveur n'a pas besoin de stocker cet ordre dans un index, ni même de trier les requêtes de chargement : il ira d'autant plus vite !). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Problème insoluble de géométrie.
ça va ? c'est de la bonne ? oui c'est de la bonne ; je l'ai acheté dans la même boutique où tu as trouvé ton dictionnaire. Ben mince alors, pas terrible donc, je vais changer de boutique et je relirais mon mail la prochaine fois. Il me semble que le problème se situe au niveau de l'interprétation d'un osm2pg (ou autre) et donc plutôt dev. Oui c'est ce que je pense aussi, mais philippe semble insister sur le fait qu'il n'arrive pas à rentrer un tel cas dans osm. C'est pour ça que je souhaite diriger le débat sur cette liste sur le peut-on bien la rentrer dans OSM et comment et déplacer l'autre partie du débat (quels outils pour faire du OSM-OGC) vers dev / dev-fr / ou autre Mais comme je ne vois pas où est le problème pour mettre une telle commune dans OSM, je pense que philippe est juste en train de mélanger les deux débats. Modifier la manière de tracer des figures complexes (mais valides) est un pis-aller pour éviter des problèmes de conversion en SQL/OGC. +1 Exact. Pour un multipolygon ça ne le rend pas invalide. Comment se prend la décision de passer un way en polygone ou en multipolygone (hors cas faciles) ? On sort du débat comment tagguer une relation multipolygon dans osm pour aller vers comment convertir que je laisse de coté ou si quelqu'un le veut, déplace ce débat sur dev-fr -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Problème insoluble de géométrie.
solution et cela ne marchait pas !). je crois que ce que tu défini par ne marche pas m'échappe. cela ne marche pas car ton test consiste à créer deux zones fermées seulement et tu ignores les deux autres zones qui entourent ce point commun. Bref ton test est incomplet. Voilà comment faire en pièce jointe, 3 communes A,B et C avec un point commun aux 3 et une commune (A) en Deux morceaux. Aucun problème pour le mettre dans OSM, donc ni le modèle osm ni JOSM ne l'empêche. Donc on en revient à la conversion des données OSM dans un modèle OGC par des outils, et ce débat n'a pas sa place sur cette liste, on peut soit basculer sur la liste dev-fr soit dev soit, comme le disait, sur le wiki (ce que j'ai commencé). Crois-moi, je l'avais essayé, et cela ne marchait pas du tout ! (...) Toujours trop long est pas lisible, j'arrête ici ma lecture. -- sly (sylvain letuffe) demo2.osm Description: XML document ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Problème insoluble de géométrie.
Le samedi 5 mai 2012 07:26:09, Philippe Verdy a écrit : Note: je suis tombé aussi sur d'autres cas de géométries qui son mal résolues lors de la conversion OSM vers OGC. Mon avis est que cette question n'a pas sa place sur cette liste car trop technique; et, spécifique, à mon avis, à l'outil de conversion utilisé. -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Problème insoluble de géométrie.
Le 5 mai 2012 12:19, sly (sylvain letuffe) li...@letuffe.org a écrit : Le samedi 5 mai 2012 07:26:09, Philippe Verdy a écrit : Note: je suis tombé aussi sur d'autres cas de géométries qui son mal résolues lors de la conversion OSM vers OGC. Mon avis est que cette question n'a pas sa place sur cette liste car trop technique; et, spécifique, à mon avis, à l'outil de conversion utilisé. Peut-être mais l'outil utilisé sert absolument à tout le monde (et pas seulement les moteurs de rendus) dès qu'on cherche à interpréter le contenu de la base OSM. Je maintiens le fait que ce qu'on met dans le base est ambigu pour le cas des polygones qui se touchent car ce cas n'est pas documenté du tout (alors que la doc des multipolygones d'OSM prétend que c'est compatible avec le GIS standard). Il manque une règle non écrite (et en fait pas respectée du tout puisque jamais vérifiée explicitement et non nécessaire la plupart du temps car l'immense majorité des multipolygones d'OSM ne contiennent pas de polygones qui se touchent). Ce n'est PAS spécifique à l'outil utilisé. L'ambiguité est intrinsèque à la représentation OSM actuelle. Ta demo2 je l'avais déjà essayée aussi (exactement comme tu l'as envoyée, regarde l'historique de la même municipalité) : elle ne marchait pas non plus, car elle contient la même ambiguïté d'interprétation au vu des règles OSM décrites actuellement. On ne sait pas dire à partir des données OSM quels ways interconnecter (ou pas) pour former les polygones fermés, ou si on doit générer un seul polygone ou plusieurs (en modèle GIS standard ce devrait être plusieurs, car il n'est pas permis aux sommets d'un même polygone d'être visité plus d'une fois par le chemin qui le traverse, sauf les 2 sommets terminaux du chemin lui-même qui peuvent être identiques pour produire un polygone fermé). Il n'y a aucune règle dans OSM pour faire les paires correctes de ways. Comment te convaincre ? Pourtant j'avais réduit le cas à quelque chose de plus simple dans un schéma pour éviter d'avoir à comprendre le cas concret bien plus compliqué. Il n'est décrit nulle part dans les règles de modélisation OSM quels ways d'un multipolugone se connectent à quel autre, et c'est bien pour ça qu'osm2gis se trompe (et ce n'est pas un bogue de cet outil). Ce qui est décrit en revanche c'est que : - les ways ne doivent pas se croiser (que ce soit sur un point non décrit par un noeud commun, ou sur un noeud intermédiaire qui n'est pas un des 2 noeuds terminaux d'un way). - il décrit aussi le fait que les noeuds terminaux des ways se touchent par paire (puisque c'est la seule façon de les connecter pour former des polygones fermés), - mais pas écrit combien de ways peuvent utiliser le même noeud terminal Dans le modèle OSM actuel, cela marche bien quel que soit le rôle indiqué pour les ways, à condition que nulle par il y ait plus de 2 ways terminés sur un même nœud), les rpoles inner et outer ne sont qu'indicatifs et servent davantage au contrôle de cohérence entre ce qu'on peut déduire de la géométrie et ce qui est dans la base, mais ces rôles ne servent encore à rien pour générer la géométrie. De fait: - peu importe comment on renseigne les rôles tant que les polygones ne se touchent pas et sont tous fermés sans se croiser eux-mêmes, et peu importe si les polygones sont décrits en un seul ou plusieurs ways, avec ou sans partage des ways pour les frontières communes de deux zones limitrophes cela marche, il n'y a pas d'ambiguîté réelle au fait de connecter systématiquement toute paire de way qui partagent un même noeud terminal. Ce n'est pas le cas ici. Il faut une règle de résolution en plus, propre à OSM lui-même, et dont ensuite les outils (osm2gis ou un autre) devront tenir compte. Bref cela a a bien place sur cette liste avant même d'aller sur la liste DEV, car c'est un problème de modélisation OSM, propre et intrinsèque au schéma OSM lui-même pour demander qu'on modifie les outils pour tenir compte d'une règle supplémentaire de résolution de l'ambiguïté. Oui c'est technique, mais on est encore loin de la solution finale. Je maintiens que le problème est encore insoluble dans le modèle OSM actuel qui mélange les rings distincts dans une même relation Sachant aussi : - qu'il n'est pas possible de déterminer depuis la liste des ways membres, même correctement ordonnée, où s'arrête la sous-liste d'un polygone fermé et ou commence la sous-liste du polygone fermé suivant, si ces deux polygones fermés (internes ou externes peu importe) partagent un noeud commun : on utilise quoi pour les séparer ? l'ordre ne suffit pas. les rôles différents ne suffisent pas non plus (et sont encore assez souvent incohérents. - et que la plupart du temps et presque partout ces ways sont très souvent dans le désordre, l'ordre pouvant être brisé à tout moment simplement en scidant un way en deux parties, selon son orientation). - que les rôles sont souvent aussi aléatoires : tant que les polygones fermés ne se touchent pas
Re: [OSM-talk-fr] Problème insoluble de géométrie.
Le 5 mai 2012 13:07, Philippe Verdy verd...@wanadoo.fr a écrit (entre autre) : Tu ne comprends pas le problème visiblement. Philippe, ce que j'ai beaucoup de mal à comprendre ce sont surtout tes mails... je ne pense pas être le seul. Il me semble que le problème se situe au niveau d'osm2gis qui fait une conversion incorrecte des objets OSM en objets GIS. Le modèle OSM dont tu parle est très permissif, on peut définir dans OSM toutes les géométries que tu as indiqué et qui sont valides (on peut même définir des géométries invalides vu qu'il n'y a aucun contrôle par l'API), c'est seulement ensuite qu'il y a un problème lors de la conversion par osm2gis. Pour moi (et visiblement pour d'autres) il n'y a pas de limitation côté OSM mais un bug dans osm2gis qui ne gère pas correctement les cas particuliers que tu as très justement signalé. -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Problème insoluble de géométrie.
Note bien ce qui est écrit dans la doc des multipolygones sur le wiki : Usage The intended use of multipolygons is this: [..] The direction of the ways does not matter. The order of the relation members does not matter (but properly sorted member lists can help human editors to verify completeness). Autrement dit la direction et l'ordre des ways nétant pas significative, tous les outils DOIVENT trier ces listes pour déterminer comment fermer les polygones ou former des lignes continues. Aucun éditeur n'assure que le tri sera conservé par exemple lorsqu'on scince un way en deux parties (les parties peuvent être ajoutées dans un ordre quelconque dans la relation. Si on ne peut pas tenir compte de l'ordre, alors ton fichier demo2 décrit 3 géométries différentes (dont une seule ici peut correspondre à une géométrie GIS valide) Mais dans d'autres cas, il y a plusieurs géométries possibles aussi dès que les polygones se touchent si on a plus que deux polygones dans la même relation. C'est le cas dans la municipalité mentionnée en Espagne qui, si on ne PEUT PAS tenir compte de l'ordre stocké dans la base (selon la doc wiki elle-même), génère 18 géométries possibles, dont 9 sont valides en GIS ! Si on doit tenir compte de l'ordre alors il y a des quantités énormes de multipolygones brisés à réparer, et la doc est donc fausse puisque l'ordre est significatif et les outils d'édition devraient alors en tenir compte pour ne pas les briser par un ordonnancement incorrect lors s'une simple scission d'un way en deux parties, ou lorsqu'on fusionne des ways communs (au passage leur orientation est aussi modifiée, mais elle n'est pas significative non plus, toujours d'après le wiki) ! Bref il n'y a PAS de bogue dans osm2gis, il est OBLIGÉ de trier lui-même (à cause des règles énoncées dans la doc du wiki OSM), et n'a aucune indication sur le nombre de ways à inclure dans un même polygone (il cherche en fait à créer les polygones comptant le plus grand nombre de segments possibles, et c'est ce qui génère alors de toute façon les boucles qui se croisent et des géométries invalides non représentables en tant que polygones GIS ; s'il cherchait uniquement à générer des polygones GIS valides, fermés, sans aucun noeud parcouru plus d'une fois par le même chemin, il aurait encore à faire un choix arbitraire). Sans règle supplémentaire (non écrite dans la doc), il n'est donc pas possible de représenter dans la même relation multipolygone OSM et sans ambiguité d'interprétation, plusieurs polygones qui ont des sommets communs, parce que les multipolygones OSM ne savent pas représenter actuellement la séparation entre les sous-ensembles de ways décrivant les polygones fermés à générer. La seule séparation virtuelle (dont osm2gis ne tient pas compte en fait car ils sont très souvent incohérents) c'est celle des rôles inner/outer, et ça ne suffit pas non plus : Il faut plus de rôles et ne plus tenir compte non plus de leur qualité inner ou outer qui est souvent mal indiquée (et qu'osm2gis recalcule lui-même après avoir généré les polygones GIS et seulement quand ils sont valides c'est-à-dire sans aucun point traversé plus d'une fois par la ligne de contour générée. Des rôles *qualifiés* et distincts (de façon symbolique) seraient donc nécessaires pour séparer explicitement les sous-ensembles de ways. Ma règle supplémentaire, basée sur des rôles explicites, est simple et ne remet pas en cause 99% des données de la base (je suis peut-être un peu large dans cette statistique estimée à vue de nez, qui pourrait être fausse dans le cas des multipolygones du bâti, et des zones landuse=*, ou si des cas comme ceux trouvés en Espagne sont plus fréquents qu'on croit dans d'autres pays) : (1) des rôles explicites ne sont nécessaires QUE s'il y a des sommets communs (faisant partie de plus de 2 ways dans la même relation) et dans ce cas ce même rôle doit être indiqué pour TOUS les ways d'un même polygone à distinguer dans la même relation. (2) par soucis de cohérence et de vérification (en cas de polygones brisés par les relations par des modifications sur des données partiellement téléchargées), on ne tient plus compte des rôles 'inner, outer, enclave, exclave, et anonymes, qui font parie par défaut du même jeu de données, mais il serait tout de même bon que ces rôles soient nommés inner:* et outer:* (uniquement s'il y a des sommets communs), tout en laissant inner et outer pour les jeux de ways formant les polygones sans sommet commun (pour ceux-là osm2gis sait correctement vérifier leur cohérence). En attendant que ce soit développé, il n'y a que la solution consistant à séparer artificiellement les noeuds communs avec un tout petit écart (10 centimètres, soit moins qu'un demi-pixel dans la résolution la plus fine de tous les moteurs de rendus actuels zoomé au maximum, mais suffisant pour différencier deux coodonnées flottantes stockées sur 32 bits, ou encore une centaine de pixels au zoom maximum de JOSM quand il affiche la barre
Re: [OSM-talk-fr] Problème insoluble de géométrie.
Le 5 mai 2012 14:04, Christian Quest cqu...@openstreetmap.fr a écrit : Pour moi (et visiblement pour d'autres) il n'y a pas de limitation côté OSM mais un bug dans osm2gis qui ne gère pas correctement les cas particuliers que tu as très justement signalé. Il n'y a pas de limitation dans OSM à condition de changer les règles. Les règles énoncées dans le wiki sont insuffisantes, je ne maintiens et je l'ai prouvé. Tant pis si tu ne comprends pas, demande à un géomètre mathématicien et qui comprend les notions de topologie des ensembles. Je maintiens que ton fichier démo2 reste ambigu selon les règles mêmes énoncées dans le wiki et qu'il n'y a PAS de bogue d'osm2gis selon les règles énoncées dans le wiki qui interdit d'interpréter l'ordre des membres mais ne propose pas d'autre mécanisme (je propose les rôles comme mécanisme de distinction) ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Problème insoluble de géométrie.
Le 5 mai 2012 14:12, Philippe Verdy verd...@wanadoo.fr a écrit : Il n'y a pas de limitation dans OSM à condition de changer les règles. Les règles énoncées dans le wiki sont insuffisantes, je ne maintiens et je l'ai prouvé. Tant pis si tu ne comprends pas, demande à un géomètre mathématicien et qui comprend les notions de topologie des ensembles. Merci, ça fait toujours plaisir de lire ce genre de choses. L'incompréhension ne vient-elle pas surtout de ton incapacité à exposer clairement et de façon synthétique (une dizaine de lignes) un problème ? J'ai regardé la relation que tu as cité au tout début. Ce que je constate, c'est que l'éditeur de relation de JOSM arrive à trier correctement les membres du multipolygone pour en extraire des outer et inner valides. Pourquoi osm2gis n'y arrive pas alors qu'il a les mêmes infos ? (réponse synthétique souhaitée, sinon comme d'autres je laisserai tomber ce sujet bien qu'il soit intéressant) -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Problème insoluble de géométrie.
Le 05/05/2012 14:12, Philippe Verdy a écrit : Le 5 mai 2012 14:04, Christian Questcqu...@openstreetmap.fr a écrit : Pour moi (et visiblement pour d'autres) il n'y a pas de limitation côté OSM mais un bug dans osm2gis qui ne gère pas correctement les cas particuliers que tu as très justement signalé. Je maintiens que ton fichier démo2 reste ambigu Ambigu mais valide. OSM c'est un peu duck typing, comme python : ça peut faire un multipolygone, donc c'est un multipolygone. selon les règles mêmes énoncées dans le wiki et qu'il n'y a PAS de bogue d'osm2gis selon les règles énoncées dans le wiki qui interdit d'interpréter l'ordre des membres mais ne propose pas d'autre mécanisme (je propose les rôles comme mécanisme de distinction) ! En fait il manque une heuristique à osm2* pour trouver des modèles valides dans leurs représentations à partir de représentations valides dans OSM. Et c'est sur qu'ajouter cette heuristique plomberait le calcul. Avec une API 0.7 et un type area, l’ambiguïté serait levée. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Problème insoluble de géométrie.
Le 5 mai 2012 14:36, Christian Quest cqu...@openstreetmap.fr a écrit : Le 5 mai 2012 14:12, Philippe Verdy verd...@wanadoo.fr a écrit : Il n'y a pas de limitation dans OSM à condition de changer les règles. Les règles énoncées dans le wiki sont insuffisantes, je ne maintiens et je l'ai prouvé. Tant pis si tu ne comprends pas, demande à un géomètre mathématicien et qui comprend les notions de topologie des ensembles. Merci, ça fait toujours plaisir de lire ce genre de choses. L'incompréhension ne vient-elle pas surtout de ton incapacité à exposer clairement et de façon synthétique (une dizaine de lignes) un problème ? J'ai regardé la relation que tu as cité au tout début. Ce que je constate, c'est que l'éditeur de relation de JOSM arrive à trier correctement les membres du multipolygone pour en extraire des outer et inner valides. Pourquoi osm2gis n'y arrive pas alors qu'il a les mêmes infos ? (réponse synthétique souhaitée, sinon comme d'autres je laisserai tomber ce sujet bien qu'il soit intéressant) JOSM y parvient dans certains cas, pas toujours. Le tri obtenu dépend de l'ordre dans lequel il considère les paires de ways possibles, lequel semble dépendre de la valeur des id (qui ne devrzit pas être significative) et donc de l'ordre de création des ways dans le jeu de données. Le tri obtenu est non stable ; il suffirait de fusionner un des ways avec un autre way décriant une autre relation, et le tri sera changé et deviendra incorrect. JOSM non plus ne sait pas trier correctement, son tri est totalement arbitraire. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Problème insoluble de géométrie.
Le 5 mai 2012 14:41, Philippe Verdy verd...@wanadoo.fr a écrit : JOSM y parvient dans certains cas, pas toujours. Le tri obtenu dépend de l'ordre dans lequel il considère les paires de ways possibles, lequel semble dépendre de la valeur des id (qui ne devrzit pas être significative) et donc de l'ordre de création des ways dans le jeu de données. Le tri obtenu est non stable ; il suffirait de fusionner un des ways avec un autre way décriant une autre relation, et le tri sera changé et deviendra incorrect. JOSM non plus ne sait pas trier correctement, son tri est totalement arbitraire. Merci pour ta réponse concise et claire, mon deuxième neurone a réussit à se connecter et je commence à saisir le problème. As-tu un exemple de multipolygone existant où le tri de JOSM se plante ? Ca permettrai de mettre le doigt précisément sur le problème avec un cas concret. Sur l'exemple que tu indiquais où 18 géométries étaient possibles dont 9 valides... ces 9 valides sont-elles équivalentes ? Si oui, ne suffit-il pas d'en choisir une parmi les 9 ? -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Problème insoluble de géométrie.
Le 5 mai 2012 14:38, Vincent Pottier vpott...@gmail.com a écrit : Le 05/05/2012 14:12, Philippe Verdy a écrit : Le 5 mai 2012 14:04, Christian Questcqu...@openstreetmap.fr a écrit : Pour moi (et visiblement pour d'autres) il n'y a pas de limitation côté OSM mais un bug dans osm2gis qui ne gère pas correctement les cas particuliers que tu as très justement signalé. Je maintiens que ton fichier démo2 reste ambigu Ambigu mais valide. Si c'est ambigu et cela décrit des géométries différentes cela ne peut pas être valide. On a besoin d'une règle claire pour lever l'ambiguïté et donc obtenir de façon stable des géométries valides. selon les règles mêmes énoncées dans le wiki et qu'il n'y a PAS de bogue d'osm2gis selon les règles énoncées dans le wiki qui interdit d'interpréter l'ordre des membres mais ne propose pas d'autre mécanisme (je propose les rôles comme mécanisme de distinction) ! En fait il manque une heuristique à osm2* pour trouver des modèles valides dans leurs représentations à partir de représentations valides dans OSM. Et c'est sur qu'ajouter cette heuristique plomberait le calcul. Non, surtout pas une heuristique ! toute heuristique n'est qu'une approximation destinée à résoudre des cas courants, mais génère des résultats faux. Ce qu'il faut c'est une règle impérative permettant de ne jamais avoir à choisir arbitrairement parmi les ways candidats possibles à ajouter pour former le polygone en cours : en arrivant à n'importe quel noeud par un way, s'il reste plus d'un way non encore parcouru par où aller ensuite, il doit être possible de le déterminer de façon unique par cette règle : - l'égalité des rôles assignés entre le way d'arrivée à ce nœud et le way de départ pour continuer le chemin fournit une solution claire qu'on peut rendre unique justement en différenciant les rôles - (il n'est pas nécessaire de contrôler les rôles s'il n'y a qu'un seul way suivant possible et non encore parcouru) - il ne doit pas être permis de trouver plusieurs ways possibles pour sortir de ce noeud et ayant tous les mêmes rôles. - cette méthode a l'avantage de ne pas dépendre de l'ordre des membres dans la relation puisque cet ordre n'est PAS significatif, ni non plus de la direction des ways (qui n'est pas significative non plus) - il reste possible de trouver les cas d'intersections incorrectes créées par des géométries mal taguées où on aurait fusionné par erreur des noeuds (y comrpis en traçant point par point un chemin à la souris ou en cliquant sur le point d'intersection de deux segments pour ajouter un noeud partagé pour lequel on devra qualifier les rôles de parcours avant et après de nouveau noeud) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Problème insoluble de géométrie.
Le 5 mai 2012 14:52, Christian Quest cqu...@openstreetmap.fr a écrit : Sur l'exemple que tu indiquais où 18 géométries étaient possibles dont 9 valides... ces 9 valides sont-elles équivalentes ? Si oui, ne suffit-il pas d'en choisir une parmi les 9 ? Non impossible d'en déterminer une : elles sont toutes valides au sens des polygones GIS générés où aucun noeud généré dans les polygones séparés n'est parcouru plus d'une fois. Et pourtant elles sont différentes au sens des surfaces délimitées (on ne sait plus quel polygone est interne ou externe, toutes les solutions sont possibles) ce qui fait qu'on ne sait plus tester si un point quelconque au milieu de tout ça fait partie ou non de la surface délimitée. On ne peut pas résoudre le problème par un algorithme de parcours de nœud en nœud en suivant les chemins pas à pas : cette méthode explose de façon combinatoire, même pour ne serait-ce que déterminer la première géométrie valide possible. La résolution vers les polygones les plus petits (méthode de la scanline, utilisée par les algos de remplissages de surfaces polygonales pour un rendu en bitmap) est celle qui produira des dispositions de surfaces en damiers, et ce n'est pas toujours la bonne, et ne permet plus de détecter les intersections inattendues produites par les modifications dans JOSM et la création de noeuds d'intersections d'un clic souris. Elle a une complexité en O(n.log n) où n est le nombre de segments, mais elle ne marche bien qu'avec des segments de droite (après les avoir tous réorientés vers le bas et en éliminant les segments horizontaux), mais elle ne marche pas avec des ways multisegments qu'il faut d'abord éclater en liste de segments individuels (ce qui éclate les ways OSM). Il reste donc à utiliser une méthode de résolution simple basée sur les rôles des ways: la méthode des parcours de pas en pas fonctionne alors en temps quasi linéaire (en fonction du nombre de ways dans la relation) et sans même avoir à les éclater au préalable en liste de segments réorientés dans une direction verticale fixe. Elle sépare simplement les sous-ensembles de ways en groupes, puis traite chaque groupe séparément. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Problème insoluble de géométrie.
Le samedi 5 mai 2012 14:12:22, Philippe Verdy a écrit : Je maintiens que ton fichier démo2 reste ambigu selon les règles mêmes énoncées dans le wiki Non, il ne l'est pas. -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Problème insoluble de géométrie.
Le 5 mai 2012 15:24, sly (sylvain letuffe) li...@letuffe.org a écrit : Le samedi 5 mai 2012 14:12:22, Philippe Verdy a écrit : Je maintiens que ton fichier démo2 reste ambigu selon les règles mêmes énoncées dans le wiki Non, il ne l'est pas. Regarde mieux ! Tiens compte du fait que l'ordre de tri des membres n'est pas significatif, pas plus que l'orientation des ways : tu obtiens 3 géométries possibles dans ton fichier (en ignorant l'orientation des anneaux obtenus ainsi que le noeud de départ de chacun d'eux), même si dans ce cas simple 1 seule correspond à une géométrie GIS valide. La difficulté c'est l'algo pour déterminer cette géométrie valide (on a un arbre de recherche combinatoire). Si tu fais le tri dans JOSM, selon l'ordre dans lequel tu as dessiné ou scindé les ways, tu obtiens soit deux carrés (ce à quoi tu t'attends), soit une figure en 8 sans croisement (on rebondit sur le point central en tournant à 90 degrés), soit une figure en 8 croisée (en continuant en ligne droite) dont la surface à droite du tracé parcouru dans la même direction sera alternativement à l'intérieur puis à l'extérieur du polygone (façon ruban de Moebius)... Le tri de JOSM est donc instable et impossible à prédire s'il dépend de l'ordre de création des ways ou de leur id dans la base (ces ids peuvent changer car les ways pourraient être scindés ou fusionnés avec d'autres ways superposés pendant des modifications successives et changer d'id : le tri de JOSM change alors sans pour autant que les contours aient changé). osm2gis aura les mêmes choix mais cela dépend en plus de la stabilité de son tri interne et de l'ordre dans lequel il indexe les segments créés par l'éclatement des ways, ordre des segments qui dépend de l'orientation des ways (alors que cela ne devrait pas influer). cela dépend aussi de son algo de tri de base (est-ce un QuickSort ? je n'ai pas regardé) et des clés de tri qu'il utilise et comment il indexe les éléments géométriquement égaux mais par ailleurs distincts par leur position relative dans la liste initiale à trier. Si l'algo de base n'est pas stable pour les valeurs égales, le tri obtenu dependra alors du nombre total de segments (qui peut varier simplement parce qu'on a coupé un segment en deux parties sans changer la forme géométrique décrite). Dans des cas plus complexes comportant plus d'1 noeud commun — ou plus rarement s'il y a 6, ou 8 chemins terminés sur ce même noeud, cas aussi possible et que j'ai vus dans OSM ! — on obtient plusieurs géométries valides, et cela explose de façon combinatoire et de façon encore plus rapide, en plus d'obtenir un algo de résolution particulièrement lent puisque le problème à résoudre pour énumérer les géométries possibles, dont chacune reste à valider selon les contraintes des polygones GIS, est topologiquement équivalent à celui du voyageur de commerce : avec un grand nombre de ways (par exemple une centaine, ce qui arrivé dans le cas justement de Xativa en Espagne), c'est prohibitif ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Problème insoluble de géométrie.
Non, il ne l'est pas. Regarde mieux ! re-lit la page du wiki qui parle des relations multipolygone, elle dit : the multipolygon relation can be used to build multipolygons in compliance with the OGC Simple Feature standard Tiens compte du fait que l'ordre de tri des membres n'est pas significatif, pas plus que l'orientation des ways Je ne fais que ça. , pas plus que l'orientation des ways : tu obtiens 3 géométries possibles dans ton fichier (en ignorant l'orientation des anneaux obtenus ainsi que le noeud de départ de chacun d'eux), même si dans ce cas simple 1 seule correspond à une géométrie GIS valide. Tout est là, tu viens de le dire, on obtient 1 seule géométrie qui peut être valide au sens OGC, et comme c'est un pré-requis de la définition de la relation type=multipolygon, alors il n'y a pas d'ambiguité dans demo2.osm puisque la commune A n'a qu'une seule représentation OGC possible. CQFD La difficulté c'est l'algo pour déterminer cette géométrie valide (on a un arbre de recherche combinatoire). Je ne le nie pas, mais la n'est pas la question (en tout cas pas pour l'instant) puisque je m'attache à expliquer que ta remarque initiale : On a le cas suivant apparemment non prévu par OSM est manifestement fausse. Maintenant, oui, on peut porter le débat sur l'éventuel difficulté de concevoir l'algorithme, de son optimisation, mais cette liste, je le répète, n'est pas le bon endroit pour parler développement. tu obtiens soit deux carrés (ce à quoi tu t'attends), soit une figure en 8 sans croisement Histoire que je sois sûr de bien me faire comprendre : non, on ne peut pas interpréter mon exemple ni comme un 8 ni comme E3 parce que cela n'est pas valide au sens OGC, donc invalide comme relation multipolygon Pour tes remarques suivantes concernant la complexité de l'ago, j'y répond sur dev-fr uniquement -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Ajout radar légal ou pas ?
Bonjour Et surtout cela n'interdit pas ni d'en produire, ni d'en acheter et surtout pas de payer les taxes qui y vont avec. Salutations Le 04/05/2012 10:27, Pieren a écrit : La meilleure analogie qu'on puisse faire, finalement, c'est de dire que c'est comme l'alcool. C'est interdit de boire et conduire mais ça n'interdit pas la vente d'alcool et le fait de pouvoir se pinter chez-soi ; ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
