import budov

69 zpráv
Zpět na přehled

import budov

69 zpráv MHMJLLPJ 20 účastníků 42 min čtení
  1. xkomczax na centrum.cz xkomczax na centrum.cz #mdb5f21
    Zdravím, chtěl jsem se zeptat jak je to s importem budov z katastru nemovitostí. U okresu Prostějov je napsána poznámka "probíhá", ale žádný pokrok osobně nepozoruji. Napsal jsem proto před časem uživateli Dave, který je u Prostějova napsán, ale od začátku března nepřišla odpověď, z čehož usuzuji, že import bude muset proběhnout jinak. Mám tedy o import požádat někoho zkušenějšího nebo se mám do něj pustit svépomocí? A mimochodem, když jsem našel na serveru http://osm.kabrt.cz/ soubor Prostějov.zip, ve kterém jsou i zbývající vesnice v .map formátu, znamená to že jsou již importovány a stačí jej pouze nějak nahrát na server? Pokud ano, jak to mohu provést? Díky, xkomczax
  2. hanoj ehanoj na gmail.com #m9b6c4f
    Predem predpokladam ze mluvime o importu adresnich bodu: http://wiki.openstreetmap.org/wiki/Import_Adres_%C4%8CR
    chtěl jsem se zeptat jak je to s importem budov z katastru nemovitostí. U okresu Prostějov je napsána poznámka "probíhá", ale žádný pokrok osobně nepozoruji. Napsal jsem proto před časem uživateli Dave, který je u Prostějova napsán, ale od začátku března nepřišla odpověď, z čehož usuzuji, že import bude muset proběhnout jinak. Mám tedy o import požádat někoho zkušenějšího nebo se mám do něj pustit svépomocí?
    *** Je treba se presvedcid jestli nejaky body uz v mape nejsou, aby nedoslo k duplicitam. Nejlepe se pred uploadem s nekym zkusenejsim poradit.
    A mimochodem, když jsem našel na serveru http://osm.kabrt.cz/ soubor Prostějov.zip, ve kterém jsou i zbývající vesnice v .map formátu, znamená to že jsou již importovány a stačí jej pouze nějak nahrát na server? Pokud ano, jak to mohu provést?
    *** viz navod na wiki. Map soubor neni kompletni je treba ho poloautomaticky sparovat s katastralni mapou. Teprve potom vznikne soubor schopny importu. A jak jsem psal vyse, pozor na duplicity. ha hanoj
  3. jzvc jzvc na tpfree.net #mdbe096
    On nekdo nejak importuje budovy? Pokud se pamatuju, mluvilo se tu o importu adresnich bodu, coz je ponekud neco jineho - a ten odkaz odpovida prave adresam. Osobne to teda delam jinak, za pomoci czech address pluginu, neb mam overeno, ze adresni body jsou dost casto naprosto mimo, pripadne chybi uplne, takze by to stejne byla dvoji prace. Vetsinou postupuju tak, ze pouziju tracer a na nakreslenou budovu rovnou pridam i adresu. V kazdym pripade, importem do mapy asi nic nezkazis - kazdej by si mel predem overit jestli tam uz data nejsou, jen to udelej pod nejakym extra uctem, aby se vedelo, ze jde o import. Kazdopadne by to pomalu chtelo nejakej tool, kterej by umel najit budovy, ktere maji uvnitr "cervenou tecku", ale jsou bez adresy (a idealne to zobrazit jako podklad do JOSM a spol), pripadne najit adresy, ktere nejsou v mape ... protoze posledni dobou uz narazim i na "starsi" oblasti, kde je zmapovano, ale mezi tim tam jsou nove budovy ... ktere se v OSM objevi jen, pokud na to nahodou nekdo narazi.
  4. xkomczax na centrum.cz xkomczax na centrum.cz #me37e92
    Aha, tak to jsem nevěděl, myslel jsem, že se importují adresy i rovnou s nakreslenými budovami :-( V tom případě bych rád poprosil, zda-li by nebyl odkaz na návod jak importovat alespoň ty adresy a jak vytvořit obrysy budov. Díky, xkomczax
  5. Petr Dlouhý petr.dlouhy na email.cz #m6b618c
    Budovy je ale možné poloautomaticky nechat natrasovat pomocí pluginu Tracer - http://wiki.openstreetmap.org/wiki/CS:JOSM/Plugins/Tracer
    ---------------------------------------- Aha, tak to jsem nevěděl, myslel jsem, že se importují adresy i rovnou s nakreslenými budovami :-( V tom případě bych rád poprosil, zda-li by nebyl odkaz na návod jak importovat alespoň ty adresy a jak vytvořit obrysy budov. Díky, xkomczax
    On nekdo nejak importuje budovy? Pokud se pamatuju, mluvilo se tu o importu adresnich bodu, coz je ponekud neco jineho - a ten odkaz odpovida prave adresam. Osobne to teda delam jinak, za pomoci czech address pluginu, neb mam overeno, ze adresni body jsou dost casto naprosto mimo, pripadne chybi uplne, takze by to stejne byla dvoji prace. Vetsinou postupuju tak, ze pouziju tracer a na nakreslenou budovu rovnou pridam i adresu. V kazdym pripade, importem do mapy asi nic nezkazis - kazdej by si mel predem overit jestli tam uz data nejsou, jen to udelej pod nejakym extra uctem, aby se vedelo, ze jde o import. Kazdopadne by to pomalu chtelo nejakej tool, kterej by umel najit budovy, ktere maji uvnitr "cervenou tecku", ale jsou bez adresy (a idealne to zobrazit jako podklad do JOSM a spol), pripadne najit adresy, ktere nejsou v mape ... protoze posledni dobou uz narazim i na "starsi" oblasti, kde je zmapovano, ale mezi tim tam jsou nove budovy ... ktere se v OSM objevi jen, pokud na to nahodou nekdo narazi.
    Zdravím, chtěl jsem se zeptat jak je to s importem budov z katastru nemovitostí. U
    okresu Prostějov je napsána poznámka "probíhá", ale žádný pokrok osobně nepozoruji. Napsal jsem proto před časem uživateli Dave, který je u Prostějova napsán, ale od začátku března nepřišla odpověď, z čehož usuzuji, že import bude muset proběhnout jinak. Mám tedy o import požádat někoho zkušenějšího nebo se mám do něj pustit svépomocí?
    A mimochodem, když jsem našel na serveru http://osm.kabrt.cz/ soubor
    Prostějov.zip, ve kterém jsou i zbývající vesnice v .map formátu, znamená to že jsou již importovány a stačí jej pouze nějak nahrát na server? Pokud ano, jak to mohu provést?
    Díky, xkomczax
    Petr Dlouhý petr.dlouhy na email.cz
  6. Libor Pechacek lpechacek na gmx.com #m3417df
    Ahoj, Postup importu adresních bodů je dobře popsán na již zmíněné wiki [1]. Až se Ti podaří rozchodit software, zapiš se na wiki jako importér a pusť se do toho. Při importu je většina práce řešení chyb při importu. Jde o to, že v jednom katastrálním území je někdy více částí obcí. V tomto případě se v souboru *-fixme.osm objeví duplicitní adresy a je třeba relaci popisující hranice karastrálního území rozdělit na části a tyto části zapojit do hierarchie adres editací *.map souboru. Malá ukázka je v adresy-priklad.zip [2]. Dál pak může být potřeba posunout hranice KÚ, v mapě jsou někdy nepřesně, nebo je třeba přiřadit části obcí katastrálním územím, když se nepodařilo Lukášovi vytvořit tato spojení algoritmicky. Hodně štěstí, pozor na oblasti kde už adresní body jsou a ozvi se kdybys potřeboval pomoc. Libor [1] http://wiki.openstreetmap.org/wiki/Import_Adres_%C4%8CR [2] http://osm.kabrt.cz/home/adresy-priklad.zip?attredirects=0&d=1
  7. Jan Bilak jan.bilak.osm na gmail.com #mdceca3
    Ahoj, s importem adresních bodů získaných z teček na mapě bych se teď moc nezatěžoval, protože v brzké době se doufám podaří provést import z RUIAN, což být měl být kvalitnější zdroj (viz probíhající diskuse o RUIAN) - tedy úplný, denně aktualizovaný, přesnější, s menším rizikem chyby, lehčeji zpracovatelný, ... Zrovna adresní body myslím budou to nejjednodušší, co z RUIAN půjde naimportovat. Honza
  8. Libor Pechacek lpechacek na gmx.com #m0029ec
    Ahoj Honzo, Souhlas. Sám se už dlouho těším na zdroj dat jako je RUIAN se kterým půjdou přetáhnout již existující informace do OSM, místo jejich znovuobjevování. Na druhou stranu, ještě nemáme žádné nástroje, které by RUIAN používaly a tady je přispivatel, který chce mapu vylepšit. Sám za sebe mu raději řeknu co může udělat dnes, místo abych ho nabádal počkat až bude software používající nové postupy. Libor
    Ahoj, s importem adresních bodů získaných z teček na mapě bych se teď moc nezatěžoval, protože v brzké době se doufám podaří provést import z RUIAN, což být měl být kvalitnější zdroj (viz probíhající diskuse o RUIAN) - tedy úplný, denně aktualizovaný, přesnější, s menším rizikem chyby, lehčeji zpracovatelný, ... Zrovna adresní body myslím budou to nejjednodušší, co z RUIAN půjde naimportovat. Honza
    Ahoj, Postup importu adresních bodů je dobře popsán na již zmíněné wiki [1].  Až se Ti podaří rozchodit software, zapiš se na wiki jako importér a pusť se do toho. Při importu je většina práce řešení chyb při importu.  Jde o to, že v jednom katastrálním území je někdy více částí obcí.  V tomto případě se v souboru *-fixme.osm objeví duplicitní adresy a je třeba relaci popisující hranice karastrálního území rozdělit na části a tyto části zapojit do hierarchie adres editací *.map souboru.  Malá ukázka je v adresy-priklad.zip [2]. Dál pak může být potřeba posunout hranice KÚ, v mapě jsou někdy nepřesně, nebo je třeba přiřadit části obcí katastrálním územím, když se nepodařilo Lukášovi vytvořit tato spojení algoritmicky. Hodně štěstí, pozor na oblasti kde už adresní body jsou a ozvi se kdybys potřeboval pomoc. Libor [1] http://wiki.openstreetmap.org/wiki/Import_Adres_%C4%8CR [2] http://osm.kabrt.cz/home/adresy-priklad.zip?attredirects=0&d=1
    Aha, tak to jsem nevěděl, myslel jsem, že se importují adresy i rovnou s nakreslenými budovami :-( V tom případě bych rád poprosil, zda-li by nebyl odkaz na návod jak importovat alespoň ty adresy a jak vytvořit obrysy budov. Díky, xkomczax
    On nekdo nejak importuje budovy? Pokud se pamatuju, mluvilo se tu o importu adresnich bodu, coz je ponekud neco jineho - a ten odkaz odpovida prave adresam. Osobne to teda delam jinak, za pomoci czech address pluginu, neb mam overeno, ze adresni body jsou dost casto naprosto mimo, pripadne chybi uplne, takze by to stejne byla dvoji prace. Vetsinou postupuju tak, ze pouziju tracer a na nakreslenou budovu rovnou pridam i adresu. V kazdym pripade, importem do mapy asi nic nezkazis - kazdej by si mel predem overit jestli tam uz data nejsou, jen to udelej pod nejakym extra uctem, aby se vedelo, ze jde o import. Kazdopadne by to pomalu chtelo nejakej tool, kterej by umel najit budovy, ktere maji uvnitr "cervenou tecku", ale jsou bez adresy (a idealne to zobrazit jako podklad do JOSM a spol), pripadne najit adresy, ktere nejsou v mape ... protoze posledni dobou uz narazim i na "starsi" oblasti, kde je zmapovano, ale mezi tim tam jsou nove budovy ... ktere se v OSM objevi jen, pokud na to nahodou nekdo narazi.
    Zdravím, chtěl jsem se zeptat jak je to s importem budov z katastru nemovitostí. U okresu Prostějov je napsána poznámka "probíhá", ale žádný pokrok osobně nepozoruji. Napsal jsem proto před časem uživateli Dave, který je u Prostějova napsán, ale od začátku března nepřišla odpověď, z čehož usuzuji, že import bude muset proběhnout jinak. Mám tedy o import požádat někoho zkušenějšího nebo se mám do něj pustit svépomocí? A mimochodem, když jsem našel na serveru http://osm.kabrt.cz/ soubor Prostějov.zip, ve kterém jsou i zbývající vesnice v .map formátu, znamená to že jsou již importovány a stačí jej pouze nějak nahrát na server? Pokud ano, jak to mohu provést? Díky, xkomczax
    --
  9. Miroslav Šulc fordfrog na fordfrog.com #m6ed41b
  10. Jan Bilak jan.bilak.osm na gmail.com #mbf827f
    Ahoj, teď z toho nechápu, zda si aplikaci představuješ jen jako evidenční nebo zda aplikace má provádět vlastní import (resp. s ním výrazně pomáhat). Tedy za zásadní považuji porovnání současných OSM dat s daty RUIAN a následné provedení změn (posuny stávajících bodů, opravy tagů, zachování stávajících tagů, doplnění chybějících tagů, ...). Samozřejmě s tím, že proces bude pod manuální kontrolou člověka, který bude import provádět (tedy nikoli plně automatický, ale poloautomatický). O těchto funkcích se v popisu nezmiňuješ. Honza
  11. Miroslav Šulc fordfrog na fordfrog.com #me0edc8
    Ahoj, teď z toho nechápu, zda si aplikaci představuješ jen jako evidenční nebo zda aplikace má provádět vlastní import (resp. s ním výrazně pomáhat).
    aplikace "pouze" připraví data z rúian, samotný import provede mapper. tj. aplikace pro import připraví data, ale nebude import provádět, ten se bude dělat ručně. i kdybychom (pokud vůbec, to vyplyne z ručních importů) v budoucnu uvažovali o nějaké automatizaci, tak v prvním kroku se to stejně musí udělat ručně, abychom věděli, nakolik je rúian spolehlivý zdroj, jaké problémy lze očekávat apod. pro kontinuální práci s daty z rúian je pak potřeba ta evidenční část.
    Tedy za zásadní považuji porovnání současných OSM dat s daty RUIAN a následné provedení změn (posuny stávajících bodů, opravy tagů, zachování stávajících tagů, doplnění chybějících tagů, ...). Samozřejmě s tím, že proces bude pod manuální kontrolou člověka, který bude import provádět (tedy nikoli plně automatický, ale poloautomatický). O těchto funkcích se v popisu nezmiňuješ.
    vycházel jsem hlavně z importu budov tam, kde je nemáme, to je asi ta nejjednodušší varianta. co se týče importu budov do míst, kde už nějaké jsou, nebo importu adresních bodů, tak se přiznám, že nevím, jestli v josm existují nástroje na zobrazení rozdílů ve vrstvách, na slučování objektů (a tagů) z různých vrstev apod. s tím zkušenosti nemám. ale určitě se tu najde někdo, kdo to vědět bude nebo aspoň bude vědět, kde hledat. ten můj nástřel je v podstatě (podle mě) asi to nejnutnější minimum pro to, aby se dala data z rúian využít pro manuální importy. nad tím potom lze dělat další nadstavby, které práci zjednoduší a zrychlí. něco určitě vyplyne i ze zkušeností se samotnými importy.
    Honza
    ff
  12. Jan Bilak jan.bilak.osm na gmail.com #mfd6d37
    Otázka je, jak by měla vypadat ta připravená data. V případě importu nových věcí tak, kde žádné nebyly, je to celkem primitivní. Ale mnohem náročnější bude import do míst, kde již nějaká data jsou. Tam bude třeba něco starého odstranit, něco modifikovat, něco přidat... Lze v OSM formátu postihnout nějak všechny tyto typy změn (odstranění, modifikace, přidání nových objektů)? A pokud lze, je možné to pak nějak rozumně vizualizovat, aby to člověk mohl projít a rozhodovat "tohle je ok, tohle zamítnu a zůstane při starém, tohle bude ještě trochu jinak..." pomocí stávajících nástrojů? Nevím, jaké jsou možnosti. Pokud nic vhodné stávajícího není, tak bych to viděl spíše na interaktivní aplikaci, která zobrazí ty rozdíly ve vhodné podobě, u každé umožní se rozhodnout, zda ponechat stará data, nová data, automaticky zmergovat nebo ručně upravit. Ruční úpravu by ta aplikace přímo nepodporovala, protože by to bylo příliš náročné (vlastně by bylo třeba vytvořit obdobu editoru jako JOSM), ale poznačilo by to nutnost ruční editace do dat nějakými tagy, aby výsledek, který z aplikace vypadne, bylo možné otevřít např. v JOSM a ručně provést potřebné úpravy. Např. u adresních bodů by bylo podle mě vhodné, aplikace provedla nějaké "inteligentní" matchování adresních bodů v OSM a RUIAN, zobrazovala původní a nový bod vizuálně propojený šipkou, jinak vyznačené body, které jsou pouze v OSM a naopak jinak vyznačené body, které jsou pouze v RUIAN. Uživatel by mohl vždy zvolit, zda ponechat novou nebo starou polohu bodu (zde by bylo možné i volit vlastní polohu - jde o primitivní úkon) atd. Nakonec by aplikace vytvořila OSM patch, který by obsahoval požadované úpravy včetně vhodně zmergovaných tagů (ty by možná bylo třeba také kontrolovat v aplikaci) atd. U budov to bude samozřejmě výrazně složitější. Obecně čistě ručního importu se celkem obávám. Dat je vetší než malé množství. Honza
  13. "Petr Morávek [Xificurk]" xificurk na gmail.com #m59826d
    Otázka je, jak by měla vypadat ta připravená data. V případě importu nových věcí tak, kde žádné nebyly, je to celkem primitivní. Ale mnohem náročnější bude import do míst, kde již nějaká data jsou. Tam bude třeba něco starého odstranit, něco modifikovat, něco přidat... Lze v OSM formátu postihnout nějak všechny tyto typy změn (odstranění, modifikace, přidání nových objektů)? A pokud lze, je možné to pak nějak rozumně vizualizovat, aby to člověk mohl projít a rozhodovat "tohle je ok, tohle zamítnu a zůstane při starém, tohle bude ještě trochu jinak..." pomocí stávajících nástrojů? Nevím, jaké jsou možnosti.
    V OSM se používají v podstatě dva formáty: 1) osm: XML soubor s jednotlivými prvky. 2) osc (osmChange): XML soubor obsahující změny dat (obsah changesetu), v podstatě se jedná o seznam prvků delete, modify, create, kde každý z nich obsahuje změněné prvky. Jestli existuje nějaký rozumný prohlížeč tohoto formátu netuším. (více viz wiki) Už nějakou dobu vyvíjím pythoní knihovnu [1] pro práci s OSM daty, mj. jsem používal pro import sídel z UIR-ZSJ. Tam jsem taky používal metodu, která diffne dva osm souboru a vytvoří z nich osc vhodný k uploadu (proto byl postup - otevři vygenerovaný osm soubor, uprav dle chuti, ulož, spusť skript pro upload).
    Např. u adresních bodů by bylo podle mě vhodné, aplikace provedla nějaké "inteligentní" matchování adresních bodů v OSM a RUIAN, zobrazovala původní a nový bod vizuálně propojený šipkou, jinak vyznačené body, které jsou pouze v OSM a naopak jinak vyznačené body, které jsou pouze v RUIAN. Uživatel by mohl vždy zvolit, zda ponechat novou nebo starou polohu bodu (zde by bylo možné i volit vlastní polohu - jde o primitivní úkon) atd. Nakonec by aplikace vytvořila OSM patch, který by obsahoval požadované úpravy včetně vhodně zmergovaných tagů (ty by možná bylo třeba také kontrolovat v aplikaci) atd.
    Pokud se shodneme, že budem adresní body skutečně do OSM dávat jako jednotlivé body (ale mám pocit, že tahle otázka se ještě definitivně nerozřešila), tak by se asi dala zrecyklovat značná část logiky z importu UIR-ZSJ. Troufám si tvrdit, že v takovém připadě by se dala synchronizace OSM a RUIAN prakticky úplně zautomatizovat. Ale teď se odhodlávám podívat se na to, v jaké formě obsahuje RUIAN hranice a jestli by se nedala nějak zautomatizovat jejich aktualizace v OSM (co jsem koukal, tak na některých místech se změnilo docela dost). Zdraví, Petr Morávek aka Xificurk [1] https://github.com/xificurk/osmapis
  14. Tomáš Tichý t.tichy na post.cz #m9de31a
    Jeden námět k prozkoumání: Aplikace pro koordinaci úloh v OSM - OSM Tasking manager. https://github.com/pgiraud/OSMTM Praktické nasazení je možné vidět v humanitárním týmu OSM: http://tasks.hotosm.org/A nebo pro koordinaci remapování po licenčním botovi: http://rebuild.poole.ch/ Na první pohled vypadá aplikace použitelně minimálně na koordinaci činností a řeší některé problémy: - není potřeba registrace, použije se přihlašování z OSM - úlohy jsou vidět na mapě - integrované vazby na JOSM a Potlatch - vyřešené rezervace úloh jednotlivými uživateli včetně automatického uvolnění při nečinnosti Pokud se chcete někdo pustit do vývoje nějaké poloautomatické importovací aplikace, mohl by to být použitelný základ. TT
  15. Jakub j na kub.cz #mefbd26
    Určitě jsem rád že směřujeme k ručnímu importu s výraznou pomocí nějakých nástrojů typu toho co teď připravil Mirek (doufám že si to dobře pamatuju). Jakub
  16. Miroslav Šulc fordfrog na fordfrog.com #mfb6faa
    v souvislosti s tím co píšeš mě napadlo udělat to komplet jako josm plugin. tj. serverová část by zůstala tak jak jsem psal, ale všechno ostatní by se dělalo přímo z josm pluginu. ten by si stáhl data přes api ode mě ze serveru z aktuální databáze rúian, provedl by porovnání s datovou vrstvou z osm a vyhodil by nějaké info o rozdílech v osm a v rúian s tím, že mapper by si vybíral varianty a potvrzoval je, případně by sáhnul přímo do osm vrstvy a udělal úpravy tam. při uploadu změn do osm by se pak zapsalo i info ke mně na server o provedení importu. do pluginu by se pak dala přidávat funkcionalita dle potřeby. ff
  17. hanoj ehanoj na gmail.com #m85171d
    Ja bych nadhodil nekolik otazek treba pro adresni body: * Kolik je adresnich bodu? 2.500.000 * Kolik mapperu se bude ucastnit takove prace? Prvni desitky. * Jak dlouho to bude trvat? ... * Jaka cast dat by mela byt mappery pridavana tam kde nikdy nebyla? Vetsina. * Jak budou uzivatele hodnotit (ne)kvalitu dat jiz v OSM? Na zaklade dat CUZK a u par stovek bodu ze znalosti z terenu kde bydli.Tezko ale suplovat: http://www.cuzk.cz/GenerujSoubor.ashx?NAZEV=10-POROVNANIADRES Opravdu je individualni prace na vetsine uzemi republiky cesta, jak data RUIAN dostat do OSM? h.anoj
  18. Miroslav Šulc fordfrog na fordfrog.com #md69ac8
    Ja bych nadhodil nekolik otazek treba pro adresni body: * Kolik je adresnich bodu? 2.500.000
    2915347 (z toho 2709859 má definované souřadnice), když bychom to brali po kú, tak těch je 13026.
    * Kolik mapperu se bude ucastnit takove prace? Prvni desitky.
    při tom množství práce (viz níž) asi nikdo :-)
    * Jak dlouho to bude trvat? ...
    no, když mapper stráví na jednom kú 5 pouhých minut, tak to je "jenom" cca 1085 hodin práce :-)
    * Jaka cast dat by mela byt mappery pridavana tam kde nikdy nebyla? Vetsina.
    tak ono se dá něco okontrolovat třeba podle bingu, ale i to má svoje problémy. co jsem četl někde na osm wiki, tak jim občas mapa nesedí a je posunutá. další věc je ta, že rúian data jsou aktuální kdežto bing mapa zastarává. takže ruční úpravy můžou mít naopak i negativní dopad, pokud by se někdo striktně držel bingu. nehledě na to, že asi většina adresních bodů z předchozího importu zůstala rukou živého mappera netknutá, ať už jsou umístěné správně nebo jsou posunuté.
    * Jak budou uzivatele hodnotit (ne)kvalitu dat jiz v OSM? Na zaklade dat CUZK a u par stovek bodu ze znalosti z terenu kde bydli.Tezko ale suplovat: http://www.cuzk.cz/GenerujSoubor.ashx?NAZEV=10-POROVNANIADRES Opravdu je individualni prace na vetsine uzemi republiky cesta, jak data RUIAN dostat do OSM?
    je fakt, že ten efekt za těch cca 1085 hodin (samozřejmě je to pouze odhad) práce ve srovnání s plnou automatizací by byl asi minimální. už jenom proto, že by se to ručně nikdy nedodělalo. možná nejlepší řešení by bylo adresní body naimportovat/zaktualizovat automaticky, akorát případy, kdy už adresní bod existuje a je od toho v rúian vzdálený víc než x jednotek by se řešily poloautomaticky. možná by nebylo špatné napsat si nějaký testovací skript, který by zjistil, jak moc se aktuální data v osm liší od rúian. z toho by se pak dalo ledaco vyčíst. až se mi doimportují osm data do db, tak to můžu zkusit napsat a uvidíme, co tu vlastně řešíme.
    h.anoj
    ff
  19. Martin Kokeš shr3k na typo3-hosting.com #m5fa808
    Já jsem pro hromadný import, případně následně pro vytvoření robota na údržbu. Minimálně u adresních bodů. MK
  20. Lukas Kohout luko na luko.name #m9eee21
    možná nejlepší řešení by bylo adresní body naimportovat/zaktualizovat automaticky, akorát případy, kdy už adresní bod existuje a je od toho v rúian vzdálený víc než x jednotek by se řešily poloautomaticky. možná by nebylo špatné napsat si nějaký testovací skript, který by zjistil, jak moc se aktuální data v osm liší od rúian. z toho by se pak dalo ledaco vyčíst. až se mi doimportují osm data do db, tak to můžu zkusit napsat a uvidíme, co tu vlastně řešíme.
    Zdravím, navrhuji udělat možnost vyřadit oblast z automatického importu/aktualizace. V naší vesnici jsou některé adresní body chybně umístěné, některé chybí úplně. Asi bych nebyl nadšený, kdyby mi je nějaký bot stále dokola automaticky přesouval/mazal (zrovna dnes jsem doplňoval jedno č.p. podle nálepky na popelnici, což je možné jen v neděli večer :) ) LuKo
  21. Jan Bilak jan.bilak.osm na gmail.com #me1ee5a
    Zdravím, metainformace o tom, že se něco nemá importovat z RUIAN, protože je to tam špatně, by podle mě chtělo mít přímo v OSM. A to včetně informace o tom, odkud konkrétně ta spolehlivější informace pochází. Honza PS: Doplňování čp. podle čísla na popelnici nemusí být moc spolehlivé, protože občas někdo popelnici prodá/koupí, ukradne, ... a číslo neodpovídá.
  22. Lukas Kohout luko na luko.name #m6ea799
    Zdravím, metainformace o tom, že se něco nemá importovat z RUIAN, protože je to tam špatně, by podle mě chtělo mít přímo v OSM. A to včetně informace o tom, odkud konkrétně ta spolehlivější informace pochází.
    Existuje k tomuto účelu nějaký tag "zjištěno při procházce se psem"? :)
    Honza PS: Doplňování čp. podle čísla na popelnici nemusí být moc spolehlivé, protože občas někdo popelnici prodá/koupí, ukradne, ... a číslo neodpovídá.
    Obecně máš asi pravdu. U nás je systém nálepek, které jsou vázané na část obce, č.p. a každý rok se vydávají nové. Bez nálepky popelnici nevyvezou. Cizí nálepka je tedy prakticky vyloučena (musela by být někoho z vesnice). Navíc č.p. sedí do číselné řady v celé ulici. LuKo
  23. Miroslav Šulc fordfrog na fordfrog.com #m98a009
    možná nejlepší řešení by bylo adresní body naimportovat/zaktualizovat automaticky, akorát případy, kdy už adresní bod existuje a je od toho v rúian vzdálený víc než x jednotek by se řešily poloautomaticky. možná by nebylo špatné napsat si nějaký testovací skript, který by zjistil, jak moc se aktuální data v osm liší od rúian. z toho by se pak dalo ledaco vyčíst. až se mi doimportují osm data do db, tak to můžu zkusit napsat a uvidíme, co tu vlastně řešíme.
    Zdravím, navrhuji udělat možnost vyřadit oblast z automatického importu/aktualizace. V naší vesnici jsou některé adresní body chybně umístěné, některé chybí úplně. Asi bych nebyl nadšený, kdyby mi je nějaký bot stále dokola automaticky přesouval/mazal (zrovna dnes jsem doplňoval jedno č.p. podle nálepky na popelnici, což je možné jen v neděli večer :) )
    chybně umístěné znamená co přesně? posunuté o kolik metrů? podle my bě skript neměl měnit body, které jsou od sebe vzdáleny víc jak x metrů (tj rúian vs osm), ale měl by je někam vypsat. tyhle by se pak museli zkontrolovat ručně. kolik jich bude, by mělo vyplynout z analýzy rozdílů mezi rúian a osm, kterou mám v plánu udělat. k těm chybějícím bodům? znamená to, že tam máte nějaká čp, o kterých rúian neví? jinak někde na osm wiki jsem četl o tagu "bot" nebo tak nějak (teď to nemůžu najít). podle mě automaticky spravované adresní body by měly tenhle tag mít. pokud by pak někdo bod přesunul, protože je umístěný špatně, tak by mu ten tag smazal a tím pádem by skript ten bod přestal aktualizovat, max by někam vypsal změny pro daný bod, pokud k nim dojde. takových bodů bude v porovnání s těmi cca třemi miliony minimum, takže případné změny (kterých taky asi bude minimum) by se daly zvládat ručně, pokud bude potřeba je do osm zanést.
  24. Lukas Kohout luko na luko.name #m416ea0
    možná nejlepší řešení by bylo adresní body naimportovat/zaktualizovat automaticky, akorát případy, kdy už adresní bod existuje a je od toho v rúian vzdálený víc než x jednotek by se řešily poloautomaticky. možná by nebylo špatné napsat si nějaký testovací skript, který by zjistil, jak moc se aktuální data v osm liší od rúian. z toho by se pak dalo ledaco vyčíst. až se mi doimportují osm data do db, tak to můžu zkusit napsat a uvidíme, co tu vlastně řešíme.
    Zdravím, navrhuji udělat možnost vyřadit oblast z automatického importu/aktualizace. V naší vesnici jsou některé adresní body chybně umístěné, některé chybí úplně. Asi bych nebyl nadšený, kdyby mi je nějaký bot stále dokola automaticky přesouval/mazal (zrovna dnes jsem doplňoval jedno č.p. podle nálepky na popelnici, což je možné jen v neděli večer :) )
    chybně umístěné znamená co přesně? posunuté o kolik metrů? podle my bě skript neměl měnit body, které jsou od sebe vzdáleny víc jak x metrů (tj rúian vs osm), ale měl by je někam vypsat. tyhle by se pak museli zkontrolovat ručně. kolik jich bude, by mělo vyplynout z analýzy rozdílů mezi rúian a osm, kterou mám v plánu udělat. k těm chybějícím bodům? znamená to, že tam máte nějaká čp, o kterých rúian neví?
    Materiály ke zkoumání: http://maps.fordfrog.com/?lat=50.05843&lon=15.19497&zoom=18&layers=0B0FTF (nástroj špatně zpracovává permalink, tedy stejný link pro orientaci: http://www.openstreetmap.org/?lat=50.05843&lon=15.19497&zoom=18 <http://www.openstreetmap.org/?lat=50.05843&lon=15.19497&zoom=18>) - Do pozornosti doporučuji čísla 125, 126, 127, 133, 162 (ty 3 "rozestavěné" domy u hlavní jsou již minimálně rok obydlené, zítra je obejdu se psem) a ve střední části vesnice pak 16, 7, 9, 10 - tam rúian označuje čísla (zbořených) stodol. Naopak ve vedlejší obci je předchozí import nějak rozházený, něco tam i chybí a tam by změna podle rúian znamenala značné zlepšení: http://maps.fordfrog.com/?lat=50.05772&lon=15.21386&zoom=18&layers=0B0FTF
  25. Martin Kokeš shr3k na typo3-hosting.com #mfe7d09
    Holt asi máte na stavebním úřadě lajdáka. :-) MK
  26. Jakub Sykora kubajz na kbx.cz #mb7e9ca
    source:survey :)
  27. Miroslav Šulc fordfrog na fordfrog.com #m1dfd48
  28. LM_1 flukas.robot+osm na gmail.com #mf028e3
    Nejsou systémy s tagováním bot/nobot moc komplikované? Co kdyby se bot podíval na autora poslední změny daného bodu a pokud by to byl on sám tak by ho upravil podle potřeby, pokud by to byl někdo jiný tak by jen vygeneroval upozornění. LM_1
  29. Miroslav Šulc fordfrog na fordfrog.com #m2b49d1
    o tomhle jsem taky uvažoval, má to ale jednu nevýhodu. neumožňuje to bod vrátit do správy botovi. stejně tak pokud by někdo jen přidal nějaký další tag k adresnímu bodu, tak by se bot taky přestal o ten bod starat, i když by se o něj měl starat dál. ff
  30. LM_1 flukas.robot+osm na gmail.com #md5e198
    Dalo by se uvažovat o posuzování jednotlivých argumentů (tagů, pozice) individuálně (člověk posune - bot už hýbat nebude, ale klidně změní číslo při přečíslování ulice nebo název při změně názvu) Změna ve zdrojových datech by mohla sloužit pro navrácení dané hodnoty do správy botovi - když se změní hodnota ve zdrojových datech, předpokládáme i změnu v realitě a tím zneplatnění původní lidské úpravy. To by mělo vyloučit většinu soubojů mezi člověkem a strojem. Lukáš Matějka (LM_1)
  31. Miroslav Šulc fordfrog na fordfrog.com #m0c0b84
    ono by se to třeba i dalo nějak vymyslet, aby to fungovalo bez tagu, ale postrádalo by to jednu důležitou vlastnost - jednoduchost. jednak bot by se musel rozhodovat na základě složitějších pravidel než jen "bot=yes" => můžu měnit, "bot=no" => nesahat, což by mohlo způsobovat chyby/nedorozumnění/mylné předpoklady. a to samé by se týkalo i mapperů. nikdo si nebude pamatovat složitá pravidla, na základě jakých se bot o body stará. ale jednoduché pravidlo "bot=yes" => bot se o bod stará, "bot=no" => bot na bod sahat nebude, pouze pošle info pro případný ruční zásah, to si myslím z toho tagu vyplývá samo a i nový mapper bota neznající by měl bez problému tenhle závěr z toho tagu vyvodit. píšu tu o tagu "bot", ale v praxi by to možná mohl být spíš tag "ruian:bot=yes|no". z toho by bylo zřejmé, že tag se týká jen a pouze bota, který pracuje nad rúian daty. stejně tak by asi mohl existovat tag "ruian:id=<kod z ruian>" (jeho asi jediný přínos ale vidím v tom, že v případě přejmenování ulice/změny čísla by se zachovala historie, jinak pro fungování bota asi není nezbytný). nicméně zatím nevím, jak je to přesně s custom tagy, sice jsem něco na osm wiki našel, ale nevyplynulo mi z toho nějaké pravidlo nebo předepsaný postup. ff
  32. LM_1 flukas.robot+osm na gmail.com #m4e1300
    Vlastní tagy obecně nejsou problém, ale měly by být popsané. Určitě bych byl pro zachování nějaké jednoznačné identifikace ruian:id nebo ref:ruian, to je jedno. Ty tagy pro bota se mi moc nelíbí proto, že nevypovídají nic o objektu na kterém jsou a není to ani dočasné řešení jako bylo odbl=clean. Srozumitelnost existujícího tagu pro neseznámené by asi byla jasná, ale způsob způsob jak dojít od bodu který se mi občas někam chybně přesune k tomu, že mám použít zvláštní tag už tak jasná není. Možá bych volil kompromis, že by bot hlídal posledního autora (to by nemuselo být tak složité) a nebo svůj bot=yes tag, který by při editaci odstranil - stal by se posledním autorem a nebyl by už potřeba. Nikomu by neutíkaly body. LM
  33. Miroslav Šulc fordfrog na fordfrog.com #m910f54
    Vlastní tagy obecně nejsou problém, ale měly by být popsané. Určitě bych byl pro zachování nějaké jednoznačné identifikace ruian:id nebo ref:ruian, to je jedno. Ty tagy pro bota se mi moc nelíbí proto, že nevypovídají nic o objektu na kterém jsou a není to ani dočasné řešení jako bylo odbl=clean. Srozumitelnost existujícího tagu pro neseznámené by asi byla jasná, ale způsob způsob jak dojít od bodu který se mi občas někam chybně přesune k tomu, že mám použít zvláštní tag už tak jasná není. Možá bych volil kompromis, že by bot hlídal posledního autora (to by nemuselo být tak složité) a nebo svůj bot=yes tag, který by při editaci odstranil - stal by se posledním autorem a nebyl by už potřeba. Nikomu by neutíkaly body.
    jestli jsem to dobře pochopil, tak navrhuješ, že pro bota by znamenalo, že se o bod má starat v případě, že buď je posledním editorem nebo je na bodu tag "ruian:bot=yes". takže jakákoliv editace bodu by znamenala, že se o něj bot přestane starat. pro navrácení bodu botovi by pak bylo nutné přidat "ruian:bot=yes". to podle mě zní rozumně. sice to postrádá tu úplnou jednoduchost, letmým pohledem není zřejmé, jestli se bot o ten bod stará nebo ne (člověk musí znát pravidlo o posledním editorovi, což většina mapperů asi vědět nebude), ale na druhou stranu mapper o botovi nemusí vůbec vědět a i tak by vše mělo fungovat správně, tj pokud je bod umístěný špatně, tak ho mapper zedituje a tím ho vyjme z kontroly bota. jak ho vrátit botovi už vědět nebude, ale to se dá někde popsat (třeba v tom mailu, který bude bot generovat). výhoda je určitě ta, že se u většiny bodů nebudou osm data zanášet dalším tagem. akorát při prvotním importu bude muset bot tohle pravidlo ignorovat, jinak by nic neudělal. a před importem bude potřeba ručně otagovat body, které jsou v rúian špatně umístěné, tagem "ruian:bot=no". ff
  34. LM_1 flukas.robot+osm na gmail.com #mfada92
    Uvažoval jsem přesně takto. Není i dnes většina adresních bodů z importů? Ty ručně dělané budou pravděpodobně správně... LM
  35. Miroslav Šulc fordfrog na fordfrog.com #mb77970
    no, tady u nás je editorem bodů účet lpechacek, tak nevím, jestli to importoval tenhle uživatel. ff
  36. Martin Kokeš shr3k na typo3-hosting.com #m93ad76
    Mimo UIR-ADR importu (hodně slabé) je IMHO většina adres je dělána pomocí czechaddress pluginu http://wiki.openstreetmap.org/wiki/CS:JOSM/Plugins/CzechAddress a následně ručně umístěných podle adresních bodů v KN. MK
  37. Libor Pechacek lpechacek na gmx.com #m640ab3
    :) Zrovna jsem se chtěl ozvat. Za svojí prací si stojím, investoval jsem hodně úsilí do korektnosti importů. Na druhou stranu vím, že některé importy nejsou až tak důkladně provedené. Nemám nic proti přepsání svých importů daty z RÚIAN, obsahově by měly být totožná. Libor
  38. jzvc jzvc na tpfree.net #mfb521e
    Ja vam tady do toho lehce vstoupim - moje predstava, jak by to mohlo docela pekne fungovat = upravit soucasny tracer plugin, a to tak, ze nebude trasovat z bitmapy, ale veme vektor/body. => zdroj zi zobrazim jako podklad, a pokud klipnu "do budovy", tak ji to bafne a vlozi do aktivniho layeru. Melo by to samo mit funkci "merge" => pokud chci slucovat, melo by jit nastavit zda poloha bude stavajici nebo ze zdroje + to drapne vsechny stavajici tagy + to samo prida IDcko ze zdroje a omarkuje pokud je poloha z OSM (aby se to v pripade zmeny ve zdroji nemenilo). Tohle by melo fungovat tak, ze klipnu (vyberu) dva objekty stejnyho typu a on je automaticky podle danych pravidel slouci. Zjistovani rozdilu = vemu objekty danyho typu v danym boxu a podivam se, zda mam v OSM vsechny objekty danyho typu s danym ID. Ty co tam nejsou vyrenderuju jako rozdil. Dale u tech co tam jsou overim, zda maji stejne souradnice (a pripadne dalsi parametry) jako ve zdroji (pokud ne = rozdil), pripadne zda sou oznaceny (= v RUIAN je blbost). Pokud to bude v podobe podkladu (trebas vrstva toho WMS generovanyho z RUIAN), tak se da velmi snadno a rychle najit kde co chybi. Melo by to mit nejakou moznost zpetne prohlasit ze v RUIAN je blbost, a takovej objekt by se neresil, dokud nebude v RUIAN zmenen (pripadne by to mohla byt dalsi vrstva). Ad adresni body - me osobne se nelibi, protoze jak uz sem psal vejs, pokud ma budova definovany vchody, da se navigovat ke vchodu i z jiny ulice nez te, kde ma adresu. Pokud je tam bod, tak kazda navigace povede do ulice, kam ta adresa patri. Dovedu si to predstavit prave pro oznaceni mist, kde z nejakyho duvodu budova neni, neni tam digitalini km, ... protoze tam budovy neni moc jak vykreslit. V takovym pripade bych si asi doved predstavit, ze (v ramci upraveneho pluginu) vyberu trebas nejaky box a prohlasim ze do nej chci vlozit vsechny adresni body ze zdroje. S matchovanim to asi bude vselijaky, neb sem svyho casu podobny veci delal, uspesnost asi nepreleze 80 - 85%. Ale opet, lze renederovat nejaky rozdil, a postupne se to da dokupy. Hlavne musi byt nekde videt co kde chybi.
  39. jzvc jzvc na tpfree.net #mae62e5
    :) Zrovna jsem se chtěl ozvat. Za svojí prací si stojím, investoval jsem hodně úsilí do korektnosti importů. Na druhou stranu vím, že některé importy nejsou až tak důkladně provedené. Nemám nic proti přepsání svých importů daty z RÚIAN, obsahově by měly být totožná.
    Tim bych si nebyl tak jisty ... ;D, opakovane sem narazel na spatne nazvy ulic (u importovanych adres) - v tom smyslu, ze tam byly zkratky, blbe mala/velka pismena, pripadne nekde byly pouzity starsi nez aktualni nazvy ...
  40. jzvc jzvc na tpfree.net #md6effe
    Já jsem pro hromadný import, případně následně pro vytvoření robota na údržbu. Minimálně u adresních bodů. MK
    A dopadne to jako potoky, ktery nejsou spraveny doted.
  41. Libor Pechacek lpechacek na gmx.com #m993a08
    :) Zrovna jsem se chtěl ozvat. Za svojí prací si stojím, investoval jsem hodně úsilí do korektnosti importů. Na druhou stranu vím, že některé importy nejsou až tak důkladně provedené. Nemám nic proti přepsání svých importů daty z RÚIAN, obsahově by měly být totožná.
    Tim bych si nebyl tak jisty ... ;D, opakovane sem narazel na spatne nazvy ulic (u importovanych adres) - v tom smyslu, ze tam byly zkratky, blbe mala/velka pismena, pripadne nekde byly pouzity starsi nez aktualni nazvy ...
    Zkratky a neaktuální názvy jdou na účet MVČR, nesprávně malá/velká písmena jsou chybou importovacího softwaru. Sice jsem software opravil, ale původní názvy už v mapě zůstaly. ;) Libor
  42. "Petr Morávek [Xificurk]" xificurk na gmail.com #m9c0893
    Zkratky a neaktuální názvy jdou na účet MVČR, nesprávně malá/velká písmena jsou chybou importovacího softwaru. Sice jsem software opravil, ale původní názvy už v mapě zůstaly. ;)
    Ahoj, ony ty registry občas taky obsahují blbosti. Můj oblíbený příklad je KÚ z UIR-ZSJ jménem "Krupá u Kostelce nad Černýni Lesy" ;-) Petr Morávek aka Xificurk
  43. hanoj ehanoj na gmail.com #mdd6ca1
    ony ty registry občas taky obsahují blbosti. Můj oblíbený příklad je KÚ z UIR-ZSJ jménem "Krupá u Kostelce nad Černýni Lesy" ;-)
    *** to neni blbost, to je fakt. KU maji unikatni nazvy napric CR. ha hanoj
  44. hanoj ehanoj na gmail.com #m615bb9
    Já jsem pro hromadný import, případně následně pro vytvoření robota na údržbu. Minimálně u adresních bodů. MK
    A dopadne to jako potoky, ktery nejsou spraveny doted.
    *** Jestli si mam vybrat mezi: * rucne s chybami=nikdy * import s chybami=letos tak vyber je jasnej.... h. hanoj
  45. "Petr Morávek [Xificurk]" xificurk na gmail.com #mc86a41
    ony ty registry občas taky obsahují blbosti. Můj oblíbený příklad je KÚ z UIR-ZSJ jménem "Krupá u Kostelce nad Černýni Lesy" ;-)
    *** to neni blbost, to je fakt. KU maji unikatni nazvy napric CR.
    Blbost to je, i když snadno přehlédnutelná, diffni si tyhle dva řetězce: Krupá u Kostelce nad Černýni Lesy Krupá u Kostelce nad Černými lesy Petr
  46. Jakub Sykora kubajz na kbx.cz #m7b934c
    Ja si myslim, ze se automatizovanemu importu nevyhneme. Tohle fakt rucne delat asi nejde :) K
  47. LM_1 flukas.robot+osm na gmail.com #m7d7aa1
    O jakých chybách se tady bavíme? V Brně bylo spostu adresních bodů pěkně vyplněných, ale posunutých o třy čtyři domy vedle. Pro navigaci lepší než nic, ale pro opravy celkem peklo (navíc oproti prázdnotě hledání původního bodu). LM
  48. Jan Breuer jan.breuer na jaybee.cz #mfb2ee1
    V celem Liberci to bylo take uplne stejne posunute nahoodne o nekolik domu, ale pritom korektne otagovane. Mnoho desitek adres jsem tehdy opravoval rucne, kdyz jsem na to narazil. JB O jakých chybách se tady bavíme? V Brně bylo spostu adresních bodů pěkně vyplněných, ale posunutých o třy čtyři domy vedle. Pro navigaci lepší než nic, ale pro opravy celkem peklo (navíc oproti prázdnotě hledání původního bodu). LM
  49. Martin Kokeš shr3k na typo3-hosting.com #m71c668
    Předpokládám, že tehdy při importu UIR-ADR nikdo chybu při převodu JTSK>WGS84 neřešil. :-) http://grass.fsv.cvut.cz/wiki/images/c/c6/Dopnul_wgs84_jtsk_xyerr.png MK
  50. "Petr Morávek [Xificurk]" xificurk na gmail.com #m00eda0
    Předpokládám, že tehdy při importu UIR-ADR nikdo chybu při převodu JTSK>WGS84 neřešil. :-) http://grass.fsv.cvut.cz/wiki/images/c/c6/Dopnul_wgs84_jtsk_xyerr.png MK
    Ahoj, to jsou odchykly v centimetrech, ne? To je/bylo pro import adresních bodů celkem irrelevantní. U importu budov už by možná mělo smysl přemýšlet nad přesnější transformací s nadgrids=czech. Na některých místech by ten necelý metr už mohl být znát, ale i tak by to asi nebyla žádná velká tragédie. Petr
  51. jzvc jzvc na tpfree.net #mbc165d
    O jakých chybách se tady bavíme? V Brně bylo spostu adresních bodů pěkně vyplněných, ale posunutých o třy čtyři domy vedle. Pro navigaci lepší než nic, ale pro opravy celkem peklo (navíc oproti prázdnotě hledání původního bodu). LM
    To je presne o cem se bavime, ze se tam naimportuje hromada dat, ktery nikdy nikdo neopravi - naprosto totez jako aktualne zmena licence, to nikdy nikdo neopravi, protoze se to nijak rozumne opravit neda. je totiz daleko jednodussi mapovat prazdny misto nez opravovat ho. A neni to samo jen posun, chyb tam bude IMO celkem hromada (sak je to registr ala CR). Takze ja sem radsi pro poloprazdnou, ale spravnou mapu, nez pro mapu stejne blbou, jako vsechny ostatni.
  52. Michal Pustějovský Michal.Pustejovsky na seznam.cz #m40ead9
    Ja vam tady do toho lehce vstoupim - moje predstava, jak by to mohlo docela pekne fungovat = upravit soucasny tracer plugin, a to tak, ze nebude trasovat z bitmapy, ale veme vektor/body. => zdroj zi zobrazim jako podklad, a pokud klipnu "do budovy", tak ji to bafne a vlozi do aktivniho layeru. Melo by to samo mit funkci "merge" => pokud chci slucovat, melo by jit nastavit zda poloha bude stavajici nebo ze zdroje + to drapne vsechny stavajici tagy + to samo prida IDcko ze zdroje a omarkuje pokud je poloha z OSM (aby se to v pripade zmeny ve zdroji nemenilo). Tohle by melo fungovat tak, ze klipnu (vyberu) dva objekty stejnyho typu a on je automaticky podle danych pravidel slouci. Zjistovani rozdilu = vemu objekty danyho typu v danym boxu a podivam se, zda mam v OSM vsechny objekty danyho typu s danym ID. Ty co tam nejsou vyrenderuju jako rozdil. Dale u tech co tam jsou overim, zda maji stejne souradnice (a pripadne dalsi parametry) jako ve zdroji (pokud ne = rozdil), pripadne zda sou oznaceny (= v RUIAN je blbost). Pokud to bude v podobe podkladu (trebas vrstva toho WMS generovanyho z RUIAN), tak se da velmi snadno a rychle najit kde co chybi. Melo by to mit nejakou moznost zpetne prohlasit ze v RUIAN je blbost, a takovej objekt by se neresil, dokud nebude v RUIAN zmenen (pripadne by to mohla byt dalsi vrstva). Ad adresni body - me osobne se nelibi, protoze jak uz sem psal vejs, pokud ma budova definovany vchody, da se navigovat ke vchodu i z jiny ulice nez te, kde ma adresu. Pokud je tam bod, tak kazda navigace povede do ulice, kam ta adresa patri. Dovedu si to predstavit prave pro oznaceni mist, kde z nejakyho duvodu budova neni, neni tam digitalini km, ... protoze tam budovy neni moc jak vykreslit. V takovym pripade bych si asi doved predstavit, ze (v ramci upraveneho pluginu) vyberu trebas nejaky box a prohlasim ze do nej chci vlozit vsechny adresni body ze zdroje. S matchovanim to asi bude vselijaky, neb sem svyho casu podobny veci delal, uspesnost asi nepreleze 80 - 85%. Ale opet, lze renederovat nejaky rozdil, a postupne se to da dokupy. Hlavne musi byt nekde videt co kde chybi.
    Dobrý nápad, jenže pokud budu chtít zmapovat budovy v celém městě/vesnici, kde zatím vůbec žádné nejsou, bude to stále ještě hodně pracné. Nebylo by pro tyto případy lepší provést tento import podobně jako import UIR-ZSJ <http://wiki.openstreetmap.org/wiki/Import_UIR-ZSJ>?Pomocí skriptu by se vytvořil .osm soubor obsahující budovy z RÚIAN z daného katastru. Otevřel by se v JOSM jako nová vrstva. Tato vrstva by se porovnala s jinými zdroji a nesrovnalosti by se ručně opravily.Soubor by se uložil a dalším skriptem (který by doplnil source=ruian apod.) poslal do databáze OSM. O programování toho ale moc nevím, takže možná navrhuju něco, co není prakticky proveditelné.
  53. LM_1 flukas.robot+osm na gmail.com #ma67381
    Pokud jde o srovnávání importované vrstvy a stávajího stavu, toto je cílem pluginu conflation. Jak moc to funguje nevím, naposledy když jsem to zkoušel tak nic moc. LM
  54. Libor Pechacek lpechacek na gmx.com #m6532be
    O jakých chybách se tady bavíme? V Brně bylo spostu adresních bodů pěkně vyplněných, ale posunutých o třy čtyři domy vedle. Pro navigaci lepší než nic, ale pro opravy celkem peklo (navíc oproti prázdnotě hledání původního bodu). LM
    To je presne o cem se bavime, ze se tam naimportuje hromada dat, ktery nikdy nikdo neopravi - naprosto totez jako aktualne zmena licence, to nikdy nikdo neopravi, protoze se to nijak rozumne opravit neda. je totiz daleko jednodussi mapovat prazdny misto nez opravovat ho. A neni to samo jen posun, chyb tam bude IMO celkem hromada (sak je to registr ala CR). Takze ja sem radsi pro poloprazdnou, ale spravnou mapu, nez pro mapu stejne blbou, jako vsechny ostatni.
    Tady mluvíme o importu z RÚIAN, jestli dávám správně pozor. Ten je na úrovni dat z KM a databáze adres MVČR. Pokud vím, nic lepšího aktuálně není. Importujme tedy, a to způsobem, který umožní budoucí úpravy, což tu právě diskutujeme. Libor
  55. Martin Kokeš shr3k na typo3-hosting.com #m037fb1
    Bohužel v metrech. :-) Např. Pardubice cca 20 metrů SV-JZ. MK
  56. "Petr Morávek [Xificurk]" xificurk na gmail.com #m8f1024
    Bohužel v metrech. :-) Např. Pardubice cca 20 metrů SV-JZ. MK
    Určitě? V porovnání s čím? Sice mám v tomhle směru fakt limitované znalosti, ale když jsem stáhnul grid [1] a zkusil transformovat pár bodů z Ostravska, tak se výsledek oproti definici [2] lišil cca o 0.5m (plus opačná znaménka). Petr [1] http://grass.fsv.cvut.cz/wiki/index.php/S-JTSK-Grid [2] http://spatialreference.org/ref/sr-org/czech-s-jtsk-epsg2065/proj4/
  57. Martin Kokeš shr3k na typo3-hosting.com #m870db5
    S tou sedmiprvkovou transformací je to samozřejmě přesnější. Jde o to, jestli byla při importu UIR-ADR použita... :-) MK
  58. hanoj ehanoj na gmail.com #mbc4271
    S tou sedmiprvkovou transformací je to samozřejmě přesnější. Jde o to, jestli byla při importu UIR-ADR použita... :-)
    Druhy transformací podle přesnosti (WGS84/ERTS89->S-JTSK) 2D: * 100-110 metrů na severozápad - základní sedmiprvková transformace bez transformačního klíče; nepoužívá se * < 1 metr - základní navíc s parametry transformačního klíče "towgs"; viz níže globální transformační klíč pro ČR/SR * < 0,1 metr - pomocí gridu (ČR); zvláštní článek hanoj
  59. hanoj ehanoj na gmail.com #m253b4a
    Blbost to je, i když snadno přehlédnutelná, diffni si tyhle dva řetězce: Krupá u Kostelce nad Černýni Lesy Krupá u Kostelce nad Černými lesy
    *** aha, to je pod mou okoschopnost ;) h. hanoj
  60. Jan Dudík jan.dudik na gmail.com #m4d041c
    Postup - rozdělit podle katastrů, velké katastry klidně ještě na pár částí a ty pak postupně ručně importovat je určitě lepší, než hromadný import. Když budou data někde k dispozici + stránka na wiki, za pár měsíců uživatelé naimportují své okolí a pak se ukáže, co zbývá a uvidí se, co s tím zbytkem. J&D Dne 2. srpna 2012 20:14 Michal Pustějovský
  61. Martin Kokeš shr3k na typo3-hosting.com #m959194
    Ooops, myšleno sedmikoeficientová (prostě těch 7 toWGS čísel), občas se mi to plete. MK
  62. hanoj ehanoj na gmail.com #m4431bf
    Ooops, myšleno sedmikoeficientová (prostě těch 7 toWGS čísel), občas se mi to plete.
    *** ja myslim ze zaklade uvedenho textu je zrejme, ze chyba 20 metru nemuze nastat. To je pak chyba nekde jinde. h. hanoj
  63. hanoj ehanoj na gmail.com #m284d1f
    Postup - rozdělit podle katastrů, velké katastry klidně ještě na pár částí a ty pak postupně ručně importovat je určitě lepší, než hromadný import.
    *** napred rucne a pak import - zda se mi to jako komplikace pro cloveka pracujiciho s importem navic. Uz tak dost je to slozite a nevidim tam prinos toho jednotlivce. Uz z koordinace UIR-ADR je zrejme ze samotna domluva je slozita: http://wiki.openstreetmap.org/wiki/Import_Adres_%C4%8CR
    Když budou data někde k dispozici + stránka na wiki, za pár měsíců uživatelé naimportují své okolí a pak se ukáže, co zbývá a uvidí se, co s tím zbytkem.
    *** kolik si z tech 13 000 k.u. beres? ;) Uzivatelske zpracovani UIR-ADR bylo po okresech a dosud neni kompletni... http://wiki.openstreetmap.org/wiki/Import_Adres_%C4%8CR ha hanoj
  64. Jiri Klement jiri.klement na gmail.com #maeac6e
    Ahoj, ja jsem pro co nejvetsi automatizaci. Predstavoval bych si to jako plugin do JOSM, ktery pro zadanou oblast zobrazi tri typy zmen: 1) trivialni zmeny - v ruian je neco navic nebo zmena u objektu z importu 2) podezrele zmeny - v ruian je zmena u objektu, ktery nekdo manualne upravil 3) potvrzene zmeny - ruian a osm se rozchazeji, ale nekdo uz oznacil osm verzi jako spravnejsi. Aplikace by mela mit moznost oznacit objekt z ruian jako neexistujici - pripadne mi to jako mensi zlo, nez mit v osm node, ktery by pouze rikal, ze tahle budova uz nestoji a v ruianu je to spatne. Az by se to trosku vyzkouselo, tak by trivialni zmeny mohl delat bot sam. Akorat bych tam nechal moznost oznacit oblast, o kterou se stara primo nektery uzivatel. Tim by se zajistilo, ze do dobre zmapovanych a kontrolovanych oblasti ruian nezavlece nejakou chybu, ktere by si nikdo nevsimnul.
  65. Pavel Machek pavel na ucw.cz #mff51f6
    Já jsem pro hromadný import, případně následně pro vytvoření robota na údržbu. Minimálně u adresních bodů. MK
    A dopadne to jako potoky, ktery nejsou spraveny doted.
    Mozna je to nepopularni nazor, ale od importu potoku se stala osm *o hodne* pouzitelnejsi. Skript ktery najde krizici-se vodni toky by nemel byt problem... Pavel
  66. Michal Pustějovský Michal.Pustejovsky na seznam.cz #m9fde59
    Já jsem pro hromadný import, případně následně pro vytvoření robota na údržbu. Minimálně u adresních bodů. MK
    A dopadne to jako potoky, ktery nejsou spraveny doted.
    Mozna je to nepopularni nazor, ale od importu potoku se stala osm *o hodne* pouzitelnejsi. Skript ktery najde krizici-se vodni toky by nemel byt problem... Pavel
    Žádný skript není nutný, tohle už je řešeno zde <http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic> (sekce Společné projekty, druhá odrážka).
  67. Václav Řehák rehakv01 na gmail.com #mf28475
    A dopadne to jako potoky, ktery nejsou spraveny doted.
    Mozna je to nepopularni nazor, ale od importu potoku se stala osm *o hodne* pouzitelnejsi.
    Naprostý souhlas. Vodní toky a nádrže jsou kromě silnic snad jedinou věcí, na kterou se můžu spolehnout, že je v mapě opravdu plošně.
  68. jzvc jzvc na tpfree.net #m074577
    Postup - rozdělit podle katastrů, velké katastry klidně ještě na pár částí a ty pak postupně ručně importovat je určitě lepší, než hromadný import.
    *** napred rucne a pak import - zda se mi to jako komplikace pro cloveka pracujiciho s importem navic. Uz tak dost je to slozite a nevidim tam prinos toho jednotlivce. Uz z koordinace UIR-ADR je zrejme ze samotna domluva je slozita: http://wiki.openstreetmap.org/wiki/Import_Adres_%C4%8CR
    Když budou data někde k dispozici + stránka na wiki, za pár měsíců uživatelé naimportují své okolí a pak se ukáže, co zbývá a uvidí se, co s tím zbytkem.
    *** kolik si z tech 13 000 k.u. beres? ;) Uzivatelske zpracovani UIR-ADR bylo po okresech a dosud neni kompletni... http://wiki.openstreetmap.org/wiki/Import_Adres_%C4%8CR
    Problem = nevizualnost. Ja taky nebudu zkoumat 100x nejakou stranku na wiki, a sacovat X strankovej seznam ... na to se kazdej vybodne. Je treba, aby to bylo videt na mape => uzemi kde je hotovo, uzemi kde neni, uzemi ktery je treba kontrolovat ... to se samo netyce jen tohoto, ale veskerych importu. Pokud by byla k dispozici mapka, kde budou prubezne mizet zpracovana uzemi, tak to kazdej jednim mrknutim zkoukne.
  69. hanoj ehanoj na gmail.com #m384898
    Postup - rozdělit podle katastrů, velké katastry klidně ještě na pár částí a ty pak postupně ručně importovat je určitě lepší, než hromadný import.
    *** napred rucne a pak import - zda se mi to jako komplikace pro cloveka pracujiciho s importem navic. Uz tak dost je to slozite a nevidim tam prinos toho jednotlivce. Uz z koordinace UIR-ADR je zrejme ze samotna domluva je slozita: http://wiki.openstreetmap.org/wiki/Import_Adres_%C4%8CR
    Když budou data někde k dispozici + stránka na wiki, za pár měsíců uživatelé naimportují své okolí a pak se ukáže, co zbývá a uvidí se, co s tím zbytkem.
    *** kolik si z tech 13 000 k.u. beres? ;) Uzivatelske zpracovani UIR-ADR bylo po okresech a dosud neni kompletni... http://wiki.openstreetmap.org/wiki/Import_Adres_%C4%8CR
    Problem = nevizualnost. Ja taky nebudu zkoumat 100x nejakou stranku na wiki, a sacovat X strankovej seznam ... na to se kazdej vybodne. Je treba, aby to bylo videt na mape => uzemi kde je hotovo, uzemi kde neni, uzemi ktery je treba kontrolovat ... to se samo netyce jen tohoto, ale veskerych importu. Pokud by byla k dispozici mapka, kde budou prubezne mizet zpracovana uzemi, tak to kazdej jednim mrknutim zkoukne.
    *** Import adres po okresech je adekvatni pro zpracovani na wiki. Jednim mrknutim oka je zrejme, ze to nefunguje. hanoj
Napsat odpověď e-mailem… Odpovědět

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