Re: [OSM-talk] Incorrect speed limit anonymous notes - who is behind that?
On 2014-08-16 01:48, Andreas Vilén wrote: This continues to be really annoying, and the obvious spam seems to cluster at a few locations, where 10-20 notes can be created with the same information. The maker of this app must be made clear that notes can't work like this, and users would at least be required to give some contact information. Most of the notes that come from this app are useless and will probably stay in the database forever. And the notes may be anonymous, but IMHO it is prudent to put in the message or the metadata which app reported it. That way you don't have to go on a wild goose chase to see where it is coming from. Maarten ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Incorrect speed limit anonymous notes - who is behind that?
2014-08-16 8:28 GMT+02:00 Maarten Deen md...@xs4all.nl: On 2014-08-16 01:48, Andreas Vilén wrote: This continues to be really annoying, and the obvious spam seems to cluster at a few locations, where 10-20 notes can be created with the same information. The maker of this app must be made clear that notes can't work like this, and users would at least be required to give some contact information. Most of the notes that come from this app are useless and will probably stay in the database forever. And the notes may be anonymous, but IMHO it is prudent to put in the message or the metadata which app reported it. That way you don't have to go on a wild goose chase to see where it is coming from. Maarten ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk With low quality and no information about source this should be treated as a spam. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM in Saudi Arabia?
On Fri, Aug 15, 2014 at 11:53:02AM -0700, Clifford Snow wrote: You might want to consult http://resultmaps.neis-one.org/oooc by Pascal Neis to identify mappers. It's funny that only one single person has located themselves on the map! Is there anyway to show the history in reverse? The history interface on OSM is pretty much occupied by too many recent changes, many of which aren't really on the selected part of the map. Regards, pgpjwiAEYpvD2.pgp Description: PGP signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] extracts for historical views at a specific point in time
thanks for the replies everyone, that all pretty much covered what i needed to know. richard -- rwe...@averillpark.net Averill Park Networking - GIS IT Consulting OpenStreetMap - PostgreSQL - Linux Java - Web Applications - Search signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Incorrect speed limit anonymous notes - who is behind that?
Like this one: http://www.openstreetmap.org/note/220298 It says map error: general map error: error... On Sat, Aug 16, 2014 at 8:34 AM, Mateusz Konieczny matkoni...@gmail.com wrote: 2014-08-16 8:28 GMT+02:00 Maarten Deen md...@xs4all.nl: On 2014-08-16 01:48, Andreas Vilén wrote: This continues to be really annoying, and the obvious spam seems to cluster at a few locations, where 10-20 notes can be created with the same information. The maker of this app must be made clear that notes can't work like this, and users would at least be required to give some contact information. Most of the notes that come from this app are useless and will probably stay in the database forever. And the notes may be anonymous, but IMHO it is prudent to put in the message or the metadata which app reported it. That way you don't have to go on a wild goose chase to see where it is coming from. Maarten ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk With low quality and no information about source this should be treated as a spam. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] OSM and Captcha
Hi, Maybe this topic has been already raised, sorry if so. When editing the OSM wiki and adding links, there is a -are-you-really-a-human-being check (what makes completely sense) through Captcha. My concern is that currently Captcha requests to put a number from a picture that is actually a photo from a great existing address. And the result, if I am not wrong, just feeds Google address database. Can we not switch to another checking system? There are others, actually less cumbersome, that do not feed a totally copyrighted database? Sincerely, Severin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Incorrect speed limit anonymous notes - who is behind that?
I noticed that note was actually made by a logged in user so I tried asking where the notes were coming from and got the answer Wrong speed limit on a speed camera together with a sent from my iphone with http://midpoint.se/ and nothing else... I have no idea what midpoint is but it feels like I was talking to a software... /Andreas On Sat, Aug 16, 2014 at 3:37 PM, Andreas Vilén andreas.vi...@gmail.com wrote: Like this one: http://www.openstreetmap.org/note/220298 It says map error: general map error: error... On Sat, Aug 16, 2014 at 8:34 AM, Mateusz Konieczny matkoni...@gmail.com wrote: 2014-08-16 8:28 GMT+02:00 Maarten Deen md...@xs4all.nl: On 2014-08-16 01:48, Andreas Vilén wrote: This continues to be really annoying, and the obvious spam seems to cluster at a few locations, where 10-20 notes can be created with the same information. The maker of this app must be made clear that notes can't work like this, and users would at least be required to give some contact information. Most of the notes that come from this app are useless and will probably stay in the database forever. And the notes may be anonymous, but IMHO it is prudent to put in the message or the metadata which app reported it. That way you don't have to go on a wild goose chase to see where it is coming from. Maarten ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk With low quality and no information about source this should be treated as a spam. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM and Captcha
The last discussions about this that I can remember (and find with a quick search) were OSM-talk threads: - Hate captchas starting March 14, https://lists.openstreetmap.org/pipermail/talk/2014-March/069320.html and the follow-up to it - ReMAPTCHA Demo BETA 0.2 online! (Was: Hate captchas) starting March 28, https://lists.openstreetmap.org/pipermail/talk/2014-March/069526.html Cheers, -Jaakko -- jaa...@helleranta.com * Skype: jhelleranta * Mobile: +505-8845-3391 (Nicaragua) * Voice(mail) / SMS / What's app: +1-202-730-9778 * http://about.me/jaakkoh On Sat, Aug 16, 2014 at 11:51 AM, Severin Menard severin.men...@gmail.com wrote: Hi, Maybe this topic has been already raised, sorry if so. When editing the OSM wiki and adding links, there is a -are-you-really-a-human-being check (what makes completely sense) through Captcha. My concern is that currently Captcha requests to put a number from a picture that is actually a photo from a great existing address. And the result, if I am not wrong, just feeds Google address database. Can we not switch to another checking system? There are others, actually less cumbersome, that do not feed a totally copyrighted database? Sincerely, Severin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM and Captcha
Hi, Severin Menard schrieb: Maybe this topic has been already raised, sorry if so. it has, but still a good thing you raised this again as I'd also like something to change here. And the result, if I am not wrong, just feeds Google address database. Yes. And that's why Stefan Keller (or one of his students I think) created ReMAPTCHA to have a captcha system helping OSM. The dicussion was on this list in March 14 (can be found in the archives: https://lists.openstreetmap.org/pipermail/talk/2014-March/069526.html) Peda -- ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM and Captcha
Hi Severin, hello all Yes, ReMAPTCHA is still running as prototypes in two versions here: http://remaptcha.herokuapp.com/ and here: http://remaptcha2.herokuapp.com/ On one hand I'm not sure how high its acceptance is and on the other hand it's challenging to implement a reliable system having limited time and resources. Yours, Stefan 2014-08-16 20:05 GMT+02:00 Peter Barth osm-t...@won2.de: Hi, Severin Menard schrieb: Maybe this topic has been already raised, sorry if so. it has, but still a good thing you raised this again as I'd also like something to change here. And the result, if I am not wrong, just feeds Google address database. Yes. And that's why Stefan Keller (or one of his students I think) created ReMAPTCHA to have a captcha system helping OSM. The dicussion was on this list in March 14 (can be found in the archives: https://lists.openstreetmap.org/pipermail/talk/2014-March/069526.html) Peda -- ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM and Captcha
...perhaps we're getting a step further at State of the Map nov. 2014 in Buenos Aires? --Stefan 2014-08-16 20:30 GMT+02:00 Stefan Keller sfkel...@gmail.com: Hi Severin, hello all Yes, ReMAPTCHA is still running as prototypes in two versions here: http://remaptcha.herokuapp.com/ and here: http://remaptcha2.herokuapp.com/ On one hand I'm not sure how high its acceptance is and on the other hand it's challenging to implement a reliable system having limited time and resources. Yours, Stefan 2014-08-16 20:05 GMT+02:00 Peter Barth osm-t...@won2.de: Hi, Severin Menard schrieb: Maybe this topic has been already raised, sorry if so. it has, but still a good thing you raised this again as I'd also like something to change here. And the result, if I am not wrong, just feeds Google address database. Yes. And that's why Stefan Keller (or one of his students I think) created ReMAPTCHA to have a captcha system helping OSM. The dicussion was on this list in March 14 (can be found in the archives: https://lists.openstreetmap.org/pipermail/talk/2014-March/069526.html) Peda -- ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Incorrect speed limit anonymous notes - who is behind that?
On 08/16/2014 01:34 AM, Mateusz Konieczny wrote: 2014-08-16 8:28 GMT+02:00 Maarten Deen md...@xs4all.nl mailto:md...@xs4all.nl: On 2014-08-16 01:48, Andreas Vilén wrote: This continues to be really annoying, and the obvious spam seems to cluster at a few locations, where 10-20 notes can be created with the same information. The maker of this app must be made clear that notes can't work like this, and users would at least be required to give some contact information. Most of the notes that come from this app are useless and will probably stay in the database forever. And the notes may be anonymous, but IMHO it is prudent to put in the message or the metadata which app reported it. That way you don't have to go on a wild goose chase to see where it is coming from. Maarten If the useless notes are concentrated at a few points, it may mean that someone who lives there or passes through on a regular basis is alpha-testing or beta-testing an app. I agree that both a user contact and the identify of the app are needed. -- John F. Eldredge -- j...@jfeldredge.com Darkness cannot drive out darkness; only light can do that. Hate cannot drive out hate; only love can do that. Dr. Martin Luther King, Jr. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Incorrect speed limit anonymous notes - who is behind that?
Uhm, no, that's not it... Look at http://www.openstreetmap.org/#map=16/57.9221/12.5033layers=N for example. Also, at least 40-50 notes have been created on this exact location: http://www.openstreetmap.org/note/215471 That leads me to believe that that position is the zero position of the app used to create these notes. It would be really great if the person who managed to figure out what app creates these notes could speak out. The guy I contacted about this also doesn't seem to want to answer questions... Why is everything so cryptic? /Andreas On Sat, Aug 16, 2014 at 8:36 PM, John F. Eldredge j...@jfeldredge.com wrote: On 08/16/2014 01:34 AM, Mateusz Konieczny wrote: 2014-08-16 8:28 GMT+02:00 Maarten Deen md...@xs4all.nl: On 2014-08-16 01:48, Andreas Vilén wrote: This continues to be really annoying, and the obvious spam seems to cluster at a few locations, where 10-20 notes can be created with the same information. The maker of this app must be made clear that notes can't work like this, and users would at least be required to give some contact information. Most of the notes that come from this app are useless and will probably stay in the database forever. And the notes may be anonymous, but IMHO it is prudent to put in the message or the metadata which app reported it. That way you don't have to go on a wild goose chase to see where it is coming from. Maarten If the useless notes are concentrated at a few points, it may mean that someone who lives there or passes through on a regular basis is alpha-testing or beta-testing an app. I agree that both a user contact and the identify of the app are needed. -- John F. Eldredge -- j...@jfeldredge.com Darkness cannot drive out darkness; only light can do that. Hate cannot drive out hate; only love can do that. Dr. Martin Luther King, Jr. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Incorrect speed limit anonymous notes - who is behind that?
Am 16.08.2014 08:28, schrieb Maarten Deen: On 2014-08-16 01:48, Andreas Vilén wrote: This continues to be really annoying, and the obvious spam seems to cluster at a few locations, where 10-20 notes can be created with the same information. The maker of this app must be made clear that notes can't work like this, and users would at least be required to give some contact information. Most of the notes that come from this app are useless and will probably stay in the database forever. And the notes may be anonymous, but IMHO it is prudent to put in the message or the metadata which app reported it. That way you don't have to go on a wild goose chase to see where it is coming from. Think any app that creates notes should have a proper user with some information on the user's page and like wise an email address to contact. This way users could still create nodes anonymously but we would reach the person with power. cu colliar signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk-nl] Word je warm van eigennamen en toponiemen?
Hoi allemaal, Word je warm van eigennamen en toponiemen? Word partner voor categorisatie van onze open collectie t.b.v. spellingcontrole en autocompletion. We hebben tienduizenden eigennamen uit crowdsourcing die gecontroleerd zijn t.o.v. open bronnen van de overheid zoals BAG, Kadaster en NTU maar ook van Wikipedia, ISO en OSM. Sinds kort hebben we nieuwe categorisatie die gebaseerd is op ISOcat waarmee internationale gestandaardiseerde en open uitwisselbaarheid mogelijk is. Naast de huidige partners zoeken we nieuwe partners die gespecialiseerd zijn in eigennamen en toponiemen om de kwantiteit en kwaliteit van elkaars collecties te kunnen vergroten om spelfouten te verbeteren en eindgebruikers te helpen d.m.v. autocompletion. Neem contact op met OpenTaal voor meer informatie over ons partnerprogramma. Groeten, Pander -- Stichting OpenTaal Taal is van ons allemaal http://www.opentaal.org ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [Talk-br] OpenStreetMap Brasil - Capítulo Brasileiro do OSM
Vitor George escreveu: John, acho que a página tem que ser um passo preliminar ao wiki, porque lá é muito bagunçado para um usuário que quer sacar rápido do que se trata o projeto. É claro que wiki é a principal referência do projeto, e acho que a página tem que ter um monte de links pra lá. Dei uma olhada no que você adicionou e realmente foi um passo-a-passo bem rápido e prático. Acho que assim fica legal sim.. Vitor George escreveu: Sobre a página do Chile, ela já joga um mapa para usuário, sem explicar bem o que é o OSM. Isto é ruim porque cria uma confusão de que o OSM é um Google Maps piorado, quando deveria ser explicado primeiramente que é um banco de dados geoespaciais abertos. Então, o problema é que no site do OpenStreetMap Chile [1] tem que clicar em algo pra ver os menus, mas fora isso achei muito bom. [1]: http://openstreetmap.cl/ Em 15 de agosto de 2014 19:59, Vitor George vitor.geo...@gmail.com escreveu: Olá, Valeu pelos comentários, pessoal. Mudei o site para jekyll e ampliei a página Aprenda, vejam lá: http://osmbrasil.github.io/aprenda John, acho que a página tem que ser um passo preliminar ao wiki, porque lá é muito bagunçado para um usuário que quer sacar rápido do que se trata o projeto. É claro que wiki é a principal referência do projeto, e acho que a página tem que ter um monte de links pra lá. Sobre a página do Chile, ela já joga um mapa para usuário, sem explicar bem o que é o OSM. Isto é ruim porque cria uma confusão de que o OSM é um Google Maps piorado, quando deveria ser explicado primeiramente que é um banco de dados geoespaciais abertos. Sobre o blog, é só questão de preparar o conteúdo. Dá para colocar dentro do Jekyll ou criar um tumblr. O primeiro post deve ser sobre o OSM Brasil. Obrigado pela referência dos logos. Aqui tem o svg http://wiki.openstreetmap.org/wiki/File:Public-images-osm_logo.svg se alguém quiser se aventurar em colocar as cores do país. Abraços, Vitor 2014-08-07 17:07 GMT-03:00 Alexandre Magno Brito de Medeiros alexandre@gmail.com: Em 7 de agosto de 2014 14:49, John Packer john.pack...@gmail.com escreveu: Me dá a impressão que alguns dos itens que você citou (Aprenda a mapear, Baixe dados) pertencem ao wiki do OSM, e não à um site específico para o país. O site poderia ter algo bem básico, tal como um mini passo-a-passo de panfleto. * Um blog Um quase-Planeta seria melhor. Só que com seleção. * Link para o wiki, lista de email local e possivelmente do fórum. Os quadros do mini passo-a-passo poderiam fazer essas ligações. Poderia até ser quadrinhos/tirinhas... [...] e explica o que é uma *Mapping Party*. Idem. Se tiver algum designer interessado, poderíamos colocar um logo do OSM adaptado para o Brasil (veja [4] para exemplos). Se tivesse como fazer um canarinho olhar o mapa pela lupa... Eu não sou designer. É uma ideia. [4]: http://wiki.openstreetmap.org/wiki/Logo#National_Logos ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] OpenStreetMap Brasil - Capítulo Brasileiro do OSM
Apesar de estranho na lógica, acho que o tom forte foi proposital. Quanto ao 02, se a carta sugestionasse o mar, a distorção tornar-se-ia mais dispensável. Por ora, aumentei a transparência da lente e tirei os algarismos binários. Diff https://github.com/OSMBrasil/graphics/commit/eaaab227b864743497bbcb8c5fe9f80f1e4f1e80#diff-f63c6332db3a989d5ba85c8b551cb199 . Em 16 de agosto de 2014 10:35, Wille wi...@wille.blog.br escreveu: O problema do mapa é que a distorção provocada pela lente da lupa não está refletida no mapa. Quanto ao logo feito por Stephane, acho que seria melhor baixar mais a camada do bandeira para que não se sobreponha a elementos presentes dentro da lupa e para que as cores da bandeira não fiquem em tons mais fortes do que as do logo do OSM. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] OpenStreetMap Brasil - Capítulo Brasileiro do OSM
Obrigado pelos comentários pessoal. A imagem abriu para todos porque o que eu enviei foi um PNG. A minha ideia era mesmo destacar a bandeira. Se deixarmos o mapa e os 0101 aparecerem, acho que fica um pocado confuso, ainda mais quando o logo for dimensionado para um tamanho menor. Até tentei colocar transparência na bandeira, mas achei que não ficou muito bom. Mas vou fazer mais uns testes e enviar outras opções. Também é preciso resolver este problema do SVG não abrir no browser. Eu vi que foi criado um repositório no Github. Mas o wiki também tem uma página pra isso: http://wiki.openstreetmap.org/wiki/Logos#National_Logos Os logos que estão lá podem também ajudar a dar ideias. Reparem no logo do Senegal, que também fui eu que fiz (qualquer semelhança é mera coincidência :p) Abraço ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] OpenStreetMap Brasil - Capítulo Brasileiro do OSM
Eu estou cansado e tenho pouca prática. Por isso não vou continuar. Pelo menos não hoje. Para a abordagem do logo 02 ficar plausível, eu ia usar o mar azul do logo da Itália http://wiki.openstreetmap.org/wiki/File:OSMItaly.svg e colocar o mapa do Brasil bandeira como destaque num mapa mundi estilizado com a textura de mapa verde que os demais logos tem utilizado. Caso de se passe quatro dias e eu não volte a editar, podem apagar os dois arquivos 02 do repositório, se quiserem. Em 16 de agosto de 2014 10:56, Alexandre Magno Brito de Medeiros alexandre@gmail.com escreveu: Apesar de estranho na lógica, acho que o tom forte foi proposital. Quanto ao 02, se a carta sugestionasse o mar, a distorção tornar-se-ia mais dispensável. Por ora, aumentei a transparência da lente e tirei os algarismos binários. Diff https://github.com/OSMBrasil/graphics/commit/eaaab227b864743497bbcb8c5fe9f80f1e4f1e80#diff-f63c6332db3a989d5ba85c8b551cb199 . Em 16 de agosto de 2014 10:35, Wille wi...@wille.blog.br escreveu: O problema do mapa é que a distorção provocada pela lente da lupa não está refletida no mapa. Quanto ao logo feito por Stephane, acho que seria melhor baixar mais a camada do bandeira para que não se sobreponha a elementos presentes dentro da lupa e para que as cores da bandeira não fiquem em tons mais fortes do que as do logo do OSM. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] OpenStreetMap Brasil - Capítulo Brasileiro do OSM
Também voto no logo do Stephane. Pensando bem, a lógica lupa-mapa não precisa ser seguida à risca. É mais importante ficar bem clara e bonita a informação da nacionalidade. Em 16 de agosto de 2014 14:52, Thiago Marcos P. Santos tmpsan...@gmail.com escreveu: +1 para o logo do Stephane pelos motivos aqui expostos pelo Paulo Carvalho. Também, se tratando de gráficos vetoriais, a primeira proposta contém bem menos vetores, portanto é mais leve. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
[Talk-br] RES: OpenStreetMap Brasil - Capítulo Brasileiro do OSM
Voto também pela proposta do Stephane, além de manter os elementos identificadores do OSM, e tem uma clara identificação do Capítulo Brasil. A transparência na bandeira realmente acho dispensável, até porque ao redimensionar o logo poderia ficar menos visível. ___ cid:AEB89D39-0ED3-48AF-9EB7-EF84C2B4BC40 Reinaldo Neves Equação Informática (: (11) 3221-3722 *: rne...@equacao.com.br De: Alexandre Magno Brito de Medeiros [mailto:alexandre@gmail.com] Enviada em: sábado, 16 de agosto de 2014 15:16 Para: OpenStreetMap no Brasil Assunto: Re: [Talk-br] OpenStreetMap Brasil - Capítulo Brasileiro do OSM Também voto no logo do Stephane. Pensando bem, a lógica lupa-mapa não precisa ser seguida à risca. É mais importante ficar bem clara e bonita a informação da nacionalidade. Em 16 de agosto de 2014 14:52, Thiago Marcos P. Santos tmpsan...@gmail.com escreveu: +1 para o logo do Stephane pelos motivos aqui expostos pelo Paulo Carvalho. Também, se tratando de gráficos vetoriais, a primeira proposta contém bem menos vetores, portanto é mais leve. attachment: image001.jpg ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-de] Wochenaufgabe KW33/34 Adressen ohne Strasse
Hallo, für die, die es nicht schon im Forum gesehen haben, möchte ich zum Samstag morgen mal einen kurzen Zwischenstand liefern, es geht um die Wochenaufgabe: http://blog.openstreetmap.de/blog/2014/08/wochenaufgabe-strassennamen-kw-3334-11-08-24-08-2014/ Insgesamt haben sich mittlerweile knapp 100 Landkreise mit mindestens 20 Korrekturen im Zeitraum beteiligt, es wurden 30.000 Adressen korrigiert. Genaueres findet ihr in Google Calc: https://docs.google.com/spreadsheets/d/1U3QIAtebzAIK_MAQgbZ4VjQs5twRDlIvW7iU7MCz_8I/edit?usp=sharing Wenn Ihr noch einsteigen wollt, im Forum findet Ihr die Aufgabe hier: http://forum.openstreetmap.org/viewtopic.php?id=26635 Und auf Twitter (:-)) hier: https://twitter.com/search?f=realtimeq=OSMWA3334src=typd Christoph Am 11.08.2014 um 19:43 schrieb Christoph (TheFive@OSM) thefive@googlemail.com: Hi, Etwas verspätet mein Thread zur Wochenaufgabe: Ihr habt ja im Forum Thread Adressstatistik schon wacker losgelegt. Ich hatte zwischen Tür und Angel schon die Auswertung von Gehrkes Zahlen getweeted (#osmwa3334). Google Tabelle zur Chartansicht Im ersten Reiter den Filter wählen und im zweiten dann die Grafik anschauen. Filterbar ist Bundesland, Grössenordnung und Grössenordnung Änderung. Viel Spass beim Fixen. Christoph ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flüchtliglager als Großstadt ?
2014-08-09 19:09 GMT+02:00 Johannes jotpe@gmail.com: Hallo, es gibt in nördlichen Gazastreifen eine Kleinstadt Dschabaliya (Jabalia) https://www.openstreetmap.org/node/3007045042#map=13/31.5417/34.5287 und eine angrenzendes Flüchtlingslager seit 1948. Heute leben dort 11 Menschen. https://www.openstreetmap.org/node/504000582#map=12/31.5446/34.5441 Habe refugee=yes hinzgefügt. Ist aber place=city angemessen, wenn es sich administrativ nicht um eine Stadt handelt? beste Grüße Johannes „Flüchtlinge“ und „Flüchtlingslager“ sind in diesem Fall politisch motivierte Bezeichnungen, die mit der Realität gar nichts mehr zu tun haben. Nach mehr als 65 Jahre sind die Einwohner dieses Ortes wirklich keine „Flüchtlinge“ mehr, die allermeisten sind vor Ort geboren. P. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Berlin Stadtbaumkampagne
Il giorno 15/ago/2014, alle ore 17:19, Florian Schäfer flor...@schaeferban.de ha scritto: P31:wikidata=Q161364 bitte weniger kryptisch taggen, Spezies als Präfix wäre wenigstens ein menschenverständlicher Anhaltspunkt Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] estratti comunali openstreetmap
Il giorno 15 agosto 2014 19:39, Any File anysomef...@gmail.com ha scritto: Grazie per tutto questo lavoro! 2014-08-13 21:02 GMT+02:00 Fabrizio Tambussa ftambu...@gmail.com: Per gli amanti dei dettagli tecnici: [...] 3) a partire dall'estratto PBF dell'Italia estraggo i ritagli regionali in PBF, poi ne converto una copia: - in osm.zip con osmconvert --complete-ways --complex-ways .. per preservare le ways che superano il bbox - in formato SHP con osm2shape [...] Tanto per curiosità, qul è l'operazione più lunga è quella di ritagliare il file PBF oppure la conversione da PBF in altri formati? L'operazione piu' lunga e' l'estrazione dei PBF comunali a partire dal PBF regionale. Tieni conto che per ogni estratto, il processo deve leggere tutto il PBF regionale. Ottenuto l'estratto del comune, la traduzione in OSM e in SHP e' veloce. e quando usi osmconvert converti il PBF ritagliato oppure parti da quello intero ed applichiun filtro? converto sempre il PBF gia' ritagliato. Saluti Saluti AnyFile ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Un articolo con geometria OSM
Ciao, mi piacerebbe avere qualche parere a riguardo. Cerco di mettere in pratica una mia idea e tecnicamente mi sto arrangiando. L'idea è di scrivere un articolo in un blog, che visualizzi l'area oggetto dell'articolo su una mappa. Le geometrie sono cliccabili e col popup visualizzano le informazioni. Ad esempio, scrivo un articolo sull'EXPO2015 e poi si visualizza la mappa con l'inquadramento dell'area. In questa mappa ci sono gli edifici in costruzione e se clicco, mi appare il nome e qualche informazione. Queste informazioni possono essere sia prese da OSM sia da un altro articolo, magari con lo stato di avanzamento o link. Tecnicamente ho customizzato un Wordpress che genera un file GeoJSON da overpass.api e distinguo i singoli elementi dall'area di progetto. Esempio: http://www.cityplanner.it/natural_tree/expo-2015-pavilions/ http://www.cityplanner.it/natural_tree/expo-2015-pavilions/ - - Le ultime dal mio blog: Perchè una mappa degli alberi? -- View this message in context: http://gis.19327.n5.nabble.com/Un-articolo-con-geometria-OSM-tp5814659.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Shape portale regione Lombardia
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Il 16/08/2014 19:15, emmexx ha scritto: Volevo utilizzare uno shape scaricato dal portale cartografico della regione lombardia per inserire in OSM i confini di una riserva naturale. La licenza e' compatibile? http://www.cartografia.regione.lombardia.it/geoportale/ptk grazie maxx Devi controllare quanto contenuto nei metadati, ad ogni modo, se è cc-by-nc-sa 3.0, direi di no, se è IODL 2.0, ho dato una letta ma mi pare ambigua, però nno sono dotto in leggper cui lascio ad altri il parere. Comunque se mettevi questo link, ci si arrivava prima a capire la tua richiesta: http://www.cartografia.regione.lombardia.it/geoportale/ptk :) Resta inteso che dipende dal contenuto dei metadati cosa dice. - -- Simone Girardelli -BEGIN PGP SIGNATURE- Version: GnuPG v1 iF4EAREIAAYFAlPvlO8ACgkQoVS0hKoD3POBMgEAiUcgVC6pmwtNML5YqaoXFjw/ xLYhcG5xtxyWyYDIKmcA/jG6swmyM+LA+35n4kAL+m819qykmQj5+iQkxjMm9YRY =eIxi -END PGP SIGNATURE- ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Shape portale regione Lombardia
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Il 16/08/2014 19:29, girarsi_liste ha scritto: Il 16/08/2014 19:15, emmexx ha scritto: Volevo utilizzare uno shape scaricato dal portale cartografico della regione lombardia per inserire in OSM i confini di una riserva naturale. La licenza e' compatibile? http://www.cartografia.regione.lombardia.it/geoportale/ptk grazie maxx Devi controllare quanto contenuto nei metadati, ad ogni modo, se è cc-by-nc-sa 3.0, direi di no, se è IODL 2.0, ho dato una letta ma mi pare ambigua, però nno sono dotto in leggper cui lascio ad altri il parere. Comunque se mettevi questo link, ci si arrivava prima a capire la tua richiesta: http://www.cartografia.regione.lombardia.it/geoportale/ptk Gr andate in fondo sul link Note legali per l'utilizzo dei contenuti del Geoportale per vedere la licenza, chiedo scusa per la gaffe. =) - -- Simone Girardelli -BEGIN PGP SIGNATURE- Version: GnuPG v1 iF4EAREIAAYFAlPvmbsACgkQoVS0hKoD3PN/tgD+PCQrSg9XIvz02cuqX4ho6AeY HBfmo1UlK0BEJuGVieMA/2zEeRYNDjpmLctC/XTOXCw6qbKNV5eGFV27S2VNuxuC =7NzJ -END PGP SIGNATURE- ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Shape portale regione Lombardia
2014-08-16 19:49 GMT+02:00 girarsi_liste liste.gira...@gmail.com: Gr andate in fondo sul link Note legali per l'utilizzo dei contenuti del Geoportale per vedere la licenza, chiedo scusa per la gaffe. =) in realtà 6 anni fa avevo chiesto e ottenuto autorizzazione al reimpiego dei dati della regione lombardia all'interno di OSM, ma tale autorizzazione era solo per la CTR. -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Shape portale regione Lombardia
Sul sito il disclamer non porta a nulla. Facendo i furbetti si potrebbe dire che quindi è open by defaut in virtù del codice di amministrazione digitale. Su dati.lombardia.it non mi sembra che il file sia presente. La licenza predefinita della lombardia è la IODL 2.0 che, in realtà, è una CC-BY con chiari riferimenti alla normativa italiana. In linea di massima è una licenza che permette di inserire i dati in openstreetmap, ma molto dipende da come è richiesta la formula di citazione. Ad esempio: se questa deve essere esposta in maniera molto chiara, allora meglio chiedere al proprietario del dataset invece che farci un giro intorno. Per tornare alla domanda: fossi in te scriverei direttamente all'indirizzo di informazioni presente sul sito e al referente di dati.lombardia.it Ciao 2014-08-16 19:15 GMT+02:00 emmexx emm...@tiscalinet.it: Volevo utilizzare uno shape scaricato dal portale cartografico della regione lombardia per inserire in OSM i confini di una riserva naturale. La licenza e' compatibile? http://www.cartografia.regione.lombardia.it/geoportale/ptk grazie maxx ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it -- Maurizio Napo Napolitano http://de.straba.us ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-at] Straßenbahnen werden nicht gerendert
Übliches Vorgehen, anschreiben und wenn kein Besserung Revert. Bin auf deiner Seite. Date: Fri, 15 Aug 2014 21:34:57 +0200 From: simon.leg...@gmail.com To: talk-at@openstreetmap.org Subject: [Talk-at] Straßenbahnen werden nicht gerendert Hallo, derzeit gibt es ein Problem mit dem Mapnik-Style auf osm.org, sodass Straßenbahnen nicht gerendert werden, wenn sie auf der Straße gemappt sind. https://github.com/gravitystorm/openstreetmap-carto/issues/874 Der Effekt ist, dass die Straßenbahnen in Wien, Graz, Innsbruck sehr lückenhaft dargestellt werden. Linz ist wohl nicht betroffen, weil railway=tram nie (?) zusammen mit highway vorkommt. In Innsbruck wurde vor Kurzem zudem das Straßenbahnnetz umgemappt. Und zwar wurde ein neuer Schienenstrang parallel zum bestehenden Straßenzug mit Straßenbahn (also highway + railway=tram + tracks=2) hinzugefügt und das alte Objekt unverändert gelassen. Siehe beispielsweise http://www.openstreetmap.org/#map=19/47.27531/11.40521layers=D ÖPNV-Relationen wurden nicht angepasst. Es gibt noch eine Reihe weiterer Probleme: z.B. duplicate Nodes, duplicate Ways (http://www.openstreetmap.org/way/295470020). Habe den User kontaktiert und befürworte ganz eindeutig einen Revert dieser Changesets. GrüßeSimon ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Straßenbahnen werden nicht gerendert
2014-08-16 12:00 GMT+02:00 martin ringer martinrin...@hotmail.com: Übliches Vorgehen, anschreiben und wenn kein Besserung Revert. Bin auf deiner Seite. Soo, habe den ganzen Vormittag mit dem Revert verbracht. Nun ist es geschafft: https://www.openstreetmap.org/changeset/24783862 Reverted wurden die Changesets 24699280 24699057 24699126 24699170 24699202 24699271 24449709 24493985 24494057 24494153 24494170 24494246 24494295 24494439 24494493 24494696 24494734 24494742 24494786 24494868 24495121 24495365 24495374 24495410 24495426 24495449 24495508 24495535 24495594 24495631 24495730 24495735 24495812 24495873 24496217 24496282 24496365 24496454 24494868 24496504 24496700 24496727 24496756 24496771 24496811 24499601 24499666 24499681 24499717 24499763 24499799 24499811 24499833 24499874 24499918, welche mühsam zusammengesucht wurden. Keines der Changesets hat nämlich einen Kommentar. Grüße Simon ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Straßenbahnen werden nicht gerendert
Ein verwandtes Thema: weiß jemand warum die Straßenbahnlinien in Wien auf der http://www.öpnvkarte.de/ dargestellt werden, aber nicht auf dem ÖV-Layer von der OSM-Hauptseite? LG, Markus On 2014-08-16 12:31, Simon Legner wrote: 2014-08-16 12:00 GMT+02:00 martin ringer martinrin...@hotmail.com: Übliches Vorgehen, anschreiben und wenn kein Besserung Revert. Bin auf deiner Seite. Soo, habe den ganzen Vormittag mit dem Revert verbracht. Nun ist es geschafft: https://www.openstreetmap.org/changeset/24783862 Reverted wurden die Changesets 24699280 24699057 24699126 24699170 24699202 24699271 24449709 24493985 24494057 24494153 24494170 24494246 24494295 24494439 24494493 24494696 24494734 24494742 24494786 24494868 24495121 24495365 24495374 24495410 24495426 24495449 24495508 24495535 24495594 24495631 24495730 24495735 24495812 24495873 24496217 24496282 24496365 24496454 24494868 24496504 24496700 24496727 24496756 24496771 24496811 24499601 24499666 24499681 24499717 24499763 24499799 24499811 24499833 24499874 24499918, welche mühsam zusammengesucht wurden. Keines der Changesets hat nämlich einen Kommentar. Grüße Simon ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Straßenbahnen werden nicht gerendert
On Sat, 16 Aug 2014 14:43:30 +0200 Markus Straub markus.straub...@gmail.com wrote: Ein verwandtes Thema: weiß jemand warum die Straßenbahnlinien in Wien auf der http://www.öpnvkarte.de/ dargestellt werden, aber nicht auf dem ÖV-Layer von der OSM-Hauptseite? Dargestellt werden sie eh, nur anders... ohne die name tags und/oder Relationen auszuwerten... wieso genau weiß ich aber auch nicht. Das betrifft jedenfalls nicht nur Wien. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
[Talk-cat] Nom de comunitat autonoma
Hola llista, Escric respecte a que s'esta el nom de la comunitat autonoma de Catalunya s'esta canviant per Cataluña de manera reiterada per l'usuari KikeTM.L'ultim canvi en el conjunt de canvis[1] Aquest usuari en l'ultim any ja ha canviat la relacio 5 vegades , totes les edicions en el mateix sentit. Tambe recordar que amb el mateix usuari ja hi va haver un problema (no intencionat) degut a que es van fer uns canvis a la Wiki d'OSM Com creieu que s'ha de solucionar i evitar entrar en una guerra d'edicions continues que no aporta res a OSM? Moltes gracies i salutacions [1]-https://www.openstreetmap.org/changeset/24620255 ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat
Re: [Talk-cat] Nom de comunitat autonoma
Jo ho modificaria i em posaria en contacte amb ell per saber si es tracte un altre cop de l'addon que té al navegador. En el cas que hagi estat modificat explícitament, se li ha d'aclarir que faci ús de les tags: - *name* es per a nom oficial (en el cas de Catalunya, els noms en català, així com a Euskadi són ambdós noms separats per guió o barra Vitoria-Gasteiz) - *name:es* per a Cataluña - *name:ca* per a Catalunya El dia 16 agost de 2014 17:51, Xavier Barnada xbarn...@gmail.com ha escrit: Hola llista, Escric respecte a que s'esta el nom de la comunitat autonoma de Catalunya s'esta canviant per Cataluña de manera reiterada per l'usuari KikeTM.L'ultim canvi en el conjunt de canvis[1] Aquest usuari en l'ultim any ja ha canviat la relacio 5 vegades , totes les edicions en el mateix sentit. Tambe recordar que amb el mateix usuari ja hi va haver un problema (no intencionat) degut a que es van fer uns canvis a la Wiki d'OSM Com creieu que s'ha de solucionar i evitar entrar en una guerra d'edicions continues que no aporta res a OSM? Moltes gracies i salutacions [1]-https://www.openstreetmap.org/changeset/24620255 ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat -- *Carlos Sánchez*About.me http://about.me/carlos.sanchez ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat
Re: [Talk-cat] Nom de comunitat autonoma
Hola, que us semblaria: Apreciado KikeTM. Desde la comunidad OSM en Catalunya hemos detectado que has realizado reiterados cambios del topónimo Catalunya por Cataluña. En el conjunto de cambios haces el comentario: Nombre de la Comunidad Autonoma de Cataluña segun Estatuto de Autonomia de Cataluña. Titulo Preliminar de Ley Orgánica 6/2006, de 19 de julio, de reforma del Estatuto de Autonomía de Cataluña. Queremos comentarte, que la justificación no la consideramos correcta, ya que esta ley, no regula la toponimia oficial, al igual que tampoco lo hace la constitución española [1] (una búsqueda en ésta sobre toponimia u onomástica no dará ningún resultado). La toponimia está regulada por otras leyes, que no son ni el estatuto ni la constitución. En el caso que nos ocupa, la toponimia oficial de Catalunya está regulada por la ley: Ley 1/1998, de 7 de enero, de Política Lingüística [2]. Dónde en su artículo 18 dicta: Los topónimos de Cataluña tienen como única forma oficial la catalana, de acuerdo con la normativa lingüística del Institut d'Estudis Catalans, excepto los del Valle de Arán, que tienen la aranesa. Así que te pedimos utilices la toponímia oficial de Catalunya en el campo name, sin perjuicio alguno a usar en el campo name:es el nombre español de Cataluña. Quedando de la siguiente manera: name=Catalunya name:es=Cataluña name:ca=Catalunya name:oc=Catalonha Saludos. [1] https://www.boe.es/buscar/act.php?id=BOE-A-1978-31229 [2] https://www.boe.es/diario_boe/txt.php?id=BOE-A-1998-2989 És una mica bord, però no és la primera vegada que tenim problemes amb aquest usuari. Per cert, un OT: He posat en el thunderbird el corrector a castellà i he quedat sorprès, ja que tan Catalunya com Cataluña surt com a incorrecte proposant Alcayata i Catalítica respectivament com a possibles correccions. Sembla que no sigui un fet atzarós (no les correccions, sino que Cataluña amb ñ surti com a error, España no ho fa pas) On 16/08/14 19:17, Carlos Sánchez wrote: Jo ho modificaria i em posaria en contacte amb ell per saber si es tracte un altre cop de l'addon que té al navegador. En el cas que hagi estat modificat explícitament, se li ha d'aclarir que faci ús de les tags: * *name* es per a nom oficial (en el cas de Catalunya, els noms en català, així com a Euskadi són ambdós noms separats per guió o barra Vitoria-Gasteiz) * *name:es* per a Cataluña * *name:ca* per a Catalunya El dia 16 agost de 2014 17:51, Xavier Barnada xbarn...@gmail.com mailto:xbarn...@gmail.com ha escrit: Hola llista, Escric respecte a que s'esta el nom de la comunitat autonoma de Catalunya s'esta canviant per Cataluña de manera reiterada per l'usuari KikeTM.L'ultim canvi en el conjunt de canvis[1] Aquest usuari en l'ultim any ja ha canviat la relacio 5 vegades , totes les edicions en el mateix sentit. Tambe recordar que amb el mateix usuari ja hi va haver un problema (no intencionat) degut a que es van fer uns canvis a la Wiki d'OSM Com creieu que s'ha de solucionar i evitar entrar en una guerra d'edicions continues que no aporta res a OSM? Moltes gracies i salutacions [1]-https://www.__openstreetmap.org/changeset/__24620255 https://www.openstreetmap.org/changeset/24620255 _ Talk-cat mailing list Talk-cat@openstreetmap.org mailto:Talk-cat@openstreetmap.org https://lists.openstreetmap.__org/listinfo/talk-cat https://lists.openstreetmap.org/listinfo/talk-cat -- *Carlos Sánchez *About.me http://about.me/carlos.sanchez* * ** ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat -- Jaume Figueras i Jové o o o Responsable de projectes SIG o o o inLab FIB o o o U P C Universitat Politècnica de Catalunya - Barcelona Tech E-mail : jaume.figue...@upc.edu Web: http://inlab.fib.upc.edu/ Telf : +34937398621 (intern UPC: 98621) Mòbil : +34650756456 (intern UPC: 44785) Fax: +34937398628 (intern UPC: 98628) Adreça : inLab FIB Edifici B5-S102 C/ Jordi Girona, 31 08025 BARCELONA Ubuntu User #14347 - Linux User #504317 ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat
Re: [Talk-cat] Nom de comunitat autonoma
Hola, Carlos,crec que es algo premeditat degut al comentari que hi ha al changeset. Jaume, em sembla correcte la resposta,voleu que la envii jo o voleu fer-ho d'alguna manera mes conjunta? Salutacions El 16/08/14 a les 20:00, Jaume Figueras i Jové ha escrit: Hola, que us semblaria: Apreciado KikeTM. Desde la comunidad OSM en Catalunya hemos detectado que has realizado reiterados cambios del topónimo Catalunya por Cataluña. En el conjunto de cambios haces el comentario: Nombre de la Comunidad Autonoma de Cataluña segun Estatuto de Autonomia de Cataluña. Titulo Preliminar de Ley Orgánica 6/2006, de 19 de julio, de reforma del Estatuto de Autonomía de Cataluña. Queremos comentarte, que la justificación no la consideramos correcta, ya que esta ley, no regula la toponimia oficial, al igual que tampoco lo hace la constitución española [1] (una búsqueda en ésta sobre toponimia u onomástica no dará ningún resultado). La toponimia está regulada por otras leyes, que no son ni el estatuto ni la constitución. En el caso que nos ocupa, la toponimia oficial de Catalunya está regulada por la ley: Ley 1/1998, de 7 de enero, de Política Lingüística [2]. Dónde en su artículo 18 dicta: Los topónimos de Cataluña tienen como única forma oficial la catalana, de acuerdo con la normativa lingüística del Institut d'Estudis Catalans, excepto los del Valle de Arán, que tienen la aranesa. Así que te pedimos utilices la toponímia oficial de Catalunya en el campo name, sin perjuicio alguno a usar en el campo name:es el nombre español de Cataluña. Quedando de la siguiente manera: name=Catalunya name:es=Cataluña name:ca=Catalunya name:oc=Catalonha Saludos. [1] https://www.boe.es/buscar/act.php?id=BOE-A-1978-31229 [2] https://www.boe.es/diario_boe/txt.php?id=BOE-A-1998-2989 És una mica bord, però no és la primera vegada que tenim problemes amb aquest usuari. Per cert, un OT: He posat en el thunderbird el corrector a castellà i he quedat sorprès, ja que tan Catalunya com Cataluña surt com a incorrecte proposant Alcayata i Catalítica respectivament com a possibles correccions. Sembla que no sigui un fet atzarós (no les correccions, sino que Cataluña amb ñ surti com a error, España no ho fa pas) On 16/08/14 19:17, Carlos Sánchez wrote: Jo ho modificaria i em posaria en contacte amb ell per saber si es tracte un altre cop de l'addon que té al navegador. En el cas que hagi estat modificat explícitament, se li ha d'aclarir que faci ús de les tags: * *name* es per a nom oficial (en el cas de Catalunya, els noms en català, així com a Euskadi són ambdós noms separats per guió o barra Vitoria-Gasteiz) * *name:es* per a Cataluña * *name:ca* per a Catalunya El dia 16 agost de 2014 17:51, Xavier Barnada xbarn...@gmail.com mailto:xbarn...@gmail.com ha escrit: Hola llista, Escric respecte a que s'esta el nom de la comunitat autonoma de Catalunya s'esta canviant per Cataluña de manera reiterada per l'usuari KikeTM.L'ultim canvi en el conjunt de canvis[1] Aquest usuari en l'ultim any ja ha canviat la relacio 5 vegades , totes les edicions en el mateix sentit. Tambe recordar que amb el mateix usuari ja hi va haver un problema (no intencionat) degut a que es van fer uns canvis a la Wiki d'OSM Com creieu que s'ha de solucionar i evitar entrar en una guerra d'edicions continues que no aporta res a OSM? Moltes gracies i salutacions [1]-https://www.__openstreetmap.org/changeset/__24620255 https://www.openstreetmap.org/changeset/24620255 _ Talk-cat mailing list Talk-cat@openstreetmap.org mailto:Talk-cat@openstreetmap.org https://lists.openstreetmap.__org/listinfo/talk-cat https://lists.openstreetmap.org/listinfo/talk-cat -- *Carlos Sánchez *About.me http://about.me/carlos.sanchez* * ** ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat
Re: [Talk-cat] Nom de comunitat autonoma
Perdò també pel top-posting i la brevetat, escric des del mòbil. Al que comentes afegiria la referència a la wiki [1] sobre el name multi idioma i la forma de fe-ho que en aquest cas seria name=Catalunya. [1] http://wiki.openstreetmap.org/wiki/Multilingual_names#Spain On 16 d’agost de 2014 20.36.38 CEST, Joan Montané j...@montane.cat wrote: Dispenseu el top-posting i la brevetat del missatge. Sóc fora de vacances. Aquest tema el vaig «preparar» fa mesos, preveient que arribaríem a aquest punt (sí, jo també he corregit el nom alguna vegada). Personalment, no aniria per la via de nom oficial, podem perdre-hi. La toponímia de les províncies i comunitats autònomes és comptència de l'Estat, via lleis (per exemple els estatuts) no de les comunitats :(( L'estatut català, a diferència del Balear, no estableix explícitament el nom oficial de la comunitat. Estic segur que no és casualitat. L'estatut simplement usa, de forma implícita, el terme «Catalunya» a la versió en català i «Cataluña» en la versió en castellà. Malauradament, legalment, l'estatut aprovat és la versió en castellà (perquè és el que s'aprova a Madrid) : Com ho podem enfocar? Donem la volta a l'argulent, :) L'etiqueta «name» *no* és per als noms oficials. És per als noms tal com apareixen als cartells, al carrer. Fa mesos vaig mirar les entrades a Catalunya per carretera. En cap hi apareix el terme «Catalunya», hi apareix «Catalunya» :))) Personalment, prefereixo evitar una guerra d'edicions, però no vull saber-ne res de noms bilíngües. Salut i mapes!!! Joan Montané El dia 16/08/2014 20.01, Jaume Figueras i Jové jaume.figue...@upc.edu va escriure: Hola, que us semblaria: Apreciado KikeTM. Desde la comunidad OSM en Catalunya hemos detectado que has realizado reiterados cambios del topónimo Catalunya por Cataluña. En el conjunto de cambios haces el comentario: Nombre de la Comunidad Autonoma de Cataluña segun Estatuto de Autonomia de Cataluña. Titulo Preliminar de Ley Orgánica 6/2006, de 19 de julio, de reforma del Estatuto de Autonomía de Cataluña. Queremos comentarte, que la justificación no la consideramos correcta, ya que esta ley, no regula la toponimia oficial, al igual que tampoco lo hace la constitución española [1] (una búsqueda en ésta sobre toponimia u onomástica no dará ningún resultado). La toponimia está regulada por otras leyes, que no son ni el estatuto ni la constitución. En el caso que nos ocupa, la toponimia oficial de Catalunya está regulada por la ley: Ley 1/1998, de 7 de enero, de Política Lingüística [2]. Dónde en su artículo 18 dicta: Los topónimos de Cataluña tienen como única forma oficial la catalana, de acuerdo con la normativa lingüística del Institut d'Estudis Catalans, excepto los del Valle de Arán, que tienen la aranesa. Así que te pedimos utilices la toponímia oficial de Catalunya en el campo name, sin perjuicio alguno a usar en el campo name:es el nombre español de Cataluña. Quedando de la siguiente manera: name=Catalunya name:es=Cataluña name:ca=Catalunya name:oc=Catalonha Saludos. [1] https://www.boe.es/buscar/act.php?id=BOE-A-1978-31229 [2] https://www.boe.es/diario_boe/txt.php?id=BOE-A-1998-2989 És una mica bord, però no és la primera vegada que tenim problemes amb aquest usuari. Per cert, un OT: He posat en el thunderbird el corrector a castellà i he quedat sorprès, ja que tan Catalunya com Cataluña surt com a incorrecte proposant Alcayata i Catalítica respectivament com a possibles correccions. Sembla que no sigui un fet atzarós (no les correccions, sino que Cataluña amb ñ surti com a error, España no ho fa pas) On 16/08/14 19:17, Carlos Sánchez wrote: Jo ho modificaria i em posaria en contacte amb ell per saber si es tracte un altre cop de l'addon que té al navegador. En el cas que hagi estat modificat explícitament, se li ha d'aclarir que faci ús de les tags: * *name* es per a nom oficial (en el cas de Catalunya, els noms en català, així com a Euskadi són ambdós noms separats per guió o barra Vitoria-Gasteiz) * *name:es* per a Cataluña * *name:ca* per a Catalunya El dia 16 agost de 2014 17:51, Xavier Barnada xbarn...@gmail.com mailto:xbarn...@gmail.com ha escrit: Hola llista, Escric respecte a que s'esta el nom de la comunitat autonoma de Catalunya s'esta canviant per Cataluña de manera reiterada per l'usuari KikeTM.L'ultim canvi en el conjunt de canvis[1] Aquest usuari en l'ultim any ja ha canviat la relacio 5 vegades , totes les edicions en el mateix sentit. Tambe recordar que amb el mateix usuari ja hi va haver un problema (no intencionat) degut a que es van fer uns canvis a la Wiki d'OSM Com creieu que s'ha de solucionar i evitar entrar en una guerra d'edicions continues que no aporta res a OSM? Moltes gracies i salutacions [1]-https://www.__openstreetmap.org/changeset/__24620255 https://www.openstreetmap.org/changeset/24620255
Re: [Talk-cat] Nom de comunitat autonoma
Hola, Tant en Joan com en Carles teniu rao. Primerament segons la wiki el camp name s'usa per a el nom comu, no el nom oficial, per al nom oficial existeix el camp official_name, tot i aixo segons el que comenta en Jaume hauria de ser official_name=Catalunya official_name:ca=Catalunya offical_name:es=Cataluña Respecte al que comenta en Joan veig que hi ha aquesta guia a la wiki i per tant s'hauria de seguir . He modificat el missatge inicial que havia proposat en Jaume que incloure totes aquestes ideas: Apreciado KikeTM. Desde la comunidad OSM en Catalunya hemos detectado que has realizado reiterados cambios del topónimo Catalunya por Cataluña. En el conjunto de cambios haces el comentario: Nombre de la Comunidad Autonoma de Cataluña segun Estatuto de Autonomia de Cataluña. Titulo Preliminar de Ley Orgánica 6/2006, de 19 de julio, de reforma del Estatuto de Autonomía de Cataluña. Queremos comentarte, que la justificación no la consideramos correcta, ya que esta ley, no regula la toponimia oficial, al igual que tampoco lo hace la constitución española [1] (una búsqueda en ésta sobre toponimia u onomástica no dará ningún resultado). La toponimia está regulada por otras leyes, que no son ni el estatuto ni la constitución. En el caso que nos ocupa, la toponimia oficial de Catalunya está regulada por la ley: Ley 1/1998, de 7 de enero, de Política Lingüística [2]. Dónde en su artículo 18 dicta: Los topónimos de Cataluña tienen como única forma oficial la catalana, de acuerdo con la normativa lingüística del Institut d'Estudis Catalans, excepto los del Valle de Arán, que tienen la aranesa. Así que te pedimos utilices la toponímia oficial de Catalunya en el campo name, sin perjuicio alguno a usar en el campo name:es el nombre español de Cataluña. Quedando de la siguiente manera: name=Catalunya name:es=Cataluña name:ca=Catalunya name:oc=Catalonha Aun asi, el campo name se usa para indicar el nombre comun[3] y no el nombre oficial ya que para ello se usa el campo official_name, con lo que añadire a las etiquetas anteriores estas: official_name=Catalunya official_name:es=Cataluña official_name:ca=Catalunya official_name:oc=Catalonha Tambien indicar que existe una guia para el etiquetado del campo name en multiidioma en al wiki de OSM[4] Saludos y espero que podamos destinar nuestros esfuerzos en aportaciones mas productivas para Open Street Map [1] https://www.boe.es/buscar/act.php?id=BOE-A-1978-31229 [2] https://www.boe.es/diario_boe/txt.php?id=BOE-A-1998-2989 [3] http://wiki.openstreetmap.org/wiki/Name [4] http://wiki.openstreetmap.org/wiki/Multilingual_names#Spain El 16/08/14 a les 21:26, Carles Muñoz Gorriz ha escrit: Perdò també pel top-posting i la brevetat, escric des del mòbil. Al que comentes afegiria la referència a la wiki [1] sobre el name multi idioma i la forma de fe-ho que en aquest cas seria name=Catalunya. [1] http://wiki.openstreetmap.org/wiki/Multilingual_names#Spain On 16 d’agost de 2014 20.36.38 CEST, Joan Montané j...@montane.cat wrote: Dispenseu el top-posting i la brevetat del missatge. Sóc fora de vacances. Aquest tema el vaig «preparar» fa mesos, preveient que arribaríem a aquest punt (sí, jo també he corregit el nom alguna vegada). Personalment, no aniria per la via de nom oficial, podem perdre-hi. La toponímia de les províncies i comunitats autònomes és comptència de l'Estat, via lleis (per exemple els estatuts) no de les comunitats :(( L'estatut català, a diferència del Balear, no estableix explícitament el nom oficial de la comunitat. Estic segur que no és casualitat. L'estatut simplement usa, de forma implícita, el terme «Catalunya» a la versió en català i «Cataluña» en la versió en castellà. Malauradament, legalment, l'estatut aprovat és la versió en castellà (perquè és el que s'aprova a Madrid) : Com ho podem enfocar? Donem la volta a l'argulent, :) L'etiqueta «name» *no* és per als noms oficials. És per als noms tal com apareixen als cartells, al carrer. Fa mesos vaig mirar les entrades a Catalunya per carretera. En cap hi apareix el terme «Catalunya», hi apareix «Catalunya» :))) Personalment, prefereixo evitar una guerra d'edicions, però no vull saber-ne res de noms bilíngües. Salut i mapes!!! Joan Montané El dia 16/08/2014 20.01, Jaume Figueras i Jové jaume.figue...@upc.edu mailto:jaume.figue...@upc.edu va escriure: Hola, que us semblaria: Apreciado KikeTM. Desde la comunidad OSM en Catalunya hemos detectado que has realizado reiterados cambios del topónimo Catalunya por Cataluña. En el conjunto de cambios haces el comentario: Nombre de la Comunidad Autonoma de Cataluña segun Estatuto de Autonomia de Cataluña. Titulo Preliminar de Ley Orgánica 6/2006, de 19 de julio, de reforma del Estatuto de Autonomía de Cataluña. Queremos
[Talk-lv] ritenjbrauceejiem - iron curtain trail ?
varbuut ritenjbraukshanas entuziasti var papildinaat sho velocelinju ? http://api.osm.org/relation/2769637#map=8/57.029/23.483 https://en.wikipedia.org/wiki/EV13_The_Iron_Curtain_Trail -- Rich ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv
[Talk-cz] FW: Folie KM strkaná do scanneru obráceně
Dobrý den, ve Vlašimi (ul. J.V.Sládka / Ke Spravedlnosti) je to evidentní chyba editora. Upozorníme jej na to a budeme doufat, že definiční body SO opraví. Petr Souček -Original Message- From: Petr Souček [mailto:sou...@maestroclub.cz] Sent: Friday, August 08, 2014 10:38 PM To: sou...@maestroclub.cz; Souček, Petr Subject: FW: [Talk-cz] Folie KM strkaná do scanneru obráceně -Original Message- From: Petr Vejsada [mailto:o...@propsychology.cz] Sent: Wednesday, July 30, 2014 6:24 PM To: OpenStreetMap Czech Republic Subject: [Talk-cz] Folie KM strkaná do scanneru obráceně Ahoj, jsem na stopě alespoň jednoho ze způsobů, jak vzniká rudý duch. Koukám na to stále nevěřícně, ale bude to tak - někdo totiž strká do scanneru fólii s katastrální mapou obráceně. Pohleďme na obrázek http://pedro.poloha.net/osm/folie.png Východně od ulice Ke Spravedlnosi a severně pd ulice J.V. Sládka vidímě popisná čísla (zleva doprava) 1771, 1772, ... 1775. Takto byla uložena v OSM. Vidíme rovněž rudého ducha, tedy definiční bod budovy s č.p. 1774. Červená čára ukazuje k polygonu budovy. Budovy jsou v realitě západně od ulice Ke Spravedlnosti a jižně od ulice J.V.Sládka. Zleva doprava jsou č.p. ovšem v pořadí 1775, 1774 ... 1771. Prostě někdo strčil něco do scanneru obráceně. Mohlo by to vysvětlovat i další řadu rudých duchů, jak jsou patrné ve Všechlapech, okres Benešov, http://ruian.poloha.net/16/49.7697/14.9304 (zapnout vrstvu budov). To taky tak trochu vypadá, jakoby někdo strkal folii do scanneru obráceně :-). V těch Všechlapech je to hodně zmatené. Jedná se zejména o budovy: 14323508 14323362 14323401 14323419 14323494 14323524 14323451 14323486 14323443 14323397 14323460 -- Petr ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Nová fíčura ve vrstvě budov
Dobrý den, Ad Troja) zde se podle mě jedná o chybu v katastrální mapě, kdy na parcelách 1321/2,3,4,5,6,7,9 a 1311/3,4,5,6,7,8,9 chybí značka budovy. Tento stav je chybný už v katastru nemovitostí, viz polygony budov v aplikaci Nahlížení, http://sgi.nahlizenidokn.cuzk.cz/marushka/default.aspx?themeid=3MarUid=7E65 95D2%209D2F4EA0%20A5AD9D88%208244EA23MarUidi=8244EA23MarMiddlePoint=-74296 3.9674310316%20-1038573.7739832742MarScale=1130 . Kontaktoval jsem KP Praha-město. Předpokládám, že dojde k opravě. Ad Všechlapy) tady to je opravdu výživné. Koukám, že v ISÚI a ISKN jsou evidovány objekty se stejnými čísly evidenčními úplně na jiných místech, viz obrázek http://s24.postimg.org/4b59xrg91/vechlapy.jpg (fialově ISÚI, červeně ISKN). Zkusím požádat kolegy o prověření. Z toho důvodu jsou také chybně napárovány budovy z ISKN a SO z ISÚI. Např. budova č.ev. 76 je dle ISÚI evidována serverněji v lokalitě Na Hůrkách, ale v ISKN je budova s tímto číslem evidenčním evidována v lokalitě Nový Mlýn. Petr Souček -Original Message- From: Petr Souček [mailto:souc...@atlas.cz] Sent: Friday, August 08, 2014 11:40 PM To: 'OpenStreetMap Czech Republic' Subject: RE: [Talk-cz] Nová fíčura ve vrstvě budov Dobrý den, děkuji moc za vysvětlení. Podívám se na to a budu Vás informovat. Petr Souček -Original Message- From: Petr Vejsada [mailto:o...@propsychology.cz] Sent: Friday, August 08, 2014 10:07 PM To: OpenStreetMap Czech Republic Subject: Re: [Talk-cz] Nová fíčura ve vrstvě budov Dobrý den, je to ulice Krynická, Praha-Troja, http://ruian.poloha.net/18/50.12606/14.41053 Nemyslím, že tento případ by zasloužil nějakou speciální pozornost, není to zase tak vzácný jev. Jsou daleko horší oblasti, například okolí Chyňavy, okres Beroun, http://ruian.poloha.net/15/50.0461/14.0952 Ve vrstvě jsou nyní spojnice mezi definičním bodem (červeným duchem) a polygonem, protože jinak by se to mnohdy nedalo dohledat. Limit vzdálenosti je nastaven na 10 metrů. Výjimečně to může být v pořádku, ale když je definiční bod jedné budovy až za jinou budovou, tak to o správnosti dost pochybuji. Další pozoruhodné místo je východní hranice obce Všechlapy, okres Benešov, kde jsou na jednom plácku definiční body budov a jejich polygony jsou stovky metrů jinde, http://ruian.poloha.net/17/49.77164/14.92749 Ještě zopakuji vysvětlivky k vrstvě budov: - růžová budova - OK, má hranice i definiční bod ve vzdálenosti do 10 metrů od polygonu - samotná červená budova bez spojnice s duchem = má jen hranice a nemá definiční bod - samotný růžový duch - definiční bod budovy, která nemá polygon (normální na nezdigitalizovaných KÚ a dalších budov, u kterých se geometrie do RÚIAN nezadává) -- Zdraví a děkuje za zájem Petr Vejsada Dne Pá 8. srpna 2014 19:56:43, Petr Souček napsal(a): Dobrý den, o jaké území se jedná na obrázku http://pedro.poloha.net/osm/red-ghosts.png? Chtěl bych se na to kouknout. Děkuji moc Petr Souček -Original Message- From: Petr Vejsada [mailto:o...@propsychology.cz] Sent: Monday, July 14, 2014 9:51 PM To: talk-cz@openstreetmap.org Subject: [Talk-cz] Nová fíčura ve vrstvě budov Ahoj, s novou verzí CzechAddress se začaly v datech pro import objevovat zdánlivě záhadná umístění adresních bodů. Aby tato umístění už nebyla záhadná, přidal jsem do vrstvy budov červené budovy a červené duchy. Červený duch je definiční bod budovy, která sice má geometrii (polygon), ale tento polygon je podezřele daleko od definičního bodu. 221 km byl opravdu rekord, ale ono i takových 50 metrů dokáže zatopit. Těžko říci, co je správně. Předpokládám, že vyšší pravděpodobnost bude mít stav, kdy definiční bod je umístěn správně a polygon špatně. CzechAddress v těchto případech a za předpokladu, že samotné adresní místo v RUIAN je bez geometrie nebo je jeho poloha úplně mimo, reaguje tak, že dává adresu na definiční bod. Toto už tedy nebude záhadou, protože definiční bod takové budovy se zobrazí jako červený duch. Červené budovy jsou ty, které patří do páru s takto vzdáleným definičním bodem. Obrázek lepší než mnoho slov - http://pedro.poloha.net/osm/red-ghosts.png . Kromě normálních budov na obrázku vidíme definiční body řady domů, jejichž polygony jsou vlevo naplácané všechny na jedno místo. Dole pak vidíme definiční bod a polygon, které jsou od sebe neobvykle vzdálené. Nyní je limit 15 metrů, možno dle praxe upravit. Vrstva asi pomůže, jak obrázek ilustruje, pochopit některé záhady dat v RUIAN. Zoom 15 a vyšší je vykreslen, zoom 12-14 se vykresluje, tedy chvilku strpení. -- Petr, p...@propsychology.cz p ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Dokončení importu adres
Dobrý den, dvojice čísel jsou problém některých chatových osad (zejména ve středních Čechách), kdy obec k evidenčním číslům přidávala nějaký prefix, např. těch 1000, 5000, atd. Bohužel ale někdo používal i tu druhou variantu bez tohoto prefixu. A tím pádem se do katastru nemovitostí, nebo do UIR-ADR dostala směs a nebo obě varianty těchto čísel. Již v minulosti jsme tento problém řešili v Mnichovicích. Bohužel se nedá jasně říct, která čísla mají existovat. To musí říct obec a hlavně v návaznosti na to, jestli na tom čísle není někdo přihlášen k trvalému pobytu, nemá sídlo provozovny, atd. V této souvislosti jsme vyšli editorům vstříc a vystavili novou kontrolu na našich stránkách, http://www.cuzk.cz/Uvod/Produkty-a-sluzby/RUIAN/3-Overeni-uplnosti-a-spravno sti-udaju-ISUI-RUIAN/Kontroly-dat-ISUI-RUIAN/Kontrola-adresnich-mist-bez-def inicniho-bodu.aspx, kde se dozví i tyto informace. Ale je to opět jen pomoc editorům, nápravu musí udělat oni. Opět jsem požádal kolegy, aby to s příslušnými editory zkusili vyřešit. Uvidíme, jak budeme úspěšní. Petr Souček -Original Message- From: Petr Vejsada [mailto:o...@propsychology.cz] Sent: Sunday, August 10, 2014 10:28 PM To: talk-cz@openstreetmap.org Subject: [Talk-cz] Dokončení importu adres Ahoj, zbývá nám necelé jedno procento adres, přičemž půlka toho procenta je problematická. Jedná se o obce: okres Praha-východ: Jevany Kozojedy Stříbrná Skalice Vyžlovka okres Břeclav: Mikulov Břeclav U všech, s výjimkou Břeclavi, jde o značný podíl dvojitých (trojitých, ...) adres typu číslo 35 a 5035. Nechce se mi vědomě toto nahrávat do OSM, i když v minulosti byly nahrány i obce s větším podílem tohoto jevu Můj dotaz také směruje na pana Součka ;-), zda zjistil, co je to vlastně za jev, proč to takto je a zda se dá očekávat oprava a kdy, případně na koho se obrátit či zda je nějaké pravidlo, podle kterého bychom mohli tyto adresy odstranit. Tím myslím třeba v těch dvojicích vždy odstranit to velké číslo, tedy 5035 a 35 ponechat? Smazat adresní místo, které přísluší nekompletnímu SO (tedy SO, který má vyplněné jen minimální množství údajů)? Obec Břeclav je trošku jiná. Také se jedná o duplicitu adres, ale týká se hlavně orientačních čísel. Jeden dům má orientační číslo třeba 3 a zároveň 124 nebo jsou tam doby, které mají orientační čísla 2 3, 3 4, 5 6 nebo 2 4, 4 6, 6 8 atd. V naprosté většině případů má geometrii jen jedna z těchto adres. Vzniká tak z toho domněnka, že obsluha příslušného programu na stavebních úřadech čí kde, si myslí, že schováním geometrie adresa neexistuje. Druhá věc - myslím si, že všechny 2/3 okresů by se měly projet ještě jednou, a to pouze se zapnutou funkcí mazání stylem co není v RÚIAN, to přijde pryč Toto se totiž dělá až od nové verze bota, kterým byla zpracována poslední třetina adres a 2/3 by se tedy měly ještě jednou prohlédnout a promazat. Stále namátkově kontroluji, co se chytal bot smazat a v naprosté většině případů to byla místa, kde je na ortofoto vidět zbořeniště či i z leteckého pohledu je patrné, že střechou do něho už roky zatéká a fakticky je to vrak ;-). S poslední informací o chybách ve výměnném formátu bych s tím ještě počkal -- Petr, p...@propsychology.cz p ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] RUIAN a inkrementální aktualizace
Dobrý den, včera jsem o tom diskutoval s kolegou. A dnes jsem si tento konkrétní případ analyzoval a situace je následující. 1) 20.6.2014 došlo k zápisu SO 78153263 do ISÚI. Jedná se o SO bez čísla (typ 3) a byl zapsán na parcelu (ID 41994826010) z potvrzeného GP (tj. tzv. G parcela), která není v RÚIAN 2) 21.6.2014 se tento SO standardně dostal do změnového VFR, neboť ten se generuje za stát a dostanou se do něj všechny SO 3) 1.7.2014 se tento SO do stavového VFR nedostal, neboť SO se rozdělují do VFR po obcích (pro číslované dle části obce, pro nečíslované dle parcely a příslušnosti do k.ú. = obce). V tomto případě se do obce nezařadí, neboť by se měl rozdělit dle parcely, ale zatím v RÚIAN neexistuje (zatím je pouze v budoucnosti, ve vrstvě potvrzených GP v ISKN). 4) 28.7.2014 došlo k zápisu stavby v KN a tím pádem se parcela (ID 41994826010) dostala do přítomnosti ISKN a také do RÚIAN. 5) 1.8.2014 došlo standardně k vygenerování stavového VFR, kde už se SO zařadil dle parcely do příslušné obce Z toho mi vyplývá, že takových případů je relativně hodně. Jsou to všechny nově zapisované SO bez čísla, která jsou zapsána na parcelu z potvrzeného GP (a když o tom přemýšlím, tak to samé platí i pro parcelu, která je již pouze v minulosti - např. pokud dojde k přečíslování parcel v důsledku obnovy operátu a tím pádem k ustřelení identifikační parcely v ISÚI). Jestli dobře koukám, tak se jedná o cca 28,5 tisíc SO. Na základě výše uvedeného si myslím, že bychom se tím měli zabývat a zapsat požadavek na úpravu generování VFR. A to tak, aby se tyto SO dostali do VFR. Tohle bohužel musíme řešit s naším dodavatelem, takže to nebude obratem. Rozhodně díky za report tohoto problému, o jeho řešení Vás budeme informovat. Petr Souček -Original Message- From: Veselý, Jiří Sent: Monday, August 11, 2014 10:31 AM To: Souček, Petr; Formánek, Jiří Subject: FW: [Talk-cz] RUIAN a inkrementální aktualizace Ahoj, víme o tom? J. -Original Message- From: Petr Morávek [Xificurk] [mailto:p...@pada.cz] Sent: Monday, August 11, 2014 10:15 AM To: talk-cz@openstreetmap.org Subject: Re: [Talk-cz] RUIAN a inkrementální aktualizace Dne 10.8.2014 21:49, Petr Vejsada napsal(a): Mám schema, vzniklé z dat ke dni 30.4. plus aktualizace. Od začátku těch aktualizací tam mám ten patch, co ignoruje čísla transakcí, tedy *ignoruje*, není tam =, jak je asi v poslední -dev, viz debata na Githubu. To jen pro pořádek. Ač není pravděpodobné, že by se čísla transakcí někdy dekrementovala, vyloučit to asi nemůžeme! * SO 78153263 je v červencovém dumpu (20140731_OB_554791_UKSH.xml.gz), ale není v dumpu z června ani žádném změnovém souboru. select deleted,id_trans_ruian,definicni_bod is not NULL as definicni_bod,hranice is not NULL as hranice,plati_od,item_timestamp from ruian.rn_stavebni_objekt where kod=78153263; deleted | id_trans_ruian | definicni_bod | hranice | plati_od | item_timestamp -++---+-++ -++---+-++ -++---+-++ -++---+-++ -++---+-++ -++---+-++ -++---+-++ f | 627026 | t | f | 20.06.2014 | 22.06.2014 11:38:58.947812 je tedy ve změnovém souboru z průběhu června. Nahráno 22.6., takže asi soubor z 21.6., ale nevím jistě. Nenahrávám každý den, jen skoro každý den. V dumpu z června by ovšem být měl. Tak tohle mě vážně nenapadlo... dohledal jsem to ve změnovém souboru z 20.6. a obsah do puntíku sedí s tím, co je v červencovém dumpu. Ale v červnu fakt nebyl. Takže chyby jsou vážně v obojím, což opravdu není dobré :/ Petr ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
[Talk-cz] FW: RUIAN a inkrementální aktualizace (VFR)
Dobrý den, Ad SO 78153263) viz povídání v předchozím mailu Ad SO 78258294) 1) V ISKN byla evidována rozestavěná budova 2) v ISÚI byl 28.7.2014 zapsán číslovaný SO (78258294) 3) 29.7.2014 se SO dostal do změnového souboru. Vazba na budovu v ISKN zde chyběla správně, neboť rozestavěné budovy nejsou obsahem RÚIAN, tj. nepřebírá se do RÚIAN ani polygon (tato budova ho navíc nemá). 4) 29.7.2014 došlo k zápisu dokončené stavby (15680609010) v ISKN. Došlo k napojení této budovy na stavební objekt v ISÚI (vznikl na straně ISKN můstek). V RÚIAN došlo k doplnění BUD_ID a změně ID_TRANSAKCE. 5) a podle mě se měl 30.7.2014 vygenerovat změnový VFR a v něm se tato informace (SO 78258294) měla objevit. Vypadá to na chybu ve VFR, informoval jsem kolegy, kteří to budou řešit s dodavatelem. 6) 1.8.2014 se už ve stavovém objevila nová verze SO, doplněná o BUD_ID. Děkuji za report této chyby! Petr Souček -Original Message- From: Petr Morávek [Xificurk] [mailto:p...@pada.cz] Sent: Sunday, August 10, 2014 8:56 PM To: OpenStreetMap Czech Republic Subject: [Talk-cz] RUIAN a inkrementální aktualizace Ahoj, mám nemilou zprávu pro vás, co pracujete s RUIAN (přes ruian2pgsql) a provádíte inkrementální aktualizace - nefunguje to. Petr Vejsada tu už na jaře psal, že má podezření, že nový import úplného dumpu RUIAN dává jiný výsledek než postupně aktualizovaná databáze přes změnové soubory. A já to bohužel teď musím potvrdit. A je to trochu komplikovanější. První problém byl v ruian2pgsql [1]. Původní algoritmus počítal s tím, že pokud dojde k nějaké změně objektu, tak se vždy zvýší id transakce, což bohužel není pravda. Tento problém byl nedávno opraven... pokud používáte ruian2pgsql a importujete změnové soubory, tak silně doporučuju update na poslední dev verzi. Jenže i tak byly indikace, že není vše úplně v pořádku - a opravdu není. Mám tu dvě databáze: 1) Vznikla importem posledního úplného dump z konce července, konkrétně soubory 20140731_OB_*_UKSH.xml.gz a 20140731_ST_UKSH.xml.gz. 2) Vznikla importem úplného dumpu z konce června a pak importem všech změnových souborů z července, tj. soubory 20140630_OB_*_UKSH.xml.gz a 20140630_ST_UKSH.xml.gz a pak 26 souborů 201407*_ST_ZKSH.xml.gz. A když porovnám výsledek obou cest, tak se dá najít opravdu velké množství rozdílů. Konkrétně jsem se díval na stavební objekty. Některé SO jsou jen v (1), některé jen v (2), jiné jsou sice v obou databázích, ale jedna verze má neúplné údaje. Problematické SO jsem vystopoval do zdrojových dat a chyba je už tam. * SO 78153263 je v červencovém dumpu (20140731_OB_554791_UKSH.xml.gz), ale není v dumpu z června ani žádném změnovém souboru. * SO 78258294 je v červencovém dumpu (20140731_OB_576000_UKSH.xml.gz) - tam má IdTransakce=648617 a IsknBudovaId=15680609010. V červnovém dumpu není, ale je v jednom jediném změnovém souboru (20140728_ST_ZKSH.xml.gz), ale tam nemá nastaveno IsknBudovaId a IdTransakce=648063. ... Na ostatní tabulky jsem nekoukal, ale je dost možné, že trpí podobným problémem. -- Informaci píšu primárně sem do talk-cz, protože to tu sledují jak konzumenti dat, tak i zástupci ČÚZK. Chtěl bych poprosit pana Součka, jestli by mě (nás) nasměroval, kam/jak/jestli tento problém reportovat, případně jaké další detaily by bylo vhodné dodat. -- Zdraví, Petr Morávek aka Xificurk [1] https://github.com/fordfrog/ruian2pgsql/issues/24 https://github.com/fordfrog/ruian2pgsql/issues/24 ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer - pLPIS
Ahoj,
také jsem narážel na nějaké plochy kterým tracer nepřiřadil typ plochy. Na
Třebíčsku to byla tak jedna z dvaceti.
Včera jsem mapoval kousek okolo Plzně-Božkova a tam byly bez typu plochy
naprosto všechny polygony.
Parkis
2014-08-15 16:08 GMT+02:00 Marián Kyral mky...@email.cz:
Ahoj,
bohužel nemám kompletní seznam toho, co můžu lpis očekávat. Takže někdy to
nezafunguje a je potřeba mi to nahlásit a já to doplním do mapování.
Nicméně, u tého konkrétní cesty se mi doplní orná půda. Takže tím to
není. Ale něco podobného jsem už viděl. Řešil jsem to s Honzou Mladým. Do
odpovědi z WMS se nějakým záhadným způsobem dostaly podivné znaky. Vždy se
vecpou na stejné místo a to, jestli se něco natrasuje správně nebo ne
záleží jen na velikosti trasované plochy. Při určitém počtu uzlů se ty
podivné znaky třefí právě do pole s kulturou a tracer pak nic nenajde.
Ale proč se to děje netuším. U mně se tento problém nevyskytuje. A Honza
je teď na dovolené, takže další zkoumání momentálně neprobíhá.
Marián
-- Původní zpráva --
Od: Jan Dudík jan.du...@gmail.com
Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org
Datum: 15. 8. 2014 15:14:44
Předmět: Re: [Talk-cz] Tracer - pLPIS
Díky, bylo to tím nastavením.
Ale narazil jsem na plochy v LPIS, kterým tracer přiřadí pouze ref a
source, žádné landuse.
asi 6 jich je na relativně malé ploše v katastru Plav:
http://www.openstreetmap.org/#map=16/48.9090/14.4976
např. http://www.openstreetmap.org/way/297894310
je to záměr nbeo chyba?
---
Ing. Jan Dudík
projekce dopravních staveb
tel. 777082195
Dne 11. srpna 2014 16:01 Martin Švec - OSM o...@maatts.cz napsal(a):
Tím to nebude (pokud nechce klasický trasování katastrální mapy).
(1) V nastavení pluginu zaškrtnout moduly RUIAN a LPIS, odškrtnout
Klasický.
(2) Mačkat T a sledovat jak se mění kurzor myši, R = budovy z RUIANu, LP
=
půda z LPISu.
Martin
Dne 11.8.2014 15:53, Michal Pustějovský napsal(a):
Máš spuštěný tracer server?
-- Původní zpráva --
Od: Jan Dudík jan.du...@gmail.com
Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org
Datum: 11. 8. 2014 14:45:35
Předmět: Re: [Talk-cz] Tracer - pLPIS
Dělám něco špatně?
stáhl jsem si tracer z [1], k němu v JOSM dva vyžadované doplňky, na
pozadí si zapnul požadovanou vrstvu wms abych viděl co klikám.
spustím tracer, kliknu na budovu - aktualizuje se dle RUIAN
kliknu na plochu, kde je v LPIS vybarvená plocha - a nic
mačkáním T dosáhnu jediné změny, že se ani po kliku na budovu nic nestane
[1] http://www.kyralovi.cz/tmp/josm/beta/lpis/Tracer.jar
JAnD
Dne 8. srpna 2014 21:04 Pavel Kwiecien pavel.kwiec...@seznam.cz
napsal(a):
Ahoj, trochu jsem si už s Tracerem zablbnul a už se mi to tady pod
horama
zazelenalo
http://www.openstreetmap.org/#map=13/50.5706/15.7740
Pokud by spojování nebylo automatické, tak nemá smysl se tím zabývat.
Tracer
funguje dobře, akorát import je potřeba vždy!! projet v JOSM validací,
protože tracováním/vstupníma daty vzniká obrovské množství chyb a
varování.
Na dvě kliknutí se toho dá zbavit.
Ještě pro neznalé. Je dobré si v JOSM nastavit třeba tuto WMS vrstvu:
http://eagri.cz/public/app/wms/plpis.fcgi?FORMAT=image/gifVERSION=1.1.1SERVICE=WMSREQUEST=GetMapLAYERS=LPIS_FB_KULSTYLES=SRS={proj}WIDTH={width}HEIGHT={height}BBOX={bbox}
aby bylo vidět, kde jsou LPIS data.
Zdraví Pavel Kwiecien
-- Původní zpráva --
Od: Marián Kyral mky...@email.cz
Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org
Datum: 8. 8. 2014 9:08:35
Předmět: Re: [Talk-cz] Tracer - pLPIS
Ahoj,
-- Původní zpráva --
Od: Pavel Machek pa...@ucw.cz
Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org
Datum: 5. 8. 2014 23:19:28
Předmět: Re: [Talk-cz] Tracer - pLPIS
ahoj!
Jak by sis to propojení představoval? Mne nenapadá, jak by se to dalo
udělat.
No úplně přesně to nevím :).
Napřed bych viděl úvahu, zda jednotlivá políčka (=parcely a LPIS
polygony)
sdružovat nebo ne. Na tom závisí i strategie aktualizací. Zatím mi
přijde
nemožné hlídat si podle ref:, zda se něco v LPIS změnilo a na změnu
zareagovat. Nevíme, co se může měnit. Určitě druh kultury, možná i
geometrie?
Je možné, že tam, kde je teď 50 malých políček bude za 3 roky jen jedno
velké
či naopak?
No, zato vime ze je to po katastralnich uzemich, ne?
Takze az to bude chtit nekdo updatovat:
Pro kazdy polygon:
Je polygon se stejnou geometrii v osm?
NE: importuju
ANO: zmenim parametry na ty z noveho lpis, je li nutne
Pro polygony z OSM ktere jsem zatim nezpracoval:
Jestlize polygon ma source=lpis
Jestlize se od importu nezmenil, smazu ho
Jinak je to na rucni rozhodnuti co je aktualnejsi.
Hmm?
Pavel
No zásadní problém je: Slučovat nebo neslučovat polygony se stejným
landuse
vedle sebe?
Třeba tady:
Re: [Talk-cz] Tracer - pLPIS
Ahoj, pos(li mi prosím konkrétní body. Mám takové podezr(ení, z(e to je ne(jaký problém s windows. Protoz(e na linuxu to je bez problému*. Mu*z(ete mi prosím vs(ichni zkusit v prohlíz(ec(i toto url: http://eagri.cz/public/app/wms/plpis_wfs.fcgi?VERSION=1.1.0SERVICE=WFSREQUEST=GetFeatureTYPENAME=LPIS_FB4featureID=LPIS_FB4.7883723SRSNAME=EPSG:102067 A pr(ípadne( mi poslat výstup? Me(lo by to vypadat podobne( jako na obrázku. Pokud atribut ms:kultura nevypadá takto: *ms:kulturaorná pu*da/ms:kultura* Tak je to s(patne( a musíme zjistit, kde je problém. V traceru není, ten uz( dostane s(patná data. (je to ten pr(íklad od Honzy níz(e, kdyby to chte(l ne(kdo zkoumat). Marián Dne 16.8.2014 10:47, Jir(í Parkan napsal(a): Ahoj, také jsem naráz(el na ne(jaké plochy kterým tracer nepr(ir(adil typ plochy. Na Tr(ebíc(sku to byla tak jedna z dvaceti. Vc(era jsem mapoval kousek okolo Plzne(-Boz(kova a tam byly bez typu plochy naprosto vs(echny polygony. Parkis 2014-08-15 16:08 GMT+02:00 Marián Kyral mky...@email.cz mailto:mky...@email.cz: Ahoj, bohuz(el nemám kompletní seznam toho, co mu*z(u lpis oc(ekávat. Takz(e ne(kdy to nezafunguje a je potr(eba mi to nahlásit a já to doplním do mapování. Nicméne(, u tého konkrétní cesty se mi doplní orná pu*da. Takz(e tím to není. Ale ne(co podobného jsem uz( vide(l. R(es(il jsem to s Honzou Mladým. Do odpove(di z WMS se ne(jakým záhadným zpu*sobem dostaly podivné znaky. Vz(dy se vecpou na stejné místo a to, jestli se ne(co natrasuje správne( nebo ne zález(í jen na velikosti trasované plochy. Pr(i urc(itém poc(tu uzlu* se ty podivné znaky tr(efí práve( do pole s kulturou a tracer pak nic nenajde. Ale proc( se to de(je netus(ím. U mne( se tento problém nevyskytuje. A Honza je ted( na dovolené, takz(e dals(í zkoumání momentálne( neprobíhá. Marián -- Pu*vodní zpráva -- Od: Jan Dudík jan.du...@gmail.com mailto:jan.du...@gmail.com Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org mailto:talk-cz@openstreetmap.org Datum: 15. 8. 2014 15:14:44 Pr(edme(t: Re: [Talk-cz] Tracer - pLPIS Díky, bylo to tím nastavením. Ale narazil jsem na plochy v LPIS, kterým tracer pr(ir(adí pouze ref a source, z(ádné landuse. asi 6 jich je na relativne( malé plos(e v katastru Plav: http://www.openstreetmap.org/#map=16/48.9090/14.4976 napr(. http://www.openstreetmap.org/way/297894310 tel:297894310 je to záme(r nbeo chyba? --- Ing. Jan Dudík projekce dopravních staveb tel. 777082195 tel:777082195 Dne 11. srpna 2014 16:01 Martin S(vec - OSM o...@maatts.cz mailto:o...@maatts.cz napsal(a): Tím to nebude (pokud nechce klasický trasování katastrální mapy). (1) V nastavení pluginu zas(krtnout moduly RUIAN a LPIS, ods(krtnout Klasický. (2) Mac(kat T a sledovat jak se me(ní kurzor mys(i, R = budovy z RUIANu, LP = pu*da z LPISu. Martin Dne 11.8.2014 15:53, Michal Puste(jovský napsal(a): Más( spus(te(ný tracer server? -- Pu*vodní zpráva -- Od: Jan Dudík jan.du...@gmail.com mailto:jan.du...@gmail.com Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org mailto:talk-cz@openstreetmap.org Datum: 11. 8. 2014 14:45:35 Pr(edme(t: Re: [Talk-cz] Tracer - pLPIS De(lám ne(co s(patne(? stáhl jsem si tracer z [1], k ne(mu v JOSM dva vyz(adované dopln(ky, na pozadí si zapnul poz(adovanou vrstvu wms abych vide(l co klikám. spustím tracer, kliknu na budovu - aktualizuje se dle RUIAN kliknu na plochu, kde je v LPIS vybarvená plocha - a nic mac(káním T dosáhnu jediné zme(ny, z(e se ani po kliku na budovu nic nestane [1] http://www.kyralovi.cz/tmp/josm/beta/lpis/Tracer.jar JAnD Dne 8. srpna 2014 21:04 Pavel Kwiecien pavel.kwiec...@seznam.cz mailto:pavel.kwiec...@seznam.cz napsal(a): Ahoj, trochu jsem si uz( s Tracerem zablbnul a uz( se mi to tady pod horama zazelenalo http://www.openstreetmap.org/#map=13/50.5706/15.7740 Pokud by spojování nebylo automatické, tak nemá smysl se tím zabývat. Tracer funguje dobr(e, akorát import je potr(eba vz(dy!! projet v JOSM validací, protoz(e tracováním/vstupníma daty vzniká obrovské mnoz(ství chyb a varování. Na dve( kliknutí se toho dá zbavit. Jes(te( pro neznalé. Je dobré si v JOSM nastavit tr(eba tuto WMS vrstvu:
Re: [Talk-cz] aktualizace chráněných území
Jenom upřesním, první dávka chráněných území (tuším snad před pár rokama - cca 4) se vkládala roboticky a čerpalo se z dat AOPK ( http://drusop.nature.cz/), tuším, že to bylo možná i nějak zkombinovaný s dalšíma datama - už si to přesně nepamatuju, přeci jen - je to dlouho. Na aktualizaci se pracuje průběžně, téměř to nelze sledovat, protože nový chráněný území jsou vyhlašovány (převážně) krajskou samosprávou a to dost nahodile a do DRUSOPu pronikají tak nějak hodně náhodně. J. 2014-08-14 9:33 GMT+02:00 Marián Kyral mky...@email.cz: Iniciativě se meze nekladou ;-) Co tak koukám do wiki, je to čistě manuální práce, žádný skript. Já se teď určitě do ničeho pouštět nebudu. O shapefile jsem zatím jen slyšel a ještě jsem neměl čas ani sílu se tím zabývat. Nicméně jsem si všiml, že existuje doplněk OpenData [1] do JOSM, který by měl umět ty shapefile načíst a dále s nimi pracovat. Na přidání linku na Wikipedii se zase hodí doplněk Wikipedia [2] Klidně si to zkus, podle mne by to neměl být až takový problém. Jen, co tak koukám, je toho nějak moc a udělat na to aktualizační skript asi bude trochu složitější. Ale možná by to mohlo být stejné jako u importu hranic. Co by se ale dalo udělat programově by byla aktualizace tagů, hlavně oprava těch nadbytečných mezer - není to dlouho, co to tady někdo chtěl řešit a nedořešil. A i to přiřazení wikipedia tagu by nemuselo být až tak složité. Začal bych asi tím, že bych si přes http://overpass-turbo.eu vytáhl seznam všech chráněných území a uložil je do osm souboru. (kliknout na Wizard, do okýnka zadat leisure=nature_reserve a kliknout na build and run query. Pak jen potvrdit, že těch pár mega nebude problém ;-) (záleží na velikosti zobrazené oblasti). Pak už jen Export a vybrat JOSM.) Pak dostaneš OSM soubor, který můžeš otevřít v JOSM, případně jej před otevřením upravit nějakým tím skriptíkem (je to jednoduché XML). [1] http://wiki.openstreetmap.org/wiki/JOSM/Plugins/OpenData [2] http://josm.openstreetmap.de/wiki/Help/Plugin/Wikipedia Tak přeji hodně štěstí ;-) Marián -- Původní zpráva -- Od: xkomc...@centrum.cz Komu: talk-cz@openstreetmap.org Datum: 13. 8. 2014 22:45:22 Předmět: [Talk-cz] aktualizace chráněných území Zdravím, chtěl jsem se zeptat na aktualizaci chráněných území EEA - http://wiki.openstreetmap.org/wiki/EEA:Nationally_designated_areas_import . Psal jsem si s uživatelem Kozuch, který import před dvěma lety prováděl a ten na aktualizaci nemá vůbec čas. Zmínil ale, že by bylo vhodné provést propojení s wikipedií - dnes téměř každá chráněná oblast má svoji vlastní stránku na cs.wikipedii. Na samotnou aktualizaci si rozhodně netroufám, ale mohl bych pomoct s nějakým poloautomatickým importem wiki stránek. Zároveň bych prosil toho, kdo bude případnou aktualizaci provádět, zda-li by bylo možné zachovat i zaniklá chráněná území (předřadit jim tag disused nebospíš abandon), neboť informace o tom kde bývalo chráněné území je stále cenné (viz třeba ta wikipedie, kde jsou stránky i o těch již zaniklých). xkomczax ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz -- S pozdravem, Jirka Sedláček --- jirisedla...@gmail.com ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer - pLPIS
Díky. Tak to je hodně divné. Vypadá to normálně a stejně se tam něco pokazí.
Diakritika problém nebude. To by se přece nenatrasovalo nic. Ale někdy orná
půda projde, jindy ne. :-(
Marián
On 16. srpna 2014 19:09:30 CEST, Jiří Parkan jpar...@gmail.com wrote:
Ahoj,
výstup url přikládám (7883723.xml), letmým pohledem se mi zdá ok.
Pár příkladů lpis ID která nefungovala: 8570042, 9403951, 8570047
Jsou to políčka v téhle oblasti: http://osm.org/go/0JbF878yo--
Přikládám také uložené xml jednoho z nich (8570042.xml), v prohlížeči
se
taky zdá v pořádku.
Při trasování proběhne v konzoli JOSM chyba parsování xml a je tam
vidět
pomršená diakritika, viz obrázky. Možná je to ale jen chyba zobrazení v
konzoli, netuším.
Systém je Win7 home CZ.
Parkis
2014-08-16 18:42 GMT+02:00 Marián Kyral mky...@email.cz:
Ahoj,
pošli mi prosím konkrétní body. Mám takové podezření, že to je nějaký
problém s windows. Protože na linuxu to je bez problémů.
Můžete mi prosím všichni zkusit v prohlížeči toto url:
http://eagri.cz/public/app/wms/plpis_wfs.fcgi?VERSION=1.1.0SERVICE=WFSREQUEST=GetFeatureTYPENAME=LPIS_FB4featureID=LPIS_FB4.7883723SRSNAME=EPSG:102067
A případně mi poslat výstup? Mělo by to vypadat podobně jako na
obrázku.
Pokud atribut ms:kultura nevypadá takto: *ms:kulturaorná
půda/ms:kultura* Tak je to špatně a musíme zjistit, kde je problém.
V
traceru není, ten už dostane špatná data.
(je to ten příklad od Honzy níže, kdyby to chtěl někdo zkoumat).
Marián
Dne 16.8.2014 10:47, Jiří Parkan napsal(a):
Ahoj,
také jsem narážel na nějaké plochy kterým tracer nepřiřadil typ
plochy. Na
Třebíčsku to byla tak jedna z dvaceti.
Včera jsem mapoval kousek okolo Plzně-Božkova a tam byly bez typu
plochy
naprosto všechny polygony.
Parkis
2014-08-15 16:08 GMT+02:00 Marián Kyral mky...@email.cz:
Ahoj,
bohužel nemám kompletní seznam toho, co můžu lpis očekávat. Takže
někdy
to nezafunguje a je potřeba mi to nahlásit a já to doplním do
mapování.
Nicméně, u tého konkrétní cesty se mi doplní orná půda. Takže tím
to
není. Ale něco podobného jsem už viděl. Řešil jsem to s Honzou
Mladým. Do
odpovědi z WMS se nějakým záhadným způsobem dostaly podivné znaky.
Vždy se
vecpou na stejné místo a to, jestli se něco natrasuje správně nebo
ne
záleží jen na velikosti trasované plochy. Při určitém počtu uzlů se
ty
podivné znaky třefí právě do pole s kulturou a tracer pak nic
nenajde.
Ale proč se to děje netuším. U mně se tento problém nevyskytuje. A
Honza
je teď na dovolené, takže další zkoumání momentálně neprobíhá.
Marián
-- Původní zpráva --
Od: Jan Dudík jan.du...@gmail.com
Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org
Datum: 15. 8. 2014 15:14:44
Předmět: Re: [Talk-cz] Tracer - pLPIS
Díky, bylo to tím nastavením.
Ale narazil jsem na plochy v LPIS, kterým tracer přiřadí pouze ref a
source, žádné landuse.
asi 6 jich je na relativně malé ploše v katastru Plav:
http://www.openstreetmap.org/#map=16/48.9090/14.4976
např. http://www.openstreetmap.org/way/297894310
je to záměr nbeo chyba?
---
Ing. Jan Dudík
projekce dopravních staveb
tel. 777082195
Dne 11. srpna 2014 16:01 Martin Švec - OSM o...@maatts.cz
napsal(a):
Tím to nebude (pokud nechce klasický trasování katastrální mapy).
(1) V nastavení pluginu zaškrtnout moduly RUIAN a LPIS, odškrtnout
Klasický.
(2) Mačkat T a sledovat jak se mění kurzor myši, R = budovy z
RUIANu,
LP =
půda z LPISu.
Martin
Dne 11.8.2014 15:53, Michal Pustějovský napsal(a):
Máš spuštěný tracer server?
-- Původní zpráva --
Od: Jan Dudík jan.du...@gmail.com
Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org
Datum: 11. 8. 2014 14:45:35
Předmět: Re: [Talk-cz] Tracer - pLPIS
Dělám něco špatně?
stáhl jsem si tracer z [1], k němu v JOSM dva vyžadované doplňky,
na
pozadí si zapnul požadovanou vrstvu wms abych viděl co klikám.
spustím tracer, kliknu na budovu - aktualizuje se dle RUIAN
kliknu na plochu, kde je v LPIS vybarvená plocha - a nic
mačkáním T dosáhnu jediné změny, že se ani po kliku na budovu nic
nestane
[1] http://www.kyralovi.cz/tmp/josm/beta/lpis/Tracer.jar
JAnD
Dne 8. srpna 2014 21:04 Pavel Kwiecien pavel.kwiec...@seznam.cz
napsal(a):
Ahoj, trochu jsem si už s Tracerem zablbnul a už se mi to tady
pod
horama
zazelenalo
http://www.openstreetmap.org/#map=13/50.5706/15.7740
Pokud by spojování nebylo automatické, tak nemá smysl se tím
zabývat.
Tracer
funguje dobře, akorát import je potřeba vždy!! projet v JOSM
validací,
protože tracováním/vstupníma daty vzniká obrovské množství chyb a
varování.
Na dvě kliknutí se toho dá zbavit.
Ještě pro neznalé. Je dobré si v JOSM nastavit třeba tuto WMS
vrstvu:
http://eagri.cz/public/app/wms/plpis.fcgi?FORMAT=image/gifVERSION=1.1.1SERVICE=WMSREQUEST=GetMapLAYERS=LPIS_FB_KULSTYLES=SRS={proj}WIDTH={width}HEIGHT={height}BBOX={bbox}
aby bylo vidět, kde jsou LPIS data.
Re: [Talk-cz] Tracer - pLPIS
Tak jsem ještě koukal na tu exception. Můžeš zkusit přidat tento parametr?
-Dfile.encoding=UTF8
Možná to bude ono.
Marián
On 16. srpna 2014 19:09:30 CEST, Jiří Parkan jpar...@gmail.com wrote:
Ahoj,
výstup url přikládám (7883723.xml), letmým pohledem se mi zdá ok.
Pár příkladů lpis ID která nefungovala: 8570042, 9403951, 8570047
Jsou to políčka v téhle oblasti: http://osm.org/go/0JbF878yo--
Přikládám také uložené xml jednoho z nich (8570042.xml), v prohlížeči
se
taky zdá v pořádku.
Při trasování proběhne v konzoli JOSM chyba parsování xml a je tam
vidět
pomršená diakritika, viz obrázky. Možná je to ale jen chyba zobrazení v
konzoli, netuším.
Systém je Win7 home CZ.
Parkis
2014-08-16 18:42 GMT+02:00 Marián Kyral mky...@email.cz:
Ahoj,
pošli mi prosím konkrétní body. Mám takové podezření, že to je nějaký
problém s windows. Protože na linuxu to je bez problémů.
Můžete mi prosím všichni zkusit v prohlížeči toto url:
http://eagri.cz/public/app/wms/plpis_wfs.fcgi?VERSION=1.1.0SERVICE=WFSREQUEST=GetFeatureTYPENAME=LPIS_FB4featureID=LPIS_FB4.7883723SRSNAME=EPSG:102067
A případně mi poslat výstup? Mělo by to vypadat podobně jako na
obrázku.
Pokud atribut ms:kultura nevypadá takto: *ms:kulturaorná
půda/ms:kultura* Tak je to špatně a musíme zjistit, kde je problém.
V
traceru není, ten už dostane špatná data.
(je to ten příklad od Honzy níže, kdyby to chtěl někdo zkoumat).
Marián
Dne 16.8.2014 10:47, Jiří Parkan napsal(a):
Ahoj,
také jsem narážel na nějaké plochy kterým tracer nepřiřadil typ
plochy. Na
Třebíčsku to byla tak jedna z dvaceti.
Včera jsem mapoval kousek okolo Plzně-Božkova a tam byly bez typu
plochy
naprosto všechny polygony.
Parkis
2014-08-15 16:08 GMT+02:00 Marián Kyral mky...@email.cz:
Ahoj,
bohužel nemám kompletní seznam toho, co můžu lpis očekávat. Takže
někdy
to nezafunguje a je potřeba mi to nahlásit a já to doplním do
mapování.
Nicméně, u tého konkrétní cesty se mi doplní orná půda. Takže tím
to
není. Ale něco podobného jsem už viděl. Řešil jsem to s Honzou
Mladým. Do
odpovědi z WMS se nějakým záhadným způsobem dostaly podivné znaky.
Vždy se
vecpou na stejné místo a to, jestli se něco natrasuje správně nebo
ne
záleží jen na velikosti trasované plochy. Při určitém počtu uzlů se
ty
podivné znaky třefí právě do pole s kulturou a tracer pak nic
nenajde.
Ale proč se to děje netuším. U mně se tento problém nevyskytuje. A
Honza
je teď na dovolené, takže další zkoumání momentálně neprobíhá.
Marián
-- Původní zpráva --
Od: Jan Dudík jan.du...@gmail.com
Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org
Datum: 15. 8. 2014 15:14:44
Předmět: Re: [Talk-cz] Tracer - pLPIS
Díky, bylo to tím nastavením.
Ale narazil jsem na plochy v LPIS, kterým tracer přiřadí pouze ref a
source, žádné landuse.
asi 6 jich je na relativně malé ploše v katastru Plav:
http://www.openstreetmap.org/#map=16/48.9090/14.4976
např. http://www.openstreetmap.org/way/297894310
je to záměr nbeo chyba?
---
Ing. Jan Dudík
projekce dopravních staveb
tel. 777082195
Dne 11. srpna 2014 16:01 Martin Švec - OSM o...@maatts.cz
napsal(a):
Tím to nebude (pokud nechce klasický trasování katastrální mapy).
(1) V nastavení pluginu zaškrtnout moduly RUIAN a LPIS, odškrtnout
Klasický.
(2) Mačkat T a sledovat jak se mění kurzor myši, R = budovy z
RUIANu,
LP =
půda z LPISu.
Martin
Dne 11.8.2014 15:53, Michal Pustějovský napsal(a):
Máš spuštěný tracer server?
-- Původní zpráva --
Od: Jan Dudík jan.du...@gmail.com
Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org
Datum: 11. 8. 2014 14:45:35
Předmět: Re: [Talk-cz] Tracer - pLPIS
Dělám něco špatně?
stáhl jsem si tracer z [1], k němu v JOSM dva vyžadované doplňky,
na
pozadí si zapnul požadovanou vrstvu wms abych viděl co klikám.
spustím tracer, kliknu na budovu - aktualizuje se dle RUIAN
kliknu na plochu, kde je v LPIS vybarvená plocha - a nic
mačkáním T dosáhnu jediné změny, že se ani po kliku na budovu nic
nestane
[1] http://www.kyralovi.cz/tmp/josm/beta/lpis/Tracer.jar
JAnD
Dne 8. srpna 2014 21:04 Pavel Kwiecien pavel.kwiec...@seznam.cz
napsal(a):
Ahoj, trochu jsem si už s Tracerem zablbnul a už se mi to tady
pod
horama
zazelenalo
http://www.openstreetmap.org/#map=13/50.5706/15.7740
Pokud by spojování nebylo automatické, tak nemá smysl se tím
zabývat.
Tracer
funguje dobře, akorát import je potřeba vždy!! projet v JOSM
validací,
protože tracováním/vstupníma daty vzniká obrovské množství chyb a
varování.
Na dvě kliknutí se toho dá zbavit.
Ještě pro neznalé. Je dobré si v JOSM nastavit třeba tuto WMS
vrstvu:
http://eagri.cz/public/app/wms/plpis.fcgi?FORMAT=image/gifVERSION=1.1.1SERVICE=WMSREQUEST=GetMapLAYERS=LPIS_FB_KULSTYLES=SRS={proj}WIDTH={width}HEIGHT={height}BBOX={bbox}
aby bylo vidět, kde jsou LPIS data.
Zdraví Pavel Kwiecien
-- Původní zpráva --
Od:
Re: [Talk-cz] Tracer - pLPIS
Bingo! s tímhle parametrem už to funguje, přidám si ho do spouštěcí dávky. Díky! 2014-08-16 21:43 GMT+02:00 Marián Kyral mky...@email.cz: Tak jsem ještě koukal na tu exception. Můžeš zkusit přidat tento parametr? -Dfile.encoding=UTF8 Možná to bude ono. Marián On 16. srpna 2014 19:09:30 CEST, Jiří Parkan jpar...@gmail.com wrote: Ahoj, výstup url přikládám (7883723.xml), letmým pohledem se mi zdá ok. Pár příkladů lpis ID která nefungovala: 8570042, 9403951, 8570047 Jsou to políčka v téhle oblasti: http://osm.org/go/0JbF878yo-- Přikládám také uložené xml jednoho z nich (8570042.xml), v prohlížeči se taky zdá v pořádku. Při trasování proběhne v konzoli JOSM chyba parsování xml a je tam vidět pomršená diakritika, viz obrázky. Možná je to ale jen chyba zobrazení v konzoli, netuším. Systém je Win7 home CZ. Parkis 2014-08-16 18:42 GMT+02:00 Marián Kyral mky...@email.cz: Ahoj, pošli mi prosím konkrétní body. Mám takové podezření, že to je nějaký problém s windows. Protože na linuxu to je bez problémů. Můžete mi prosím všichni zkusit v prohlížeči toto url: http://eagri.cz/public/app/wms/plpis_wfs.fcgi?VERSION=1.1.0SERVICE=WFSREQUEST=GetFeatureTYPENAME=LPIS_FB4featureID=LPIS_FB4.7883723SRSNAME=EPSG:102067 A případně mi poslat výstup? Mělo by to vypadat podobně jako na obrázku. Pokud atribut ms:kultura nevypadá takto: *ms:kulturaorná půda/ms:kultura* Tak je to špatně a musíme zjistit, kde je problém. V traceru není, ten už dostane špatná data. (je to ten příklad od Honzy níže, kdyby to chtěl někdo zkoumat). Marián Dne 16.8.2014 10:47, Jiří Parkan napsal(a): Ahoj, také jsem narážel na nějaké plochy kterým tracer nepřiřadil typ plochy. Na Třebíčsku to byla tak jedna z dvaceti. Včera jsem mapoval kousek okolo Plzně-Božkova a tam byly bez typu plochy naprosto všechny polygony. Parkis 2014-08-15 16:08 GMT+02:00 Marián Kyral mky...@email.cz: Ahoj, bohužel nemám kompletní seznam toho, co můžu lpis očekávat. Takže někdy to nezafunguje a je potřeba mi to nahlásit a já to doplním do mapování. Nicméně, u tého konkrétní cesty se mi doplní orná půda. Takže tím to není. Ale něco podobného jsem už viděl. Řešil jsem to s Honzou Mladým. Do odpovědi z WMS se nějakým záhadným způsobem dostaly podivné znaky. Vždy se vecpou na stejné místo a to, jestli se něco natrasuje správně nebo ne záleží jen na velikosti trasované plochy. Při určitém počtu uzlů se ty podivné znaky třefí právě do pole s kulturou a tracer pak nic nenajde. Ale proč se to děje netuším. U mně se tento problém nevyskytuje. A Honza je teď na dovolené, takže další zkoumání momentálně neprobíhá. Marián -- Původní zpráva -- Od: Jan Dudík jan.du...@gmail.com Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 15. 8. 2014 15:14:44 Předmět: Re: [Talk-cz] Tracer - pLPIS Díky, bylo to tím nastavením. Ale narazil jsem na plochy v LPIS, kterým tracer přiřadí pouze ref a source, žádné landuse. asi 6 jich je na relativně malé ploše v katastru Plav: http://www.openstreetmap.org/#map=16/48.9090/14.4976 např. http://www.openstreetmap.org/way/297894310 je to záměr nbeo chyba? --- Ing. Jan Dudík projekce dopravních staveb tel. 777082195 Dne 11. srpna 2014 16:01 Martin Švec - OSM o...@maatts.cz napsal(a): Tím to nebude (pokud nechce klasický trasování katastrální mapy). (1) V nastavení pluginu zaškrtnout moduly RUIAN a LPIS, odškrtnout Klasický. (2) Mačkat T a sledovat jak se mění kurzor myši, R = budovy z RUIANu, LP = půda z LPISu. Martin Dne 11.8.2014 15:53, Michal Pustějovský napsal(a): Máš spuštěný tracer server? -- Původní zpráva -- Od: Jan Dudík jan.du...@gmail.com Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 11. 8. 2014 14:45:35 Předmět: Re: [Talk-cz] Tracer - pLPIS Dělám něco špatně? stáhl jsem si tracer z [1], k němu v JOSM dva vyžadované doplňky, na pozadí si zapnul požadovanou vrstvu wms abych viděl co klikám. spustím tracer, kliknu na budovu - aktualizuje se dle RUIAN kliknu na plochu, kde je v LPIS vybarvená plocha - a nic mačkáním T dosáhnu jediné změny, že se ani po kliku na budovu nic nestane [1] http://www.kyralovi.cz/tmp/josm/beta/lpis/Tracer.jar JAnD Dne 8. srpna 2014 21:04 Pavel Kwiecien pavel.kwiec...@seznam.cz napsal(a): Ahoj, trochu jsem si už s Tracerem zablbnul a už se mi to tady pod horama zazelenalo http://www.openstreetmap.org/#map=13/50.5706/15.7740 Pokud by spojování nebylo automatické, tak nemá smysl se tím zabývat. Tracer funguje dobře, akorát import je potřeba vždy!! projet v JOSM validací, protože tracováním/vstupníma daty vzniká obrovské množství chyb a varování. Na dvě kliknutí se toho dá zbavit. Ještě pro neznalé. Je dobré si v JOSM nastavit třeba tuto WMS vrstvu:
Re: [Talk-cz] Tracer - pLPIS
On 16.8.2014 19:09, Jiří Parkan wrote: Ahoj, výstup url přikládám (7883723.xml), letmým pohledem se mi zdá ok. Pár příkladů lpis ID která nefungovala: 8570042, 9403951, 8570047 Jsou to políčka v téhle oblasti: http://osm.org/go/0JbF878yo-- Přikládám také uložené xml jednoho z nich (8570042.xml), v prohlížeči se taky zdá v pořádku. Při trasování proběhne v konzoli JOSM chyba parsování xml a je tam vidět pomršená diakritika, viz obrázky. Možná je to ale jen chyba zobrazení v konzoli, netuším. Systém je Win7 home CZ. Parkis 2014-08-16 18:42 GMT+02:00 Marián Kyral mky...@email.cz mailto:mky...@email.cz: Ahoj, pošli mi prosím konkrétní body. Mám takové podezření, že to je nějaký problém s windows. Protože na linuxu to je bez problémů. Můžete mi prosím všichni zkusit v prohlížeči toto url: http://eagri.cz/public/app/wms/plpis_wfs.fcgi?VERSION=1.1.0SERVICE=WFSREQUEST=GetFeatureTYPENAME=LPIS_FB4featureID=LPIS_FB4.7883723SRSNAME=EPSG:102067 A případně mi poslat výstup? Mělo by to vypadat podobně jako na obrázku. Pokud atribut ms:kultura nevypadá takto: *ms:kulturaorná půda/ms:kultura* Tak je to špatně a musíme zjistit, kde je problém. V traceru není, ten už dostane špatná data. (je to ten příklad od Honzy níže, kdyby to chtěl někdo zkoumat). Marián Dne 16.8.2014 10:47, Jiří Parkan napsal(a): Ahoj, také jsem narážel na nějaké plochy kterým tracer nepřiřadil typ plochy. Na Třebíčsku to byla tak jedna z dvaceti. Včera jsem mapoval kousek okolo Plzně-Božkova a tam byly bez typu plochy naprosto všechny polygony. Parkis 2014-08-15 16:08 GMT+02:00 Marián Kyral mky...@email.cz mailto:mky...@email.cz: Ahoj, bohužel nemám kompletní seznam toho, co můžu lpis očekávat. Takže někdy to nezafunguje a je potřeba mi to nahlásit a já to doplním do mapování. Nicméně, u tého konkrétní cesty se mi doplní orná půda. Takže tím to není. Ale něco podobného jsem už viděl. Řešil jsem to s Honzou Mladým. Do odpovědi z WMS se nějakým záhadným způsobem dostaly podivné znaky. Vždy se vecpou na stejné místo a to, jestli se něco natrasuje správně nebo ne záleží jen na velikosti trasované plochy. Při určitém počtu uzlů se ty podivné znaky třefí právě do pole s kulturou a tracer pak nic nenajde. Ale proč se to děje netuším. U mně se tento problém nevyskytuje. A Honza je teď na dovolené, takže další zkoumání momentálně neprobíhá. Marián -- Původní zpráva -- Od: Jan Dudík jan.du...@gmail.com mailto:jan.du...@gmail.com Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org mailto:talk-cz@openstreetmap.org Datum: 15. 8. 2014 15:14:44 Předmět: Re: [Talk-cz] Tracer - pLPIS Díky, bylo to tím nastavením. Ale narazil jsem na plochy v LPIS, kterým tracer přiřadí pouze ref a source, žádné landuse. asi 6 jich je na relativně malé ploše v katastru Plav: http://www.openstreetmap.org/#map=16/48.9090/14.4976 např. http://www.openstreetmap.org/way/297894310 tel:297894310 je to záměr nbeo chyba? --- Ing. Jan Dudík projekce dopravních staveb tel. 777082195 tel:777082195 Dne 11. srpna 2014 16:01 Martin Švec - OSM o...@maatts.cz mailto:o...@maatts.cz napsal(a): Tím to nebude (pokud nechce klasický trasování katastrální mapy). (1) V nastavení pluginu zaškrtnout moduly RUIAN a LPIS, odškrtnout Klasický. (2) Mačkat T a sledovat jak se mění kurzor myši, R = budovy z RUIANu, LP = půda z LPISu. Martin Dne 11.8.2014 15:53, Michal Pustějovský napsal(a): Máš spuštěný tracer server? -- Původní zpráva -- Od: Jan Dudík jan.du...@gmail.com mailto:jan.du...@gmail.com Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org mailto:talk-cz@openstreetmap.org Datum: 11. 8. 2014 14:45:35 Předmět: Re: [Talk-cz] Tracer - pLPIS Dělám něco špatně? stáhl jsem si tracer z [1], k němu v JOSM dva vyžadované doplňky, na pozadí si zapnul požadovanou vrstvu wms abych viděl co klikám. spustím tracer, kliknu na budovu - aktualizuje se dle RUIAN kliknu na plochu, kde je v LPIS vybarvená plocha - a nic mačkáním T dosáhnu jediné změny, že se ani po kliku na budovu nic nestane [1] http://www.kyralovi.cz/tmp/josm/beta/lpis/Tracer.jar
[OSM-talk-fr] Corruption des noms par Osmose (troncation sur guillemets ASCII, espaces surnuméraire)
Certaines correction proposées par Osmose sont complètement erronées,
particulièrement celles concernant les espaces surnuméraires.
Je me suis aperçu en consultant les historiques de certains objets que
ceux-ci était nommés par exemple (je met le tout entre accolades ici pour
que ce soit plus clair):
{name=École publique maternelle XYZ}
Oui, avec des guillemets ASCII autour du nom qui suit une désignation
générique.
Le problème est qu'Osmose ne détecte pas correctement ces guillemets ASCII
dans le nom (ils sont pourtant stockés et correctement encodés en XML), et
en fait va tronquer la chaîne au premier guillemet pour obtenir:
{name=École publique maternelle }
Et Osmose alors proteste en disant Espace surnuméraire à la fin. On se
retrouve même dans certains cas avec :
{name=}
ou (dans les cas où Osmoe a déjà supprimé la désignation générique avant le
nom entre guillemets)
{name= }
Et Osmose alors propose de supprimer totalement la clé qui pourtant
contenait un nom (qui a pu disparaître plusieurs modifs aurparvant dans
Osmose qui a déjà fait a troncature erronée).
Si on accepte la correction proposée par Osmose sans regarder le contenu
original (visible non pas dans l'éditeur à droite mais dans l'info-bulle à
gauche), les mots importants entre guillemets disparaissent, et il ne reste
plus que la désignation générique.
Bref BOGUE, à corriger d'urgence car cela aboutit à des suppressions
intempestives d'informations !
NOTE: Osmose devrait afficher dans son éditeur le nom original avant la
modif proposée, pour faciliter les comparaisons. Il ne ne fait plus avec
son nouvel éditeur. Danger !
Osmose devrait plutôt suggérer d'abord de supprimer ces guillemets ASCII ou
proposer une correction les rempleçant par des « guillemets français »
voire des “guillemets courbes” (ce qui élimine les problèmes de syntaxe en
XML dans les datas au format OSM ou dans les requêtes de recherche, qui
utilisent déjà des guillemets ASCII comme délimiteur de chaînes).
Et ensuite seulement il peut rechercher les espaces surnuméraires
(attention aux guillemets françaus qui incluent normalement une espace fine
U+203F à l'intérieur, mais ce caractère étant difficile à sasir au clavier,
la plupart du temps on utilise l'espace insécable U+00A0=nbsp; voire juste
une espace normale U+0020 qui sera contextuellement remplacé au rendu par
une espace fine insécable quand ils sont accolés aux guillemets français)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Corruption des noms par Osmose (troncation sur guillemets ASCII, espaces surnuméraire)
Exemple de corruption causée par Osmose:
http://www.openstreetmap.org/node/1110246018/history
Le 16 août 2014 10:17, Philippe Verdy verd...@wanadoo.fr a écrit :
Certaines correction proposées par Osmose sont complètement erronées,
particulièrement celles concernant les espaces surnuméraires.
Je me suis aperçu en consultant les historiques de certains objets que
ceux-ci était nommés par exemple (je met le tout entre accolades ici pour
que ce soit plus clair):
{name=École publique maternelle XYZ}
Oui, avec des guillemets ASCII autour du nom qui suit une désignation
générique.
Le problème est qu'Osmose ne détecte pas correctement ces guillemets ASCII
dans le nom (ils sont pourtant stockés et correctement encodés en XML), et
en fait va tronquer la chaîne au premier guillemet pour obtenir:
{name=École publique maternelle }
Et Osmose alors proteste en disant Espace surnuméraire à la fin. On se
retrouve même dans certains cas avec :
{name=}
ou (dans les cas où Osmoe a déjà supprimé la désignation générique avant
le nom entre guillemets)
{name= }
Et Osmose alors propose de supprimer totalement la clé qui pourtant
contenait un nom (qui a pu disparaître plusieurs modifs aurparvant dans
Osmose qui a déjà fait a troncature erronée).
Si on accepte la correction proposée par Osmose sans regarder le contenu
original (visible non pas dans l'éditeur à droite mais dans l'info-bulle à
gauche), les mots importants entre guillemets disparaissent, et il ne reste
plus que la désignation générique.
Bref BOGUE, à corriger d'urgence car cela aboutit à des suppressions
intempestives d'informations !
NOTE: Osmose devrait afficher dans son éditeur le nom original avant la
modif proposée, pour faciliter les comparaisons. Il ne ne fait plus avec
son nouvel éditeur. Danger !
Osmose devrait plutôt suggérer d'abord de supprimer ces guillemets ASCII
ou proposer une correction les rempleçant par des « guillemets français »
voire des “guillemets courbes” (ce qui élimine les problèmes de syntaxe en
XML dans les datas au format OSM ou dans les requêtes de recherche, qui
utilisent déjà des guillemets ASCII comme délimiteur de chaînes).
Et ensuite seulement il peut rechercher les espaces surnuméraires
(attention aux guillemets françaus qui incluent normalement une espace fine
U+203F à l'intérieur, mais ce caractère étant difficile à sasir au clavier,
la plupart du temps on utilise l'espace insécable U+00A0=nbsp; voire juste
une espace normale U+0020 qui sera contextuellement remplacé au rendu par
une espace fine insécable quand ils sont accolés aux guillemets français)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] JOSM et son scan de disque - J'en ai ma claque !!!
Avé tout le monde, Depuis que je suis passé sous JOSM java7, j'ai remarqué que le logiciel se met à scanner mon disque dur pendant des minutes et des minutes peu après son lancement. C'est systématique. Ça ralentit le PC et ça fait mouliner le disque dur. Dans quel but ? A la longue, cela devient franchement irritant ! Je voudrais savoir pourquoi ce logiciel scanne mon disque et ce qu'il scanne exactement pour que cela dure aussi longtemps. Il lit et écrit sur le disque. Sans compter l'antivirus, par derrière, qui intercepte les données (écrites certainement) et qui consomme encore plus de CPU. Si je quitte JOSM, l'activité disque s'arrête aussitôt. Y a-t-il une option pour faire cesser cela ? Avez-vous aussi ce problème ? Merci. @+ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] JOSM et son scan de disque - J'en ai ma claque !!!
Le 16/08/2014 10:47, Lapinos03 a écrit : Avé tout le monde, Depuis que je suis passé sous JOSM java7, j'ai remarqué que le logiciel se met à scanner mon disque dur pendant des minutes et des minutes peu après son lancement. C'est systématique. Ça ralentit le PC et ça fait mouliner le disque dur. Dans quel but ? A la longue, cela devient franchement irritant ! Je voudrais savoir pourquoi ce logiciel scanne mon disque et ce qu'il scanne exactement pour que cela dure aussi longtemps. Il lit et écrit sur le disque. Sans compter l'antivirus, par derrière, qui intercepte les données (écrites certainement) et qui consomme encore plus de CPU. Si je quitte JOSM, l'activité disque s'arrête aussitôt. Y a-t-il une option pour faire cesser cela ? Avez-vous aussi ce problème ? Vu que tu parles d'antivirus, j'en conclus que tu es sous Winbloat. L'option pour faire cesser ce problème est de passer à GNU/Linux. Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Corruption des noms par Osmose (troncation sur guillemets ASCII, espaces surnuméraire)
J'ai du mal à suivre l'historique : elle s'appelle «La Caravelle » ou «Le
Centaure», cette école ?
Art.
Le 16 août 2014 10:27, Philippe Verdy verd...@wanadoo.fr a écrit :
Exemple de corruption causée par Osmose:
http://www.openstreetmap.org/node/1110246018/history
Le 16 août 2014 10:17, Philippe Verdy verd...@wanadoo.fr a écrit :
Certaines correction proposées par Osmose sont complètement erronées,
particulièrement celles concernant les espaces surnuméraires.
Je me suis aperçu en consultant les historiques de certains objets que
ceux-ci était nommés par exemple (je met le tout entre accolades ici pour
que ce soit plus clair):
{name=École publique maternelle XYZ}
Oui, avec des guillemets ASCII autour du nom qui suit une désignation
générique.
Le problème est qu'Osmose ne détecte pas correctement ces guillemets
ASCII dans le nom (ils sont pourtant stockés et correctement encodés en
XML), et en fait va tronquer la chaîne au premier guillemet pour obtenir:
{name=École publique maternelle }
Et Osmose alors proteste en disant Espace surnuméraire à la fin. On se
retrouve même dans certains cas avec :
{name=}
ou (dans les cas où Osmoe a déjà supprimé la désignation générique avant
le nom entre guillemets)
{name= }
Et Osmose alors propose de supprimer totalement la clé qui pourtant
contenait un nom (qui a pu disparaître plusieurs modifs aurparvant dans
Osmose qui a déjà fait a troncature erronée).
Si on accepte la correction proposée par Osmose sans regarder le
contenu original (visible non pas dans l'éditeur à droite mais dans
l'info-bulle à gauche), les mots importants entre guillemets disparaissent,
et il ne reste plus que la désignation générique.
Bref BOGUE, à corriger d'urgence car cela aboutit à des suppressions
intempestives d'informations !
NOTE: Osmose devrait afficher dans son éditeur le nom original avant la
modif proposée, pour faciliter les comparaisons. Il ne ne fait plus avec
son nouvel éditeur. Danger !
Osmose devrait plutôt suggérer d'abord de supprimer ces guillemets ASCII
ou proposer une correction les rempleçant par des « guillemets français »
voire des “guillemets courbes” (ce qui élimine les problèmes de syntaxe en
XML dans les datas au format OSM ou dans les requêtes de recherche, qui
utilisent déjà des guillemets ASCII comme délimiteur de chaînes).
Et ensuite seulement il peut rechercher les espaces surnuméraires
(attention aux guillemets françaus qui incluent normalement une espace fine
U+203F à l'intérieur, mais ce caractère étant difficile à sasir au clavier,
la plupart du temps on utilise l'espace insécable U+00A0=nbsp; voire juste
une espace normale U+0020 qui sera contextuellement remplacé au rendu par
une espace fine insécable quand ils sont accolés aux guillemets français)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] JOSM et son scan de disque - J'en ai ma claque !!!
Christophe Merlet red...@redfoxcenter.org wrote: Vu que tu parles d'antivirus, j'en conclus que tu es sous Winbloat. L'option pour faire cesser ce problème est de passer à GNU/Linux. Euh... je suis pas sur du rapport... Sauf a laisser entendre que c'est autrechose que JOSM qui scanne le disque. De mon coté je suis resté avec java6 et sur MacOS X (je sais c'est mal aussi) mais ça marche bien. -- Pierre-Alain Dorange OSM experiences : http://www.leretourdelautruche.com/map/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Corruption des noms par Osmose (troncation sur guillemets ASCII, espaces surnuméraire)
Elle s'appelle le Centaure, La Caravelle je ne sais pas d'où ça vient mais
je n'ai pas saisi ça dans Osmose qui s'est planté tout seul quand il a vu
des guillemets à nouveau. Du coup j'ai corrigé dans iD (sans les
guillemets).
Le 16 août 2014 11:11, Art Penteur art.pent...@gmail.com a écrit :
J'ai du mal à suivre l'historique : elle s'appelle «La Caravelle » ou «Le
Centaure», cette école ?
Art.
Le 16 août 2014 10:27, Philippe Verdy verd...@wanadoo.fr a écrit :
Exemple de corruption causée par Osmose:
http://www.openstreetmap.org/node/1110246018/history
Le 16 août 2014 10:17, Philippe Verdy verd...@wanadoo.fr a écrit :
Certaines correction proposées par Osmose sont complètement erronées,
particulièrement celles concernant les espaces surnuméraires.
Je me suis aperçu en consultant les historiques de certains objets que
ceux-ci était nommés par exemple (je met le tout entre accolades ici pour
que ce soit plus clair):
{name=École publique maternelle XYZ}
Oui, avec des guillemets ASCII autour du nom qui suit une désignation
générique.
Le problème est qu'Osmose ne détecte pas correctement ces guillemets
ASCII dans le nom (ils sont pourtant stockés et correctement encodés en
XML), et en fait va tronquer la chaîne au premier guillemet pour obtenir:
{name=École publique maternelle }
Et Osmose alors proteste en disant Espace surnuméraire à la fin. On se
retrouve même dans certains cas avec :
{name=}
ou (dans les cas où Osmoe a déjà supprimé la désignation générique avant
le nom entre guillemets)
{name= }
Et Osmose alors propose de supprimer totalement la clé qui pourtant
contenait un nom (qui a pu disparaître plusieurs modifs aurparvant dans
Osmose qui a déjà fait a troncature erronée).
Si on accepte la correction proposée par Osmose sans regarder le
contenu original (visible non pas dans l'éditeur à droite mais dans
l'info-bulle à gauche), les mots importants entre guillemets disparaissent,
et il ne reste plus que la désignation générique.
Bref BOGUE, à corriger d'urgence car cela aboutit à des suppressions
intempestives d'informations !
NOTE: Osmose devrait afficher dans son éditeur le nom original avant la
modif proposée, pour faciliter les comparaisons. Il ne ne fait plus avec
son nouvel éditeur. Danger !
Osmose devrait plutôt suggérer d'abord de supprimer ces guillemets ASCII
ou proposer une correction les rempleçant par des « guillemets français »
voire des “guillemets courbes” (ce qui élimine les problèmes de syntaxe en
XML dans les datas au format OSM ou dans les requêtes de recherche, qui
utilisent déjà des guillemets ASCII comme délimiteur de chaînes).
Et ensuite seulement il peut rechercher les espaces surnuméraires
(attention aux guillemets françaus qui incluent normalement une espace fine
U+203F à l'intérieur, mais ce caractère étant difficile à sasir au clavier,
la plupart du temps on utilise l'espace insécable U+00A0=nbsp; voire juste
une espace normale U+0020 qui sera contextuellement remplacé au rendu par
une espace fine insécable quand ils sont accolés aux guillemets français)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] JOSM et son scan de disque - J'en ai ma claque !!!
Le 16/08/2014 11:28, Pierre-Alain Dorange a écrit : Christophe Merlet red...@redfoxcenter.org wrote: Vu que tu parles d'antivirus, j'en conclus que tu es sous Winbloat. L'option pour faire cesser ce problème est de passer à GNU/Linux. Euh... je suis pas sur du rapport... Sauf a laisser entendre que c'est autrechose que JOSM qui scanne le disque. Il aurait été irresponsable de lui dire de supprimer son(ses) antivirus. De mon coté je suis resté avec java6 et sur MacOS X (je sais c'est mal aussi) mais ça marche bien. Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] JOSM et son scan de disque - J'en ai ma claque !!!
Je n'ai strictement aucun problème avec Java7 que j'utilisse depuis longtemps pour JOSM sous Win7. Cependant je ne l'utilise PAS en version 32bits mais 64bits. le compilateur Hotspot ClientVM Java7 32 bits est une vraie daube. Je n'utilise QUE la version serveur qui est très stable, très rapide; ne swappe pas à répétition. La version 32 bits a été optimisée pour des installations sur de très petits appareils mais n'est définitivement plsu faire pour une appli comme JOSM qui traite un grand volume de données en mémoire (il est courant que j'ai plusieurs millions d'objets chargés, impossible de travailler correctement avec la VM 32 bits). Elle passe tout son temp à créer des threads de nettoyage mémoire et c'est son pool de threads qui grossit de façon inconsidérée dans JOSM. Passe en Java 64 bits et c'est réglé ! Pour ça il suffit de modifier le lien créé sur ton bureau ou dans un menu démarrer: C:\Windows\System32\javaws.exe -J-d64 -Xmx2048M -localfile -J-Djnlp.application.href= https://josm.openstreetmap.de/download/josm-latest.jnlp C:\Users\Philippe\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\31\583aa85f-13b77784 En gros j'ai ajouté -J-d64 pour utiliser la VM Server 64 bits au lieu de la VM Hotspot 32 bits, et -Xmx2048M pour passer à 2 Go de RAM, j'ai laissé l'emplacement du cache JNLP d'où je lance JOSM (qui se met à jour alors tout seul au lancement vers la version latest). Le 16 août 2014 10:47, Lapinos03 lapino...@free.fr a écrit : Avé tout le monde, Depuis que je suis passé sous JOSM java7, j'ai remarqué que le logiciel se met à scanner mon disque dur pendant des minutes et des minutes peu après son lancement. C'est systématique. Ça ralentit le PC et ça fait mouliner le disque dur. Dans quel but ? A la longue, cela devient franchement irritant ! Je voudrais savoir pourquoi ce logiciel scanne mon disque et ce qu'il scanne exactement pour que cela dure aussi longtemps. Il lit et écrit sur le disque. Sans compter l'antivirus, par derrière, qui intercepte les données (écrites certainement) et qui consomme encore plus de CPU. Si je quitte JOSM, l'activité disque s'arrête aussitôt. Y a-t-il une option pour faire cesser cela ? Avez-vous aussi ce problème ? Merci. @+ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] JOSM et son scan de disque - J'en ai ma claque !!!
Le 16/08/2014 11:55, Philippe Verdy a écrit : Je n'ai strictement aucun problème avec Java7 que j'utilisse depuis longtemps pour JOSM sous Win7. Cependant je ne l'utilise PAS en version 32bits mais 64bits. le compilateur Hotspot ClientVM Java7 32 bits est une vraie daube. Je n'utilise QUE la version serveur qui est très stable, très rapide; ne swappe pas à répétition. La version 32 bits a été optimisée pour des installations sur de très petits appareils mais n'est définitivement plsu faire pour une appli comme JOSM qui traite un grand volume de données en mémoire (il est courant que j'ai plusieurs millions d'objets chargés, impossible de Plusieurs millions d'objets chargés ??? Rien que ça !! Tu peux nous faire une capture d'écran de JOSM avec la petite fenêtre d'informations du calque ? Je demande à voir ! Et n'hésite pas a nous expliquer pourquoi tu dois bosser avec des volumes de données aussi gigantesque à la fois... et aussi comment tu fais pour tenir à jour ces données. travailler correctement avec la VM 32 bits). Elle passe tout son temp à créer des threads de nettoyage mémoire et c'est son pool de threads qui grossit de façon inconsidérée dans JOSM. Passe en Java 64 bits et c'est réglé ! Pour ça il suffit de modifier le lien créé sur ton bureau ou dans un menu démarrer: C:\Windows\System32\javaws.exe -J-d64 -Xmx2048M -localfile -J-Djnlp.application.href=https://josm.openstreetmap.de/download/josm-latest.jnlp C:\Users\Philippe\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\31\583aa85f-13b77784 En gros j'ai ajouté -J-d64 pour utiliser la VM Server 64 bits au lieu de la VM Hotspot 32 bits, et -Xmx2048M pour passer à 2 Go de RAM, j'ai laissé l'emplacement du cache JNLP d'où je lance JOSM (qui se met à jour alors tout seul au lancement vers la version latest). Le 16 août 2014 10:47, Lapinos03 lapino...@free.fr mailto:lapino...@free.fr a écrit : Avé tout le monde, Depuis que je suis passé sous JOSM java7, j'ai remarqué que le logiciel se met à scanner mon disque dur pendant des minutes et des minutes peu après son lancement. C'est systématique. Ça ralentit le PC et ça fait mouliner le disque dur. Dans quel but ? A la longue, cela devient franchement irritant ! Je voudrais savoir pourquoi ce logiciel scanne mon disque et ce qu'il scanne exactement pour que cela dure aussi longtemps. Il lit et écrit sur le disque. Sans compter l'antivirus, par derrière, qui intercepte les données (écrites certainement) et qui consomme encore plus de CPU. Si je quitte JOSM, l'activité disque s'arrête aussitôt. Y a-t-il une option pour faire cesser cela ? Avez-vous aussi ce problème ? Merci. @+ _ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org https://lists.openstreetmap.__org/listinfo/talk-fr https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] JOSM et son scan de disque - J'en ai ma claque !!!
Tout à fait d'accord, d'ailleurs jai un antivirus aussi et ça n'empêche pas JOSM de très bien fonctionner sur Java 7 (en fait j'utlise déjà Java 8). ll serait temps qu'Oracle arrête d'installer par défaut la version 32 bits sur un système 64 bits (ou bien n'installe la version 32 bits que pour les applets affichées dans un navigateur web 32 bits. Cette version 32 bits est beaucoup trop limitée et l'est encore plus depuis qu'elle a été modifiée pour fonctionner aussi sur des mobiles (mais juste pour exécuter de petites applets web. Et je me demande pourquoi un navigateur 32 bits ne pourrait pas instancier une micro-applet 32bits utilisant une VM proxy où l'application tourne en fait dans une VM 64 bits. La VM 32 bits de toute façon manque tout de suite de mémoire avec sa limite à 256Mo qu'on atteint beaucoup trop vite dans JOSM (du coup le garbage collector prend l'essentiel du temps, il swappe et les weak references sont effacées sans arrˆt, on perd les objets préconstruits en cache, et JOSM est sans arrêt en train de faire appel aux constructeurs d'objets). C'est vrai toutefois que JOSM n'est pas économique en création d'objets temporaires : il utilise trop abondamment l'allocateur mémoire pour tout (et toutes les 5 minutes il génère un fichier XML de sauvegarde automatique de la totlaité de ce qui est en mémoire, ce qui fait appel à plein de convertisseurs de type pour allour des fragments de chaines temporaires, et il gère pas très bien son allocateur de tampon de travail en mémoire. Cequi ralentit énormément aussi dans la version 32 bits est que même le code précompilé doit être recompilé sans arrêt car il passe à la trappe dès que ça commence à swapper. JOSM utilisant de très nombreux threads on a des swaps dique même sur leur pile de paramètres. JOSM n'est utilisable en 32 bits que pour des modifs très locales et chargeant peu de données (ajouts de POis par exemple), bref guère mieux que ce que fait iD en ligne (qui rame lui aussi même sur un PC octocoeur avec 64 Go de RAM...). Le 16 août 2014 11:52, Christophe Merlet red...@redfoxcenter.org a écrit : Le 16/08/2014 11:28, Pierre-Alain Dorange a écrit : Christophe Merlet red...@redfoxcenter.org wrote: Vu que tu parles d'antivirus, j'en conclus que tu es sous Winbloat. L'option pour faire cesser ce problème est de passer à GNU/Linux. Euh... je suis pas sur du rapport... Sauf a laisser entendre que c'est autrechose que JOSM qui scanne le disque. Il aurait été irresponsable de lui dire de supprimer son(ses) antivirus. De mon coté je suis resté avec java6 et sur MacOS X (je sais c'est mal aussi) mais ça marche bien. Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] JOSM et son scan de disque - J'en ai ma claque !!!
Le 16 août 2014 12:07, Christophe Merlet red...@redfoxcenter.org a écrit : Le 16/08/2014 11:55, Philippe Verdy a écrit : Je n'ai strictement aucun problème avec Java7 que j'utilisse depuis longtemps pour JOSM sous Win7. Cependant je ne l'utilise PAS en version 32bits mais 64bits. le compilateur Hotspot ClientVM Java7 32 bits est une vraie daube. Je n'utilise QUE la version serveur qui est très stable, très rapide; ne swappe pas à répétition. La version 32 bits a été optimisée pour des installations sur de très petits appareils mais n'est définitivement plsu faire pour une appli comme JOSM qui traite un grand volume de données en mémoire (il est courant que j'ai plusieurs millions d'objets chargés, impossible de Plusieurs millions d'objets chargés ??? Rien que ça !! Pas en permanence, j'ai dit couramment). Mais en moyenne c'est souvent plus de 400 000 objets et de toute façon des millions de tags. Et la taille de VM est en permanence au dessus de 500Mo (donc déjà au delà des 256Mo de la version 32 bits). Pour la plus petite modif en cours j'ai par exemple (en appuyant sur cfgm dans la console: Java Web Start 11.5.2.13 Utilisation de la version JRE 1.8.0_05-b13 Java HotSpot(TM) 64-Bit Server VM Répertoire de base de l'utilisateur = C:\Users\Philippe Finaliser les objets de la file d'attente de finalisation ... terminé. Mémoire : 685 056 ko ; disponible : 427 411 ko ; (62 %) ... terminé. Nettoyer la mémoire ... terminé. Mémoire : 696 320 ko ; disponible : 591 649 ko ; (84 %) ... terminé. Tu peux nous faire une capture d'écran de JOSM avec la petite fenêtre d'informations du calque ? Je demande à voir ! Et n'hésite pas a nous expliquer pourquoi tu dois bosser avec des volumes de données aussi gigantesque à la fois... et aussi comment tu fais pour tenir à jour ces données. Je les garde en cache pour retrouver plus facilement les objets et ne pas en oublier (et éviter aussi de créer des doublons). Cela n'empêche pas de mettre à jour sur la sélection et de mettre à jour très souvent les dépendances d'objets sur des listes plus petites, mais sans avoir ˆà charger des zones avec tous les objets contenus dedans. Je peux travailler sur des zones très grandes, même sur plusieurs pays (ce qui est impossible si on n'a pas assez de mémoire, sans faire de nombreuses erreurs et dépendre entièrement de l'analyse à postériori par des outils en ligne externes dont on ne sait pas quand il feront leur analyse ni comment les autres interprêteront les oublis). J'ai donc une série de fichiers OSM en cache local, tous d'une taille voisine de 200 Mo à 4 Go, créés de façn plus ou moins thématique. Je m'en sors très bien pour les mises à jour même en évitant les conflits d'édition et aussi en n'ayant jamais à les rafraîchir en totalité (ce qui prendrait trop de ressources sur le serveur et trop souvent). Mes amis sont: CTRL+ALT+D et mettre à jour les modifications (avant d'envoyer quoi que ce soit). Aussi j'utilise abondamment le validateur (qui lui aussi a besoin de beaucoup de mémoire de travail). Essaye le passage en 64 bits au lieu de laisser par défaut en 32 bits, tu verras combien JOSM est BEAUCOUP plus performant dans ce mode ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] JOSM et son scan de disque - J'en ai ma claque !!!
Note aussi: Si tu travaille sur disqeu du et non sur SSD, et tu y stocke le cache de l'imagerie, sache que ce cache nefait QUE se remplir avec assez vote des milliers (ou dizaines de milliers) de fichiers dans ce dossier cache qui ne se purge jamais tout seul (même pour des tas d'images obsolètes depuis longtemps). Le problème est que ces images sont regroupées pour chaque source d'imagerie dans un unique dossier et on se retrouve avec un unique dossier sur le système de fichiers local pour lequel les recherches et ajouts deviennent de plus en plus lourds (et l'OS passe son temps soit à le maintenir trié sur NTFS, soit à le scanner en entier à la moindre modif pour ajouter ou recherchr un fichier image si c'est sur un volume FAT. C'est un problème en fait dans la façon dont JOSM gère son cache d'imagerie: il met beaucoup trop de fichiers ensemble dans le même dossier (un fichier PNG plus un fichier de tag pour chaque tuile). C'est très inefficace car plus le dossier se remplit et plus il devient lent, au point même de devenir beaucoup plus lent que de ne pas l'utiliser du tout et demander les images sur le web (bref le cache ne sert plus à rien). Le temps d'accès au dossier est encore plus inefficace en FAT qu'en NTFS (car un dossier FAT est lu linéairement de bout en bout, alors que les dossiers NTFS sont indexés; cependant NTFS reste lent en modif à cause des manipulations sur la MFT et la fragmentation de la MFT que cela provoque dans un volume stocké sur disque dur si tu n'as pas de SSD). Les navigateurs web peuvent gérer leur cache de façon plus efficace: ils stockent les pages téléchargées dans un cache réparti en plusieurs centaines de sous-dossiers, et stockent les tags dans un index séparé qui permet des recherche accélérées). C'est cela que je fait pas encore JOSM pour son cache local d'imagerie. DONC, de temps en temps (une fois par mois) pense à purger ce dossier cache d'imagerie complètement: il suffit de le supprimer avec tout son contenu (ce dossier est dans ton profil utilisateur, il porte le nom de la source d'imagerie que tu as choisie dans JOSM). (Note: tu peux même purger de dossier avec une session JOSM en cours, ce n'est pas gênant, tu n'es pas obligé de fermer JOSM, mais évite juste de glisser la carte à l'écran pour éviter que JOSM pendant ce temps là essaye de lire le dossier d'images que tu es en train de purger). Tu verras que l'OS met facilement plusieurs minutes à effacer ce dossier (et plus encore si c'est sur disque dur et non SSD): ne supprime pas les fichiers un par un, déplace carrément le dosseir qui les contient à la corbeille et purge la corbeille, cela va beaucoup plus vite. Mais même un DEL /D/P sur le nom du dossier en ligne de commande met un temps considérable sur un dossier qui comprend des dizaines de millliers de fichiers (alors que le même nombre de fichiers réparti dans des sous-dossiers avec moins de 1000 fichiers par dossier se crée et s'efface 10 000 fois plus vite). Dans JOSM tu as aussi une option de menu au clic droit pour purger le cache (mais cela ne purge que la couche d'imagerie la plus en avant-plan et dans ce que j'ai vu ça ne purge pas tout non plus). Tu peux aussi utiliser une tache programmée dans l'OS (ou dans un outil de nettoyage) pour purger tous les fichiers (images PNG et fichiers tags assocoés) du cache plus vieux d'une semaine (ou même plus vieux que 24 heures), et programmer cette tâche pour qu'elle tourne une fois par jour. ou faire cette purge manuellement quand tu as fini ta session JOSM et avant de faire le nettoyage de ton système, ou une sauvegarde système, une défragmention sur disque dur, un scan complet de l'antivirus, etc. Un trop gros cache entame en plus les performances de toutes les autres applis sur ton PC qui utilisent le même système de fichiers. Ce petit conseil est d'ailleurs indépendant de la version de JOSM ou de Java que tu utilises si tu vois ses perfs se dégrader avec le temps, c'est que tu dois faire un peu de ménage. Le 16 août 2014 10:47, Lapinos03 lapino...@free.fr a écrit : Avé tout le monde, Depuis que je suis passé sous JOSM java7, j'ai remarqué que le logiciel se met à scanner mon disque dur pendant des minutes et des minutes peu après son lancement. C'est systématique. Ça ralentit le PC et ça fait mouliner le disque dur. Dans quel but ? A la longue, cela devient franchement irritant ! Je voudrais savoir pourquoi ce logiciel scanne mon disque et ce qu'il scanne exactement pour que cela dure aussi longtemps. Il lit et écrit sur le disque. Sans compter l'antivirus, par derrière, qui intercepte les données (écrites certainement) et qui consomme encore plus de CPU. Si je quitte JOSM, l'activité disque s'arrête aussitôt. Y a-t-il une option pour faire cesser cela ? Avez-vous aussi ce problème ? Merci. @+ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] JOSM et son scan de disque - J'en ai ma claque !!!
Le 16/08/14 10:53, Christophe Merlet a écrit : Le 16/08/2014 10:47, Lapinos03 a écrit : Vu que tu parles d'antivirus, j'en conclus que tu es sous Winbloat. L'option pour faire cesser ce problème est de passer à GNU/Linux. Librement, Non, je suis sous MAC OS X. Anitivirus Sophos. Mais ce n'est pas l'antivirus qui est en cause, c'est bien JOSM. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] JOSM et son scan de disque - J'en ai ma claque !!!
Le 16/08/14 10:47, Lapinos03 a écrit : Avé tout le monde, Depuis que je suis passé sous JOSM java7, j'ai remarqué que le logiciel se met à scanner mon disque dur pendant des minutes et des minutes peu après son lancement. C'est systématique. Ça ralentit le PC et ça fait mouliner le disque dur. Dans quel but ? A la longue, cela devient franchement irritant ! Je voudrais savoir pourquoi ce logiciel scanne mon disque et ce qu'il scanne exactement pour que cela dure aussi longtemps. Il lit et écrit sur le disque. Sans compter l'antivirus, par derrière, qui intercepte les données (écrites certainement) et qui consomme encore plus de CPU. Si je quitte JOSM, l'activité disque s'arrête aussitôt. Y a-t-il une option pour faire cesser cela ? Avez-vous aussi ce problème ? Merci. @+ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr J'oubliais de préciser que j'étais sous MAC OS X 10.8.5, JAVA 7 1.7.0_67-b01. J'utilise la version .jnlp via l'icône qui a été installée automatiquement sur mon bureau (lien vers /Users/moi/Library/Application Support/Oracle/Java/Deployment/cache/6.0/bundles/JOSM.app) la première fois que j'ai lancé cette version une fois Java7 installé. Je ne sais pas si JOSM est en 32bits ou 64bits. Mon Moniteur d'activité ne me donne pas beaucoup de renseignements. @+ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] JOSM et son scan de disque - J'en ai ma claque !!!
Le 16 août 2014 14:26, Lapinos03 lapino...@free.fr a écrit : J'oubliais de préciser que j'étais sous MAC OS X 10.8.5, JAVA 7 1.7.0_67-b01. J'utilise la version .jnlp via l'icône qui a été installée automatiquement sur mon bureau (lien vers /Users/moi/Library/Application Support/Oracle/Java/Deployment/cache/6.0/bundles/JOSM.app) la première fois que j'ai lancé cette version une fois Java7 installé. Il fallait commencer par ça... Java ne fonctionne pas encore parfaitement sur Mac, il y a plein de bugs et ce problème de performances est connu; ça n'a rien à voir avec JOSM. On fait ce qu'on peut pour supporter cette plate-forme, mais aucun de nous n'utilise de Mac et on ne compte certainement pas passer du temps à débugguer/essayer de contourner tous ces problèmes qui sont causés par la volonté historique d'Apple à faire pendant des années bande à part vis-à-vis des runtimes Sun/Oracle, et qui n'a concédé que récemment que la JVM sur Mac soit enfin la même que celle proposée sur Linux et Windows. La meilleure chose à faire est de mettre à jour Java au fur et à mesure des releases. Je te conseille de migrer à la version 8u20 dès qu'elle sera disponible (courant de ce mois) et de continuer à mettre à jour régulièrement. Ce problème finira par être corrigé par Oracle. Sinon la solution proposée par Christophe est valable aussi ^^ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] JOSM et son scan de disque - J'en ai ma claque !!!
Le 16/08/14 17:06, Vincent Privat a écrit : Le 16 août 2014 14:26, Lapinos03 lapino...@free.fr mailto:lapino...@free.fr a écrit : J'oubliais de préciser que j'étais sous MAC OS X 10.8.5, JAVA 7 1.7.0_67-b01. J'utilise la version .jnlp via l'icône qui a été installée automatiquement sur mon bureau (lien vers /Users/moi/Library/__Application Support/Oracle/Java/__Deployment/cache/6.0/bundles/__JOSM.app) la première fois que j'ai lancé cette version une fois Java7 installé. Bonjour Installe un Linux et JOSM dans une VirtualBox sur ton Mac https://www.virtualbox.org/ C'est solution que j'ai adoptée (dans mon cas Mac OS était trop vieux pour mettre à jour la machine Java. Ça marche très bien, c'est complétement transparent, tu a accès aux 2 OS simultanément ;-) Françoise http://www.libres-chemins.org/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] JOSM et son scan de disque - J'en ai ma claque !!!
Le samedi 16 août 2014 14:06:12 Lapinos03 a écrit : Le 16/08/14 10:53, Christophe Merlet a écrit : Le 16/08/2014 10:47, Lapinos03 a écrit : Vu que tu parles d'antivirus, j'en conclus que tu es sous Winbloat. L'option pour faire cesser ce problème est de passer à GNU/Linux. Librement, Non, je suis sous MAC OS X. Anitivirus Sophos. Mais ce n'est pas l'antivirus qui est en cause, c'est bien JOSM. Pour en savoir plus sur l'origine de ce comportement, tu peux déplacer le répertoire de préférences de josm (~/.josm) et voir si le comportement persiste. -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] JOSM et son scan de disque - J'en ai ma claque !!!
J'utilise JOSM sous OSX (10.6 et 10.9) et je n'ai pas remarqué ce comportement. Par contre aucun antivirus pour moi sur mes Mac depuis l'abandon de Disinfectant (en juin 1997). Le 16 août 2014 21:59, Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net a écrit : Le samedi 16 août 2014 14:06:12 Lapinos03 a écrit : Le 16/08/14 10:53, Christophe Merlet a écrit : Le 16/08/2014 10:47, Lapinos03 a écrit : Vu que tu parles d'antivirus, j'en conclus que tu es sous Winbloat. L'option pour faire cesser ce problème est de passer à GNU/Linux. Librement, Non, je suis sous MAC OS X. Anitivirus Sophos. Mais ce n'est pas l'antivirus qui est en cause, c'est bien JOSM. Pour en savoir plus sur l'origine de ce comportement, tu peux déplacer le répertoire de préférences de josm (~/.josm) et voir si le comportement persiste. -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-ja] (RFC) OSMのWeb アプリ: POI editor
2014年8月16日 0:21 Satoru Takeuchi satoru.takeu...@gmail.com: 武内@沼津です。みなさまこんばんは。 お盆休みのハックネタとしてwebベースのPOIエディタのプロトタイプ版を作りました。 開発動機は、(前も少しここで言ったのですが)iOSのPushpinOSMに相当するものが AndroidやWebアプリにないので、ライトユーザを呼びこむために、あるといいなあと 思ったことです。 ちょっと触って試してコメントなどいただけると助かります。 http://satoru-takeuchi.org/~sat/satosmtest/edit.cgi 今できること - 現在地の地図を表示 - クリック(or タッチ)した場所にノードを追加できる - 追加できる要素の種類は、テスト用に適当につくった十数個のみ 備考 - ログイン画面にも書いているが、編集対象地図はOSM本家ではなくアプリ実験用の地図 - うまく動かなくなったら、cookieを消してリロードを推奨 - 認証取り消しはwebサイトにログインしてOAuthの設定から実施 とりあえずのタスク(趣味の活動なので、期限はとくになし) - OSS化: 最低限のセキュリティホールのチェックや、認証用のtokenがソースに残ってないか確認後、即実施予定 osmpoiという名前をつけて、GitHubにGPLv2でソース公開しました。ソースのREADME.mdにも書いていますが、 これで直接不特定多数向けサービスを提供するようなことはせず、テスト目的でのみ使用してください。 https://github.com/satoru-takeuchi/osmpoi 上記ソースをもとに作ったテスト用サイトはこちらです。 http://satoru-takeuchi.org/~sat/test/osmpoi/edit.cgi ちょっと触って試してコメントなどいただけると助かります。 http://satoru-takeuchi.org/~sat/satosmtest/edit.cgi こちらの古いテスト用サイトは近いうちに消します。 以上 - 本家OSMの地図を編集できるようにする - SSL対応 - ログアウト、webサイト以外から認証解除のサポート - 編集結果が地図に反映されるようにする - 地図上に他のノードが見えるようにする - 追加できるノードの種類を増やす(とりあえず日本語版cheet sheetの範囲) - 追加できるタグの種類を増やす(source, noteなど) - 英語化、本家へのアナウンス - Androidアプリ作成(手持ちのAndroid端末で試したところ、webアプリとしてもまあまあ使えそうだったが…) 以上 ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
[Talk-GB] The Secret Corners And Peculiar Nicknames Of Victoria Station
Good luck mapping these: http://londonist.com/2014/08/the-secret-corners-and-peculiar-nicknames-of-victoria-station.php ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
