Re: [Talk-cz] Izometrická 3D mapa z OSM
Kubajz píše v Út 23. 02. 2010 v 08:20 +0100: Hele i tak to zacina vypadat naprosto dokonale! Myslim, ze OSM potrebuje takovehle obrazky, aby BFU vedeli, ze ta data se daji vyborne zneuzit temer k cemukoliv :) Myslím že přihlášení do http://wiki.openstreetmap.org/wiki/Featured_image_proposals s nějakým zajímavým místem by nebylo od věci. Stanislav Brabec http://www.penguin.cz/~utx ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import adres z katastralni mapy
2010/2/23 Jan Dudík jan.du...@gmail.com: Chtěl jsem se na to podívat, ale chce to po mě .NET Framework 4.0.3... Nějak si nejsem jistý, kterou z těch mnoha verzí co MS nabízí mám nainstalovat a po předchoízch zkušenostech, kdy mi instalace .NET 3.5 rozhasila některé věci se mi do toho ani moc nechce. Můžeš dát podrobnější návod, případně link na správnou verzi? .NET Framework 4.0 bych určitě běžným uživatelům nedoporučoval instalovat, zatím to není finální verze a zaděláte si na možné problémy, až budete instalovat ostrou verzi (mluvím z vlastní zkušenosti s aktualizací z Beta 1 na Beta 2…). -- Petr Kadlec / Mormegil ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import adres z katastralni mapy
Dne 23. února 2010 9:56 Petr Kadlec petr.kad...@gmail.com napsal(a): 2010/2/23 Jan Dudík jan.du...@gmail.com: Chtěl jsem se na to podívat, ale chce to po mě .NET Framework 4.0.3... Nějak si nejsem jistý, kterou z těch mnoha verzí co MS nabízí mám nainstalovat a po předchoízch zkušenostech, kdy mi instalace .NET 3.5 rozhasila některé věci se mi do toho ani moc nechce. Můžeš dát podrobnější návod, případně link na správnou verzi? .NET Framework 4.0 bych určitě běžným uživatelům nedoporučoval instalovat, zatím to není finální verze a zaděláte si na možné problémy, až budete instalovat ostrou verzi (mluvím z vlastní zkušenosti s aktualizací z Beta 1 na Beta 2…). -- Petr Kadlec / Mormegil Tekže dotaz zní, zda lze tuto práci udělat i jinak, s dostupnými prostředky (JOSM, Java, NET 4) JD ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import adres z katastralni mapy
Chtěl jsem se na to podívat, ale chce to po mě .NET Framework 4.0.3... Nějak si nejsem jistý, kterou z těch mnoha verzí co MS nabízí mám nainstalovat a po předchoízch zkušenostech, kdy mi instalace .NET 3.5 rozhasila některé věci se mi do toho ani moc nechce. Můžeš dát podrobnější návod, případně link na správnou verzi? Za .NET framework 4 se omlouvám, používám Beta verzi nového Visual Studia a ta má defaultně nastavené použití .NET frameworku 4, nějak jsem si to neuvědomil. Tady [1] program zkompilován pro verzi 3.5. [1] http://sites.google.com/a/kabrt.cz/osm/home/adresy.zip?attredirects=0d=1 -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
[Talk-cz] revert needed -- import DIBAVOD (was Re: Import DIBAVOD)
Hi!
(Unfortunately, talk is moderated, so the message probably waits in
queue somewhere).
Moderators, could you let the message through? Alternatively, can
someone who is subscribed to talk just forward it?
Pavel
It seems that I created duplicate data when importing DIBAVOD; I
assumed that if connection died before closing transaction, no data
would be uploaded, and it seems it is not so :-(.
Edits in question are:
#3938287 February 21, 2010 20:50 dibavod, cast 41
11.985,48.587,17.993,50.959 (big)
#3938219 February 21, 2010 21:37 import dibavod, cast
4111.985,48.587,17.993,50.959 (big)
#3938181 February 21, 2010 21:30 import dibavod, cast
4111.985,48.587,17.993,50.959 (big)
#3938082 February 21, 2010 21:23 import dibavod, cast
4111.985,48.587,17.993,50.959 (big)
...they should be duplicates (if not, the biggest one should be left).
Now, there are big fat warnings about revert scripts and I'd prefer
not to mess up the database even more. What is the best way to
proceed?
Sorry for the mess,
Pavel
Pokud jsem se díval na několik rybníků, tak všechny byly nahrány 4x.
Například Trubární rybník - cesta č. 50937312 je nahrán ještě jako cesta č.
50932852, 50935613 a 50934642
Praák
Původní zpráva
Od: Pavel Machek pa...@ucw.cz
Předmět: Re: [Talk-cz] Import DIBAVOD
Datum: 22.2.2010 08:03:14
Ahoj!
Namátkou jsem zjistil, že Pavel nahrál omylem část č. 41 celkem
čtyřikrát.
Padlo spojeni ve fazi uploading, ale pred uzavrenim transakce. Takze
jsem letmo skontroloval ze tam data nejsou (a nebyla?!) a zkusil to
znovu.
Opravdu je duplicita v datech?
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import adres z katastralni mapy
Ve staženém souboru (Beroun) už jsou všechny výstupy udělané, proč je tedy třeba zprovozňovat program? Výstupy jsou udělané pro města, kde se podařil automaticky vytvořit *.map soubor. U dalších (název souboru začíná podtržítkem) je nějaká nejasnost v *.map souboru. Je potřeba map soubor upravit a vygenerovat osm soubory - proto je potřeba zprovoznit program. tam, kde jsou konflikty mi program spadne. Můžu se zeptat co vypíše za chybu? (spustit přes příkazový řádek, pak zůstane chyba na obrazovace) BTW, co ten import ktastrálních území? soubor existuje, proč není zároveň nahrán? Nahrán není, protože to ještě nikdo neudělal :-) A nahrávat ho současně s adresami mi nepřijde jako šťastný nápad - je nutné vyřešit konflikty s existujícími daty, napojení na existující relace apod. -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import DIBAVOD
Aha, ja nekdy predevcirem nektere casti uz v JOSM opravoval (s validatorem to jde rychle a vcelku automaticky...), takze nektere rybniky tam jsou uz jen jednou. Tak doufejme, ze se toho pri tom revertu nesmaze vic nez se ma (aby aspon jedna kopie zustala) - validator to aspon dela deterministicky (z vice kopii jedne cesty ponecha tu s nejnizsim ID, tedy tu nejstarsi ...). Jinak dalsi problem je v datech nahranych uzivatelem Medulove. Skript, kterym kontroluju cas od casu dumpy na mozne chyby mi na dumpu z dnesniho rana nahlasil asi 10700 duplicitnich nodu od nej (rozprostrenych po cele CR) a co jsem tak koukal, tak je to taky dibavod (byt kazdy rybnik je tam jen dvakrat). pavel ma 13700 duplicitnich nodu (nez jsem vcera nektere casti opravoval, tak jich bylo asi 32000) Takze duplicity od Medulove by taky asi chtely vyresit... Martin On 22/02/2010, Pavel Machek pa...@ucw.cz wrote: Hi! It seems that I created duplicate data when importing DIBAVOD; I assumed that if connection died before closing transaction, no data would be uploaded, and it seems it is not so :-(. Edits in question are: #3938287 February 21, 2010 20:50 dibavod, cast 41 11.985,48.587,17.993,50.959 (big) #3938219February 21, 2010 21:37 import dibavod, cast 41 11.985,48.587,17.993,50.959 (big) #3938181February 21, 2010 21:30 import dibavod, cast 41 11.985,48.587,17.993,50.959 (big) #3938082February 21, 2010 21:23 import dibavod, cast 41 11.985,48.587,17.993,50.959 (big) ...they should be duplicates (if not, the biggest one should be left). Now, there are big fat warnings about revert scripts and I'd prefer not to mess up the database even more. What is the best way to proceed? Sorry for the mess, Pavel Pokud jsem se díval na několik rybníků, tak všechny byly nahrány 4x. Například Trubární rybník - cesta č. 50937312 je nahrán ještě jako cesta č. 50932852, 50935613 a 50934642 Praák Původní zpráva Od: Pavel Machek pa...@ucw.cz Předmět: Re: [Talk-cz] Import DIBAVOD Datum: 22.2.2010 08:03:14 Ahoj! Namátkou jsem zjistil, že Pavel nahrál omylem část č. 41 celkem čtyřikrát. Padlo spojeni ve fazi uploading, ale pred uzavrenim transakce. Takze jsem letmo skontroloval ze tam data nejsou (a nebyla?!) a zkusil to znovu. Opravdu je duplicita v datech? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import DIBAVOD
Jo, to je možný část 91 mi spadla chvilku po začátku imortu, myslel jsem ,že se stačilo přenést jen pár kousků a zatím to vypadá na skoro celý díl :-(... JD Dne 23. února 2010 20:41 MP singular...@gmail.com napsal(a): Aha, ja nekdy predevcirem nektere casti uz v JOSM opravoval (s validatorem to jde rychle a vcelku automaticky...), takze nektere rybniky tam jsou uz jen jednou. Jinak dalsi problem je v datech nahranych uzivatelem Medulove. Skript, kterym kontroluju cas od casu dumpy na mozne chyby mi na dumpu z dnesniho rana nahlasil asi 10700 duplicitnich nodu od nej (rozprostrenych po cele CR) a co jsem tak koukal, tak je to taky dibavod (byt kazdy rybnik je tam jen dvakrat). pavel ma 13700 duplicitnich nodu (nez jsem vcera nektere casti opravoval, tak jich bylo asi 32000) Takze duplicity od Medulove by taky asi chtely vyresit... Martin On 22/02/2010, Pavel Machek pa...@ucw.cz wrote: Hi! It seems that I created duplicate data when importing DIBAVOD; I assumed that if connection died before closing transaction, no data would be uploaded, and it seems it is not so :-(. Edits in question are: #3938287 February 21, 2010 20:50 dibavod, cast 41 11.985,48.587,17.993,50.959 (big) #3938219 February 21, 2010 21:37 import dibavod, cast 41 11.985,48.587,17.993,50.959 (big) #3938181 February 21, 2010 21:30 import dibavod, cast 41 11.985,48.587,17.993,50.959 (big) #3938082 February 21, 2010 21:23 import dibavod, cast 41 11.985,48.587,17.993,50.959 (big) ...they should be duplicates (if not, the biggest one should be left). Now, there are big fat warnings about revert scripts and I'd prefer not to mess up the database even more. What is the best way to proceed? Sorry for the mess, Pavel Pokud jsem se díval na několik rybníků, tak všechny byly nahrány 4x. Například Trubární rybník - cesta č. 50937312 je nahrán ještě jako cesta č. 50932852, 50935613 a 50934642 Praák Původní zpráva Od: Pavel Machek pa...@ucw.cz Předmět: Re: [Talk-cz] Import DIBAVOD Datum: 22.2.2010 08:03:14 Ahoj! Namátkou jsem zjistil, že Pavel nahrál omylem část č. 41 celkem čtyřikrát. Padlo spojeni ve fazi uploading, ale pred uzavrenim transakce. Takze jsem letmo skontroloval ze tam data nejsou (a nebyla?!) a zkusil to znovu. Opravdu je duplicita v datech? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list talk...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz -- -- Ing. Jan Dudík ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import DIBAVOD
A jak se ma pri tomto postupovat? Ja myslel, ze pro kazdy bod co JOSM
uploadne si priradi nove id. Takze kdyz spadne spojeni melo by stacit
dat save a tim uz by mel byt XML updatovan o to co se uploadlo. Nebo se
mylim?
Tomas
Jan Dudík napsal(a):
Jo, to je možný část 91 mi spadla chvilku po začátku imortu, myslel
jsem ,že se stačilo přenést jen pár kousků a zatím to vypadá na skoro
celý díl :-(...
JD
Dne 23. února 2010 20:41 MP singular...@gmail.com napsal(a):
Aha, ja nekdy predevcirem nektere casti uz v JOSM opravoval (s
validatorem to jde rychle a vcelku automaticky...), takze nektere
rybniky tam jsou uz jen jednou.
Jinak dalsi problem je v datech nahranych uzivatelem Medulove. Skript,
kterym kontroluju cas od casu dumpy na mozne chyby mi na dumpu z
dnesniho rana nahlasil asi 10700 duplicitnich nodu od nej
(rozprostrenych po cele CR) a co jsem tak koukal, tak je to taky
dibavod (byt kazdy rybnik je tam jen dvakrat). pavel ma 13700
duplicitnich nodu (nez jsem vcera nektere casti opravoval, tak jich
bylo asi 32000)
Takze duplicity od Medulove by taky asi chtely vyresit...
Martin
On 22/02/2010, Pavel Machek pa...@ucw.cz wrote:
Hi!
It seems that I created duplicate data when importing DIBAVOD; I
assumed that if connection died before closing transaction, no data
would be uploaded, and it seems it is not so :-(.
Edits in question are:
#3938287 February 21, 2010 20:50 dibavod, cast 41
11.985,48.587,17.993,50.959 (big)
#3938219February 21, 2010 21:37 import dibavod, cast
41 11.985,48.587,17.993,50.959 (big)
#3938181February 21, 2010 21:30 import dibavod, cast
41 11.985,48.587,17.993,50.959 (big)
#3938082February 21, 2010 21:23 import dibavod, cast
41 11.985,48.587,17.993,50.959 (big)
...they should be duplicates (if not, the biggest one should be left).
Now, there are big fat warnings about revert scripts and I'd prefer
not to mess up the database even more. What is the best way to
proceed?
Sorry for the mess,
Pavel
Pokud jsem se díval na několik rybníků, tak všechny byly nahrány 4x.
Například Trubární rybník - cesta č. 50937312 je nahrán ještě jako cesta č.
50932852, 50935613 a 50934642
Praák
Původní zpráva
Od: Pavel Machek pa...@ucw.cz
Předmět: Re: [Talk-cz] Import DIBAVOD
Datum: 22.2.2010 08:03:14
Ahoj!
Namátkou jsem zjistil, že Pavel nahrál omylem část č. 41 celkem
čtyřikrát.
Padlo spojeni ve fazi uploading, ale pred uzavrenim transakce. Takze
jsem letmo skontroloval ze tam data nejsou (a nebyla?!) a zkusil to
znovu.
Opravdu je duplicita v datech?
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import DIBAVOD
Nahravani changesetu z JOSM je transakcni, ne? Takze bude se to povede cele nebo vubec a je to mozne opakovat. Nebo jsem to pochopil spatne? Honza Dne 23. února 2010 21:44 Tomas Kolda ko...@web2net.cz napsal(a): A jak se ma pri tomto postupovat? Ja myslel, ze pro kazdy bod co JOSM uploadne si priradi nove id. Takze kdyz spadne spojeni melo by stacit dat save a tim uz by mel byt XML updatovan o to co se uploadlo. Nebo se mylim? Tomas Jan Dudík napsal(a): Jo, to je možný část 91 mi spadla chvilku po začátku imortu, myslel jsem ,že se stačilo přenést jen pár kousků a zatím to vypadá na skoro celý díl :-(... JD Dne 23. února 2010 20:41 MP singular...@gmail.com napsal(a): Aha, ja nekdy predevcirem nektere casti uz v JOSM opravoval (s validatorem to jde rychle a vcelku automaticky...), takze nektere rybniky tam jsou uz jen jednou. Jinak dalsi problem je v datech nahranych uzivatelem Medulove. Skript, kterym kontroluju cas od casu dumpy na mozne chyby mi na dumpu z dnesniho rana nahlasil asi 10700 duplicitnich nodu od nej (rozprostrenych po cele CR) a co jsem tak koukal, tak je to taky dibavod (byt kazdy rybnik je tam jen dvakrat). pavel ma 13700 duplicitnich nodu (nez jsem vcera nektere casti opravoval, tak jich bylo asi 32000) Takze duplicity od Medulove by taky asi chtely vyresit... Martin On 22/02/2010, Pavel Machek pa...@ucw.cz wrote: Hi! It seems that I created duplicate data when importing DIBAVOD; I assumed that if connection died before closing transaction, no data would be uploaded, and it seems it is not so :-(. Edits in question are: #3938287 February 21, 2010 20:50 dibavod, cast 41 11.985,48.587,17.993,50.959 (big) #3938219 February 21, 2010 21:37 import dibavod, cast 41 11.985,48.587,17.993,50.959 (big) #3938181 February 21, 2010 21:30 import dibavod, cast 41 11.985,48.587,17.993,50.959 (big) #3938082 February 21, 2010 21:23 import dibavod, cast 41 11.985,48.587,17.993,50.959 (big) ...they should be duplicates (if not, the biggest one should be left). Now, there are big fat warnings about revert scripts and I'd prefer not to mess up the database even more. What is the best way to proceed? Sorry for the mess, Pavel Pokud jsem se díval na několik rybníků, tak všechny byly nahrány 4x. Například Trubární rybník - cesta č. 50937312 je nahrán ještě jako cesta č. 50932852, 50935613 a 50934642 Praák Původní zpráva Od: Pavel Machek pa...@ucw.cz Předmět: Re: [Talk-cz] Import DIBAVOD Datum: 22.2.2010 08:03:14 Ahoj! Namátkou jsem zjistil, že Pavel nahrál omylem část č. 41 celkem čtyřikrát. Padlo spojeni ve fazi uploading, ale pred uzavrenim transakce. Takze jsem letmo skontroloval ze tam data nejsou (a nebyla?!) a zkusil to znovu. Opravdu je duplicita v datech? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list talk...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import DIBAVOD
Dne 23.2.2010 21:55, Jan Bilak napsal(a): Ja vychazel z tohoto: Diff upload: POST /api/0.6/changeset/#id/upload With this API call files in the OsmChange format can be uploaded to the server. This is guaranteed to be running in a transaction. So either all the changes are applied or none. To upload an OSC file it has to conform to the OsmChange specification with the addition of a changeset and a version attribute for each element, except when you are creating an element where the version is not required as the server sets that for you. [http://wiki.openstreetmap.org/wiki/OSM_Protocol_Version_0.6] Honza Otazka je, jestli vam to nezbuchlo ve finalni fazi, kdyz uz transakce byla uzavrena = melo by to by duplicitni komplet a teoreticky by melo jit revertnout komplet jeden changeset (pokud ho nekdo mezi tim nezmenil). Dalsi varianta, ktera me napada (spekulace) ze kdyz changeset je otevreny dyl nez X (hodina ???) tak ho OSM uzavre automaticky. Nektere typy chyb by tomu nasvedcovaly. BTW: Osobne trochu nechapu co trva na uploadu 1MB dat na 8Mbit lince cca 20 - 30 minut. Tech +- 10k zaznamu se da nacpat do databaze behem vterin. 2010/2/23 Tomas Kolda ko...@web2net.cz: No asi to tak neni, protoze by pak nevznikly ty duplikaty. Jak presne jste postupovali, kdyz vam to spadlo? At vysledujeme jak se spravne pri uploadech chovat... Tomas Jan Bilak napsal(a): Nahravani changesetu z JOSM je transakcni, ne? Takze bude se to povede cele nebo vubec a je to mozne opakovat. Nebo jsem to pochopil spatne? Honza Dne 23. února 2010 21:44 Tomas Kolda ko...@web2net.cz napsal(a): A jak se ma pri tomto postupovat? Ja myslel, ze pro kazdy bod co JOSM uploadne si priradi nove id. Takze kdyz spadne spojeni melo by stacit dat save a tim uz by mel byt XML updatovan o to co se uploadlo. Nebo se mylim? Tomas Jan Dudík napsal(a): Jo, to je možný část 91 mi spadla chvilku po začátku imortu, myslel jsem ,že se stačilo přenést jen pár kousků a zatím to vypadá na skoro celý díl :-(... JD Dne 23. února 2010 20:41 MP singular...@gmail.com napsal(a): Aha, ja nekdy predevcirem nektere casti uz v JOSM opravoval (s validatorem to jde rychle a vcelku automaticky...), takze nektere rybniky tam jsou uz jen jednou. Jinak dalsi problem je v datech nahranych uzivatelem Medulove. Skript, kterym kontroluju cas od casu dumpy na mozne chyby mi na dumpu z dnesniho rana nahlasil asi 10700 duplicitnich nodu od nej (rozprostrenych po cele CR) a co jsem tak koukal, tak je to taky dibavod (byt kazdy rybnik je tam jen dvakrat). pavel ma 13700 duplicitnich nodu (nez jsem vcera nektere casti opravoval, tak jich bylo asi 32000) Takze duplicity od Medulove by taky asi chtely vyresit... Martin On 22/02/2010, Pavel Machek pa...@ucw.cz wrote: Hi! It seems that I created duplicate data when importing DIBAVOD; I assumed that if connection died before closing transaction, no data would be uploaded, and it seems it is not so :-(. Edits in question are: #3938287 February 21, 2010 20:50 dibavod, cast 41 11.985,48.587,17.993,50.959 (big) #3938219February 21, 2010 21:37 import dibavod, cast 41 11.985,48.587,17.993,50.959 (big) #3938181February 21, 2010 21:30 import dibavod, cast 41 11.985,48.587,17.993,50.959 (big) #3938082February 21, 2010 21:23 import dibavod, cast 41 11.985,48.587,17.993,50.959 (big) ...they should be duplicates (if not, the biggest one should be left). Now, there are big fat warnings about revert scripts and I'd prefer not to mess up the database even more. What is the best way to proceed? Sorry for the mess, Pavel Pokud jsem se díval na několik rybníků, tak všechny byly nahrány 4x. Například Trubární rybník - cesta č. 50937312 je nahrán ještě jako cesta č. 50932852, 50935613 a 50934642 Praák Původní zpráva Od: Pavel Machek pa...@ucw.cz Předmět: Re: [Talk-cz] Import DIBAVOD Datum: 22.2.2010 08:03:14 Ahoj! Namátkou jsem zjistil, že Pavel nahrál omylem část č. 41 celkem čtyřikrát. Padlo spojeni ve fazi uploading, ale pred uzavrenim transakce. Takze jsem letmo skontroloval ze tam data nejsou (a nebyla?!) a zkusil to znovu. Opravdu je duplicita v datech? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz -- (english)
Re: [Talk-cz] Import DIBAVOD
Tak jsem to asi vykoukal. Ja jsem si 0.6 jeste necetl, coz je mozna skoda. Naposledy jsem delal lesy a to byla verze 0.5. Ty soubory co jsem posilal se totiz dali udelat velmi rychle pomoci toho diff upload. Mozna JOSMu vadilo, ze v xml bylo osm version='0.5'. Netusim. JOSM to dela po jednom nodu v changesetu a nakonec po jedne line. To je samozrejmne 1 requestu a to trva tu hodinu. Pak je tam napsano: To avoid stale open changesets a mechanism is implemented to automatically close changesets upon one of the following three conditions: * More than 50.000 edits on a single changeset See more specific limits http://wiki.openstreetmap.org/wiki/OSM_Protocol_Version_0.6#New_Limits * The changeset has been open for more than 24 hours * There have been no changes/API calls related to a changeset in 1 hour (i.e. idle timeout) Coz vysvetluje proc data zustaly. Ja to pochopil, ze je changeset jen kvuli lepsi identifikaci pro reverty ne jako transakce. Na transakci je pouzit ten diff upload. No aspon vime jak se to asi ma priste delat. Tomas jzvc napsal(a): Dne 23.2.2010 21:55, Jan Bilak napsal(a): Ja vychazel z tohoto: Diff upload: POST /api/0.6/changeset/#id/upload With this API call files in the OsmChange format can be uploaded to the server. This is guaranteed to be running in a transaction. So either all the changes are applied or none. To upload an OSC file it has to conform to the OsmChange specification with the addition of a changeset and a version attribute for each element, except when you are creating an element where the version is not required as the server sets that for you. [http://wiki.openstreetmap.org/wiki/OSM_Protocol_Version_0.6] Honza Otazka je, jestli vam to nezbuchlo ve finalni fazi, kdyz uz transakce byla uzavrena = melo by to by duplicitni komplet a teoreticky by melo jit revertnout komplet jeden changeset (pokud ho nekdo mezi tim nezmenil). Dalsi varianta, ktera me napada (spekulace) ze kdyz changeset je otevreny dyl nez X (hodina ???) tak ho OSM uzavre automaticky. Nektere typy chyb by tomu nasvedcovaly. BTW: Osobne trochu nechapu co trva na uploadu 1MB dat na 8Mbit lince cca 20 - 30 minut. Tech +- 10k zaznamu se da nacpat do databaze behem vterin. 2010/2/23 Tomas Kolda ko...@web2net.cz: No asi to tak neni, protoze by pak nevznikly ty duplikaty. Jak presne jste postupovali, kdyz vam to spadlo? At vysledujeme jak se spravne pri uploadech chovat... Tomas Jan Bilak napsal(a): Nahravani changesetu z JOSM je transakcni, ne? Takze bude se to povede cele nebo vubec a je to mozne opakovat. Nebo jsem to pochopil spatne? Honza Dne 23. února 2010 21:44 Tomas Kolda ko...@web2net.cz napsal(a): A jak se ma pri tomto postupovat? Ja myslel, ze pro kazdy bod co JOSM uploadne si priradi nove id. Takze kdyz spadne spojeni melo by stacit dat save a tim uz by mel byt XML updatovan o to co se uploadlo. Nebo se mylim? Tomas Jan Dudík napsal(a): Jo, to je možný část 91 mi spadla chvilku po začátku imortu, myslel jsem ,že se stačilo přenést jen pár kousků a zatím to vypadá na skoro celý díl :-(... JD Dne 23. února 2010 20:41 MP singular...@gmail.com napsal(a): Aha, ja nekdy predevcirem nektere casti uz v JOSM opravoval (s validatorem to jde rychle a vcelku automaticky...), takze nektere rybniky tam jsou uz jen jednou. Jinak dalsi problem je v datech nahranych uzivatelem Medulove. Skript, kterym kontroluju cas od casu dumpy na mozne chyby mi na dumpu z dnesniho rana nahlasil asi 10700 duplicitnich nodu od nej (rozprostrenych po cele CR) a co jsem tak koukal, tak je to taky dibavod (byt kazdy rybnik je tam jen dvakrat). pavel ma 13700 duplicitnich nodu (nez jsem vcera nektere casti opravoval, tak jich bylo asi 32000) Takze duplicity od Medulove by taky asi chtely vyresit... Martin On 22/02/2010, Pavel Machek pa...@ucw.cz wrote: Hi! It seems that I created duplicate data when importing DIBAVOD; I assumed that if connection died before closing transaction, no data would be uploaded, and it seems it is not so :-(. Edits in question are: #3938287 February 21, 2010 20:50 dibavod, cast 41 11.985,48.587,17.993,50.959 (big) #3938219February 21, 2010 21:37 import dibavod, cast 41 11.985,48.587,17.993,50.959 (big) #3938181February 21, 2010 21:30 import dibavod, cast 41 11.985,48.587,17.993,50.959 (big) #3938082February 21, 2010 21:23 import dibavod, cast 41 11.985,48.587,17.993,50.959 (big) ...they should be duplicates (if not, the biggest one should be left). Now, there are big fat warnings about revert scripts and I'd prefer not to mess up the database even more. What is the best way to proceed? Sorry for the mess, Pavel Pokud jsem se díval na několik rybníků, tak všechny byly nahrány 4x. Například Trubární rybník - cesta č. 50937312 je
Re: [Talk-cz] Import DIBAVOD
Ted jsem to asi uplne nepochopil. V JSOM lze nejak nastavit, jestli pouzije API metodu diff upload, aby nahral vsechno v jednom changesetu a transakci nebo to delal nejak jinak? Osobne bych cekal, ze ten alternativni postup je pro ten webovy editor a JOSM bude pouzivat vzdy diff upload. Tedy vse pekne v transakci a jednom changesetu. Tedy, pokud se to vejde do toho limitu poctu zmen. Honza 2010/2/23 Tomas Kolda ko...@web2net.cz: Tak jsem to asi vykoukal. Ja jsem si 0.6 jeste necetl, coz je mozna skoda. Naposledy jsem delal lesy a to byla verze 0.5. Ty soubory co jsem posilal se totiz dali udelat velmi rychle pomoci toho diff upload. Mozna JOSMu vadilo, ze v xml bylo osm version='0.5'. Netusim. JOSM to dela po jednom nodu v changesetu a nakonec po jedne line. To je samozrejmne 1 requestu a to trva tu hodinu. Pak je tam napsano: To avoid stale open changesets a mechanism is implemented to automatically close changesets upon one of the following three conditions: More than 50.000 edits on a single changeset See more specific limits The changeset has been open for more than 24 hours There have been no changes/API calls related to a changeset in 1 hour (i.e. idle timeout) Coz vysvetluje proc data zustaly. Ja to pochopil, ze je changeset jen kvuli lepsi identifikaci pro reverty ne jako transakce. Na transakci je pouzit ten diff upload. No aspon vime jak se to asi ma priste delat. Tomas jzvc napsal(a): Dne 23.2.2010 21:55, Jan Bilak napsal(a): Ja vychazel z tohoto: Diff upload: POST /api/0.6/changeset/#id/upload With this API call files in the OsmChange format can be uploaded to the server. This is guaranteed to be running in a transaction. So either all the changes are applied or none. To upload an OSC file it has to conform to the OsmChange specification with the addition of a changeset and a version attribute for each element, except when you are creating an element where the version is not required as the server sets that for you. [http://wiki.openstreetmap.org/wiki/OSM_Protocol_Version_0.6] Honza Otazka je, jestli vam to nezbuchlo ve finalni fazi, kdyz uz transakce byla uzavrena = melo by to by duplicitni komplet a teoreticky by melo jit revertnout komplet jeden changeset (pokud ho nekdo mezi tim nezmenil). Dalsi varianta, ktera me napada (spekulace) ze kdyz changeset je otevreny dyl nez X (hodina ???) tak ho OSM uzavre automaticky. Nektere typy chyb by tomu nasvedcovaly. BTW: Osobne trochu nechapu co trva na uploadu 1MB dat na 8Mbit lince cca 20 - 30 minut. Tech +- 10k zaznamu se da nacpat do databaze behem vterin. 2010/2/23 Tomas Kolda ko...@web2net.cz: No asi to tak neni, protoze by pak nevznikly ty duplikaty. Jak presne jste postupovali, kdyz vam to spadlo? At vysledujeme jak se spravne pri uploadech chovat... Tomas Jan Bilak napsal(a): Nahravani changesetu z JOSM je transakcni, ne? Takze bude se to povede cele nebo vubec a je to mozne opakovat. Nebo jsem to pochopil spatne? Honza Dne 23. února 2010 21:44 Tomas Kolda ko...@web2net.cz napsal(a): A jak se ma pri tomto postupovat? Ja myslel, ze pro kazdy bod co JOSM uploadne si priradi nove id. Takze kdyz spadne spojeni melo by stacit dat save a tim uz by mel byt XML updatovan o to co se uploadlo. Nebo se mylim? Tomas Jan Dudík napsal(a): Jo, to je možný část 91 mi spadla chvilku po začátku imortu, myslel jsem ,že se stačilo přenést jen pár kousků a zatím to vypadá na skoro celý díl :-(... JD Dne 23. února 2010 20:41 MP singular...@gmail.com napsal(a): Aha, ja nekdy predevcirem nektere casti uz v JOSM opravoval (s validatorem to jde rychle a vcelku automaticky...), takze nektere rybniky tam jsou uz jen jednou. Jinak dalsi problem je v datech nahranych uzivatelem Medulove. Skript, kterym kontroluju cas od casu dumpy na mozne chyby mi na dumpu z dnesniho rana nahlasil asi 10700 duplicitnich nodu od nej (rozprostrenych po cele CR) a co jsem tak koukal, tak je to taky dibavod (byt kazdy rybnik je tam jen dvakrat). pavel ma 13700 duplicitnich nodu (nez jsem vcera nektere casti opravoval, tak jich bylo asi 32000) Takze duplicity od Medulove by taky asi chtely vyresit... Martin On 22/02/2010, Pavel Machek pa...@ucw.cz wrote: Hi! It seems that I created duplicate data when importing DIBAVOD; I assumed that if connection died before closing transaction, no data would be uploaded, and it seems it is not so :-(. Edits in question are: #3938287 February 21, 2010 20:50 dibavod, cast 41 11.985,48.587,17.993,50.959 (big) #3938219February 21, 2010 21:37 import dibavod, cast 41 11.985,48.587,17.993,50.959 (big) #3938181February 21, 2010 21:30 import dibavod, cast 41 11.985,48.587,17.993,50.959 (big) #3938082February 21, 2010 21:23 import dibavod, cast 41 11.985,48.587,17.993,50.959 (big) ...they should be duplicates (if not, the
Re: [Talk-cz] Import DIBAVOD
Mě bohužel spadl celý systém z důvodu jiného programu, takže nepomůžu. JD 2010/2/23 Tomas Kolda ko...@web2net.cz: No asi to tak neni, protoze by pak nevznikly ty duplikaty. Jak presne jste postupovali, kdyz vam to spadlo? At vysledujeme jak se spravne pri uploadech chovat... Tomas Jan Bilak napsal(a): Nahravani changesetu z JOSM je transakcni, ne? Takze bude se to povede cele nebo vubec a je to mozne opakovat. Nebo jsem to pochopil spatne? Honza Dne 23. února 2010 21:44 Tomas Kolda ko...@web2net.cz napsal(a): A jak se ma pri tomto postupovat? Ja myslel, ze pro kazdy bod co JOSM uploadne si priradi nove id. Takze kdyz spadne spojeni melo by stacit dat save a tim uz by mel byt XML updatovan o to co se uploadlo. Nebo se mylim? Tomas Jan Dudík napsal(a): Jo, to je možný část 91 mi spadla chvilku po začátku imortu, myslel jsem ,že se stačilo přenést jen pár kousků a zatím to vypadá na skoro celý díl :-(... JD Dne 23. února 2010 20:41 MP singular...@gmail.com napsal(a): Aha, ja nekdy predevcirem nektere casti uz v JOSM opravoval (s validatorem to jde rychle a vcelku automaticky...), takze nektere rybniky tam jsou uz jen jednou. Jinak dalsi problem je v datech nahranych uzivatelem Medulove. Skript, kterym kontroluju cas od casu dumpy na mozne chyby mi na dumpu z dnesniho rana nahlasil asi 10700 duplicitnich nodu od nej (rozprostrenych po cele CR) a co jsem tak koukal, tak je to taky dibavod (byt kazdy rybnik je tam jen dvakrat). pavel ma 13700 duplicitnich nodu (nez jsem vcera nektere casti opravoval, tak jich bylo asi 32000) Takze duplicity od Medulove by taky asi chtely vyresit... Martin On 22/02/2010, Pavel Machek pa...@ucw.cz wrote: Hi! It seems that I created duplicate data when importing DIBAVOD; I assumed that if connection died before closing transaction, no data would be uploaded, and it seems it is not so :-(. Edits in question are: #3938287 February 21, 2010 20:50 dibavod, cast 41 11.985,48.587,17.993,50.959 (big) #3938219 February 21, 2010 21:37 import dibavod, cast 41 11.985,48.587,17.993,50.959 (big) #3938181 February 21, 2010 21:30 import dibavod, cast 41 11.985,48.587,17.993,50.959 (big) #3938082 February 21, 2010 21:23 import dibavod, cast 41 11.985,48.587,17.993,50.959 (big) ...they should be duplicates (if not, the biggest one should be left). Now, there are big fat warnings about revert scripts and I'd prefer not to mess up the database even more. What is the best way to proceed? Sorry for the mess, Pavel Pokud jsem se díval na několik rybníků, tak všechny byly nahrány 4x. Například Trubární rybník - cesta č. 50937312 je nahrán ještě jako cesta č. 50932852, 50935613 a 50934642 Praák Původní zpráva Od: Pavel Machek pa...@ucw.cz Předmět: Re: [Talk-cz] Import DIBAVOD Datum: 22.2.2010 08:03:14 Ahoj! Namátkou jsem zjistil, že Pavel nahrál omylem část č. 41 celkem čtyřikrát. Padlo spojeni ve fazi uploading, ale pred uzavrenim transakce. Takze jsem letmo skontroloval ze tam data nejsou (a nebyla?!) a zkusil to znovu. Opravdu je duplicita v datech? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list talk...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz -- -- Ing. Jan Dudík ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import DIBAVOD
A jak se ma pri tomto postupovat? Ja myslel, ze pro kazdy bod co JOSM uploadne si priradi nove id. Takze kdyz spadne spojeni melo by stacit dat save a tim uz by mel byt XML updatovan o to co se uploadlo. Nebo se mylim? Pokud se pouziuva diff upload tak se nova ID priradi az na konci a JOSM se o nich dozvi az pote, co si server vsechno prebere a ty ID vrati zpatky takze pokud spojeni vyhnije pote co bylo vse odeslano na server, ale predtim, nez JOSM dostane zpet nova IDcka, tak server to tam vse sice uspesne nacpe, ale po vyhnilem spojeni uz nevrati nova ID a JOSM se pak tvari, ze to cele selhalo. A kdyz to clovek zkusi znovu tak tam uz cpe druhou kopii Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import DIBAVOD
Tak jsem to zkusil. Ten diff upload asi chodi jen na devel verzi JOSM. Ted jsem uploadnul svuj posledni soubor a trvalo to asi 10 minut. Data tam byli za par sekund, ale ten commit trosku trval. Nejdriv mi to prislo dlouhe tak jsem dal cancel. Na podruhe jsem vydrzel. Duplicita tam neni. Takze na tohle asi bylo lepsi pouzit JOSM devel verzi. Tomas MP napsal(a): A jak se ma pri tomto postupovat? Ja myslel, ze pro kazdy bod co JOSM uploadne si priradi nove id. Takze kdyz spadne spojeni melo by stacit dat save a tim uz by mel byt XML updatovan o to co se uploadlo. Nebo se mylim? Pokud se pouziuva diff upload tak se nova ID priradi az na konci a JOSM se o nich dozvi az pote, co si server vsechno prebere a ty ID vrati zpatky takze pokud spojeni vyhnije pote co bylo vse odeslano na server, ale predtim, nez JOSM dostane zpet nova IDcka, tak server to tam vse sice uspesne nacpe, ale po vyhnilem spojeni uz nevrati nova ID a JOSM se pak tvari, ze to cele selhalo. A kdyz to clovek zkusi znovu tak tam uz cpe druhou kopii Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
[Talk-cz] opět duplicitní data v oblasti 005
Opět jsem zjistil duplicitu nahraných dat v oblasti 005 nahraných včera před půlncí Tomášem Koldou. Například rybník dibavod ID 204090020015 je nahrán jako cesta 5512 a cesta 51110690. Changesety 3958769 a 3958832 Pražák ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
