Koukal jsem do zdrojaku potrace a kdyz mi neprojde ten 64bit tak to trosku hacknu a vysledky se budou ukladat do mezisouboru. Az konecne budu mit vektorovy dump tak to poslu a muze si pripadne kdokoliv pohrat s generalizaci. Jeste se tedy nevzdavam :)
S tou generalizaci jsem neco podobneho resil s tema adresama na built-up area tak to s tim zkusim prohnat, ale zatim nevim lec nemam vsechny vektory. Postup byl tusim takovy, ze nasel vsechny vzdalenosti bodu v polygonu a kratsi nez neco se spojily. Tim se zaceluji uzke ulicky a vznikaji diry. Dira se, ale postupne zmensovala a decimovala az zmizela... Pokud byla vetsi nez limit tak zustala. No chtel bych to udelat poradne, protoze presne to same potrebuji pro generalizaci velkych zoomu do navigace. Takze tim ztratim ted cas, ale pak treba bude super rychla mapka i pro velke zoomy. T > Ahoj, > > Tomas Kolda napsal(a): >> Tak jsem vcera ze srandy zkusil, potracnout celou cr. Akorat jsem blbe >> pocital, takze cela CR ma 1GB. Potrace si dela vnitrne kopii, takze >> nez neco zacne pocitat uz je na dvou. Nakonec velmi neusporne uklada >> vysledne vektory (dostane se tak na 4-5GB RAM). Doma mam bohuzel jen >> 32 bit stroj, takze koncim tak na max. 1/4 republiky. Zkusim to dneska >> pustit na 64bit, > ja jsem si to myslel, ale nechtel jsem to rozmlouvat... >> mozna to nejak procesne. Jako nejvetsi problem asi vidim ty cesticky v >> lesich. To bude nejvetsi problem pro generalizaci. > Co zkusit sloucit body, ktere jsou od sebe vzdaleny mene nez xxx? > Nepomohlo by to? Popripade by se i rucne nechala upravit ta bitmapa - > stetcem v gimpu to bude mozna rychlejsi :) >> Polygony se budou muset pospojovat a cesticky nejak odstranit. Je jich >> docela dost a vektor vypada blbe. > >> >> T >> >> Kubajz napsal(a): >>> [EMAIL PROTECTED] napsal(a): >>> >>>> Uz jsme toho nakecali dost, takze poznamka na zaver. Les samozrejmne >>>> neni >>>> o velikosti 0.1x0.1, ale lesu, ktere lezi na hranach tilu uz mozna >>>> neni >>>> zanedbatelne mnozstvi. Muze to byt libovolne maly les, ktery se >>>> zbytecne >>>> rozsekne. Naopak jak jsem psal, proc vadi stahnout velky les, ktery ma >>>> jen >>>> 10bodu? Rozsekaval bych jen polygony, ktere maji vice jak napr. 50 >>>> bodu. >>>> >>>> >>> 50 je asi malo, ale rekl bych, ze to nebude spatnej pristup. Trochu >>> bude >>> ale problem s dirama. Pokud ma polygon diru, musi se rozseknout >>> sikovne. >>> Coz uz je aspon pro me trochu vyssi divci... >>> >>>> V dusledku je to asi jedno, ale tak nejak pocitove nemam rad sekani po >>>> ctvercich. Je to asi dane tim, ze pak data pouzivam do me "navigace" a >>>> kazdy zbytecny zasah do polygonu zvetsuje databazi, index a graficky >>>> preprocesing vubec. >>>> >>>> >>> jo to je mozny. To nevim... >>> >>>> T >>>> >>>> >>>> >>>>> Ahoj, >>>>> >>>>> [EMAIL PROTECTED] napsal(a): >>>>> >>>>> >>>>>>> Zatim jsem delal pouze ten tile 0.1 na 0.1 stupne pri 2000x2000px. >>>>>>> Nevim, jak je na tom potrace se zpracovavanim vetsich obrazu a >>>>>>> lepit ty >>>>>>> dlazdice dohromady mi taky neprijde uplne uzasny, protoze to bude >>>>>>> strasne narocny na pamet. Uplne vidim imagemagick, jak se pri tom >>>>>>> zapoti... >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Tohle se prave moc hezky resi tim bindingem, protoze mu uz predhodim >>>>>> jednobitovou bitmapu (nemusim ji generovat). Proste se nactou >>>>>> vsechny >>>>>> tiles pomoci PIL a vytvori obrovskej BLOB, kterej se predhodi >>>>>> potrace >>>>>> (vychazi to kolem 500MB). To, ze se procesor trosku zapoti je myslim >>>>>> >>>>>> >>>>>> >>>>> to je pouze vstup. Pak potrebujes jeste hafo pameti na samotne >>>>> zpracovani, ale da se to tak udelat. To samozrejme, ze ano. Pokud >>>>> budes >>>>> chtit vsechny dlazdice, tak je to na jeden radek na konzoli. Viz >>>>> konec >>>>> e-mailu. >>>>> >>>>> >>>>>> jedno. Bude se to delat jen jednou, ale bude to bez chyb spojovani. >>>>>> Spojovani jsem si uz tolikrat uzil a vzdy vznikaly problemy. At si >>>>>> klidne >>>>>> bezi hodinu, ale bez chyb. A za hodinu to ani nenapises... >>>>>> >>>>>> >>>>>> >>>>> tady by vicemene problemy se spojovanim nevznikaly, protoze me >>>>> primarne >>>>> nejde o to, aby se vysledek spojil dohromady. Me jde o to, aby >>>>> maximalni >>>>> velikost utvaru v OSM nepresahla 0.1x0.1 stupne. Uz jsem takhle >>>>> strihal >>>>> nektere reky, dalnice atp. Stava se totiz, ze si potrebujes stahnout >>>>> malou vesnicku a kvuli tomu, ze ji proteka reka se ti stahne milion >>>>> bodu, ktere vubec nepotrebujes. S lesem by to dopadlo uplne stejne. >>>>> Takze mi primarne slo o to, aby se ty lesy pak nemusely rucne zase >>>>> rozdelovat, ale byly rozdeleny nejak predem. >>>>> >>>>> >>>>>>> Udelal bych to po dlazdicich a pri generalizaci atp. bychom >>>>>>> slucovali >>>>>>> body, ktere budou blizko u sebe. A rozsekane bych ty lesy pak >>>>>>> nechal >>>>>>> podel tech dlazdic (duvody uz jsem psal minule - treba takove >>>>>>> krivoklatsko by se stahlo v podstate cele kdyz by se clovek podival >>>>>>> na >>>>>>> kousek ulice v Beroune). >>>>>>> >>>>>>> >>>>>>> >>>>>> Jak jsem povidal vyse, spojovani je des. Ohledne sekani podle >>>>>> dlazdic, >>>>>> tak >>>>>> to neni nejlepsi. Vznikaly by zbytecne ctverce. Tobe totiz ani >>>>>> nevadi, >>>>>> ze >>>>>> je area obrovska pokus se sklada z 10 bodu.... Podle dlazdic Ti >>>>>> naopak >>>>>> budou vznika usekle vycnelky z tilu... >>>>>> >>>>>> >>>>>> >>>>> zbytecne 4 body tam vnziknou pouze ve velmi malo oblastech. Nevim o >>>>> uzemi v CR, kde by byl les bez diry na uzemi 0.1x0.1 stupne. >>>>> >>>>> >>>>>>> Binding do pythona nepotrebuji - cas behu potrace >>> cas spusteni >>>>>>> aplikace, takze to prozenu normalne pres prikazovej radek a svgcka >>>>>>> pak >>>>>>> zpracuju jednoduchym parserem v jave. Dnesek jsem stravil >>>>>>> studovanim >>>>>>> formatu SVG, abych pochopil, co ty cisilka a pismenka uvnitr >>>>>>> znamenaji >>>>>>> :) >>>>>>> >>>>>>> >>>>>>> >>>>>> No jak myslis. Ja preferuji na tyto prace python, protoze ho precte >>>>>> skoro >>>>>> kazdej a vyviji se mnohem rychleji. A nemusis studovat SVG ;-). Java >>>>>> je >>>>>> pekna, ale na takove vecicky je asi zbytecna... Krom toho kazdy >>>>>> dalsi >>>>>> mezikrok (meziformat) zvysuje pravdepodobnost chyb v procesu. Kdyz >>>>>> mas >>>>>> moznost ziskat raw data z potrace, nebranil bych se tomu (i kdyz sis >>>>>> samozrejmne dal praci studovanim SVG...) >>>>>> >>>>>> >>>>>> >>>>> ja ho sice prectu, ale delal jsem v nem tak malo, ze nez nastuduju, >>>>> jak >>>>> se s tim dela, tak to mam jinde hotove... >>>>> >>>>> >>>>>> Muzes nekam hodit tak 5*5 tilu, ze bych se podival jak vypadaji a >>>>>> vedel >>>>>> alespon o cem mluvim? >>>>>> >>>>>> >>>>>> >>>>> stahni si, kolik potrebujes, akorat dodrz vzdy rozmer bboxu 0.1x0.1 a >>>>> sirku a vysku obrazku si nechej 2000 >>>>> >>>>> http://geoportal2.uhul.cz/cgi-bin/oprl.asp?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG:4326&LAYERS=Les_OPRL&STYLES=default&FORMAT=image/png&TRANSPARENT=TRUE&BBOX=14.5,50,14.6,50.1&WIDTH=2000&HEIGHT=2000 >>>>> >>>>> >>>>> >>>>>> Dik T >>>>>> >>>>>> >>>>>> >>>>>> >>>>> neni zac K >>>>> >>>>> >>>>>>> K >>>>>>> >>>>>>> [EMAIL PROTECTED] napsal(a): >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Ahoj, >>>>>>>> >>>>>>>> to je super zprava, ze na tom delas. Mozna bych se vubec nestaral >>>>>>>> o >>>>>>>> pocet >>>>>>>> bodu. Ty se odstrani generalizaci, kde je budes mit vic pod >>>>>>>> kontrolou. >>>>>>>> Preci jen do potracove zdrojaky jsou slozitejsi nez jednoduchy >>>>>>>> algoritmus. >>>>>>>> Jestli chces muzu poskytnout python binding na potrace vcetne >>>>>>>> douglas-pluckera. Pak bysme mohli vyseknout rozumne velkou bitmapu >>>>>>>> (30x30km) a na te zdrojaky odladit ku oblibe cele konference. >>>>>>>> Vyslednym >>>>>>>> kodem se pak prozene cela CR a bude hotovo. >>>>>>>> >>>>>>>> Z ceho nakonec generujes? Spojil jsi cele Cechy do jedne bitmapy? >>>>>>>> Tim >>>>>>>> totiz odpada problem se spojovanim podel tilu apod.... >>>>>>>> >>>>>>>> T >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Tak jsem prisel na to, jak se v potracu vypina generovani krivek. >>>>>>>>> Ted >>>>>>>>> uz >>>>>>>>> tedy prevod bitmapy na vektory je zcela trivialni. Musim rict, ze >>>>>>>>> to >>>>>>>>> generuje moc hezke obrazky. Jeste si pohraju s vyladenim >>>>>>>>> parametru, >>>>>>>>> aby >>>>>>>>> to generovalo malo bodu a bude to. >>>>>>>>> >>>>>>>>> K >>>>>>>>> >>>>>>>>> Kubajz napsal(a): >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Ahoj, >>>>>>>>>> >>>>>>>>>> [EMAIL PROTECTED] napsal(a): >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> S tim naprosto souhlasim. Sjednocene typy a zjednodusit na >>>>>>>>>>> napr. >>>>>>>>>>> 15m >>>>>>>>>>> chybu >>>>>>>>>>> v Douglas-Pluckeru. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> diky za podporu :) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Daji se tedy pouzit ty xml data od Vas? Jestli ne tak se musi >>>>>>>>>>> rozpoznat >>>>>>>>>>> nejaka bitmapa z wms serveru uhulu? Pochopil jsem to tak, ze >>>>>>>>>>> ten >>>>>>>>>>> vektor >>>>>>>>>>> jiz na UHUL neni. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> ta data, co jsem tehdy vytahl z WFS nemuseji byt korektni a trpi >>>>>>>>>> spoustou neduhu (napr. duplicity bodu aj.), takze neni dobre z >>>>>>>>>> nich >>>>>>>>>> vychazet. Na webu jsem je pro jistotu jiz znepristupnil. Uhul ma >>>>>>>>>> nejaky >>>>>>>>>> problem v nastaveni WFS serveru, takze vktorova data jiz nelze >>>>>>>>>> stahnout. >>>>>>>>>> Nicmene stale lze stahnout bitmapy pres WMS v pozadovanem >>>>>>>>>> rozliseni. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Na vektorizaci jsem pouzival potrace na buildup area. Zkousel >>>>>>>>>>> jsem >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> na potrace jsem narazil dnes asi pred hodinou. Zkusim, co to >>>>>>>>>> provede >>>>>>>>>> na >>>>>>>>>> obrazku z UHUL WMS. Da se mu zabranit v tom, aby vytvarel krivky >>>>>>>>>> a >>>>>>>>>> misto >>>>>>>>>> toho to udelal z usecek (hranate)? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> vytvorit bitmapu o nejakem rozliseni s tim, ze se na kazdou >>>>>>>>>>> adresu >>>>>>>>>>> udelal >>>>>>>>>>> pixel, blur a vzal pixely s hodnotou vyssi nez neco. Vysledek >>>>>>>>>>> se >>>>>>>>>>> prohnal >>>>>>>>>>> potrace a vzniknul vektor. Bohuzel vysledek se mi nelibil tolik >>>>>>>>>>> jako >>>>>>>>>>> rucni >>>>>>>>>>> vyber, takze jsem od toho nakonec upustil. Hezci bylo vytvorit >>>>>>>>>>> kolem >>>>>>>>>>> adresy sestiuhelnik o nejake plose a polygony vektorove >>>>>>>>>>> zmergovat a >>>>>>>>>>> simplifikovat pro vyhlazeni zoubku. Pouzival jsem algoritmy >>>>>>>>>>> popsane >>>>>>>>>>> v >>>>>>>>>>> predchozim mejlu. S pouzitim dat z CSU vznikla pekna mapka. >>>>>>>>>>> Bohuzel >>>>>>>>>>> asi >>>>>>>>>>> nejde pouzit kvuli licenci. Ale z UIR by take mozna neco >>>>>>>>>>> pekneho >>>>>>>>>>> vzniklo... >>>>>>>>>>> >>>>>>>>>>> Jaky je tedy navrh? XML nebo bitmapa? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> bitmapa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> T >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Pokud si to dobre pamatuji, tak nazor byl ano, ale ve >>>>>>>>>>>> zjednodusenem >>>>>>>>>>>> stavu. Preci neni mozne mit tam lesy v rozliseni 5m s >>>>>>>>>>>> rozlisenim >>>>>>>>>>>> poddruhu lesu. Navic jsem zjistil i chybu v puvodni >>>>>>>>>>>> implementaci, >>>>>>>>>>>> ze >>>>>>>>>>>> se >>>>>>>>>>>> muze stat, ze nektere lesy nebudou importovany a nektere lesy >>>>>>>>>>>> tam >>>>>>>>>>>> budou >>>>>>>>>>>> dvakrat - je to z duvodu toho, ze puvodni WFS pracovalo trochu >>>>>>>>>>>> zvlastne >>>>>>>>>>>> s BB oblasti. Kdyz tam zasahoval jen maly kousek lesa, tak jej >>>>>>>>>>>> nezobrazil a kdyz tam zasahoval vetsi, tak uz jo. A mohlo se >>>>>>>>>>>> stat, >>>>>>>>>>>> ze >>>>>>>>>>>> takhle les zobrazil ve dvou dlazdicich. >>>>>>>>>>>> >>>>>>>>>>>> K >>>>>>>>>>>> >>>>>>>>>>>> Pavel Machek napsal(a): >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On Sun 2008-07-13 19:00:26, Kubajz wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Pavel Machek napsal(a): >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Ahoj! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Importoval jsem okoli klanovic a kus vychodni Prahy... v >>>>>>>>>>>>>>> oblastech >>>>>>>>>>>>>>> je >>>>>>>>>>>>>>> malo lesu a dost jinych dat, takze tech dat nebylo tolik, a >>>>>>>>>>>>>>> Praha >>>>>>>>>>>>>>> se >>>>>>>>>>>>>>> trochu zazelena... Dlazdice jsou vyjmenovany na wiki. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Hm - bylo by celkem dobre respektovat nazor vetsiny na >>>>>>>>>>>>>> konferenci. >>>>>>>>>>>>>> Ta >>>>>>>>>>>>>> data pro jistotu smazu, aby to nekoho nelakalo... >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> Bohuzel "respektovat nazor vetsiny na konferenci" (a nemyslim >>>>>>>>>>>>> ze >>>>>>>>>>>>> to >>>>>>>>>>>>> byla vetsina) v tomto pripade znamena "nemapovat lesy". >>>>>>>>>>>>> >>>>>>>>>>>>> A je dost smutny kdyz v praze jsou nakresleny jednotlivy >>>>>>>>>>>>> domky v >>>>>>>>>>>>> Dejvicich, a pak v ni jaksi chybi Sarecky les. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Pavel >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>>> >>> >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
