Bordel

13 zpráv
Zpět na přehled

Bordel

13 zpráv MPPMMJ 6 účastníků 10 min čtení
  1. Petr Vejsada osm na propsychology.cz #m5e7828
    Ahoj, právě mažu přes 200 tisíc osiřelých uzlů. Wtf? http://www.openstreetmap.org/changeset/30794706
  2. Marián Kyral mkyral na email.cz #me78f7c
    Ahoj, můžeš udělat nějakou statistiku? Stáří, changesety, uživatelé? Co jsem tak namátkou prošel, všechno to byly uzly staré dva měsíce od jednoho uživatele. Možná nějaký dočasný problém. Ať už JOSM nebo OSM API? Marián
  3. Martin Ždila martin.zdila na freemap.sk #meac4df
    Mozno by tu bolo na mieste pouzit JOSM reverter plugin. 2015-05-05 2:41 GMT+02:00 Petr Vejsada <osm na propsychology.cz>:
    Ahoj, právě mažu přes 200 tisíc osiřelých uzlů. Wtf? http://www.openstreetmap.org/changeset/30794706
    -- Ing. Martin Ždila <http://www.openstreetmap.org/user/*Martin*> OZ Freemap Slovakia tel:+421-908-363-848 mailto:martin.zdila na freemap.sk http://www.freemap.sk/
  4. Marián Kyral mkyral na email.cz #m7a9031
    V té době to bylo asi nejlepší a nejrychlejší řešení. Ale raději alespoň takhle než vůbec. On ten reverter plugin to udělá skoro stejně - dané uzly smaže. A Zdeněk v tom není sám, našel jsem ještě jeden problémový changeset od jiného uživatele. A možná je jich více. Ono vůbec nejlepší řešení by bylo to nějak ošetřit v JOSM. Tedy, že by si editor takovéto situace pohlídal a v případě problémů s nahráním changesetu by navázal tam, kde přestal. Ale tohle asi bude trochu více komplikovanější. Další možnost je upravit pořadí, jakým se data nahrávají. Momentálně se nejprve nahrají všechny uzly, pak všechny cesty a nakonec všechny relace. Když se nahrávání ukončí někde uprostřed, tak tam zůstanou bezprizorní body. Ideální by bylo, kdyby se vždy nahrály body jen k jedné cestě, hned na to cesta, pak další body a další cesta. Když to pak někde spadne, tak možná nějaké bezprizorní body zůstanou, ale nebude jich moc. A úplně nejlepší by bylo, kdyby OSM API podporovalo nějakou kontrolu konzistence dat. Marián Ing. Martin Ždila OZ Freemap Slovakia tel:+421-908-363-848 mailto:martin.zdila na freemap.sk http://www.freemap.sk/
  5. Petr Vejsada osm na propsychology.cz #mf869bc
    Ahoj,
    V té době to bylo asi nejlepší a nejrychlejší řešení. Ale raději alespoň takhle než vůbec. On ten reverter plugin to udělá skoro stejně - dané uzly smaže.
    já tohleto (mazání bezprizorních entit) dělám už delší dobu, ale takováto porce nebyla ještě nikdy - ani když jsem to dělal poprvé. Poprvé to bylo kolem 100k uzlů. Přes 200k uzlů - to je 5 changesetů. Co jsem si to zběžně prohlížel, tak některé tyto bezprizorní uzly dokonce pocházely z changesetu, který byl okomentován sám o sobě jako revert.
    Ono vůbec nejlepší řešení by bylo to nějak ošetřit v JOSM. Tedy, že by si editor takovéto situace pohlídal a v případě problémů s nahráním changesetu by navázal tam, kde přestal. Ale tohle asi bude trochu více komplikovanější.
    Tohle IMO JOSM dělá. Už mi dlouho nahrávání nespadlo, ale co pamatuji, tak když mi spadlo, tak JOSM navázal. Toto samozřejmě nemůže platit, když spadne samotný JOSM.
  6. Petr Holub hopet na ics.muni.cz #mb3014a
    Ono vůbec nejlepší řešení by bylo to nějak ošetřit v JOSM. Tedy, že by si editor takovéto situace pohlídal a v případě problémů s nahráním changesetu by navázal tam, kde přestal. Ale tohle asi bude trochu více komplikovanější.
    Tohle IMO JOSM dělá. Už mi dlouho nahrávání nespadlo, ale co pamatuji, tak když mi spadlo, tak JOSM navázal.
    Problém nastane v okamžiku, kdy ten changeset zůstane dlouho otevřený. Pak dojde k jeho automatickému uzavření a JOSM už navázat nedokáže. Typicky to může nastat, když člověk pustí nahrávání velké várky přes noc, jde spat a ráno pak zjistí, že třeba upadla síť. Bohužel s tím mám taky blbou osobní zkušenost... Petr
  7. Marián Kyral mkyral na email.cz #m427e5b
    "Ahoj, prohlížel, tak některé tyto bezprizorní uzly dokonce pocházely z changesetu, který byl okomentován sám o sobě jako revert. Pěkné.
    Ono vůbec nejlepší řešení by bylo to nějak ošetřit v JOSM. Tedy, že by si editor takovéto situace pohlídal a v případě problémů s nahráním
    changesetu
    by navázal tam, kde přestal. Ale tohle asi bude trochu více
    komplikovanější. Tohle IMO JOSM dělá. Už mi dlouho nahrávání nespadlo, ale co pamatuji, tak když mi spadlo, tak JOSM navázal. Toto samozřejmě nemůže platit, když spadne samotný JOSM. Proč by nemohlo? Když spadne, tak ti taky při startu napíše, že našel neuložené změny. Stejně tak dobře může napsat, že detekoval nedokončené nahrávání a nabídl jeho dokončení nebo revert. Samotný proces bych si představoval tak, že z OSM stáhne aktuální stav, spáruje data (body, uzly, relace) a nahrávání dokončí. Nebo prostě revertuje poslední changeset, jehož číslo si uložil na začátku nahrávání. Marián
  8. Marián Kyral mkyral na email.cz #mbb5a62
    "> > Ono vůbec nejlepší řešení by bylo to nějak ošetřit v JOSM. Tedy, že by si
    editor takovéto situace pohlídal a v případě problémů s nahráním
    changesetu
    by navázal tam, kde přestal. Ale tohle asi bude trochu více
    komplikovanější.
    Tohle IMO JOSM dělá. Už mi dlouho nahrávání nespadlo, ale co pamatuji, tak když mi spadlo, tak JOSM navázal.
    Problém nastane v okamžiku, kdy ten changeset zůstane dlouho otevřený. Pak dojde k jeho automatickému uzavření a JOSM už navázat nedokáže. Typicky to může nastat, když člověk pustí nahrávání velké várky přes noc, jde spat a ráno pak zjistí, že třeba upadla síť. Bohužel s tím mám taky blbou osobní zkušenost... Nemusí to nahrávat do stejného changesetu. Může otevřít další. Ale podstatné je, aby se všechny změny dostaly na OSM server. Že to bude ve více kouscích není podstatné. Marián Petr
  9. Petr Holub hopet na ics.muni.cz #m22ae31
    Problém nastane v okamžiku, kdy ten changeset zůstane dlouho otevřený. Pak dojde k jeho automatickému uzavření a JOSM už navázat nedokáže. Typicky to může nastat, když člověk pustí nahrávání velké várky přes noc, jde spat a ráno pak zjistí, že třeba upadla síť. Bohužel s tím mám taky blbou osobní zkušenost... Nemusí to nahrávat do stejného changesetu. Může otevřít další. Ale podstatné je, aby se všechny změny dostaly na OSM server. Že to bude ve více kouscích není podstatné.
    Jo, to je jasné - bohužel jsem narazil na situaci, kdy dokončení takto přerušeného importu v následujícím importu vyvolalo řadu konfliktů a byla s tím strašná práce. Petr
  10. Martin Švec - OSM osm na maatts.cz #mf76e2c
    Ahoj, Petře, můžeš vytáhnout něco jako "SELECT changeset_id, user, COUNT(sirotci) ... GROUP BY changeset_id v kterém uzly osiřely"? Namátkou to vypadá jen na pár changesetů. Rád bych vyloučil chybu v Traceru. Btw, nedávno jsem při nahrávání LPISu narazil na zajímavou haluz -- v changesetu se mi náhodně zdvojily cesty LPIS polí. Duplikáty měly stejné tagy a sdílely všechny svoje uzly. Jako kdyby JOSM nahrál část nových cest a relací dvakrát za sebou. Objevil jsem je až za měsíc v Osmose, byl to jeden konkrétní changeset. Tracer to (doufám) udělat nemohl, to bych hned viděl, dvojitá pole měla v JOSM tmavší barvu. Martin
  11. Petr Vejsada osm na propsychology.cz #m2b1a25
    Ahoj,
    Petře, můžeš vytáhnout něco jako "SELECT changeset_id, user, COUNT(sirotci) ... GROUP BY changeset_id v kterém uzly osiřely"? Namátkou to vypadá jen na pár changesetů. Rád bych vyloučil chybu v Traceru.
    já nemám historii, takže nemůžu nalézt changeset, ve kterém uzly osiřely, ale s vysokou pravděpodobností to bude ten changeset poslední. Ledaže by někdo tyto sirotky editoval; těžko. Přikládám group-by changeset i group-by user. <sarkasm>Výsledek asi málokoho překvapí</sarkasm>.
    Btw, nedávno jsem při nahrávání LPISu narazil na zajímavou haluz -- v changesetu se mi náhodně zdvojily cesty LPIS polí. Duplikáty měly stejné tagy a sdílely všechny svoje uzly. Jako kdyby JOSM nahrál část nových cest a relací dvakrát za sebou. Objevil jsem je až za měsíc v Osmose, byl to jeden konkrétní changeset. Tracer to (doufám) udělat nemohl, to bych hned viděl, dvojitá pole měla v JOSM tmavší barvu.
    Tohle se občas, ale opravdu jen občas stane. Nejsem si úplně jist, zda je to softwarem nebo člověkem. Spíš to přisuzuji sobě. Nicméně - pokud jsou oba polygony naprosto stejné, JOSM, doufám, že vždy, zařve. Stalo se mi ovšem i to, že nebyly naprosto stejné. Sdílely třeba všechny uzly až na jeden. To může IMO vzniknout tak, že když se tracuje podruhé, je to jiná situace - na daném místě už landuse je. Co se týká povšimnutí si duplicity, tak nevím, o jaké tmavší barvě to píšeš - to asi hodně závisí na nastavení JOSM. Mám tu skript, který umí najít duplicity či téměř duplicity z LPIS, tak jsem ho teď pustil, ono to bude nějakou dobu chroupat.
  12. Martin Švec - OSM osm na maatts.cz #mcb9243
    Ahoj,
    Ahoj,
    Petře, můžeš vytáhnout něco jako "SELECT changeset_id, user, COUNT(sirotci) ... GROUP BY changeset_id v kterém uzly osiřely"? Namátkou to vypadá jen na pár changesetů. Rád bych vyloučil chybu v Traceru.
    já nemám historii, takže nemůžu nalézt changeset, ve kterém uzly osiřely, ale s vysokou pravděpodobností to bude ten changeset poslední. Ledaže by někdo tyto sirotky editoval; těžko. Přikládám group-by changeset i group-by user. <sarkasm>Výsledek asi málokoho překvapí</sarkasm>.
    :-)) Díky, mrknu na to, příležitostně. Vidím tam i sebe, třeba něco zjistím z logů. Nepamatuju si, že by mi JOSM v posledních měsících křupnul při uploadu.
    Btw, nedávno jsem při nahrávání LPISu narazil na zajímavou haluz -- v changesetu se mi náhodně zdvojily cesty LPIS polí. Duplikáty měly stejné tagy a sdílely všechny svoje uzly. Jako kdyby JOSM nahrál část nových cest a relací dvakrát za sebou. Objevil jsem je až za měsíc v Osmose, byl to jeden konkrétní changeset. Tracer to (doufám) udělat nemohl, to bych hned viděl, dvojitá pole měla v JOSM tmavší barvu.
    Tohle se občas, ale opravdu jen občas stane. Nejsem si úplně jist, zda je to softwarem nebo člověkem. Spíš to přisuzuji sobě. Nicméně - pokud jsou oba polygony naprosto stejné, JOSM, doufám, že vždy, zařve. Stalo se mi ovšem i to, že nebyly naprosto stejné. Sdílely třeba všechny uzly až na jeden. To může IMO vzniknout tak, že když se tracuje podruhé, je to jiná situace - na daném místě už landuse je.
    Já podezírám upload changesetu do OSM. Ty cesty a relace byly _naprosto_ identické, proto je taky našlo Osmose. JOSM validace nic nehlásila, to bych ven nepustil, a trasované polygony vizuálně hlídám jak jen to jde. Každopádně je dobré se občas mrknout do Osmose na svoje chyby. ;-)) Martin
  13. jzvc jzvc na tpfree.net #m4ceafd
    Ahoj,
    Ahoj,
    Petře, můžeš vytáhnout něco jako "SELECT changeset_id, user, COUNT(sirotci) ... GROUP BY changeset_id v kterém uzly osiřely"? Namátkou to vypadá jen na pár changesetů. Rád bych vyloučil chybu v Traceru.
    já nemám historii, takže nemůžu nalézt changeset, ve kterém uzly osiřely, ale s vysokou pravděpodobností to bude ten changeset poslední. Ledaže by někdo tyto sirotky editoval; těžko. Přikládám group-by changeset i group-by user. <sarkasm>Výsledek asi málokoho překvapí</sarkasm>.
    :-)) Díky, mrknu na to, příležitostně. Vidím tam i sebe, třeba něco zjistím z logů. Nepamatuju si, že by mi JOSM v posledních měsících křupnul při uploadu.
    Btw, nedávno jsem při nahrávání LPISu narazil na zajímavou haluz -- v changesetu se mi náhodně zdvojily cesty LPIS polí. Duplikáty měly stejné tagy a sdílely všechny svoje uzly. Jako kdyby JOSM nahrál část nových cest a relací dvakrát za sebou. Objevil jsem je až za měsíc v Osmose, byl to jeden konkrétní changeset. Tracer to (doufám) udělat nemohl, to bych hned viděl, dvojitá pole měla v JOSM tmavší barvu.
    Tohle se občas, ale opravdu jen občas stane. Nejsem si úplně jist, zda je to softwarem nebo člověkem. Spíš to přisuzuji sobě. Nicméně - pokud jsou oba polygony naprosto stejné, JOSM, doufám, že vždy, zařve. Stalo se mi ovšem i to, že nebyly naprosto stejné. Sdílely třeba všechny uzly až na jeden. To může IMO vzniknout tak, že když se tracuje podruhé, je to jiná situace - na daném místě už landuse je.
    Já podezírám upload changesetu do OSM. Ty cesty a relace byly _naprosto_ identické, proto je taky našlo Osmose. JOSM validace nic nehlásila, to bych ven nepustil, a trasované polygony vizuálně hlídám jak jen to jde. Každopádně je dobré se občas mrknout do Osmose na svoje chyby. ;-)) Martin
    Cus, ad BTW: nedavno sem nekoho pres web upozornoval na to, ze se mu povedlo zdvojit cesty (uzly byly totozny, jen pres ne vedla jak puvodni, nerozdelena way, tak nova, rozdelena), zeby nejakej bug v JOSM? Vyrabel rychlostni omezeni a pritom zjevne way rozdeloval, ale jak se u to povedlo takhle ... .
Napsat odpověď e-mailem… Odpovědět

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