import dibavod

74 zpráv
Zpět na přehled

import dibavod

74 zpráv PJJZTPMJ 20 účastníků 36 min čtení
  1. Zdeněk Pražák ZPrazak na seznam.cz #m8f9f2d
    Namátkou jsem zjistil, že Pavel nahrál omylem část č. 41 celkem čtyřikrát.
  2. Pavel Machek pavel na ucw.cz #m1721b7
    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?
  3. Zdeněk Pražák ZPrazak na seznam.cz #m37f379
    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
  4. Jiri Parkan jparkan na gmail.com #md23d4e
    Bohužel se zdá že ano, všechny 4 changesety obsahují přes 10000 bodů. Namátkou třeba http://osm.org/go/0JycpXo na U-- po otevření v potlachu je tam rybník 4x pře sebe (a potlach na to upozorňuje červeným blikání, tohle by se mi líbilo i v JOSM) Parkis 2010/2/22 Pavel Machek <pavel na ucw.cz>:
  5. MP singularita na gmail.com #me876ab
    Bohužel se zdá že ano, všechny 4 changesety obsahují přes 10000 bodů. Namátkou třeba http://osm.org/go/0JycpXo na U-- po otevření v potlachu je tam rybník 4x pře sebe (a potlach na to upozorňuje červeným blikání, tohle by se mi líbilo i v JOSM)
    JOSM to umi - staci mit plugin validator a duplicitni cesty (ty, jejichz nody maji stejne souradnice) to dokaze najit (a cervene zvyraznit) a kdyz se pak ty cesty ve validatoru vyberou a klikne se na "Fix" tak ze vsech duplicitnich cest zustane jenom ta nejstarsi. Pak spustit validaci znovu, vybrat "untagged and unconnected nodes" a zase dat "Fix". Potreti pak spravit "Duplicate nodes" a je to, extra data jsou na par kliknuti smazana :) Martin
  6. Pavel Machek pavel na ucw.cz #mcdd37d
    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
    ---------------------------------------- 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
  7. MP singularita na gmail.com #mab7b3f
    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
  8. Jan Dudík jan.dudik na gmail.com #m1c6d37
    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 :-(... J&D
    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
    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 <pavel na 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 > > _______________________________________________
    _______________________________________________
    -- -- Ing. Jan Dudík
  9. Tomas Kolda kolda na web2net.cz #m483971
    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
  10. Jan Bilak jan.bilak.osm na gmail.com #m517ff2
    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
  11. Tomas Kolda kolda na web2net.cz #mcbdc6f
    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
  12. Jan Bilak jan.bilak.osm na gmail.com #m6378d0
    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 2010/2/23 Tomas Kolda <kolda na web2net.cz>:
  13. jzvc jzvc na tpfree.fdns.net #mefe6bb
    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.
  14. Tomas Kolda kolda na web2net.cz #m487cee
    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 10000 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
  15. Jan Bilak jan.bilak.osm na gmail.com #mea44cc
    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 <kolda na web2net.cz>:
  16. Jan Dudík jan.dudik na gmail.com #m18bd86
    Mě bohužel spadl celý systém z důvodu jiného programu, takže nepomůžu. J&D 2010/2/23 Tomas Kolda <kolda na 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 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 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 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 :-(... J&D 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 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 <pavel na 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 > > _______________________________________________
    _______________________________________________
    -- -- Ing. Jan Dudík
  17. MP singularita na gmail.com #md3977c
    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
  18. Tomas Kolda kolda na web2net.cz #mf54c64
    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
  19. jzvc jzvc na tpfree.fdns.net #m5a0217
    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
    Pokud to funguje, tak je to default volba - vse v jednom pozadavku. Da se to zmenit na "kazdou zmenu jako samostatny pozadavek" nebo vybrat pocet zmen v pozadavku. Je to aktualne v tabu advanced pri uploadu zmen. JOSM tusim protestuje, pokud by pocet zmen byl prilis velky, tak si vynuti zmenu tohodle nastaveni.
  20. jzvc jzvc na tpfree.fdns.net #m09f761
    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
    Tu jsem pouzil ja, ostatni ji pouzivam (pokud zrovna nezbuchne) prakticky vzdy, ale i tak mi to prislo pomale.
  21. Pavel Machek pavel na ucw.cz #mfc40e1
    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 ....
    ...a kdyz se mezi tim podiva, jestli to tam uz nahodou neni, tak mu server rekne ze neni, protoze stale jeste uklada :-(. Takze jeste jednou sorry za duplicity. Pavel
  22. Pavel Machek pavel na ucw.cz #m2c31ca
    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]
    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.
    Ono to vypadalo tak ze to behem par vterin poslalo ten megabyte, a pak se nic nedelo -- server zrejme 30 minut ukladal do databaze... Pavel
  23. jzvc jzvc na tpfree.fdns.net #m6eda7b
    Jen pro informaci, data jsou v nekterych miste ponekud (vice) zastarala, me napriklad do Teplic import umistil (nekonfliktni) vodni plochu, ktera tam uz dobre 10, mozna 15let neni (koupaliste Anger). To jen az se budete divit, ze mate za domem rybnik, ktery jste nikdy nevideli :D.
  24. Pavel Zbytovský mail na zby.cz #mb23a79
    Tohle je hloupé, také jsem u sebe potkal různá podivná nebo i nepravdivá data. Je možné to někam hlásit, aby si to v DIBAVODu opravili? 2010/3/1 jzvc <jzvc na tpfree.fdns.net>
  25. hanoj ehanoj na gmail.com #m481fc5
    To by bylo dobre, co trebas zalozit stranku na nasi wiki? hanoj 2010/3/1 Pavel Zbytovský <mail na zby.cz>:
  26. Pavel Pilát pavel.pilat na gmail.com #m894968
    Import dibavod je fajn, kolem Napajedel si to už kontroluju. Jen přemýšlím, proč je to otagováno jako landuse=reservoir, ale určitě to důvod má. Pouze tady kolem mě je to samé mrtvé rameno a spíš natural=water... Pontiac_CZ
  27. Frettie frettie na gmail.com #ma2f097
    Souhlasím, taky na to teď koukám a je to krásný, až budu mít víc času, tak zkontroluju přesnost, ale tak podle oka je to báječný. Mimojiné, koukal jsem, že už pokročili i katastry, taky WOW. JS. 2010/3/8 Pavel Pilát <pavel.pilat na gmail.com>:
  28. Petr Dlouhý petr.dlouhy na email.cz #m00e65a
    Ahoj, pravděpodobně v DIBAVODU ta informace nebyla, takže nezbývá, než to ručně změnit. On Mon, 08 Mar 2010 19:31:54 +0100, Pavel Pilát <pavel.pilat na gmail.com>
  29. Tomáš Kolda kolda na web2net.cz #m8d209d
    Ano je to tak. Zatim se importoval soubor DIBAVOD nadrze. Zadne dalsi rozliseni nebylo, takze se dalo reservoir. Tomas
  30. jzvc jzvc na tpfree.fdns.net #mb45f57
    Import dibavod je fajn, kolem Napajedel si to už kontroluju. Jen přemýšlím, proč je to otagováno jako landuse=reservoir, ale určitě to důvod má. Pouze tady kolem mě je to samé mrtvé rameno a spíš natural=water...
    Protoze se to z te hromady dat neda urcit. U tech par souboru co sem delal sem to v pripade ze slo napriklad o ricni breh pretagoval. Ale coz, ono se to casem nejak spravi, hlavne ze je co opravovat :D.
  31. Pavel Machek pavel na ucw.cz #m2cb2fc
    To by bylo dobre, co trebas zalozit stranku na nasi wiki?
    Ma to cenu psat na wiki? Ja bych si predstavoval ze se zastarala data proste smazou... Pavel
  32. jzvc jzvc na tpfree.fdns.net #m85cc69
    To by bylo dobre, co trebas zalozit stranku na nasi wiki?
    Ma to cenu psat na wiki? Ja bych si predstavoval ze se zastarala data proste smazou... Pavel
    Tj, ale bylo to mysleno tak, ze by se zdroji mohlo rict, ze tam maj stary data a jaky, a necht si to opravi.
  33. Pavel Zbytovský mail na zby.cz #m881c39
    Ahoj, pokusil jsem se importovat data z areas_conflict_170.xml, ale narazil jsem docela na problém. Kontroloval jsem data podle Cenie a převážná většina nádrží byla zvětšených nebo jinak zásadně upravených. Všechny nádrže tam samozřejmě jsou z místních survey. Přestože jsou hodně střílené od oka, tak ale více odpovídají skutečnosti (cenii) než z toho dibavodu. Teď co s tím. *Jednak z hlediska importu* - podle Cenie lze jen kontrolovat, takže jsem zachovával buď jeden nebo druhý, podle toho, který byl aktuálnější. Což ovšem znamenalo, že jsem skoro všude nechal ty staré. Je vhodné zachovávat i to IDčko u těch "aktuálnějších" tvarů? Jednak také co *z hlediska datasetu* - většina nádrží neodpovídají skutečnosti a troufám si říct, že mnoho těch nekonfliktních bude taky hodně vedle. Třeba: * id:105040060017 - špatný tvar nádrže * id:105040070003 - špatný tvar nádrže, chybí name=Ctěnický rybník * id:105040060019 - špatný tvar nádrže, chybí name=Biologický rybník * id:105040060018 - špatný tvar nádrže * id:105040060002 - špatný tvar nádrže Rád bych, kdyby se nám povedlo vrátit nějaké updaty zpět do dibavodu, byla by to pěkná ukázka, že se úřadům vyplatí otevírat data, protože komunita je schopna nabídnout velkou kontrolní sílu a hodnotu nazpět. Stejně ty konfliktní importy všechny ručně procházíme, takže pro nás by to nebyla práce navíc. Už výše jsme s tím tady nic moc kloudného nevymysleli. Nevíte, kdo to vlastně s úřadem komunikoval, asi by bylo rozumné aby s úřadem mailoval případně on. A ještě mimochodem, jak je na tom import potoků a řek? wiki stránka se o něm nezmiňuje. Hezký den vám všem, Pavel Zbytovský aka zbycz 2010/3/10 jzvc <jzvc na tpfree.fdns.net>
  34. Jan Dudík jan.dudik na gmail.com #m3ec0c2
    Sám jsem naimportoval asi 30 areas,, v jednom souboru jsem z 20 nádrží nechal 15 původních, protože byly zjevně podobnější skutečnosti. Jednalo se tuším o oblast někde mezi Tachovem a M. Lázněmi. J&D 2010/4/26 Pavel Zbytovský <mail na zby.cz>:
  35. jzvc jzvc na tpfree.fdns.net #m4ed405
    Ahoj, pokusil jsem se importovat data z areas_conflict_170.xml, ale narazil jsem docela na problém. Kontroloval jsem data podle Cenie a převážná většina nádrží byla zvětšených nebo jinak zásadně upravených. Všechny nádrže tam samozřejmě jsou z místních survey. Přestože jsou hodně střílené od oka, tak ale více odpovídají skutečnosti (cenii) než z toho dibavodu. Teď co s tím. *Jednak z hlediska importu* - podle Cenie lze jen kontrolovat, takže jsem zachovával buď jeden nebo druhý, podle toho, který byl aktuálnější. Což ovšem znamenalo, že jsem skoro všude nechal ty staré. Je vhodné zachovávat i to IDčko u těch "aktuálnějších" tvarů?
    Jo, ID zachovat, muze se hodit.
    Jednak také co *z hlediska datasetu* - většina nádrží neodpovídají skutečnosti a troufám si říct, že mnoho těch nekonfliktních bude taky hodně vedle. Třeba: * id:105040060017 - špatný tvar nádrže * id:105040070003 - špatný tvar nádrže, chybí name=Ctěnický rybník * id:105040060019 - špatný tvar nádrže, chybí name=Biologický rybník * id:105040060018 - špatný tvar nádrže * id:105040060002 - špatný tvar nádrže
    Nekonflikni napriklad udelaly vodu tam, kde uz desiky let zadna neni, dibavod ma poradne zastaraly data. Zatim sem to nechal byt, prave proto, ze by nebylo od veci se snima nako dohodnout na nejaky zpetny vazbe.
    Rád bych, kdyby se nám povedlo vrátit nějaké updaty zpět do dibavodu, byla by to pěkná ukázka, že se úřadům vyplatí otevírat data, protože komunita je schopna nabídnout velkou kontrolní sílu a hodnotu nazpět. Stejně ty konfliktní importy všechny ručně procházíme, takže pro nás by to nebyla práce navíc. Už výše jsme s tím tady nic moc kloudného nevymysleli. Nevíte, kdo to vlastně s úřadem komunikoval, asi by bylo rozumné aby s úřadem mailoval případně on. A ještě mimochodem, jak je na tom import potoků a řek? wiki stránka se o něm nezmiňuje.
    Pokud vim, tak toto (vodni plochy) byl prakticky jeden soubor prohnanej pres detektor kolizi a rozparcelovanej po unosnym poctu 20/soubor. S vodnimi toky to bude mozna horsi, protoze detekovat kolize bude asi tezsi, takze pocitam ze to bude vic rucni prace.
  36. Pavel Zbytovský mail na zby.cz #mf23ff3
    Jo, ID zachovat, muze se hodit.
    Napsal jsem to na wiki, chybí tam ještě link na nějakou úvodní konferu.. Pro někoho kdo do problému třeba teď vstoupil tam prostě chybí trocha informací.
    dohodnout na nejaky zpetny vazbe.
    lepší by to bylo vědět teď, když už to stejně musíme procházet ručně. Co bude v osm datech za pár měsíců už není tak spolehlivé ... "můžeme reportovat chybějící rybník nebo ho někdo smazal omylem?" :-)
  37. Stanislav Brabec utx na penguin.cz #med52c2
    Pavel Zbytovský píše v St 28. 04. 2010 v 16:45 +0200:
    Jo, ID zachovat, muze se hodit.
    Napsal jsem to na wiki, chybí tam ještě link na nějakou úvodní konferu.. Pro někoho kdo do problému třeba teď vstoupil tam prostě chybí trocha informací.
    dohodnout na nejaky zpetny vazbe.
    lepší by to bylo vědět teď, když už to stejně musíme procházet ručně. Co bude v osm datech za pár měsíců už není tak spolehlivé ... "můžeme reportovat chybějící rybník nebo ho někdo smazal omylem?" :-)
    Existuje už někde databáze nebo stránka pro zadávání chybných dat v DIBAVOD, případně nějaký způsob, jak to odtagovat přímo v mapě? Narazil jsem na dva rybníčky v místech, kde dnes stojí domy (zatím ověřeno pouze podle ortofoto): http://www.openstreetmap.org/?lat=49.085642&lon=14.71834&zoom=18&layers=B000FTF Stanislav Brabec http://www.penguin.cz/~utx
  38. Pavel Zbytovský mail na zby.cz #m2a49a4
    Napsal jsem na wiki návrh, jak bychom ta chybná data mohli systémově označit: http://wiki.openstreetmap.org/wiki/Import_DIBAVOD Předpokládám, že wiki zas tolik lidí nečte, takže můžeme ještě vymyslet změnu - klidně to tam upravte, ale přijde mi to takto funkční. Pavel Zbytovský 2010/5/4 Stanislav Brabec <utx na penguin.cz>
  39. Stanislav Brabec utx na penguin.cz #m7876b7
    Pavel Zbytovský píše v St 19. 05. 2010 v 21:46 +0200:
    Napsal jsem na wiki návrh, jak bychom ta chybná data mohli systémově označit: http://wiki.openstreetmap.org/wiki/Import_DIBAVOD Předpokládám, že wiki zas tolik lidí nečte, takže můžeme ještě vymyslet změnu - klidně to tam upravte, ale přijde mi to takto funkční.
    Ještě vymyslet způsob, jak vyznačit, že vodní plocha již neexistuje. Odstranit hlavní tag, a zbytek ponechat, a smazat při příštím importu? Stanislav Brabec http://www.penguin.cz/~utx
  40. Jan Dudík jan.dudik na gmail.com #mc67855
    Vím o místě, kde byl v importu rybník, ale v OSM ani ve skutečnosti už není. Dá se nějak rozumně zjistit historie oblasti? historie na OSM mi totiž ukáže i změny stovky kilometrů daleko. A dá se najít jak vypadala oblast k určitému datu, včetně smazaných věcí? J&D 2010/5/19 Stanislav Brabec <utx na penguin.cz>:
  41. jzvc jzvc na tpfree.fdns.net #m6fb61d
    Vím o místě, kde byl v importu rybník, ale v OSM ani ve skutečnosti už není. Dá se nějak rozumně zjistit historie oblasti? historie na OSM mi totiž ukáže i změny stovky kilometrů daleko. A dá se najít jak vypadala oblast k určitému datu, včetně smazaných věcí?
    Melo by jit stahnout changesety ktere nejak zasahovaly do vybrane oblasti, pokud je dotycny alespon trochu komentuje, tak se da zjistit ktery to byl.
  42. Jan Dudík jan.dudik na gmail.com #m0375c0
    Jenže to je ten problém, že changesety pro naši vesnici o 500 obyvatelích jsou často typu "robotická oprava názů vesnic v celém rakousku" [1], takže i věc stará jen pár dnů už je na několikáté stránce s historií (navíc tam medle dřív bývalo datum, a teď ne), která je navíc neskutečně pomalá. Třeba tenhle konkrétní asi dohledat dokážu, protože to byla moje editace, ale přiznejme si, kdo z nás podrobně popisuje změny? zvlášť když dělám najednou větší oblast napíšu třeba "ČB a okolí" ... [1] http://www.openstreetmap.org/history?bbox=14.49229%2C48.925727%2C14.497805%2C48.928504 J&D
  43. Zdeněk Pražák ZPrazak na seznam.cz #m85ef2c
    Dobře, projdu tedy mnou importované konfliktní oblasti a doplním tagy u změněných rybníků a neexistující rybníky Pražák
  44. Pavel Zbytovský mail na zby.cz #m5385be
    Vím o místě, kde byl v importu rybník, ale v OSM ani ve skutečnosti už není. Dá se nějak rozumně zjistit historie oblasti? historie na OSM mi totiž ukáže i změny stovky kilometrů daleko. A dá se najít jak vypadala oblast k určitému datu, včetně smazaných věcí? J&D
    Jediné co by mohlo posloužit je http://www.web2net.cz/osm/dibavod/ -vytáhnout si "svou" oblast a podívat se co přibylo do "prázdných" -bezkonfliktních míst. Bohužel v OSM se nedá uložit informace, že tam rybník už není, takže nikdo pořádně neví, jestli tam býval nebo jen nebyl ještě zmapován. Otázkou je jestli používat třeba reservoir=no :-))) Jasně, že nepoužívat, ale tohle je nedořešeno - když mapper smaže v místě bydliště třeba barák, protože ho včera zbourali, může zítra přijít dobrá duše a namapovat ho znovu podle km+uhul. Jediné řešení mě napadá místo smazaného objektu hned dát alespoň village_green, to dobrou duši upozorní, že tu něco nehraje. A ještě jedna myšlenka - nechtělo by to nějak datům z dibavodu připsat, že byla někým ověřena? Vlastně všechny konfliktní (ruční importy) status ověřenosti mají, kdyžto ten automatický (bezkonfliktní) import může být místy dost vedle. Hmm, to je asi blbost, to bychom nakonec mohli každému objektu dávat atribut vyžaduje kontrolu, ale kdo by to dělal? :) Hezký den, Pavel Zbytovský
  45. Jan Dudík jan.dudik na gmail.com #mb5e782
    Ovšem to by muselo být poznat, který paklík je která oblast. a zkoušet hledat zkusmo, ve kterém z několika set souborů je ten konkrétní rybník... Navíc to byl určitě z nekonfliktního importu, vzhledem ke skutečnosti, že na tom místě dnes je silnice...
  46. Vojta vts.vts na gmail.com #mf88fe3
  47. Pavel Machek pavel na ucw.cz #m3896b2
    ...bezi -- tedy doufam, nerusit. Pavel
  48. Zdeněk Pražák ZPrazak na seznam.cz #mb98c10
    Díval jsem se na probíhající import, ale nerozumím tomu. Importují se pouze prázdné body bez žádného tagu ani spojení do cest. Pražák
  49. Jiri Parkan jparkan na gmail.com #m0396ea
    2010/10/14 Zdeněk Pražák <ZPrazak na seznam.cz>:
    Díval jsem se na probíhající import, ale nerozumím tomu. Importují se pouze prázdné body bez žádného tagu ani spojení do cest. Pražák
    Předpokládám že cesty se budou importovat následně, stejně jako tomu bylo u administrativních hranic. Mě by spíš zajímalo jestli jsou nějak řešené konflikty, některé body jsem viděl u zakreslených řek. Parkis
  50. Jan Dudík jan.dudik na gmail.com #m773e68
    STejně to probíhalo u rybníků - nejdřív se nahrají body a až na závěr spojnice, takže dokud probíhá, nerušit, maximálně by nastal konflikt. J&D 2010/10/14 Zdeněk Pražák <ZPrazak na seznam.cz>:
    Díval jsem se na probíhající import, ale nerozumím tomu. Importují se pouze prázdné body bez žádného tagu ani spojení do cest. Pražák
    ---------------------------------------- ...bezi -- tedy doufam, nerusit. Pavel
    -- -- Ing. Jan Dudík
  51. Petr Dlouhý petr.dlouhy na email.cz #mc579c1
    Při takovém postupu existuje riziko, že o importu někdo nebude vědět, a prázdné body smaže. Nešlo by alespoň k bodům přidat nějakou poznámku?
    ---------------------------------------- STejně to probíhalo u rybníků - nejdřív se nahrají body a až na závěr spojnice, takže dokud probíhá, nerušit, maximálně by nastal konflikt. J&D
    Petr Dlouhý petr.dlouhy na email.cz
  52. Jan Dudík jan.dudik na gmail.com #mb5636e
    No, u rybníků jsem přesně takhle smazal v JOSM nějaké body v průběhu importu, ale při nahrávání jsem dostal hlášený konflikt... J&D 2010/10/14 Petr Dlouhý <petr.dlouhy na email.cz>:
  53. Pavel Machek pavel na ucw.cz #mec8507
    Ahoj!
    Díval jsem se na probíhající import, ale nerozumím tomu. Importují se pouze prázdné body bez žádného tagu ani spojení do cest.
    Sorry, takhle velky mnozstvi dat se uploadujou pomalu. Nejdriv to uploaduje body, pak budou cesty. Pavel
  54. Pavel Machek pavel na ucw.cz #m03774e
    Ahoj!
    Při takovém postupu existuje riziko, že o importu někdo nebude vědět, a prázdné body smaže. Nešlo by alespoň k bodům přidat nějakou poznámku?
    Existuje, snad budu mit stesti. Puvodni plan byl udelat to rychle, ale uplne to nevyslo... Davat tam nejakou poznamku ... to bych ji musel pak mazat, ale mozna jsem mohl dat source= tag i tem bodum. ... zas by to nafouklo data... Pavel
  55. Jan Dudík jan.dudik na gmail.com #m9da352
    a co dát k dispozici data, aby se import rozdělil mezi víc lidí, tak by se i daly ošetřit některé konflikty a duplicity... J&D
    Ahoj!
    Při takovém postupu existuje riziko, že o importu někdo nebude vědět, a prázdné body smaže. Nešlo by alespoň k bodům přidat nějakou poznámku?
    Existuje, snad budu mit stesti. Puvodni plan byl udelat to rychle, ale uplne to nevyslo... Davat tam nejakou poznamku ... to bych ji musel pak mazat, ale mozna jsem mohl dat source= tag i tem bodum. ... zas by to nafouklo data... Pavel
    -- -- Ing. Jan Dudík
  56. Petr Dlouhý petr.dlouhy na email.cz #m90d0fa
    Super, už se začínají objevovat nové potoky (např. na Šumavě). Koukám, že tam ale je několik problémů: 1) Vodní toky, které byli označeny v OSM jako "river" jsou v importu jako "stream". Rozlišují nějak importovaná data řeky? Od jaké je to velikosti? Bude nutné větší toky přetagovat tak aby vyhovovaly hranici uznávané v OSM, tedy přeskočitelnosti? 2) Jak jsou data přesná a stará? Předpokládám, že v naprosté většině případů budou data z Dibavodu přesnější, než to co je v OSM. Znamená to tedy, že je vhodné smazat původní vodní tok, pokud narazím na nějakou duplicitu a do nových pouze doplnit některé tedy (pokud tam nebudou)? 3) V importovaných datech se používají zkratky (Hamerský p.), což je v OSM obecně nedoporučovaná praktika. Nešlo by názvy toků v importovaných datech ještě automaticky doplnit?
  57. Michal Grézl michal.grezl na openstreetmap.cz #m87b119
    2010/10/16 Petr Dlouhý <petr.dlouhy na email.cz>: ...
    2) Jak jsou data přesná a stará? Předpokládám, že v naprosté většině případů budou data z Dibavodu přesnější, než to co je v OSM. Znamená to tedy, že je vhodné smazat původní vodní tok, pokud narazím na nějakou duplicitu a do nových pouze doplnit některé tedy (pokud tam nebudou)?
    pokud to bude jak vodni plochy, tak budou sice superpresna, ale nesmirne stara, radeji necham reku co sem kreslil podle uhulu a gps, nez 20 let stare data. ...
  58. Pavel Machek pavel na ucw.cz #m0d72e9
    Ahoj!
    Super, už se začínají objevovat nové potoky (např. na Šumavě). Koukám, že tam ale je několik problémů:
    Jo jo, prosim jeste chvili nesahat.
    1) Vodní toky, které byli označeny v OSM jako "river" jsou v importu jako "stream". Rozlišují nějak importovaná data řeky? Od jaké je to velikosti? Bude nutné větší toky přetagovat tak aby vyhovovaly hranici uznávané v OSM, tedy přeskočitelnosti?
    Bude nutne pretagovat. Vsemu jsem dal stream, protoze IMO potoku bude vic nez rek; predpokladam ze se to udela pri rucni kontrole duplicit.
    2) Jak jsou data přesná a stará? Předpokládám, že v naprosté většině případů budou data z Dibavodu přesnější, než to co je v OSM. Znamená to tedy, že je vhodné smazat původní vodní tok, pokud narazím na nějakou duplicitu a do nových pouze doplnit některé tedy (pokud tam nebudou)?
    Presna vypadaji, stara nevim. Casto asi budou lepsi...
    3) V importovaných datech se používají zkratky (Hamerský p.), což je v OSM obecně nedoporučovaná praktika. Nešlo by názvy toků v importovaných datech ještě automaticky doplnit?
    To bych kdyztak udelal po importu pres xapi. Hmm... aha, ono to je v prevazny vetsine jmen. No, u tech co uz se importujou to zmenit nemuzu, v ty druhy casti bych to asi mohl opravit sed-em. Zkusim. Pavel
  59. Pavel Machek pavel na ucw.cz #m86f01c
    Ahoj!
    1) Vodní toky, které byli označeny v OSM jako "river" jsou v importu jako "stream". Rozlišují nějak importovaná data řeky? Od jaké je to velikosti? Bude nutné větší toky přetagovat tak aby vyhovovaly hranici uznávané v OSM, tedy přeskočitelnosti?
    Bude nutne pretagovat. Vsemu jsem dal stream, protoze IMO potoku bude vic nez rek; predpokladam ze se to udela pri rucni kontrole duplicit.
    Napada me... mozna by slo automaticky dat "river" vsemu co a) je z dibavod importu b) ma jmeno c) jmeno nekonci na "potok" nebo "p." Chce si nekdo pohrat s xapi? Na druhou stranu... rek je malo a stejne budou duplicitni... (Ale prosim az bude hotov import). Pavel
  60. Jan Masopust masopust.jan na gmail.com #mc56d0e
    3) V importovaných datech se používají zkratky (Hamerský p.), což je v OSM obecně nedoporučovaná praktika. Nešlo by názvy toků v importovaných datech ještě automaticky doplnit?
    To bych kdyztak udelal po importu pres xapi. Hmm... aha, ono to je v prevazny vetsine jmen. No, u tech co uz se importujou to zmenit nemuzu, v ty druhy casti bych to asi mohl opravit sed-em. Zkusim.
    Jestli to bude někdo hromadně přejmenovávat, tak by bylo dobré tam ještě zařadit z minulého importu ryb. na rybník a v.n. na vodní nádrž masox
  61. Pavel Machek pavel na ucw.cz #m73aa30
    Ahoj!
    Super, už se začínají objevovat nové potoky (např. na Šumavě). Koukám, že tam ale je několik problémů:
    Jo jo, prosim jeste chvili nesahat.
    Tak si nekdo sahnul :-(. Uvidime, co s tim pujde udelat. Jeste chvili prosim nesahat at to neni horsi nez to je... Pavel
  62. Michal Grézl michal.grezl na openstreetmap.cz #m4c6fdb
    2010/10/17 Pavel Machek <pavel na ucw.cz>:
    Ahoj!
    Super, už se začínají objevovat nové potoky (např. na Šumavě). Koukám, že tam ale je několik problémů:
    Jo jo, prosim jeste chvili nesahat.
    Tak si nekdo sahnul :-(. Uvidime, co s tim pujde udelat. Jeste chvili prosim nesahat at to neni horsi nez to je... Pavel
    jak dlouho to jeste bude zhruba trvat, strasne nutne potrebuju odmazat ty stary potoky kresleny podle katastru:)
  63. Pavel Machek pavel na ucw.cz #m393476
    Ahoj!
    Super, už se začínají objevovat nové potoky (např. na Šumavě). Koukám, že tam ale je několik problémů:
    Jo jo, prosim jeste chvili nesahat.
    Tak si nekdo sahnul :-(. Uvidime, co s tim pujde udelat. Jeste chvili prosim nesahat at to neni horsi nez to je...
    jak dlouho to jeste bude zhruba trvat, strasne nutne potrebuju odmazat ty stary potoky kresleny podle katastru:)
    S trochou stesti to dobehne dneska v noci. Na lon 15-16 chybel jediny node. Bohuzel na lon 14-15 chybelo nodu tolik, ze uz to nebylo unosny opravovat rucne, takze to uploaduju uplne jinym skriptem. Ochadem 10% way se odmita uploadovat :-(((. Takze jeste bude co cistit :-(. Pavel
  64. Pavel Machek pavel na ucw.cz #mc50054
    Ahoj!
    Super, už se začínají objevovat nové potoky (např. na Šumavě). Koukám, že tam ale je několik problémů:
    Jo jo, prosim jeste chvili nesahat.
    Tak si nekdo sahnul :-(. Uvidime, co s tim pujde udelat. Jeste chvili prosim nesahat at to neni horsi nez to je...
    jak dlouho to jeste bude zhruba trvat, strasne nutne potrebuju odmazat ty stary potoky kresleny podle katastru:)
    S trochou stesti to dobehne dneska v noci. Na lon 15-16 chybel jediny node. Bohuzel na lon 14-15 chybelo nodu tolik, ze uz to nebylo unosny opravovat rucne, takze to uploaduju uplne jinym skriptem. Ochadem 10% way se odmita uploadovat :-(((. Takze jeste bude co cistit :-(.
    Aha, a to znamena: mezi lon 14 a 15 prosim porad jeste nesahat. Asi to bude chtit stahnout data pomoci xapi, a potom znovu uploadnout to co se nepodarilo uploadnout na prvni pokus. Pavel
  65. Pavel Machek pavel na ucw.cz #m07f232
    Ahoj!
    Díval jsem se na probíhající import, ale nerozumím tomu. Importují se pouze prázdné body bez žádného tagu ani spojení do cest. Pražák
    Předpokládám že cesty se budou importovat následně, stejně jako tomu bylo u administrativních hranic. Mě by spíš zajímalo jestli jsou nějak řešené konflikty, některé body jsem viděl u zakreslených řek.
    Konflikty se udelaji rucne az to bude uploadovane... bude potreba: 1) vybrat ze dvou rek tu hezci, a tu druhou smazat 2) u toho co je reka a ne potok zmenit tag na waterway=river. (je tam waterway=stream, protoze potoku je podstatne vic nez rek). 3) napojit na existujici data 4) pospojovat na hranicich celeho stupne (Ale zatim prosim jen mimo lon 14 a 15). Pavel
  66. Zdeněk Pražák ZPrazak na seznam.cz #md62118
    Dotazy k jednotlivým bodům: 1) Bude tedy někde k disposici seznam konfliktních úseků řek nebo se budou muset hledat. 3) co se rozumí pod pojmem napojit na stávající data? Pražák
  67. Michal Grézl michal.grezl na openstreetmap.cz #m48935b
    2010/10/20 Zdeněk Pražák <ZPrazak na seznam.cz>:
    Dotazy k jednotlivým bodům: 1) Bude tedy někde k disposici seznam konfliktních úseků řek nebo se budou muset hledat.
    Napriklad tam, kde se pohybuji ja je konfliktni vsechno. To znamena ze vsechny reky a potoky co sem kdy zadal jsou ted 2x.
  68. Marek Prokop marek na sovavsiti.cz #mcfc231
    Ahoj,
    Napriklad tam, kde se pohybuji ja je konfliktni vsechno. To znamena ze vsechny reky a potoky co sem kdy zadal jsou ted 2x.
    Ha! Koukám, že jsem Doubravu zakreslil velmi přesně. Už tedy můžeme opravovat? Zdraví, Marek Prokop
  69. Pavel Machek pavel na ucw.cz #m6e4d0d
    Ahoj!
    Dotazy k jednotlivým bodům: 1) Bude tedy někde k disposici seznam konfliktních úseků řek nebo se budou muset hledat.
    Zatim ho nikdo nevygeneroval, tak asi nebude. Jestli ho nekdo chce vygenerovat, melo by to jit na zaklade dumpu cr, import je jasne oznacen. Hmm.. ve skutecnosti staci stahnout dump z doby pred importem, vyfiltrovat na waterway=, a to budou prave konflikty.
    3) co se rozumí pod pojmem napojit na stávající data?
    No, asi by bylo dobre udelat kdyz se potok a vleva do potoku b, tak aby sdileli bod. Pavel
  70. MP singularita na gmail.com #m18efc2
    Hmm.. ve skutecnosti staci stahnout dump z doby pred importem, vyfiltrovat na waterway=, a to budou prave konflikty.
    To bude fungovat nejaky cas = ale z bude vetsi cast CR opravena (i kdyz to bude nejaky cas trvat), tak to bude chtit neco, co projde cely dump a najde krizici se cesty. V soucasnem stavu vzhledem k tomu, ze i pred importem bylo v mape relativne dost vodnich cest, tak staci najet na nahodne misto v CR, nahrat do editoru ctverec tak 5x5 km a urcite tam minimalne par konfliktu bude :) Mozna bych casem mohl napsat neco co projde dump a vyplivne vsechny cesty co se nejak nekde s necim krizi .... nebo na tohle uz existuje nejaky nastroj? Martin
  71. Zdeněk Pražák ZPrazak na seznam.cz #m21fb03
    nedá se k tomu využít OSM Inspector ? viz http://tools.geofabrik.de/osmi/Pražák
  72. "Petr Morávek [Xificurk]" xificurk na gmail.com #me921ab
    Mozna bych casem mohl napsat neco co projde dump a vyplivne vsechny cesty co se nejak nekde s necim krizi .... nebo na tohle uz existuje nejaky nastroj?
    http://keepright.ipax.at
  73. Tomáš Tichý t.tichy na post.cz #mf7685a
    Dá se k tomu použít keepright, http://keepright.ipax.at/ V levém sloupečku zaškrtněte intersections without junctions, waterway-waterway a ukáže to všechny zkřížené řeky. TT 2010/10/25 Zdeněk Pražák <ZPrazak na seznam.cz>:
  74. jzvc jzvc na tpfree.fdns.net #mc48307
    Koukam ze ty data teda nic moc. Ted prave resim dilema. Verit smeru potoka z dibavodu nebo km ??? Jelikoz v importu jsou potoky v trasach, kudy uz desitky let nevedou, tak mi duveryhodnejsi prijde km. Obdobne pokud vedou dva potoky do rybnika a zadnej ven ...
Napsat odpověď e-mailem… Odpovědět

Otevře váš e-mailový klient. Odpovědi pak sledujte zde na webu.