Re: [Talk-cz] problém s gml řetězcem
Dne 15.7.2012 23:44, hanoj napsal(a):
Nemuze to souviset s timto?
http://www.cuzk.cz/Dokument.aspx?PRARESKOD=998MENUID=10769AKCE=DOC:10-VDP_NOVINKY
Ve výměnném formátu VFR je chybně ukládána geometrie parcel a
stavebních objektů, které jsou tvořeny kružnicí (případně se kružnice
vyskytuje jako jeden z vnitřních polygonů parcely). Problém se
vyskytuje v souborech mmdd_OB_cc_UKSH.xml.
Ve výměnném formátu VFR je chybně ukládána geometrie parcel, které
obsahují vnitřní polygon, který je tvořen částí oblouku. Problém se
vyskytuje v souborech mmdd_OB_cc_UKSH.xml.
to bude asi ono. akorát mi není jasné, jestli lze z toho řetězce
vytvořit správný řetězec jeho přepsáním, nebo je chyba jiného rázu a
opravit ji nelze, protože v něm některá data chybí. hledal jsem na netu
gml validátor pro verzi 3, ale asi zatím nic neexistuje. nebo mám
invalidní data prostě ignorovat s tím, že to bude (nebo už i je?) v
nějakém aktualizačním souboru správně a při updatu se to přepíše?
PS: jak resis, ze jsou souradnice kladne a maji byt zaporne?
to zatím neřeším, netušil jsem, že to co je v datech není správně, a
nějak mě to netrklo :-) stačí, když před všechny souřadnice dám mínus
nebo to vyžaduje ještě něco dalšího?
ha
hanoj
ff
Dne 15. července 2012 23:18 Miroslav Šulc fordf...@fordfrog.com napsal(a):
ahoj,
netušíte někdo, co je za problém s tímhle gml řetězcem při převodu
postgis funkcí st_geomfromgml?
ruian-test=# insert into test values (st_geomfromgml('gml:Polygon
xmlns:gml=http://www.opengis.net/gml/3.2; gml:id=HPA.13631950010
srsName=urn:ogc:def:crs:EPSG::2065
srsDimension=2gml:exteriorgml:Ringgml:curveMembergml:LineString
gml:id=HPA.13631950010.1gml:posList481595.25
1102177.50 481594.26 1102173.81 481595.20 1102173.14 481595.73
1102172.20 481595.87 1102171.13 481599.33 1102170.22 481599.01
1102169.00 481606.76 1102166.97 481605.22 1102161.03 481600.78
1102162.15 481599.03 1102154.97 481591.89 1102156.87 481589.28
1102157.56 481590.24 1102161.70 481590.97 1102164.88 481589.46
1102165.28/gml:posList/gml:LineString/gml:curveMembergml:curveMembergml:Curve
gml:id=HPA.13631950010.2.3gml:segmentsgml:ArcStringgml:posList481589.46
1102165.28 481588.41 1102165.67 481587.72 1102166.19 481587.07
1102166.85 481586.30 1102168.29 481585.96 1102169.71 481586.03
1102171.13/gml:posList/gml:ArcString/gml:segments/gml:Curve/gml:curveMembergml:curveMembergml:LineString
gml:id=HPA.13631950010.3gml:posList481586.03 1102171.13 481588.39
1102179.94 481588.85 1102179.86 481590.37 1102185.72 481594.17
1102184.79 481594.52
1102186.07/gml:posList/gml:LineString/gml:curveMembergml:curveMembergml:Curve
gml:id=HPA.13631950010.4.5gml:segmentsgml:ArcStringgml:posList481594.52
1102186.07 481595.95 1102185.59 481597.56 1102183.98 481598.13
1102181.79 481597.87
1102180.21/gml:posList/gml:ArcString/gml:segments/gml:Curve/gml:curveMembergml:curveMembergml:LineString
gml:id=HPA.13631950010.5gml:posList481597.87 1102180.21 481596.54
1102180.56 481595.68 1102177.39 481595.25
1102177.50/gml:posList/gml:LineString/gml:curveMember/gml:Ring/gml:exterior/gml:Polygon'));
ERROR: invalid GML representation
KONTEXT: SQL function st_geomfromgml statement 1
ten xml string se zdá být validní. háže mi to postgresql 9.2 beta2 +
postgis 2.0.1. na jiné verzi jsem to nezkoušel. v postgresql logu je to
samé co mi to píše v pgsql, není tam žádné doplňující info. je to při
importu souboru 20120630_OB_500291_UKSH.xml.gz.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Praha bude brzy děravá :-(
Docela me zarazi, ze tam dojde ke smazani veci, ktere jsem mapoval v zacatcich OSM jen proto, ze to nekdo, kdo s licenci nesouhlasi lehce opravil nebo k tomu pridal nazev... Ach jo... Dne 16.7.2012 17:42, Jakub Těšínský napsal(a): Tak jsem si zazoomoval na Prahu abych viděl, co nám relicencovací bot v nejbližší době smázne a veselý pohled to není. Koukněte na http://harrywood.dev.openstreetmap.org/license-change/botprocessing.php?zoom=12lat=50.05582lon=14.44004layers=00BFTTFF Pokud máte zrovna čas je nejspíš posledních pár hodin některé te věci třeba z leteckých snímků opravit. Jakub ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Praha bude brzy děravá :-(
Ahoj, to mě také zaráží. V takovém případě by snad mělo smysl použít poslední licenčně použitelnou verzi, případně selektivně odstranit licenčně problematické tagy apod. Honza Dne 16.7.2012 18:04 Jakub Sykora kub...@kbx.cz napsal(a): Docela me zarazi, ze tam dojde ke smazani veci, ktere jsem mapoval v zacatcich OSM jen proto, ze to nekdo, kdo s licenci nesouhlasi lehce opravil nebo k tomu pridal nazev... Ach jo... Dne 16.7.2012 17:42, Jakub Těšínský napsal(a): Tak jsem si zazoomoval na Prahu abych viděl, co nám relicencovací bot v nejbližší době smázne a veselý pohled to není. Koukněte na http://harrywood.dev.**openstreetmap.org/license-** change/botprocessing.php?zoom=**12lat=50.05582lon=14.44004** layers=00BFTTFFhttp://harrywood.dev.openstreetmap.org/license-change/botprocessing.php?zoom=12lat=50.05582lon=14.44004layers=00BFTTFF Pokud máte zrovna čas je nejspíš posledních pár hodin některé te věci třeba z leteckých snímků opravit. Jakub __**_ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-czhttp://lists.openstreetmap.org/listinfo/talk-cz __**_ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-czhttp://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Praha bude brzy děravá :-(
Na mapě jsou objekty jejichž první vlastník neschválil ODbL. hanoj Dne 16. července 2012 18:14 Jan Bilak jan.bilak@gmail.com napsal(a): Ahoj, to mě také zaráží. V takovém případě by snad mělo smysl použít poslední licenčně použitelnou verzi, případně selektivně odstranit licenčně problematické tagy apod. ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Praha bude brzy děravá :-(
Na mapě jsou objekty jejichž první vlastník neschválil ODbL. Ale neni mi jasne, proc se tam dostalo treba tohle: http://www.openstreetmap.org/browse/way/44890172 v historii to ma akorat hanoje a pritom to je v BADMAP: http://harrywood.dev.openstreetmap.org/license-change/botprocessing.php?zoom=16lat=49.19004lon=16.55838layers=00BFTTFF Jestli je to kvuli tehle jedne zavore? http://www.openstreetmap.org/browse/node/88397258 Petr ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] k wiki
Dne 12.7.2012 10:24, Jakub napsal(a): On 12.7.2012 09:09, talk-cz-requ...@openstreetmap.org wrote: v?era jsem si pro??tal ?eskou wiki k osm, ale n?jak jsem z n? nepochopil, jestli jsou pr?ce na ?esk?ch map?ch n?jak koordinovan? nebo ka?d? d?l? to, co ho zrovna bav?. str?nka o progresu je asi dva roky star?, tak?e z n? jsem se toho moc nedozv?d?l. *** Ano stranky wiki pisou zpravidla novacci, kdy pochopi jak to funguje. Stari matadori to maji v hlave (derave). No možná to odpovídá realitě, ale není to dobře. Pro mě alespoň tedy ta nejvíce matoucí a flustrující věc na OSM je to, že sice existuje nějaká polodokumentace (wiki), ale není moc jasné jaký mají informace v ní obsažené status. U některých věcí mám pocit, že by bylo lepší je tam vůbec nemít, než je mít napůl. Jako nováček bych ocenil stručnou informaci typu: Jak mapovat budovy: použijte tag building=yes, housenumber= , nepoužívejte XY, to je zastaralé, tam kde to je to můžete smazat. Jak mapovat polí cestu: žádná pravidla nejsou (nějaké vodítko je zde - odkaz). Jak mapovat to mi na wiki chybí. A mimochodem, mám pocit že vůbec není pravda, že matadoři mají správné odpovědi v hlavě. Spíš mi přijde, že pochopili, že v OSM správné odpovědi neexistují a že místo zdlouhavého procesu prosazení nějaké normy je prostě jednodušší začít mapovat tak jak se mu to líbí a tak jak chce on. Koneckonců to tak dělají všichni. Jestli je to dobře, nebo špatně ukáže čas. Jakub Z toho si nic nedelej, to je normalni stav ;D. Varianty jsou vpodstate v zakladu dve - podivas se, jak se co renederuje a podle toho to otagujes = mapa bude sice vypadat pekne, ale tagovani muze byt logicky spatne (= napriklad navigace te bude blbe navigovat). Varianta druha je, ze to budes tagovat nejak logicky spravne, ale to muze prozmenu generovat nepeknou mapu. Tady samo muzes vznest pozadavek na upravy renederu, ale v nekterych pripadech to je na hodne dlouhe lokte. Vicemene totiz panuje +- schoda na nejzakladnejsim (a i to bude v ruznych zemich jinak - staci kdyz trocha odzoomujes, a uvidis jak je kazda zeme jinak barevne ladena), ale jakykoli dalsi detaily = kazdej si to dela jak se nekde docet/vykoumal/mysli si ... ze je to spravne. ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Praha bude brzy děravá :-(
Jan Bilak wrote: Ahoj, to mě také zaráží. V takovém případě by snad mělo smysl použít poslední licenčně použitelnou verzi, případně selektivně odstranit licenčně problematické tagy apod. Honza Ano takto nějak (ještě trochu chytřeji) bot pracuje... Ale žádný nástroj upozorňující na špinavá data nemá implementovanou úplnou logiku bota, takže všechny zobrazují i věci, které (částečně) přežijí. Petr Morávek aka Xificurk attachment: xificurk.vcf signature.asc Description: OpenPGP digital signature ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] kde můžu pomoct?
Dne 12.7.2012 9:37, Miroslav Šulc napsal(a): Dne 11.7.2012 23:22, Michal Pustějovský napsal(a): Miroslav Šulc fordfrog@... writes: zdravím, jsem tu nový a tak se chci zeptat, kde a s čím případně můžu pomoct, na čem má smysl pracovat a na čem ne. co jsem třeba tak nějak pochopil, tak adresní body asi aktuálně nemá smysl ručně v mapách řešit. přijde mi, že aktuálně asi hlavním uživatelsky kvalitativním nedostatkem čr map jsou ulice bez názvů, ale nemám přehled, v jakém rozsahu chybí názvy ulic a jestli se na tom nějak pracuje. další problém, na který jsem narazil, je že některé ulice na mapě vůbec nejsou. to se ale asi špatně hledá, pokud člověk danou oblast nezná nebo ji nezpracovává globálně. chybějící ulice by se asi daly najít porovnáním osm dat s nějakou db ulic. další věc, která mě napadá, je malování budov, ale to si myslím, že je v tuhle chvíli spíš bonus a v současnosti to nemá takovou prioritu. Na doplňování názvů ulic ve městech může skvěle posloužit OSM Inspector (http://tools.geofabrik.de/osmi/?view=wtfe ; vrstva highways zobrazuje silnice bez ref. čísla nebo názvu - ale i u vesnic). Dalším dobrým nástrojem pro mapování je KeepRight (http://www.keepright.at/). oba nástroje vypadají dost dobře, díky za tip. fordfrog Mozna by nebylo od veci vytvorit na wiki nejakou linkfarmu ;D, shromazduju ruzny linky z ruznych zdroju, a to jak aplikace mapy a jeji ruzna vyuziti, tak i ruzne tools. Pro zkoumani chyb je napr dobry: http://www.itoworld.com/ - ruzne pohledy na mapy se zvyraznenim ruznych aspektu - napr rychlostni omezeni, budovy s adresou/bez adresy ... energeticke rozvody, vodni toky ... http://www.mapdust.com/ - existuje i plugin do JOSM, nastroj pro reportovani chyb, ale v CR neni moc pouzivany ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Praha bude brzy děravá :-(
Dne 16.7.2012 17:42, Jakub Těšínský napsal(a): Tak jsem si zazoomoval na Prahu abych viděl, co nám relicencovací bot v nejbližší době smázne a veselý pohled to není. Koukněte na http://harrywood.dev.openstreetmap.org/license-change/botprocessing.php?zoom=12lat=50.05582lon=14.44004layers=00BFTTFF Pokud máte zrovna čas je nejspíš posledních pár hodin některé te věci třeba z leteckých snímků opravit. Jakub Kdyby jen praha ... koukam na trat, kterou sem prakticky komplet o desitky metru zpresnoval a ta je tam cela ... ja sem odjakziva pro, jit ty voly co tohle spachali zastrelit. V Berline budou mit taky radost - koukam ze tak 80% POI lol Mno tomu se rika ucta k praci jinych. Mimochodem, chapu spravne ze nam zmizi cela severni cast statni hranice? Tohle nikdy nikdo uz neda dohromady ... to meli radsi tu mapu smazat komplet, protoze je 1000x narocnejsi spravovat neco, co ani nevim kde je rozbity nez to udelat komplet znova. Zvu na pivo kazdyho, kdo mi prinese dukaz, ze zbavil planetu pravnika. ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] ruian a automatizace?
Dne 12.7.2012 13:21, Miroslav S(ulc napsal(a): Dne 12.7.2012 10:15, Jakub napsal(a): S s plnou a dokonce i c(ástec(nou automatizací je to sloz(ité, resp. je sloz(ité to ude(lat dobr(e. Navíc kdyz( se to ude(lá s(patne(, tak to mu*z(e ve(ci i zhors(it - napr(íklad pr(epsat zdánlive( chybnou informaci, která se ale zakládá na osobním pozorování na míste( namotném a je naopak správne(. OSM je zaloz(eno na tom, z(e se v ne(m mixují ru*zní zdroje informací, takz(e dlouhodobe( jednosme(rná synchronizace z ne(jakého jediného zdroje je proti smyslu projektu. Pokud by ovs(em onen projekt byl schopen a ochoten i zpe(tné synchronizace informací doplne(ných OSM tak to je jiná, ale i tohle bude spís( spousta práce, nez( ne(jaký automatický proces. K té práci se samozr(ejme( mohou hodit ru*zné nástroje, ale z(ádný nástroj ti nevyr(es(í jednoduchý problém typu: naimportujes( odne(kud budouvu a za rok pr(i snaze o synchronizaci zjistís( z(e jak v OSM tak v prvotním zdroji dos(lo ke úpravám polohy. Co s tím? Pokud se nevydás( do terénu, pravdu nezjistís(. C(ili ude(látka typu automatické generovátka chyb ano, ale stejne( na konci bude ruc(ní práce. proto jsem psal o té poloautomatice. je mi jasné, z(e nelze proste( vzít data z rúian a pr(epsat s tím data v osm. ale asi by se na základe( urc(itých pravidel daly ty importy aspon( zpoloautomatizovat, tj. ne(co by se naimportovalo rovnou (tr(eba proto, z(e to v osm chybí), u ne(c(eho tr(eba bude moz(né urc(it, z(e to lze taky automaticky pr(epsat (needitovaný záznam, rozdíl v sour(adnicích pouze v rámci ne(jaké malé odchylky, atd.), a zbytek by se musel pr(i prvotním importu odkontrolovat ruc(ne(. pak uz( by ale me(lo být moz(né jen sledovat zme(ny a podle toho pr(ípadne( upravovat údaje v mape(. v praxi by to samozr(ejme( znamenalo spoustu testování a ove(r(ování, nez( by se takovému systému povolilo ne(co zapisovat, ale do budoucna by v tom podle me( byl rozhodne( velký pr(ínos. samozr(ejme( ale základní otázka je, nakolik kvalitní data rúian obsahuje. Ad kvalita dat - zrovna nedavno sem nekde cet vyjadreni z nejaky obce typu ten system funguje blbe, a jeste v tom je hromada chyb prave k RUIAN, s tim, ze pry se pokusili opravit nejake chyby, ale neni jak to dam dostat, protoze to funguje jako vsechny registry ... Ad zbytek - moje predstava (obecne) je zhruba ta, ze by to chtelo nejakou prehledovou mapu, kde by nejak barevne bylo videt trebas % rozdilu. Dal by to chtelo neco jako tracer, ale aby to neobkreslovalo ale primo importovalo vybrany prvky (plugin do JOSM). Proste jednoduse by user jen klikal na vybrany prvky a ty by se mu ladovaly do datasetu - rychly, jednoduchy, a podlehajici alespon zbezny vizualni kontrole = jakas takas ochrana proti importu ptakovin. Soucinosti s tim prehledem by se relativne rychle dala zpracovat drtiva vetsina dat + zaroven by se nemuselo vymejslet, co se kde cim rozbije. Samo optimalne s moznosti si zobrazit jen vybrany typ (trebas jen ulice) a vybrat celou oblast. Technicky ses pak schopen zpetne generovat nejakej seznam objektu, ktery byly v OSM zmeneny, na ktery se pak muze kdokoli podivat a trebas do poznamky napsat je to OK, v RUIAN je pitomost, pripadne u toho objektu nejak nastavi fixme = muzes objekt prepsat. Jakub fordfrog ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Praha bude brzy děravá :-(
On 16.7.2012 22:26, jzvc wrote: Dne 16.7.2012 17:42, Jakub Těšínský napsal(a): Tak jsem si zazoomoval na Prahu abych viděl, co nám relicencovací bot v nejbližší době smázne a veselý pohled to není. Koukněte na http://harrywood.dev.openstreetmap.org/license-change/botprocessing.php?zoom=12lat=50.05582lon=14.44004layers=00BFTTFF Pokud máte zrovna čas je nejspíš posledních pár hodin některé te věci třeba z leteckých snímků opravit. Jakub Kdyby jen praha ... koukam na trat, kterou sem prakticky komplet o desitky metru zpresnoval a ta je tam cela ... ja sem odjakziva pro, jit ty voly co tohle spachali zastrelit. V Berline budou mit taky radost - koukam ze tak 80% POI lol Mno tomu se rika ucta k praci jinych. Mimochodem, chapu spravne ze nam zmizi cela severni cast statni hranice? Tohle nikdy nikdo uz neda dohromady ... to meli radsi tu mapu smazat komplet, protoze je 1000x narocnejsi spravovat neco, co ani nevim kde je rozbity nez to udelat komplet znova. Zvu na pivo kazdyho, kdo mi prinese dukaz, ze zbavil planetu pravnika. Autora železničních tratí a velmi detailně zpracovaných stanic v Lipsku asi trefí, až zjistí, že o všechno přišel, viz: http://harrywood.dev.openstreetmap.org/license-change/botprocessing.php?zoom=13lat=51.35288lon=12.43143layers=00BFTTFF http://harrywood.dev.openstreetmap.org/license-change/botprocessing.php?zoom=13lat=51.35288lon=12.43143layers=00BFTTFF Souhlasím, že občas někde zmizelých pár metrů silnice už nikdo nikdy nemůže dát dohromady. Achjo... Jsem poměrně nový a moc tomu nerozumím - smím se zeptat, proč se musí všechna data tak rychle smazat? Místo aby se zneviditelnila a byla dostupná jen v JOSM pro dodatečnou editaci v souladu s licencí? LuKo ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Praha bude brzy děravá :-(
Aaa to byla cesta Pavlova a hanoj ji dnes opravil. Jeste jsem delal taxiway letiste LKTB a cyklostezku v Pisárkách, track v Kohoutovicich, kousek zeleznice na Hl. nadrazi, lesni cesty v Kohoutovicich nedaleko ulice Borodinovy, dale ulice Tomanova, Studanka, Porici, Rybarska, Ecerova a Vejrostova. Zbyvaji ty ulice v Husovicich. omlouvam se, mel jsem to sem napsat. ha hanoj 2012/7/16 Petr Holub ho...@ics.muni.cz: Na mapě jsou objekty jejichž první vlastník neschválil ODbL. Ale neni mi jasne, proc se tam dostalo treba tohle: http://www.openstreetmap.org/browse/way/44890172 v historii to ma akorat hanoje a pritom to je v BADMAP: http://harrywood.dev.openstreetmap.org/license-change/botprocessing.php?zoom=16lat=49.19004lon=16.55838layers=00BFTTFF Jestli je to kvuli tehle jedne zavore? http://www.openstreetmap.org/browse/node/88397258 ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Praha bude brzy děravá :-(
jzvc wrote: Mno tomu se rika ucta k praci jinych. Mimochodem, chapu spravne ze nam zmizi cela severni cast statni hranice? Chapes spatne... Zrovna hranice jsem uz pred par mesici prochazel a v tech nekolika malo pripadech, kde do toho hrabnul nejaky odmitac, jsem dany usek naimportoval podle CUZK znova. V BADMAP se pokud vim renderuji jen a pouze objekty vytvorene odmitaci. To ovsem neznamena, ze je bot kompletne smaze. Napr. pokud se uplne zmenily vsechny vlastnosti objektu (nody v ceste + tagy), tak objekt zustane tak jak je. Obecne - bot odstrani vsechny prezivajici editace odmitacu. Ta severni hranice se tam asi dostala protoze je soucasti nejake nemecke relace, kterou vytvoril odmitac. Trochu nestastnym dusledkem toho, ze se bot snazi zachranit, co nejvice informaci, je to, ze po jeho pruchodu zustavaji napr. opustene nody bez tagu (nody byly ciste, ale cesta jejiz byly soucasti ne). Panikarit ted je uz/jeste zbytecne, jeste bych s tim par hodin pockal :-) Petr Morávek aka Xificurk signature.asc Description: OpenPGP digital signature ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] ruian a automatizace?
Ad kvalita dat - zrovna nedavno sem nekde cet vyjadreni z nejaky obce typu ten system funguje blbe, a jeste v tom je hromada chyb prave k RUIAN, s tim, ze pry se pokusili opravit nejake chyby, ale neni jak to dam dostat, protoze to funguje jako vsechny registry ... *** ...ale nic lepsiho neni a lepsi nez dosavadni UIR-ADR to je. Ad zbytek - moje predstava (obecne) je zhruba ta, ze by to chtelo nejakou prehledovou mapu, kde by nejak barevne bylo videt trebas % rozdilu. Dal by to chtelo neco jako tracer, ale aby to neobkreslovalo ale primo importovalo vybrany prvky (plugin do JOSM). Proste jednoduse by user jen klikal na vybrany prvky a ty by se mu ladovaly do datasetu - rychly, jednoduchy, a podlehajici alespon zbezny vizualni kontrole = jakas takas ochrana proti importu ptakovin. Soucinosti s tim prehledem by se relativne rychle dala zpracovat drtiva vetsina dat + zaroven by se nemuselo vymejslet, co se kde cim rozbije. Samo optimalne s moznosti si zobrazit jen vybrany typ (trebas jen ulice) a vybrat celou oblast. *** Ja moc na pluginy neverim. Takovou vec tu mame a dosud neni dodelana (waterway). *** Ze stovky beznych useru budou rozhodovat co jo/ne a resit konflikty... A uz vubec to neni realne ze bezni useri projdou 12 000 sidel, natoz uspesne. ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] problém s gml řetězcem
hledal jsem na netu gml validátor pro verzi 3, ale asi zatím nic neexistuje. nebo mám invalidní data prostě ignorovat s tím, že to bude (nebo už i je?) v nějakém aktualizačním souboru správně a při updatu se to přepíše? *** Myslim, ze to opravi v nejakem pristim mesicnim celkovem vydani, validovat to neumim. PS: jak resis, ze jsou souradnice kladne a maji byt zaporne? to zatím neřeším, netušil jsem, že to co je v datech není správně, a nějak mě to netrklo :-) stačí, když před všechny souřadnice dám mínus nebo to vyžaduje ještě něco dalšího? *** Ano, zda se ze jen zaporne znamenko. (Někdy byva třeba v jinych datech prohodit X za Y...) PS: dival jsem se, ze ulice ve VFR nemaji geometrii, tudiz nas vlastne zajimaji jen: * parcely zastavene (druh pozemku kod= myslim 13 ) * adresni body hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] problém s gml řetězcem
Dne 16.7.2012 23:29, hanoj napsal(a): hledal jsem na netu gml validátor pro verzi 3, ale asi zatím nic neexistuje. nebo mám invalidní data prostě ignorovat s tím, že to bude (nebo už i je?) v nějakém aktualizačním souboru správně a při updatu se to přepíše? *** Myslim, ze to opravi v nejakem pristim mesicnim celkovem vydani, validovat to neumim. já jsem to nakonec vyřešil tak, že jsem do aplikace přidal parametr --ingore-invalid-gml. při importu to s tímhle parametrem kontroluje každou gml definici, takže je to pomalejší, ale zase to na chybné gml definici nespadne. pokud st_geomfromgml definici odmítne, tak se záznam uloží, jako by tam žádná definice nebyla. taky právě počítám s tím, že v nějakém updatu se to pak přehraje. otázka ovšem je, jestli se změní i údaj platné od (podle něj filtruju, jestli se má záznam zaktualizovat nebo ne, starší platné od nepřepíše novější platné od). asi by to bylo lepší navázat na id transakce, ale nikde jsem k tomu id transakce neviděl popis, jestli jdou ty transakce vzestupně nebo jsou id náhodná. PS: jak resis, ze jsou souradnice kladne a maji byt zaporne? to zatím neřeším, netušil jsem, že to co je v datech není správně, a nějak mě to netrklo :-) stačí, když před všechny souřadnice dám mínus nebo to vyžaduje ještě něco dalšího? *** Ano, zda se ze jen zaporne znamenko. (Někdy byva třeba v jinych datech prohodit X za Y...) ok, takhle jsem to udělal. PS: dival jsem se, ze ulice ve VFR nemaji geometrii, tudiz nas vlastne zajimaji jen: * parcely zastavene (druh pozemku kod= myslim 13 ) * adresni body a budovy? hanoj ff smime.p7s Description: Elektronicky podpis S/MIME ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] problém s gml řetězcem
PS: dival jsem se, ze ulice ve VFR nemaji geometrii, tudiz nas vlastne zajimaji jen: * parcely zastavene (druh pozemku kod= myslim 13 ) * adresni body a budovy? *** budovy jsou... a) bud zastavene parcely (dnes delane tracerem v JOSM) b) nebo bod stavebniho objektu a s tim toho mnoho neudelame. Importovat body s tagem building=yes, mi neprijde dobre. Slo by z toho generovat neco jako landuse=residential. Vic mne nenapada. hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] problém s gml řetězcem
Dne 16.7.2012 23:48, Miroslav Šulc napsal(a): PS: dival jsem se, ze ulice ve VFR nemaji geometrii, tudiz nas vlastne zajimaji jen: * parcely zastavene (druh pozemku kod= myslim 13 ) * adresni body a budovy? resp. stavební objekty. jaký je rozdíl mezi stavebními objekty a parcelami? ty ulice by se daly aktuálně použít aspoň ke kontrole, jestli nám na mapě nechybí. hanoj ff ff smime.p7s Description: Elektronicky podpis S/MIME ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
