Re: [Talk-cz] UHUL WFS import
Ta nezapadla. Psal jsem, ze do noveho importu to udelam. K noone02 napsal(a): > BH napsal(a): > >> A rozhodne bych udelal optimalizaci (jako treba vyhazeni duplicitnich >> nodes a tak ...) >> >> >> ___ >> Talk-cz mailing list >> Talk-cz@openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> >> >> >> > > Myslim, ze by lesum velmi pomohla tato myslenka, která zapadla. V mem > regionu, je kazdy les urcite z 50% tvoren duplicitnima bodama. > > > ___ > Talk-cz mailing list > Talk-cz@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] UHUL WFS import
BH napsal(a): > A rozhodne bych udelal optimalizaci (jako treba vyhazeni duplicitnich > nodes a tak ...) > > > ___ > Talk-cz mailing list > Talk-cz@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > > > Myslim, ze by lesum velmi pomohla tato myslenka, která zapadla. V mem regionu, je kazdy les urcite z 50% tvoren duplicitnima bodama. ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] UHUL WFS import
No tak ve chvili kdy nekdo nahraje o josm cely svet (rozbalene xml ma tusim asi 35 GB) tak se to asi sesype na libovolnem existujicim pocitaci. JOSM zvlada, jen musi byt vyrez rozumne velky. Co jde udelat je upravit JOSM aby zvladal vice dat najednou, ale nejaky limit tam bude vzdycky a v huste mapovanych oblastech (mesta) bude koncentrace dat na kilometr ctverecni obvykle vyssi, tudiz muzu editovat najednou mensi kus. Ono staci vybrat si maximalni vyrez kolem centra prahy co server posle (0.25 stupne tusim, cela praha se tam nevejde, ale vetsina jo) a uz za soucasneho stavu to v josm jede pomerne pomalu (holt mnozstvi ulic a dalsich veci v mape je pomerne znacne.) Rozhodne bych nezjednodusoval hranice polygonu, maximalne bych zvazil slouceni navazujicich polygonu s ruznymi typy lesa (mt jen "les" by mohlo vetsine lidi stacit, nevim jak moc lidi bude z toho co je v OSM vyrabet treba orientacky mapy nebo mapy porostu :) A rozhodne bych udelal optimalizaci (jako treba vyhazeni duplicitnich nodes a tak ...) Martin On 12/5/07, Michal Grézl <[EMAIL PROTECTED]> wrote: > On Dec 5, 2007 3:02 AM, BH <[EMAIL PROTECTED]> wrote: > > No > > On 12/3/07, Pavel Machek <[EMAIL PROTECTED]> wrote: > > > Ahoj! > > > > > > > prave jsem si nahral a vypada to moc pekne: > > > > http://kubajz.kbx.cz/junk/uhul/output/x603388_x1159320_x593388_x1149320.xml.gz > > > > > > > > coz pokryva asi 1/6 mesta Brna. > > > > Tento jeden XML ma 7MB, takze po jeho natazeni uz nejde s JOSM rozumne > > > > pracovat, na hloupych 10km ctverecnich. > > > > v zmapovane zastavbe to kvuli mnozstvi detailu asi tak dobre nepujde. > > Ono kilometr ctverecni v zastavbe muze mit stejne mnozstvi detailu > > jako 1000 km ctverecnich nekde v polich. Holt se bude muset pouzit > > mensi okno (nebo zlepsit JOSM) > > > > Koukam ze vsechny lesy maji 141Mb dohromady zabalene, v soucasnosti ma > > CR asi 7 Mb ... vcelku vyznamne ji to nafoukne, ale jinak bych to tam > > nahral cele, z nejakemu prilisnemu zjednodusovani bych se neuchyloval > > ... kdyz uz nahrat, tak poradne. Zjednodusit si to muze treba az > > renderer > > > > > > * vytvorime tematicke vrstvy v JOSM, tak abych treba si > > > > nestahoval/vypnul zobr. lesu, ci zjednodusil vykreslovani se zoomem? > > > > To by ale asi muselo podporovat serverove api - stahnout z vyrezu data > > v nejake vrstve nebo vyhovujici nejakemu filtru. > > > > Martin > > > Ja osobne bych upravoval editovaci nastroje, nez omezoval data v mape! > Pokud na to josm nestaci tak je chyba v nem a musi se opravit. Myslim, > ze by nebyl problem napriklad zahodit urcita data po stazeni, aby pri > editaci nezavazely a nezpomalovaly program. Ale to je spis diskuze do > josm-devel listu nebo na jejich bugzillu (trac nebo co to je). > > ___ > Talk-cz mailing list > Talk-cz@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] UHUL WFS import
On Dec 5, 2007 3:02 AM, BH <[EMAIL PROTECTED]> wrote: > No > On 12/3/07, Pavel Machek <[EMAIL PROTECTED]> wrote: > > Ahoj! > > > > > prave jsem si nahral a vypada to moc pekne: > > > http://kubajz.kbx.cz/junk/uhul/output/x603388_x1159320_x593388_x1149320.xml.gz > > > > > > coz pokryva asi 1/6 mesta Brna. > > > Tento jeden XML ma 7MB, takze po jeho natazeni uz nejde s JOSM rozumne > > > pracovat, na hloupych 10km ctverecnich. > > v zmapovane zastavbe to kvuli mnozstvi detailu asi tak dobre nepujde. > Ono kilometr ctverecni v zastavbe muze mit stejne mnozstvi detailu > jako 1000 km ctverecnich nekde v polich. Holt se bude muset pouzit > mensi okno (nebo zlepsit JOSM) > > Koukam ze vsechny lesy maji 141Mb dohromady zabalene, v soucasnosti ma > CR asi 7 Mb ... vcelku vyznamne ji to nafoukne, ale jinak bych to tam > nahral cele, z nejakemu prilisnemu zjednodusovani bych se neuchyloval > ... kdyz uz nahrat, tak poradne. Zjednodusit si to muze treba az > renderer > > > > * vytvorime tematicke vrstvy v JOSM, tak abych treba si > > > nestahoval/vypnul zobr. lesu, ci zjednodusil vykreslovani se zoomem? > > To by ale asi muselo podporovat serverove api - stahnout z vyrezu data > v nejake vrstve nebo vyhovujici nejakemu filtru. > > Martin > Ja osobne bych upravoval editovaci nastroje, nez omezoval data v mape! Pokud na to josm nestaci tak je chyba v nem a musi se opravit. Myslim, ze by nebyl problem napriklad zahodit urcita data po stazeni, aby pri editaci nezavazely a nezpomalovaly program. Ale to je spis diskuze do josm-devel listu nebo na jejich bugzillu (trac nebo co to je). ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] UHUL WFS import
Sedi presne souradnice vnitrniho a vnejsiho polygonu? Potom by sla udelat nejaka lookup table se souradnicemi jako klicem a seznamem polygonu jako hodnotou. Tam nacpu vsechny data, pak prochazim vsechny hodnoty a kde je pro jeden bod vice polygonu, tak tam delam cely test na to, jestli to jde sloucit (ale tech testu pro jeden polygon bude o dost min nez n) Slozitost tohodle pak bude nekde kolem n log n. Pokud by nesedely, tak nasadit treba nejaky quadtree Martin On 12/4/07, Jakub Sykora <[EMAIL PROTECTED]> wrote: > Ahoj, > > hanoj napsal(a): > >> Z pozorovani take vyplyva, ze vetsina vyrezu v datech je pak zaplnena > >> jinym typem lesa - tudiz pro zobrazeni zeleneho fleku je vyuzito > >> zbytecne mnoho bodu. > >> > >>> Ted je opet otazka jak dal: > >>> > >>> * zlepsi se JOSM tak aby slo pracovat i s tak velkymi datasety? > >> To nepredpokladam. > >> > >>> * generalizujeme data tak, aby slo dale pracovat a tento vystup > >>> nechame na jindy/na jine pouziti mimo hlavni vrstvu JOSM? > >> Jak na to? > > *** zkusim se na to podivat. snad to umi JUMP... > > zatim jsem se dostal pres kompilaci noveho osm2shp, ale vyhazuje prazdne > > shapefily... Je slozita konverze vzorku do GML? > > V GML jsou data od UHULu, takze je jednodussi vzit tento soubor vraceny > WMS a provest primo v nem transformaci do WGS84. > > > > >>> * vytvorime tematicke vrstvy v JOSM, tak abych treba si > >>> nestahoval/vypnul zobr. lesu, ci zjednodusil vykreslovani se > >>> zoomem? > >> Jak na to? To netusim uz vubec... > > *** to vi mozna Petr... > > > >>> * zjednodussime klasifikaci lesa (jak jsem o tom puvodne mluvil) na > >>> napr: buk dub, nebo jen listnaty/jehlicnaty? > >> Ten tag sam o sobe zjednodusit vlastne ani moc nejde. Sam o sobe tam > >> nicemu nevadi a lesakovi to udela radost. Normalni clovek si z toho > >> informace les listnaty/jehlicnaty/smiseny vytahne sam... > > *** myslel jsem tim to co asi pises vyse. zrusit "vnitrni kresbu" nejake > > oblasti lesa z mnoha polygonu na dva typy a to laicke napr. > > listnac/jehlicnan deleni zapsat napr do description. Pro lesaky muzeme > > udelat shapefile do jejich GISu s plnym datasetem. > > Je asi fakt, ze v OSM tato metadata nemaji valneho smyslu. Proste bych > nechal, ze je to les a tim to hasne. Ovsem to neni problem, ktery by se > resil tezko - jedna se o zakomentovani dvou radku. > Vyhazeni vnitrnich polygonu je ovsem vec, ktera uz neni trivialni. > Muselo by se zjistovat, jestli dira obsahuje vypln (coz je jiny typ > lesa) a pokud ano, tak ji odstranit spolecne s dirou. > Na tento problem neznam nic moc dorby algoritmus - vede to na slozitost > n^2, kde n je pocet polygonu - porovnavat skoro kazdy les s kazdym > lesem. Pametova narocnost by v tomto pripade byla take nezanedbatelna. > > > > > Jeste jedna vec. On ten les je vlastne neni potreba editovat - tezko > > vytvorime neco lepsiho, presnejsiho, podrobnejsiho. Je-li nejaka cast > > vykacena, bude opet vysazena (pokud nebyla vynata z lesniho fondu pudy). > > > > > > > > > ha > > > > hanoj > > > > ___ > > Talk-cz mailing list > > Talk-cz@openstreetmap.org > > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > > ___ > Talk-cz mailing list > Talk-cz@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] UHUL WFS import
No On 12/3/07, Pavel Machek <[EMAIL PROTECTED]> wrote: > Ahoj! > > > prave jsem si nahral a vypada to moc pekne: > > http://kubajz.kbx.cz/junk/uhul/output/x603388_x1159320_x593388_x1149320.xml.gz > > > > coz pokryva asi 1/6 mesta Brna. > > Tento jeden XML ma 7MB, takze po jeho natazeni uz nejde s JOSM rozumne > > pracovat, na hloupych 10km ctverecnich. v zmapovane zastavbe to kvuli mnozstvi detailu asi tak dobre nepujde. Ono kilometr ctverecni v zastavbe muze mit stejne mnozstvi detailu jako 1000 km ctverecnich nekde v polich. Holt se bude muset pouzit mensi okno (nebo zlepsit JOSM) Koukam ze vsechny lesy maji 141Mb dohromady zabalene, v soucasnosti ma CR asi 7 Mb ... vcelku vyznamne ji to nafoukne, ale jinak bych to tam nahral cele, z nejakemu prilisnemu zjednodusovani bych se neuchyloval ... kdyz uz nahrat, tak poradne. Zjednodusit si to muze treba az renderer > > * vytvorime tematicke vrstvy v JOSM, tak abych treba si > > nestahoval/vypnul zobr. lesu, ci zjednodusil vykreslovani se zoomem? To by ale asi muselo podporovat serverove api - stahnout z vyrezu data v nejake vrstve nebo vyhovujici nejakemu filtru. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] UHUL WFS import
Ahoj! > > V GML jsou data od UHULu, takze je jednodussi vzit tento soubor vraceny > > WMS a provest primo v nem transformaci do WGS84. > *** to me nejak nedoslo. > > *** Nevim jak jsou presne v GML ci SHP definovany ostrovy polygonu, ale > ta nejhorsi varianta, je ze by se ostrovy daly bokem a pak znova do > slouceneho datasetu vlozily. > > existuje do JUMP plugin mapgeneralize, ktery ma i funkci klasickeho > slouceni polygonu. Pokud jsem to zkousel na prikladu: > > http://212.158.143.149/cgi-bin/wfs?service=WFS&version=1.0.0&request=getFeature&typeName=typo&bbox=-685591,-1064775,-682518,-1061770 > > * priklad stazeny (2967 bodů) > * priklad se sloucenim vsech polygonu do uzavrenych celku vcetne ostrovu > (1128 bodů) > takze tudy vede cesta... ale asi by to stejne jeste chtelo generalizovat Mozna je prvni rozumny krok odstranit duplicitni nody? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] UHUL WFS import
>>> Z pozorovani take vyplyva, ze vetsina vyrezu v datech je pak zaplnena >>> jinym typem lesa - tudiz pro zobrazeni zeleneho fleku je vyuzito >>> zbytecne mnoho bodu. >>> Ted je opet otazka jak dal: * zlepsi se JOSM tak aby slo pracovat i s tak velkymi datasety? >>> To nepredpokladam. >>> * generalizujeme data tak, aby slo dale pracovat a tento vystup nechame na jindy/na jine pouziti mimo hlavni vrstvu JOSM? >>> Jak na to? >> *** zkusim se na to podivat. snad to umi JUMP... >> zatim jsem se dostal pres kompilaci noveho osm2shp, ale vyhazuje prazdne >> shapefily... Je slozita konverze vzorku do GML? > > V GML jsou data od UHULu, takze je jednodussi vzit tento soubor vraceny > WMS a provest primo v nem transformaci do WGS84. *** to me nejak nedoslo. *** Nevim jak jsou presne v GML ci SHP definovany ostrovy polygonu, ale ta nejhorsi varianta, je ze by se ostrovy daly bokem a pak znova do slouceneho datasetu vlozily. existuje do JUMP plugin mapgeneralize, ktery ma i funkci klasickeho slouceni polygonu. Pokud jsem to zkousel na prikladu: http://212.158.143.149/cgi-bin/wfs?service=WFS&version=1.0.0&request=getFeature&typeName=typo&bbox=-685591,-1064775,-682518,-1061770 * priklad stazeny (2967 bodů) * priklad se sloucenim vsech polygonu do uzavrenych celku vcetne ostrovu (1128 bodů) takze tudy vede cesta... ale asi by to stejne jeste chtelo generalizovat hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] UHUL WFS import
Tak vysledne osm mate k dispozici, pokud je nekdo schopen tento filtr udelat, pak neni problem ta data tim prohnat. Neda se ovsem predpokladat, ze vsechny vyplne se nachazeji v jednom ctverci, ale to by se dalo ozelet, popripade otevirat cely nonet, kdyz by to melo byt echt spravne. K Martin Vidner napsal(a): > On Dec 4, 2007 1:55 PM, Jakub Sykora <[EMAIL PROTECTED]> wrote: >> Vyhazeni vnitrnich polygonu je ovsem vec, ktera uz neni trivialni. >> Muselo by se zjistovat, jestli dira obsahuje vypln (coz je jiny typ >> lesa) a pokud ano, tak ji odstranit spolecne s dirou. >> Na tento problem neznam nic moc dorby algoritmus - vede to na slozitost >> n^2, kde n je pocet polygonu - porovnavat skoro kazdy les s kazdym >> lesem. Pametova narocnost by v tomto pripade byla take nezanedbatelna. > > Hm, ja to vidim tak, ze kde je polygon, ktery presne vyplnuje diru, > tak maji shodne hrany, pouze opacne orientovane. Takze staci > zahashovat hrany, ne? > > Martin > > ___ > Talk-cz mailing list > Talk-cz@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] UHUL WFS import
On Dec 4, 2007 1:55 PM, Jakub Sykora <[EMAIL PROTECTED]> wrote: > Vyhazeni vnitrnich polygonu je ovsem vec, ktera uz neni trivialni. > Muselo by se zjistovat, jestli dira obsahuje vypln (coz je jiny typ > lesa) a pokud ano, tak ji odstranit spolecne s dirou. > Na tento problem neznam nic moc dorby algoritmus - vede to na slozitost > n^2, kde n je pocet polygonu - porovnavat skoro kazdy les s kazdym > lesem. Pametova narocnost by v tomto pripade byla take nezanedbatelna. Hm, ja to vidim tak, ze kde je polygon, ktery presne vyplnuje diru, tak maji shodne hrany, pouze opacne orientovane. Takze staci zahashovat hrany, ne? Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] UHUL WFS import
[EMAIL PROTECTED] napsal(a): > Ahoj, > prave jsem si nahral a vypada to moc pekne: > http://kubajz.kbx.cz/junk/uhul/output/x603388_x1159320_x593388_x1149320.xml.gz Hmm, kdyz maji dva polygony polecnou hranu (coz je bezny pripad na rozhranni dvou druhu lesa), jsou nody duplikovany (kazdy polygon ma na hrane vlastni nody). Chtelo by to ty nody reusovat. Mimo jine se tim zmensi mnozstvi dat v databazi > > coz pokryva asi 1/6 mesta Brna. > Tento jeden XML ma 7MB, takze po jeho natazeni uz nejde s JOSM rozumne > pracovat, na hloupych 10km ctverecnich. Ani s vypnutym mappaintem a vypnutymi sipkami? Muj upraveny JOSM to nahral bez zakolisani a bez mappaintu zoomuju i panuju v realnem case. Ale pravda, je to stale jen jeden ctverec, ne vsechna data. Snad se pred vanocema dostanu k navrzeni a obhajeni zmen v trunku JOSM. Zatim jsem nedelal nic tak kontroverzniho... (Hehe, az budu chtit maintainerum vysvetlit, ze ta enkapsulace a striktne privatni fieldy maji neco do sebe, to teprve pujde do tuheho...) > Pocitac je to Pent Dual 2,8GHZ/2GB ram + JAVA 1.6win. > > Ted je opet otazka jak dal: > > * zlepsi se JOSM tak aby slo pracovat i s tak velkymi datasety? JOSM vzdy bude mit sve limity. Do editoru se precijen trochu hure implementuje kvadraturni strom, nez do vieweru. > * generalizujeme data tak, aby slo dale pracovat a tento vystup nechame na > jindy/na jine pouziti mimo hlavni vrstvu JOSM? > * vytvorime tematicke vrstvy v JOSM, tak abych treba si nestahoval/vypnul > zobr. lesu, ci zjednodusil vykreslovani se zoomem? Umi snad OSM jako takove tematicke vrstvy? Pravda, do JOSM by sel dopsat importni filtr, co by to prorezal. -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] UHUL WFS import
Ahoj, hanoj napsal(a): >> Z pozorovani take vyplyva, ze vetsina vyrezu v datech je pak zaplnena >> jinym typem lesa - tudiz pro zobrazeni zeleneho fleku je vyuzito >> zbytecne mnoho bodu. >> >>> Ted je opet otazka jak dal: >>> >>> * zlepsi se JOSM tak aby slo pracovat i s tak velkymi datasety? >> To nepredpokladam. >> >>> * generalizujeme data tak, aby slo dale pracovat a tento vystup >>> nechame na jindy/na jine pouziti mimo hlavni vrstvu JOSM? >> Jak na to? > *** zkusim se na to podivat. snad to umi JUMP... > zatim jsem se dostal pres kompilaci noveho osm2shp, ale vyhazuje prazdne > shapefily... Je slozita konverze vzorku do GML? V GML jsou data od UHULu, takze je jednodussi vzit tento soubor vraceny WMS a provest primo v nem transformaci do WGS84. > >>> * vytvorime tematicke vrstvy v JOSM, tak abych treba si >>> nestahoval/vypnul zobr. lesu, ci zjednodusil vykreslovani se >>> zoomem? >> Jak na to? To netusim uz vubec... > *** to vi mozna Petr... > >>> * zjednodussime klasifikaci lesa (jak jsem o tom puvodne mluvil) na >>> napr: buk dub, nebo jen listnaty/jehlicnaty? >> Ten tag sam o sobe zjednodusit vlastne ani moc nejde. Sam o sobe tam >> nicemu nevadi a lesakovi to udela radost. Normalni clovek si z toho >> informace les listnaty/jehlicnaty/smiseny vytahne sam... > *** myslel jsem tim to co asi pises vyse. zrusit "vnitrni kresbu" nejake > oblasti lesa z mnoha polygonu na dva typy a to laicke napr. > listnac/jehlicnan deleni zapsat napr do description. Pro lesaky muzeme > udelat shapefile do jejich GISu s plnym datasetem. Je asi fakt, ze v OSM tato metadata nemaji valneho smyslu. Proste bych nechal, ze je to les a tim to hasne. Ovsem to neni problem, ktery by se resil tezko - jedna se o zakomentovani dvou radku. Vyhazeni vnitrnich polygonu je ovsem vec, ktera uz neni trivialni. Muselo by se zjistovat, jestli dira obsahuje vypln (coz je jiny typ lesa) a pokud ano, tak ji odstranit spolecne s dirou. Na tento problem neznam nic moc dorby algoritmus - vede to na slozitost n^2, kde n je pocet polygonu - porovnavat skoro kazdy les s kazdym lesem. Pametova narocnost by v tomto pripade byla take nezanedbatelna. > > Jeste jedna vec. On ten les je vlastne neni potreba editovat - tezko > vytvorime neco lepsiho, presnejsiho, podrobnejsiho. Je-li nejaka cast > vykacena, bude opet vysazena (pokud nebyla vynata z lesniho fondu pudy). > > > ha > > hanoj > > ___ > Talk-cz mailing list > Talk-cz@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] UHUL WFS import
> Z pozorovani take vyplyva, ze vetsina vyrezu v datech je pak zaplnena > jinym typem lesa - tudiz pro zobrazeni zeleneho fleku je vyuzito > zbytecne mnoho bodu. > >> Ted je opet otazka jak dal: >> >> * zlepsi se JOSM tak aby slo pracovat i s tak velkymi datasety? > > To nepredpokladam. > >> * generalizujeme data tak, aby slo dale pracovat a tento vystup >> nechame na jindy/na jine pouziti mimo hlavni vrstvu JOSM? > > Jak na to? *** zkusim se na to podivat. snad to umi JUMP... zatim jsem se dostal pres kompilaci noveho osm2shp, ale vyhazuje prazdne shapefily... Je slozita konverze vzorku do GML? >> * vytvorime tematicke vrstvy v JOSM, tak abych treba si >> nestahoval/vypnul zobr. lesu, ci zjednodusil vykreslovani se >> zoomem? > > Jak na to? To netusim uz vubec... *** to vi mozna Petr... >> * zjednodussime klasifikaci lesa (jak jsem o tom puvodne mluvil) na >> napr: buk dub, nebo jen listnaty/jehlicnaty? > > Ten tag sam o sobe zjednodusit vlastne ani moc nejde. Sam o sobe tam > nicemu nevadi a lesakovi to udela radost. Normalni clovek si z toho > informace les listnaty/jehlicnaty/smiseny vytahne sam... *** myslel jsem tim to co asi pises vyse. zrusit "vnitrni kresbu" nejake oblasti lesa z mnoha polygonu na dva typy a to laicke napr. listnac/jehlicnan deleni zapsat napr do description. Pro lesaky muzeme udelat shapefile do jejich GISu s plnym datasetem. Jeste jedna vec. On ten les je vlastne neni potreba editovat - tezko vytvorime neco lepsiho, presnejsiho, podrobnejsiho. Je-li nejaka cast vykacena, bude opet vysazena (pokud nebyla vynata z lesniho fondu pudy). ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] UHUL WFS import
Ahoj! > prave jsem si nahral a vypada to moc pekne: > http://kubajz.kbx.cz/junk/uhul/output/x603388_x1159320_x593388_x1149320.xml.gz > > coz pokryva asi 1/6 mesta Brna. > Tento jeden XML ma 7MB, takze po jeho natazeni uz nejde s JOSM rozumne > pracovat, na hloupych 10km ctverecnich. > Pocitac je to Pent Dual 2,8GHZ/2GB ram + JAVA 1.6win. > > Ted je opet otazka jak dal: > > * zlepsi se JOSM tak aby slo pracovat i s tak velkymi datasety? Doufejme. Bylo by skoda ponicit data jen proto ze josm nestaci. > * vytvorime tematicke vrstvy v JOSM, tak abych treba si > nestahoval/vypnul zobr. lesu, ci zjednodusil vykreslovani se zoomem? Tohle by bylo dost pekny... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] UHUL WFS import
Ahoj, [EMAIL PROTECTED] wrote: > Ahoj, > prave jsem si nahral a vypada to moc pekne: > http://kubajz.kbx.cz/junk/uhul/output/x603388_x1159320_x593388_x1149320.xml.gz > > coz pokryva asi 1/6 mesta Brna. > Tento jeden XML ma 7MB, takze po jeho natazeni uz nejde s JOSM rozumne > pracovat, na hloupych 10km ctverecnich. > Pocitac je to Pent Dual 2,8GHZ/2GB ram + JAVA 1.6win. O tomto problemu vim a uz jsem ho nekolikrat nenapadne prezentoval - generalizace vede ke zmenseni datasetu, ale v mnoha pripadech i k drastickemu narustu chyby. Viz data z HELP SERVICE. Pokud nekdo umite data prohnat generalizacnim algoritmem, aby zustala pouzitelne, pak s tim nemam problem. Z pozorovani take vyplyva, ze vetsina vyrezu v datech je pak zaplnena jinym typem lesa - tudiz pro zobrazeni zeleneho fleku je vyuzito zbytecne mnoho bodu. > > Ted je opet otazka jak dal: > > * zlepsi se JOSM tak aby slo pracovat i s tak velkymi datasety? To nepredpokladam. > * generalizujeme data tak, aby slo dale pracovat a tento vystup nechame na > jindy/na jine pouziti mimo hlavni vrstvu JOSM? Jak na to? > * vytvorime tematicke vrstvy v JOSM, tak abych treba si nestahoval/vypnul > zobr. lesu, ci zjednodusil vykreslovani se zoomem? Jak na to? To netusim uz vubec... > * zjednodussime klasifikaci lesa (jak jsem o tom puvodne mluvil) na napr: buk > dub, nebo jen listnaty/jehlicnaty? Ten tag sam o sobe zjednodusit vlastne ani moc nejde. Sam o sobe tam nicemu nevadi a lesakovi to udela radost. Normalni clovek si z toho informace les listnaty/jehlicnaty/smiseny vytahne sam... > * cokoliv jineho? > > PS: ctverec opet/jeste obsahuje nulove body v JTSK Nevim, proc to tak je, ale v UHULu jsou body dobre, vypada to na problem pri transformaci XML UHUL -> Point2D.Double > > ha Kkkk Kubajz :] > > hanoj > > ___ > Talk-cz mailing list > Talk-cz@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz -- Jakub Sýkora email: [EMAIL PROTECTED] <') ICQ: 68976632 ( =- mobil: +420 777 594 201 '' ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] UHUL WFS import
Ahoj, prave jsem si nahral a vypada to moc pekne: http://kubajz.kbx.cz/junk/uhul/output/x603388_x1159320_x593388_x1149320.xml.gz coz pokryva asi 1/6 mesta Brna. Tento jeden XML ma 7MB, takze po jeho natazeni uz nejde s JOSM rozumne pracovat, na hloupych 10km ctverecnich. Pocitac je to Pent Dual 2,8GHZ/2GB ram + JAVA 1.6win. Ted je opet otazka jak dal: * zlepsi se JOSM tak aby slo pracovat i s tak velkymi datasety? * generalizujeme data tak, aby slo dale pracovat a tento vystup nechame na jindy/na jine pouziti mimo hlavni vrstvu JOSM? * vytvorime tematicke vrstvy v JOSM, tak abych treba si nestahoval/vypnul zobr. lesu, ci zjednodusil vykreslovani se zoomem? * zjednodussime klasifikaci lesa (jak jsem o tom puvodne mluvil) na napr: buk dub, nebo jen listnaty/jehlicnaty? * cokoliv jineho? PS: ctverec opet/jeste obsahuje nulove body v JTSK ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] UHUL WFS import
Pavel Machek wrote: > On Fri 2007-11-30 13:58:24, Jakub Sykora wrote: >> Podle vseho by to mel byt tento: >> http://kubajz.kbx.cz/junk/uhul/output/x723388_x1059320_x713388_x1049320.xml.gz >> >> ev. dalsi kolem > > Dik... posles prosim jeste zbytek url? Uz si ho nepamatuju :-(. > > Pavel >> K >> >> Pavel Machek wrote: >>> Ahoj! >>> Nyni plne podle API 0.5 vcetne relaci. Doufam, ze ted uz budou data OK, protoze to jelo celou noc, nez to vygenerovalo zabalenych 500MB. Nicmene je fakt, ze to jelo na skvelem Celeron M 360 s 512MB pameti :] Take jsem dodatecne pridal identifikaci kolizi a zjistil jsem, ze jich mezi sousednimi ctverci nebylo malo (UHUL WFS vraci vse co zasahuje do BB, tudiz vice nez BB a kdyz to udela kazdy ctverec, tak se pak prekryvaji). Mela by tam byt komplet cela CR. Pokud potrebujete konkreti soubor s Vasi oblasti, tak provedu reverzni preklad souradnic a poslu odkaz n konkretni soubor/y. Kazdy soubor je 100sqkm. >>> Jestli to neni problem, rad bych si prohlid' ctverec kolem N50, >>> E14.75. Trochu to tam znam, a mapoval jsem tam podle orthofoto... >>> Pavel >> -- >> Jakub Sýkora >> email: [EMAIL PROTECTED] <') >> ICQ: 68976632 ( =- >> mobil: +420 777 594 201 '' >> >> ___ >> Talk-cz mailing list >> Talk-cz@openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > -- Jakub Sýkora email: [EMAIL PROTECTED] <') ICQ: 68976632 ( =- mobil: +420 777 594 201 '' ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] UHUL WFS import
On Fri 2007-11-30 13:58:24, Jakub Sykora wrote: > Podle vseho by to mel byt tento: > > x723388_x1059320_x713388_x1049320.xml.gz > > ev. dalsi kolem Dik... posles prosim jeste zbytek url? Uz si ho nepamatuju :-(. Pavel > K > > Pavel Machek wrote: > > Ahoj! > > > >> Nyni plne podle API 0.5 vcetne relaci. Doufam, ze ted uz budou data OK, > >> protoze to jelo celou noc, nez to vygenerovalo zabalenych 500MB. Nicmene > >> je fakt, ze to jelo na skvelem Celeron M 360 s 512MB pameti :] > >> > >> Take jsem dodatecne pridal identifikaci kolizi a zjistil jsem, ze jich > >> mezi sousednimi ctverci nebylo malo (UHUL WFS vraci vse co zasahuje do > >> BB, tudiz vice nez BB a kdyz to udela kazdy ctverec, tak se pak > >> prekryvaji). > >> > >> Mela by tam byt komplet cela CR. Pokud potrebujete konkreti soubor s > >> Vasi oblasti, tak provedu reverzni preklad souradnic a poslu odkaz n > >> konkretni soubor/y. Kazdy soubor je 100sqkm. > > > > Jestli to neni problem, rad bych si prohlid' ctverec kolem N50, > > E14.75. Trochu to tam znam, a mapoval jsem tam podle orthofoto... > > Pavel > > -- > Jakub Sýkora > email: [EMAIL PROTECTED] <') > ICQ: 68976632 ( =- > mobil: +420 777 594 201 '' > > ___ > Talk-cz mailing list > Talk-cz@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] UHUL WFS import
Ahoj! > Podle vseho by to mel byt tento: > > x723388_x1059320_x713388_x1049320.xml.gz > > ev. dalsi kolem Diky, nalezeno, s pomoci historie v browseru. Vypada to opravdu dobre! Pavel > >> Nyni plne podle API 0.5 vcetne relaci. Doufam, ze ted uz budou data OK, > >> protoze to jelo celou noc, nez to vygenerovalo zabalenych 500MB. Nicmene > >> je fakt, ze to jelo na skvelem Celeron M 360 s 512MB pameti :] > >> > >> Take jsem dodatecne pridal identifikaci kolizi a zjistil jsem, ze jich > >> mezi sousednimi ctverci nebylo malo (UHUL WFS vraci vse co zasahuje do > >> BB, tudiz vice nez BB a kdyz to udela kazdy ctverec, tak se pak > >> prekryvaji). > >> > >> Mela by tam byt komplet cela CR. Pokud potrebujete konkreti soubor s > >> Vasi oblasti, tak provedu reverzni preklad souradnic a poslu odkaz n > >> konkretni soubor/y. Kazdy soubor je 100sqkm. > > > > Jestli to neni problem, rad bych si prohlid' ctverec kolem N50, > > E14.75. Trochu to tam znam, a mapoval jsem tam podle orthofoto... > > Pavel > -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] UHUL WFS import
Podle vseho by to mel byt tento: x723388_x1059320_x713388_x1049320.xml.gz ev. dalsi kolem K Pavel Machek wrote: > Ahoj! > >> Nyni plne podle API 0.5 vcetne relaci. Doufam, ze ted uz budou data OK, >> protoze to jelo celou noc, nez to vygenerovalo zabalenych 500MB. Nicmene >> je fakt, ze to jelo na skvelem Celeron M 360 s 512MB pameti :] >> >> Take jsem dodatecne pridal identifikaci kolizi a zjistil jsem, ze jich >> mezi sousednimi ctverci nebylo malo (UHUL WFS vraci vse co zasahuje do >> BB, tudiz vice nez BB a kdyz to udela kazdy ctverec, tak se pak >> prekryvaji). >> >> Mela by tam byt komplet cela CR. Pokud potrebujete konkreti soubor s >> Vasi oblasti, tak provedu reverzni preklad souradnic a poslu odkaz n >> konkretni soubor/y. Kazdy soubor je 100sqkm. > > Jestli to neni problem, rad bych si prohlid' ctverec kolem N50, > E14.75. Trochu to tam znam, a mapoval jsem tam podle orthofoto... > Pavel -- Jakub Sýkora email: [EMAIL PROTECTED] <') ICQ: 68976632 ( =- mobil: +420 777 594 201 '' ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] UHUL WFS import
Ahoj! > Nyni plne podle API 0.5 vcetne relaci. Doufam, ze ted uz budou data OK, > protoze to jelo celou noc, nez to vygenerovalo zabalenych 500MB. Nicmene > je fakt, ze to jelo na skvelem Celeron M 360 s 512MB pameti :] > > Take jsem dodatecne pridal identifikaci kolizi a zjistil jsem, ze jich > mezi sousednimi ctverci nebylo malo (UHUL WFS vraci vse co zasahuje do > BB, tudiz vice nez BB a kdyz to udela kazdy ctverec, tak se pak > prekryvaji). > > Mela by tam byt komplet cela CR. Pokud potrebujete konkreti soubor s > Vasi oblasti, tak provedu reverzni preklad souradnic a poslu odkaz n > konkretni soubor/y. Kazdy soubor je 100sqkm. Jestli to neni problem, rad bych si prohlid' ctverec kolem N50, E14.75. Trochu to tam znam, a mapoval jsem tam podle orthofoto... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] UHUL WFS import
Tak jsem zjistil, ze se do nekterych oblasti propasovala nejaka zvlastni chyba. Jedna se o sest duplicitnich bodu s konstantnimi souradnicemi kdesi daleko od nasi zemicky. Skript upravim tak, aby ramcovve kontroloval, zda se data nachazeji nekde ve vymezenem BB a popripade je nenahraval vubec. Chyba bud vznikla tak, ze UHUL sam poskytuje nekorektni data nebo cs2cs udelalo nejakou chybu. Neni trivialni to odstranit dodatecne na uz hotovych datech, protoze body jsou uz soucasti way a ty uz soucasti relaci. Rucne by to taky byl opruz, takze jdu modifikovat skript. K Jakub Sykora wrote: > Nova varka! > > Nyni plne podle API 0.5 vcetne relaci. Doufam, ze ted uz budou data OK, > protoze to jelo celou noc, nez to vygenerovalo zabalenych 500MB. Nicmene > je fakt, ze to jelo na skvelem Celeron M 360 s 512MB pameti :] > > Take jsem dodatecne pridal identifikaci kolizi a zjistil jsem, ze jich > mezi sousednimi ctverci nebylo malo (UHUL WFS vraci vse co zasahuje do > BB, tudiz vice nez BB a kdyz to udela kazdy ctverec, tak se pak > prekryvaji). > > Mela by tam byt komplet cela CR. Pokud potrebujete konkreti soubor s > Vasi oblasti, tak provedu reverzni preklad souradnic a poslu odkaz n > konkretni soubor/y. Kazdy soubor je 100sqkm. > > Na hranicich jsou pak data moc hezka - jsou tam videt i signalky... viz > http://kubajz.kbx.cz/junk/uhul/map.png > > V adresari http://kubajz.kbx.cz/junk/uhul/ je pak pro zajemce i java > zdrojak (omlouvam se, je to desna prasecina, ale funguje a je celkem > rozsiritelna/upravitelna :]) > > K > > Jakub Sykora wrote: >> Ahoj, >> >> skripty jsem doladil snad do finalni podoby. Podivejte se, prosim, na >> >> http://kubajz.kbx.cz/junk/uhul/output >> >> Je tam zatim par desitek souboru, ale snad z toho jde poznat, jestli je >> to dobre nebo ne. Prouzkuje to od zapadu na vychod. Soubory, co maji >> 129B jsou prazdne (resp. prazdne validni xml - v danem regionu nejsou >> zadna data). V archivu jsou ted urcite data Krusnych hor, KV kraje a >> pomalu se presouvam k Plzni. >> >> Pokud budou data shledana pouzitelnymi, tak soubor po souboru budu >> importovat pres JOSM na server. Pokud mate lepsi zpusob, uvitam ho :] >> > -- Jakub Sýkora email: [EMAIL PROTECTED] <') ICQ: 68976632 ( =- mobil: +420 777 594 201 '' ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] UHUL WFS import
Nova varka! Nyni plne podle API 0.5 vcetne relaci. Doufam, ze ted uz budou data OK, protoze to jelo celou noc, nez to vygenerovalo zabalenych 500MB. Nicmene je fakt, ze to jelo na skvelem Celeron M 360 s 512MB pameti :] Take jsem dodatecne pridal identifikaci kolizi a zjistil jsem, ze jich mezi sousednimi ctverci nebylo malo (UHUL WFS vraci vse co zasahuje do BB, tudiz vice nez BB a kdyz to udela kazdy ctverec, tak se pak prekryvaji). Mela by tam byt komplet cela CR. Pokud potrebujete konkreti soubor s Vasi oblasti, tak provedu reverzni preklad souradnic a poslu odkaz n konkretni soubor/y. Kazdy soubor je 100sqkm. Na hranicich jsou pak data moc hezka - jsou tam videt i signalky... viz http://kubajz.kbx.cz/junk/uhul/map.png V adresari http://kubajz.kbx.cz/junk/uhul/ je pak pro zajemce i java zdrojak (omlouvam se, je to desna prasecina, ale funguje a je celkem rozsiritelna/upravitelna :]) K Jakub Sykora wrote: > Ahoj, > > skripty jsem doladil snad do finalni podoby. Podivejte se, prosim, na > > http://kubajz.kbx.cz/junk/uhul/output > > Je tam zatim par desitek souboru, ale snad z toho jde poznat, jestli je > to dobre nebo ne. Prouzkuje to od zapadu na vychod. Soubory, co maji > 129B jsou prazdne (resp. prazdne validni xml - v danem regionu nejsou > zadna data). V archivu jsou ted urcite data Krusnych hor, KV kraje a > pomalu se presouvam k Plzni. > > Pokud budou data shledana pouzitelnymi, tak soubor po souboru budu > importovat pres JOSM na server. Pokud mate lepsi zpusob, uvitam ho :] > -- Jakub Sýkora email: [EMAIL PROTECTED] <') ICQ: 68976632 ( =- mobil: +420 777 594 201 '' ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] UHUL WFS import
Ahoj, ja tam radeji dam inner a outer, protoze nemuzu z principu zarucit, ze na UHULu maji ta data prave takhle usporadana (i kdyz se to tak zda). Kazdopadne do toho sveho udelatka pridelam na relatko :] K BH napsal(a): >> To by nemela byt chyba, ale vlastnost. Ty diry by mely jit protismeru >> hod. rucicek a obrys jako takovy po smeru, cimz by melo byt zaruceno >> korektni renderovani. > > To je pravda, ale aby to tak opravdu fungovalo tak musi byt vsechny > polygony v relaci (s "type"="multipolygon"). Pokud je dodrzeno > pravidlo "po/proti" smeru rucicek, nemusi se nastavovat inner/outer > (jak tu uz nekdo zminoval) > > Na http://www.openstreetmap.org/?lat=50.09965&lon=14.4013&zoom=17&layers=B0F > jsou videt priklady budov s dirama, kde je to takhle reseny (bez > inner/outer, ale se spravnym smerovanim) Nekde jsou i tri "vrstvy" > (budova, pak vykus a pak mensi "domek na dvorku", ktery je opet po > smeru a zobrazen je jako polygon) > > Martin > > ___ > Talk-cz mailing list > Talk-cz@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] UHUL WFS import
> To by nemela byt chyba, ale vlastnost. Ty diry by mely jit protismeru > hod. rucicek a obrys jako takovy po smeru, cimz by melo byt zaruceno > korektni renderovani. To je pravda, ale aby to tak opravdu fungovalo tak musi byt vsechny polygony v relaci (s "type"="multipolygon"). Pokud je dodrzeno pravidlo "po/proti" smeru rucicek, nemusi se nastavovat inner/outer (jak tu uz nekdo zminoval) Na http://www.openstreetmap.org/?lat=50.09965&lon=14.4013&zoom=17&layers=B0F jsou videt priklady budov s dirama, kde je to takhle reseny (bez inner/outer, ale se spravnym smerovanim) Nekde jsou i tri "vrstvy" (budova, pak vykus a pak mensi "domek na dvorku", ktery je opet po smeru a zobrazen je jako polygon) Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] UHUL WFS import
Ono to nakonec dopadne tim nejuniverzalnejsim zpusobem. Budou tam role i polygony budou obracene. K Michal Grézl napsal(a): > On Nov 27, 2007 7:49 AM, Jakub Sykora <[EMAIL PROTECTED]> wrote: >> A nemely by byt role inner a outer? >> >> Jinak jsem zjistil, ze UHUL WFS ma v datech krasne popsane, co je >> outline a co je uvnitr. Modifikace tak budou nenarocne. >> >> K >> > > role tam klidne napis:) to sem nezkousel, zkousel sem jen ruzne > smerovane vektory polygonu, kdyz byly shodne dira nebyla, kdyz byly > jak sem napsal tak dira byla. Ani v tom Buckingham palacu role nemel. > > ___ > Talk-cz mailing list > Talk-cz@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] UHUL WFS import
On Nov 27, 2007 7:49 AM, Jakub Sykora <[EMAIL PROTECTED]> wrote: > A nemely by byt role inner a outer? > > Jinak jsem zjistil, ze UHUL WFS ma v datech krasne popsane, co je > outline a co je uvnitr. Modifikace tak budou nenarocne. > > K > role tam klidne napis:) to sem nezkousel, zkousel sem jen ruzne smerovane vektory polygonu, kdyz byly shodne dira nebyla, kdyz byly jak sem napsal tak dira byla. Ani v tom Buckingham palacu role nemel. ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] UHUL WFS import
Z tohoto prikladu to moc zrejme neni, protoze diru vyplnuje jeste hriste, nicmene udelam to tak a budu verit, ze to bude fungovat :] K Petr Nejedly napsal(a): > Jakub Sykora napsal(a): >> Ahoj, >> >> To by nemela byt chyba, ale vlastnost. Ty diry by mely jit protismeru >> hod. rucicek a obrys jako takovy po smeru, cimz by melo byt zaruceno >> korektni renderovani. > > Myslel jsem, ze "spravne"(tm) se derave polygony tvori pomoci relace > multipolygon s inner/outer way. > viz relace#3033: > > > > > > > a jeji korektni renderovani: > http://openstreetmap.org/?lat=50.051056&lon=14.365452&zoom=18&layers=B0F > > Neco je zmineno tez na: > http://wiki.openstreetmap.org/index.php/Relations/Multipolygon > > ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] UHUL WFS import
A nemely by byt role inner a outer? Jinak jsem zjistil, ze UHUL WFS ma v datech krasne popsane, co je outline a co je uvnitr. Modifikace tak budou nenarocne. K Michal Grézl napsal(a): > On Nov 26, 2007 5:25 PM, Jakub Sykora <[EMAIL PROTECTED]> wrote: >> Jak jsou na tom renderery, co se tyka teto relace? Zobrazi ji korektne? >> >> K >> > http://lists.openstreetmap.org/pipermail/talk/2007-October/019437.html > > prave sem to vyzkousel na lese, funguje to, vnejsi polygon po smeru, > vnitrni proti smeru. > relace: > > > > > > > a je tam dira. > > rendrovano osmarenderem6 > > ___ > Talk-cz mailing list > Talk-cz@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] UHUL WFS import
On Nov 26, 2007 5:25 PM, Jakub Sykora <[EMAIL PROTECTED]> wrote: > Jak jsou na tom renderery, co se tyka teto relace? Zobrazi ji korektne? > > K > http://lists.openstreetmap.org/pipermail/talk/2007-October/019437.html prave sem to vyzkousel na lese, funguje to, vnejsi polygon po smeru, vnitrni proti smeru. relace: a je tam dira. rendrovano osmarenderem6 ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] UHUL WFS import
Jak jsou na tom renderery, co se tyka teto relace? Zobrazi ji korektne? K Michal Grézl wrote: > On Nov 26, 2007 5:10 PM, Jakub Sykora <[EMAIL PROTECTED]> wrote: >> Aha, tak to mi uniklo. Nicmene na strance s API 0.5 jsem skoncil tim, ze >> restrictions jsou, ale zatim nemaji zadne specifikace. Proto jsem to >> nechal tak, jak to je. Je to take tim, ze jsem akorat predelaval skript >> z API 0.4 na 0.5 a ve starsi verzi se to resilo obracenim smeru, coz >> nekdy fungovalo. >> >> Zde je tedy prostor pro diskuzi, jestli to nezkusit udelat pomoci relaci... >> >> K > > Urcite ano, do budoucna to bude mnohem jednodussi na spravovani. Jinak > ty data vypadaji super, uz se tesim az to bude vsecko zelene. > > ___ > Talk-cz mailing list > Talk-cz@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz -- Jakub Sýkora email: [EMAIL PROTECTED] <') ICQ: 68976632 ( =- mobil: +420 777 594 201 '' ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] UHUL WFS import
Tak na to koukam - UHUL ty polygony generuje oddelene, takze tady by problem byt nemusel. Otazkou je, jestli vzdy vnejsi polygon generuje jak o prvni. V par souborech, co tu mam to tak je, ale jestli je to pravidlo, to nevim. A porovnavat proti sobe polygony by se mi zrovna nechtelo... K Michal Grézl wrote: > On Nov 26, 2007 5:10 PM, Jakub Sykora <[EMAIL PROTECTED]> wrote: >> Aha, tak to mi uniklo. Nicmene na strance s API 0.5 jsem skoncil tim, ze >> restrictions jsou, ale zatim nemaji zadne specifikace. Proto jsem to >> nechal tak, jak to je. Je to take tim, ze jsem akorat predelaval skript >> z API 0.4 na 0.5 a ve starsi verzi se to resilo obracenim smeru, coz >> nekdy fungovalo. >> >> Zde je tedy prostor pro diskuzi, jestli to nezkusit udelat pomoci relaci... >> >> K > > Urcite ano, do budoucna to bude mnohem jednodussi na spravovani. Jinak > ty data vypadaji super, uz se tesim az to bude vsecko zelene. > > ___ > Talk-cz mailing list > Talk-cz@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz -- Jakub Sýkora email: [EMAIL PROTECTED] <') ICQ: 68976632 ( =- mobil: +420 777 594 201 '' ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] UHUL WFS import
On Nov 26, 2007 5:10 PM, Jakub Sykora <[EMAIL PROTECTED]> wrote: > Aha, tak to mi uniklo. Nicmene na strance s API 0.5 jsem skoncil tim, ze > restrictions jsou, ale zatim nemaji zadne specifikace. Proto jsem to > nechal tak, jak to je. Je to take tim, ze jsem akorat predelaval skript > z API 0.4 na 0.5 a ve starsi verzi se to resilo obracenim smeru, coz > nekdy fungovalo. > > Zde je tedy prostor pro diskuzi, jestli to nezkusit udelat pomoci relaci... > > K Urcite ano, do budoucna to bude mnohem jednodussi na spravovani. Jinak ty data vypadaji super, uz se tesim az to bude vsecko zelene. ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] UHUL WFS import
Aha, tak to mi uniklo. Nicmene na strance s API 0.5 jsem skoncil tim, ze restrictions jsou, ale zatim nemaji zadne specifikace. Proto jsem to nechal tak, jak to je. Je to take tim, ze jsem akorat predelaval skript z API 0.4 na 0.5 a ve starsi verzi se to resilo obracenim smeru, coz nekdy fungovalo. Zde je tedy prostor pro diskuzi, jestli to nezkusit udelat pomoci relaci... K Petr Nejedly wrote: > Jakub Sykora napsal(a): >> Ahoj, >> >> To by nemela byt chyba, ale vlastnost. Ty diry by mely jit protismeru >> hod. rucicek a obrys jako takovy po smeru, cimz by melo byt zaruceno >> korektni renderovani. > > Myslel jsem, ze "spravne"(tm) se derave polygony tvori pomoci relace > multipolygon s inner/outer way. > viz relace#3033: > > > > > > > a jeji korektni renderovani: > http://openstreetmap.org/?lat=50.051056&lon=14.365452&zoom=18&layers=B0F > > Neco je zmineno tez na: > http://wiki.openstreetmap.org/index.php/Relations/Multipolygon > > -- Jakub Sýkora email: [EMAIL PROTECTED] <') ICQ: 68976632 ( =- mobil: +420 777 594 201 '' ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] UHUL WFS import
Jakub Sykora napsal(a): > Ahoj, > > To by nemela byt chyba, ale vlastnost. Ty diry by mely jit protismeru > hod. rucicek a obrys jako takovy po smeru, cimz by melo byt zaruceno > korektni renderovani. Myslel jsem, ze "spravne"(tm) se derave polygony tvori pomoci relace multipolygon s inner/outer way. viz relace#3033: a jeji korektni renderovani: http://openstreetmap.org/?lat=50.051056&lon=14.365452&zoom=18&layers=B0F Neco je zmineno tez na: http://wiki.openstreetmap.org/index.php/Relations/Multipolygon -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] UHUL WFS import
Ahoj, To by nemela byt chyba, ale vlastnost. Ty diry by mely jit protismeru hod. rucicek a obrys jako takovy po smeru, cimz by melo byt zaruceno korektni renderovani. Kazdopadne s daty z UHULu jako takovymi jsem nedelal vic nez translaci z jednoho typu souradnic na druhy typ - tam bych popripade hledal chyby, ale zatim u nahodne pootviranych souboru to sedi proti orotofoto mape. K Petr Nejedly wrote: > Jakub Sykora napsal(a): >> Ahoj, >> >> skripty jsem doladil snad do finalni podoby. Podivejte se, prosim, na >> >> http://kubajz.kbx.cz/junk/uhul/output >> >> Je tam zatim par desitek souboru, ale snad z toho jde poznat, jestli je >> to dobre nebo ne. Prouzkuje to od zapadu na vychod. Soubory, co maji >> 129B jsou prazdne (resp. prazdne validni xml - v danem regionu nejsou >> zadna data). V archivu jsou ted urcite data Krusnych hor, KV kraje a >> pomalu se presouvam k Plzni. >> >> Pokud budou data shledana pouzitelnymi, tak soubor po souboru budu >> importovat pres JOSM na server. Pokud mate lepsi zpusob, uvitam ho :] > Hnedka prvni soubor co jsem zkousel > (http://kubajz.kbx.cz/junk/uhul/output/x853388_x1139320_x843388_x1129320.xml.bz2) > ma v sobe deravy polygon s propojkou a nejake prekryvy. > viz uhul:id=1478,2554,1482 > > -- Jakub Sýkora email: [EMAIL PROTECTED] <') ICQ: 68976632 ( =- mobil: +420 777 594 201 '' ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] UHUL WFS import
Jakub Sykora napsal(a): > Ahoj, > > skripty jsem doladil snad do finalni podoby. Podivejte se, prosim, na > > http://kubajz.kbx.cz/junk/uhul/output > > Je tam zatim par desitek souboru, ale snad z toho jde poznat, jestli je > to dobre nebo ne. Prouzkuje to od zapadu na vychod. Soubory, co maji > 129B jsou prazdne (resp. prazdne validni xml - v danem regionu nejsou > zadna data). V archivu jsou ted urcite data Krusnych hor, KV kraje a > pomalu se presouvam k Plzni. > > Pokud budou data shledana pouzitelnymi, tak soubor po souboru budu > importovat pres JOSM na server. Pokud mate lepsi zpusob, uvitam ho :] Hnedka prvni soubor co jsem zkousel (http://kubajz.kbx.cz/junk/uhul/output/x853388_x1139320_x843388_x1129320.xml.bz2) ma v sobe deravy polygon s propojkou a nejake prekryvy. viz uhul:id=1478,2554,1482 -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
