> Ahoj, > > co kdybychom pomoci WFS importovali hranice lesu do OSM? Polygony by > mely byt v epsg:2065, ale nevim, jak se tato projekce prekloip do GPS. > Kdyby byl nekdo schopen mi dodat rutinu, kterou se to udela, tak je > mozne zahajit poloautomaticky import (napsal bych JOSM plugin). > > Plugin bych take mohl udelat pro rucni import z te databaze, co psal > Pavel - automaticky by to delalo body s nazvy a populaci... > > Diky za vyjadreni, > > K > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz

> co kdybychom pomoci WFS importovali hranice lesu do OSM? Polygony by > mely byt v epsg:2065, ale nevim, jak se tato projekce prekloip do GPS. > Kdyby byl nekdo schopen mi dodat rutinu, kterou se to udela, tak je > mozne zahajit poloautomaticky import (napsal bych JOSM plugin).

> Plugin bych take mohl udelat pro rucni import z te databaze, co psal > Pavel - automaticky by to delalo body s nazvy a populaci...

> Ahojky! > > > co kdybychom pomoci WFS importovali hranice lesu do OSM? Polygony by > > mely byt v epsg:2065, ale nevim, jak se tato projekce prekloip do GPS. > > Kdyby byl nekdo schopen mi dodat rutinu, kterou se to udela, tak je > > mozne zahajit poloautomaticky import (napsal bych JOSM plugin). > > No, udelat import hranic lesa by bylo super. Rucne se to nedela uplne > dobre. > > Je nejaky popis toho epsg:2065? Na konversi bodu se pouziva cs2cs, ale > nemuzu vymyslet parametry.. > > PROJ(1) > > NAME > cs2cs - cartographic coordinate system filter > > SYNOPSIS > cs2cs [ -eEfIlrstvwW [ args ] ] [ +opts[=arg] ] > [ +to [+opts[=arg]] ] file[s] > > ..aha... > > http://spatialreference.org/ref/epsg/2065/ > http://spatialreference.org/ref/epsg/2065/proj4/ > > ...tj se to nejspis konvertuje takhle: > > cs2cs +proj=krovak +lat_0=49.5 +lon_0=42.5 +alpha=30.28813972222222 > +k=0.9999 +x_0=0 +y_0=0 +ellps=bessel +pm=ferro +units=m +no_defs > +to +proj=latlong > > > Plugin bych take mohl udelat pro rucni import z te databaze, co psal > > Pavel - automaticky by to delalo body s nazvy a populaci... > > To by bylo fajn... > Pavel

> jedna, jestli se nepletu, UHUL nabizi data i ve WGS84 (epsg:4326) a > jednak to lze udělat např. takhle: > > ogr2ogr -s_srs "epsg:2065" -t_srs "epsg:4326" -f "GML" output_file.xml > input_file.xml > > > ogr2ogr je soucast baliku GDAL (http://www.gdal.org) > > snad to pomuze > > jachym > > Jakub Sykora píše v Po 10. 09. 2007 v 12:20 +0200: >> Ahoj, >> >> co kdybychom pomoci WFS importovali hranice lesu do OSM? Polygony by >> mely byt v epsg:2065, ale nevim, jak se tato projekce prekloip do GPS. >> Kdyby byl nekdo schopen mi dodat rutinu, kterou se to udela, tak je >> mozne zahajit poloautomaticky import (napsal bych JOSM plugin). >> >> Plugin bych take mohl udelat pro rucni import z te databaze, co psal >> Pavel - automaticky by to delalo body s nazvy a populaci... >> >> Diky za vyjadreni, >> >> K >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz

> 2. Jake informace o lesu importovat do OSM (rozloha, urceni atp., zdroj dat)

> > 2. Jake informace o lesu importovat do OSM (rozloha, urceni atp., zdroj dat) > *** urcite ID z uhul, datum importu, puvod dat (autor), vznik datasetu, > jehl/listnaty > > *** je nejaky ciselnik popisne slozky dat?

> > zdravi > > haonj > > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz

>> 2. Jake informace o lesu importovat do OSM (rozloha, urceni atp., zdroj dat) >> > *** urcite ID z uhul, datum importu, puvod dat (autor), vznik datasetu, > jehl/listnaty > > *** je nejaky ciselnik popisne slozky dat? > > zdravi > > haonj > > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

> To nevim, ja jsem pouze technik a udelal jsem to nejzakladnejsi - > vyuzil dva odkazy na www.uhul.cz. Kazdopadne me zatim tizi ten > offset. Nejake napady?

> myslis tech dat z UHULu? Oblastni plan rozvoje lesu (OPRL)? urcite > existuje, asi bych se na to umel dostat. co konkretne te zajima?

> Jakub Sykora napsal(a): > >> To nevim, ja jsem pouze technik a udelal jsem to nejzakladnejsi - >> vyuzil dva odkazy na www.uhul.cz. Kazdopadne me zatim tizi ten >> offset. Nejake napady? >> > *** ze by ten posun byl konstantni je velmi podivne. Neco podobneho > (lokalne to vypadalo jako posun na vychod) se stavalo pri spatne > transformaci JTSK->WGS84 (na strane serveru). > *** zkusim zitra otestovat to WFS jinde, zda je zdroj dat OK. > > > Jachym napsal(a): > >> myslis tech dat z UHULu? Oblastni plan rozvoje lesu (OPRL)? urcite >> existuje, asi bych se na to umel dostat. co konkretne te zajima? >> > *** ano, nejaka metadata odpovidajici, lesu tedy: > http://212.158.143.149/cgi-bin/wfs?service=WFS&version=1.0.0&request=describeFeatureType > > > ha > hanoj > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

> To bys byl hodnej, abychom pripadne upravili prevodni vztah tak, aby to > sedelo. > Jeste jedna otazka - existuje nejaky program z GDALu, kteremu podsunu > pouze souradnice lat a lon v jedne projekci a vysype to souradnice v > druhe? Potrebuji nejak prevadet mezi sebou souradnice boundary boxu. > Maji totiz ve features pokryti v GPS, ale jako parametr WFS se zadavaji > souradnice v tom druhem formatu. > > Jinak uz jsem vyresil problem transformace GML do OSM celkem uspokojive > - sice to bude dvojpruchodove, ale nebude to mit chybu :] > > Diky, > > hanoj napsal(a): > > Jakub Sykora napsal(a): > > > >> To nevim, ja jsem pouze technik a udelal jsem to nejzakladnejsi - > >> vyuzil dva odkazy na www.uhul.cz. Kazdopadne me zatim tizi ten > >> offset. Nejake napady? > >> > > *** ze by ten posun byl konstantni je velmi podivne. Neco podobneho > > (lokalne to vypadalo jako posun na vychod) se stavalo pri spatne > > transformaci JTSK->WGS84 (na strane serveru). > > *** zkusim zitra otestovat to WFS jinde, zda je zdroj dat OK. > > > > > > Jachym napsal(a): > > > >> myslis tech dat z UHULu? Oblastni plan rozvoje lesu (OPRL)? urcite > >> existuje, asi bych se na to umel dostat. co konkretne te zajima? > >> > > *** ano, nejaka metadata odpovidajici, lesu tedy: > > http://212.158.143.149/cgi-bin/wfs?service=WFS&version=1.0.0&request=describeFeatureType > > > > > > ha > > hanoj > > > > _______________________________________________ > > Talk-cz mailing list > > Talk-cz na openstreetmap.org > > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

> Jakub Sykora napsal(a): > > To nevim, ja jsem pouze technik a udelal jsem to nejzakladnejsi - > > vyuzil dva odkazy na www.uhul.cz. Kazdopadne me zatim tizi ten > > offset. Nejake napady? > *** ze by ten posun byl konstantni je velmi podivne. Neco podobneho > (lokalne to vypadalo jako posun na vychod) se stavalo pri spatne > transformaci JTSK->WGS84 (na strane serveru). > *** zkusim zitra otestovat to WFS jinde, zda je zdroj dat OK. > > > Jachym napsal(a): > > myslis tech dat z UHULu? Oblastni plan rozvoje lesu (OPRL)? urcite > > existuje, asi bych se na to umel dostat. co konkretne te zajima? > *** ano, nejaka metadata odpovidajici, lesu tedy: > http://212.158.143.149/cgi-bin/wfs?service=WFS&version=1.0.0&request=describeFeatureType > > > ha > hanoj > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

> Obecně: převod z JTSK do WGS84 potřebuje pro korektní převod parametry +towgs84 > > ty jsou k nalezení na http://grass.fsv.cvut.cz/wiki/index.php/S-JTSK a > jsou 570.8,85.7,462.8,4.998,1.587,5.261,3.56 > > ale > > při použití epsg 102067 (nebo tak nejak), coz neni epsg, ale esri, by > tam ty parametry mely byt. v me instalaci PROJ je epsg (esri) 102067 > definovan jako > <102067> +proj=krovak +lat_0=49.5 +lon_0=24.83333333333333 > +alpha=30.28813975277->778 +k=0.9999 +x_0=0 +y_0=0 +ellps=bessel > +units=m no_defs <> > > cizlize bez parametru +towgs84 > > zaver > > zkuste to nějak takhle: gdalwarp +init=epsg:102067 > +towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56 +to +init=epsg:4326 > > snad to zabere > > jachym > > P.S. Omlouvám se za zmatek, sám v tom mám jasno jenom intuitivně > 25.9.07, hanoj <enemy na mail.muni.cz>: > >> Jakub Sykora napsal(a): >> >>> To nevim, ja jsem pouze technik a udelal jsem to nejzakladnejsi - >>> vyuzil dva odkazy na www.uhul.cz. Kazdopadne me zatim tizi ten >>> offset. Nejake napady? >>> >> *** ze by ten posun byl konstantni je velmi podivne. Neco podobneho >> (lokalne to vypadalo jako posun na vychod) se stavalo pri spatne >> transformaci JTSK->WGS84 (na strane serveru). >> *** zkusim zitra otestovat to WFS jinde, zda je zdroj dat OK. >> >> >> Jachym napsal(a): >> >>> myslis tech dat z UHULu? Oblastni plan rozvoje lesu (OPRL)? urcite >>> existuje, asi bych se na to umel dostat. co konkretne te zajima? >>> >> *** ano, nejaka metadata odpovidajici, lesu tedy: >> http://212.158.143.149/cgi-bin/wfs?service=WFS&version=1.0.0&request=describeFeatureType >> >> >> ha >> hanoj >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> >> > > >

> Obecně: převod z JTSK do WGS84 potřebuje pro korektní převod parametry +towgs84 > > ty jsou k nalezení na http://grass.fsv.cvut.cz/wiki/index.php/S-JTSK a > jsou 570.8,85.7,462.8,4.998,1.587,5.261,3.56 > > ale > > při použití epsg 102067 (nebo tak nejak), coz neni epsg, ale esri, by > tam ty parametry mely byt. v me instalaci PROJ je epsg (esri) 102067 > definovan jako > <102067> +proj=krovak +lat_0=49.5 +lon_0=24.83333333333333 > +alpha=30.28813975277->778 +k=0.9999 +x_0=0 +y_0=0 +ellps=bessel > +units=m no_defs <> > > cizlize bez parametru +towgs84 > > zaver > > zkuste to nějak takhle: gdalwarp +init=epsg:102067 > +towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56 +to +init=epsg:4326 > > snad to zabere > > jachym > > P.S. Omlouvám se za zmatek, sám v tom mám jasno jenom intuitivně > 25.9.07, hanoj <enemy na mail.muni.cz>: >> Jakub Sykora napsal(a): >>> To nevim, ja jsem pouze technik a udelal jsem to nejzakladnejsi - >>> vyuzil dva odkazy na www.uhul.cz. Kazdopadne me zatim tizi ten >>> offset. Nejake napady? >> *** ze by ten posun byl konstantni je velmi podivne. Neco podobneho >> (lokalne to vypadalo jako posun na vychod) se stavalo pri spatne >> transformaci JTSK->WGS84 (na strane serveru). >> *** zkusim zitra otestovat to WFS jinde, zda je zdroj dat OK. >> >> >> Jachym napsal(a): >>> myslis tech dat z UHULu? Oblastni plan rozvoje lesu (OPRL)? urcite >>> existuje, asi bych se na to umel dostat. co konkretne te zajima? >> *** ano, nejaka metadata odpovidajici, lesu tedy: >> http://212.158.143.149/cgi-bin/wfs?service=WFS&version=1.0.0&request=describeFeatureType >> >> >> ha >> hanoj >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> > >

> Ahoj, > > prave procitam, co dela gdalwarp - snad by to melo prevadet rastrova > data z jedne projekce do druhe - to je mi celkem na nic. Potrebuji > prevest souradnice z jedne projekce do druhe. Z UHULu se vytahne GML > soubor a ten transfromuji. > Da se Tvuj poznatek aplikovat na ogr2ogr? > > K > > Jachym Cepicky wrote: > > Obecně: převod z JTSK do WGS84 potřebuje pro korektní převod parametry +towgs84 > > > > ty jsou k nalezení na http://grass.fsv.cvut.cz/wiki/index.php/S-JTSK a > > jsou 570.8,85.7,462.8,4.998,1.587,5.261,3.56 > > > > ale > > > > při použití epsg 102067 (nebo tak nejak), coz neni epsg, ale esri, by > > tam ty parametry mely byt. v me instalaci PROJ je epsg (esri) 102067 > > definovan jako > > <102067> +proj=krovak +lat_0=49.5 +lon_0=24.83333333333333 > > +alpha=30.28813975277->778 +k=0.9999 +x_0=0 +y_0=0 +ellps=bessel > > +units=m no_defs <> > > > > cizlize bez parametru +towgs84 > > > > zaver > > > > zkuste to nějak takhle: gdalwarp +init=epsg:102067 > > +towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56 +to +init=epsg:4326 > > > > snad to zabere > > > > jachym > > > > P.S. Omlouvám se za zmatek, sám v tom mám jasno jenom intuitivně > > 25.9.07, hanoj <enemy na mail.muni.cz>: > >> Jakub Sykora napsal(a): > >>> To nevim, ja jsem pouze technik a udelal jsem to nejzakladnejsi - > >>> vyuzil dva odkazy na www.uhul.cz. Kazdopadne me zatim tizi ten > >>> offset. Nejake napady? > >> *** ze by ten posun byl konstantni je velmi podivne. Neco podobneho > >> (lokalne to vypadalo jako posun na vychod) se stavalo pri spatne > >> transformaci JTSK->WGS84 (na strane serveru). > >> *** zkusim zitra otestovat to WFS jinde, zda je zdroj dat OK. > >> > >> > >> Jachym napsal(a): > >>> myslis tech dat z UHULu? Oblastni plan rozvoje lesu (OPRL)? urcite > >>> existuje, asi bych se na to umel dostat. co konkretne te zajima? > >> *** ano, nejaka metadata odpovidajici, lesu tedy: > >> http://212.158.143.149/cgi-bin/wfs?service=WFS&version=1.0.0&request=describeFeatureType > >> > >> > >> ha > >> hanoj > >> > >> _______________________________________________ > >> Talk-cz mailing list > >> Talk-cz na openstreetmap.org > >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > >> > > > > > > -- > Jakub Sýkora > email: kubajz na kbx.cz <') > ICQ: 68976632 ( =- > mobil: +420 777 594 201 '' > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

>>>>> 14.024991 49.808742 45.841619 <<<<<<<<<<<<<<<<<

> Hoj, > pokud tedy shrnu Jachyma (a jeho publikace [1],[3]) tak: > > > echo "-775279.26 -1069759.49" |cs2cs -f "%f" +init=epsg:2065 > +towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56 +to +init=epsg:4326 > > > >>>>> 14.024991 49.808742 45.841619 <<<<<<<<<<<<<<<<< > ===(14d1'29.966"E 49d48'31.472"N 45.842) > > coz odpovida bodu 104 kampane DOPNUL [2]: > 49d48'31,47599" 14d1'29,96593" (IRTF); > 755279,26 1069759,49 (S-JTSK) > > > Takze pokud aplikuji na priklad WFS UHUL: > http://212.158.143.149/cgi-bin/wfs?service=WFS&version=1.0.0&request=getFeature&typeName=typo&bbox=-685591,-1064775,-682518,-1061770 > > Tak mam korektni vysledek... > http://osm.templ.net/josm-wfs-import.png > > > [1] http://grass.fsv.cvut.cz/wiki/index.php?title=S-JTSK > [2] http://www.geospeleos.com/Mapovani/WGS84toSJTSK/WGS_JTSK.pdf > [3] http://www.les-ejk.cz/docs/skoleni/projekce.pdf > > takze jeste ziskat metadata k atributum... > > > ha hanoj > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

> Hoj, > pokud tedy shrnu Jachyma (a jeho publikace [1],[3]) tak: > > > echo "-775279.26 -1069759.49" |cs2cs -f "%f" +init=epsg:2065 > +towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56 +to +init=epsg:4326 > > > >>>>> 14.024991 49.808742 45.841619 <<<<<<<<<<<<<<<<< > ===(14d1'29.966"E 49d48'31.472"N 45.842) > > coz odpovida bodu 104 kampane DOPNUL [2]: > 49d48'31,47599" 14d1'29,96593" (IRTF); > 755279,26 1069759,49 (S-JTSK) > > > Takze pokud aplikuji na priklad WFS UHUL: > http://212.158.143.149/cgi-bin/wfs?service=WFS&version=1.0.0&request=getFeature&typeName=typo&bbox=-685591,-1064775,-682518,-1061770 > > Tak mam korektni vysledek... > http://osm.templ.net/josm-wfs-import.png > > > [1] http://grass.fsv.cvut.cz/wiki/index.php?title=S-JTSK > [2] http://www.geospeleos.com/Mapovani/WGS84toSJTSK/WGS_JTSK.pdf > [3] http://www.les-ejk.cz/docs/skoleni/projekce.pdf > > takze jeste ziskat metadata k atributum... > > > ha hanoj > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

> Problem bude tedy v tom, ze ogr2ogr dela tu transformaci nekorektne. > Prepisu to tak, aby se to konvertovalo pomoci cs2cs s tim nastavenim, > ktere jsi poslal. > > Muzu zkusit na UHUL zavolat tomu cloveku, co to ma na starost a zeptat > se ho, co ktere udaje presne znamenaji. > > K > > hanoj napsal(a): > > Hoj, > > pokud tedy shrnu Jachyma (a jeho publikace [1],[3]) tak: > > > > > > echo "-775279.26 -1069759.49" |cs2cs -f "%f" +init=epsg:2065 > > +towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56 +to +init=epsg:4326 > > > > > > >>>>> 14.024991 49.808742 45.841619 <<<<<<<<<<<<<<<<< > > ===(14d1'29.966"E 49d48'31.472"N 45.842) > > > > coz odpovida bodu 104 kampane DOPNUL [2]: > > 49d48'31,47599" 14d1'29,96593" (IRTF); > > 755279,26 1069759,49 (S-JTSK) > > > > > > Takze pokud aplikuji na priklad WFS UHUL: > > http://212.158.143.149/cgi-bin/wfs?service=WFS&version=1.0.0&request=getFeature&typeName=typo&bbox=-685591,-1064775,-682518,-1061770 > > > > Tak mam korektni vysledek... > > http://osm.templ.net/josm-wfs-import.png > > > > > > [1] http://grass.fsv.cvut.cz/wiki/index.php?title=S-JTSK > > [2] http://www.geospeleos.com/Mapovani/WGS84toSJTSK/WGS_JTSK.pdf > > [3] http://www.les-ejk.cz/docs/skoleni/projekce.pdf > > > > takze jeste ziskat metadata k atributum... > > > > > > ha hanoj > > > > _______________________________________________ > > Talk-cz mailing list > > Talk-cz na openstreetmap.org > > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

> nekorektně? tak nahlaš bug. frank se bude určitě těšit na další > problémy s křovákem :D > > http://trac.osgeo.org/gdal/ > > jachym > > 27.9.07, Jakub Sýkora <kubajz na kbx.cz>: > >> Problem bude tedy v tom, ze ogr2ogr dela tu transformaci nekorektne. >> Prepisu to tak, aby se to konvertovalo pomoci cs2cs s tim nastavenim, >> ktere jsi poslal. >> >> Muzu zkusit na UHUL zavolat tomu cloveku, co to ma na starost a zeptat >> se ho, co ktere udaje presne znamenaji. >> >> K >> >> hanoj napsal(a): >> >>> Hoj, >>> pokud tedy shrnu Jachyma (a jeho publikace [1],[3]) tak: >>> >>> >>> echo "-775279.26 -1069759.49" |cs2cs -f "%f" +init=epsg:2065 >>> +towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56 +to +init=epsg:4326 >>> >>> >>> >>>>> 14.024991 49.808742 45.841619 <<<<<<<<<<<<<<<<< >>> ===(14d1'29.966"E 49d48'31.472"N 45.842) >>> >>> coz odpovida bodu 104 kampane DOPNUL [2]: >>> 49d48'31,47599" 14d1'29,96593" (IRTF); >>> 755279,26 1069759,49 (S-JTSK) >>> >>> >>> Takze pokud aplikuji na priklad WFS UHUL: >>> http://212.158.143.149/cgi-bin/wfs?service=WFS&version=1.0.0&request=getFeature&typeName=typo&bbox=-685591,-1064775,-682518,-1061770 >>> >>> Tak mam korektni vysledek... >>> http://osm.templ.net/josm-wfs-import.png >>> >>> >>> [1] http://grass.fsv.cvut.cz/wiki/index.php?title=S-JTSK >>> [2] http://www.geospeleos.com/Mapovani/WGS84toSJTSK/WGS_JTSK.pdf >>> [3] http://www.les-ejk.cz/docs/skoleni/projekce.pdf >>> >>> takze jeste ziskat metadata k atributum... >>> >>> >>> ha hanoj >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>> >>> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> >> > > >

> Hoj, > pokud tedy shrnu Jachyma (a jeho publikace [1],[3]) tak: > > > echo "-775279.26 -1069759.49" |cs2cs -f "%f" +init=epsg:2065 > +towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56 +to +init=epsg:4326 > > > >>>>> 14.024991 49.808742 45.841619 <<<<<<<<<<<<<<<<< > ===(14d1'29.966"E 49d48'31.472"N 45.842) > > coz odpovida bodu 104 kampane DOPNUL [2]: > 49d48'31,47599" 14d1'29,96593" (IRTF); > 755279,26 1069759,49 (S-JTSK) > > > Takze pokud aplikuji na priklad WFS UHUL: > http://212.158.143.149/cgi-bin/wfs?service=WFS&version=1.0.0&request=getFeature&typeName=typo&bbox=-685591,-1064775,-682518,-1061770 > > Tak mam korektni vysledek... > http://osm.templ.net/josm-wfs-import.png > > > [1] http://grass.fsv.cvut.cz/wiki/index.php?title=S-JTSK > [2] http://www.geospeleos.com/Mapovani/WGS84toSJTSK/WGS_JTSK.pdf > [3] http://www.les-ejk.cz/docs/skoleni/projekce.pdf > > takze jeste ziskat metadata k atributum... > > > ha hanoj > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

> nekorektně? tak nahlaš bug. frank se bude určitě těšit na další > problémy s křovákem :D > > http://trac.osgeo.org/gdal/ > > jachym > > 27.9.07, Jakub Sýkora <kubajz na kbx.cz>: >> Problem bude tedy v tom, ze ogr2ogr dela tu transformaci nekorektne. >> Prepisu to tak, aby se to konvertovalo pomoci cs2cs s tim nastavenim, >> ktere jsi poslal. >> >> Muzu zkusit na UHUL zavolat tomu cloveku, co to ma na starost a zeptat >> se ho, co ktere udaje presne znamenaji. >> >> K >> >> hanoj napsal(a): >>> Hoj, >>> pokud tedy shrnu Jachyma (a jeho publikace [1],[3]) tak: >>> >>> >>> echo "-775279.26 -1069759.49" |cs2cs -f "%f" +init=epsg:2065 >>> +towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56 +to +init=epsg:4326 >>> >>> >>> >>>>> 14.024991 49.808742 45.841619 <<<<<<<<<<<<<<<<< >>> ===(14d1'29.966"E 49d48'31.472"N 45.842) >>> >>> coz odpovida bodu 104 kampane DOPNUL [2]: >>> 49d48'31,47599" 14d1'29,96593" (IRTF); >>> 755279,26 1069759,49 (S-JTSK) >>> >>> >>> Takze pokud aplikuji na priklad WFS UHUL: >>> http://212.158.143.149/cgi-bin/wfs?service=WFS&version=1.0.0&request=getFeature&typeName=typo&bbox=-685591,-1064775,-682518,-1061770 >>> >>> Tak mam korektni vysledek... >>> http://osm.templ.net/josm-wfs-import.png >>> >>> >>> [1] http://grass.fsv.cvut.cz/wiki/index.php?title=S-JTSK >>> [2] http://www.geospeleos.com/Mapovani/WGS84toSJTSK/WGS_JTSK.pdf >>> [3] http://www.les-ejk.cz/docs/skoleni/projekce.pdf >>> >>> takze jeste ziskat metadata k atributum... >>> >>> >>> ha hanoj >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> > >

> Tak pomoci informaci na webu jsem zatim dospel k nasledujicimu: > > PLO_KOD odpovida kodu Prirodni Lesni Oblasti podle tabulky uvedene v > technickem listu OPRL. Na prikladovych datech je to 17, coz znaci > Polabi. Zatim to take vypada, ze hodnota je stejna s LES_OBL. > LT znaci Lesni Typ a je to kompletni kod SLT+cislo, ktere zatim nevim, > co znamena, ale tipl bych nejakou hustotu porostu nebo tak... > SLT znaci Soubor Lesnich typu a udava jaky porost je v dane > oblasti viz: http://www.uhul.cz/ssl/techlisty/03oprl/tabulka.htm > LO_CAST znaci podcast lesni oblasti. Pro Oblast 17b je to tedy to becko. > Muze nabyvat hodnot a,b,c,d. > PLOCHA je plocha a doufam, ze v ha. > > Zde se da najit taky vysvetleni vsemoznych cisel :) > ftp://ftp.uhul.cz/Public/IStandard/2006/OPRL/ISLH_CISELNIKY_OPRL_2006.xls

> Asi jsem prisel na problem! ogr2ogr si totiz z dvourozmerneho vstupniho > souboru vymyslel trojrozmerny a umistil treti souradnici do -700 a > nejake drobne. Rekl bych, ze to je to, co zpusobuje ten offset. Zkusim > ho presvedcit, aby provedl pouze rovinnou transformaci.

> Jakub Sykora napsal(a): > >> Asi jsem prisel na problem! ogr2ogr si totiz z dvourozmerneho vstupniho >> souboru vymyslel trojrozmerny a umistil treti souradnici do -700 a >> nejake drobne. Rekl bych, ze to je to, co zpusobuje ten offset. Zkusim >> ho presvedcit, aby provedl pouze rovinnou transformaci. >> > *** to se mi take nezda, neb jsou ruzne polohy stupnic v projekcich, ale > vzdy kolme ke stredu zeme a ten je +/- vzdy stejny. Rozdil vysek mezi > kouli u krovaka a wgs84 je cca 1m, mezi elipsoidickou vyskou wgs84 a > geoidem asi 50m. > > ha hanoj > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

>> Tak pomoci informaci na webu jsem zatim dospel k nasledujicimu: >> >> PLO_KOD odpovida kodu Prirodni Lesni Oblasti podle tabulky uvedene v >> technickem listu OPRL. Na prikladovych datech je to 17, coz znaci >> Polabi. Zatim to take vypada, ze hodnota je stejna s LES_OBL. >> LT znaci Lesni Typ a je to kompletni kod SLT+cislo, ktere zatim nevim, >> co znamena, ale tipl bych nejakou hustotu porostu nebo tak... >> SLT znaci Soubor Lesnich typu a udava jaky porost je v dane >> oblasti viz: http://www.uhul.cz/ssl/techlisty/03oprl/tabulka.htm >> LO_CAST znaci podcast lesni oblasti. Pro Oblast 17b je to tedy to becko. >> Muze nabyvat hodnot a,b,c,d. >> PLOCHA je plocha a doufam, ze v ha. >> >> Zde se da najit taky vysvetleni vsemoznych cisel :) >> ftp://ftp.uhul.cz/Public/IStandard/2006/OPRL/ISLH_CISELNIKY_OPRL_2006.xls >> > *** vyborne! navrhuji teda pridat plose tagy: > * "ID", pro pozdejsi pouziti GIS uzivatelu, id="1256666" > > * zjednodusit "SLT" na zakladni druhy porostu jako napr. smrk, jedle, > dub... (poprosim naproti u biologu...) . Jak ale vysledek ulozit? v > CZ/EN? pouzit nejaky neplatny tag, jako se to dela jinde pri importech? > > * "source:topoUhulWFS" (nebo obdobny konstrukt) > > ha > hanoj > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

> Ahoj, > > zatim to tedy udelam tak, ze udelam transformaci z xml do csv s > komentari. Ten projedu pomoci cs2cs - protoze to funguje - a naposledy > to csvcko s komentari prevedu na OSM xml. Az budu mit pouzitelny > vysledek, tak ho dam jako RFC a pokud bude OK, tak ho naimportuji do > databaze. > > K > > hanoj napsal(a): > > Jakub Sykora napsal(a): > > > >> Asi jsem prisel na problem! ogr2ogr si totiz z dvourozmerneho vstupniho > >> souboru vymyslel trojrozmerny a umistil treti souradnici do -700 a > >> nejake drobne. Rekl bych, ze to je to, co zpusobuje ten offset. Zkusim > >> ho presvedcit, aby provedl pouze rovinnou transformaci. > >> > > *** to se mi take nezda, neb jsou ruzne polohy stupnic v projekcich, ale > > vzdy kolme ke stredu zeme a ten je +/- vzdy stejny. Rozdil vysek mezi > > kouli u krovaka a wgs84 je cca 1m, mezi elipsoidickou vyskou wgs84 a > > geoidem asi 50m. > > > > ha hanoj > > > > _______________________________________________ > > Talk-cz mailing list > > Talk-cz na openstreetmap.org > > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

> hanoj napsal(a): > >> Tak pomoci informaci na webu jsem zatim dospel k nasledujicimu: > >> > >> PLO_KOD odpovida kodu Prirodni Lesni Oblasti podle tabulky uvedene v > >> technickem listu OPRL. Na prikladovych datech je to 17, coz znaci > >> Polabi. Zatim to take vypada, ze hodnota je stejna s LES_OBL. > >> LT znaci Lesni Typ a je to kompletni kod SLT+cislo, ktere zatim nevim, > >> co znamena, ale tipl bych nejakou hustotu porostu nebo tak... > >> SLT znaci Soubor Lesnich typu a udava jaky porost je v dane > >> oblasti viz: http://www.uhul.cz/ssl/techlisty/03oprl/tabulka.htm > >> LO_CAST znaci podcast lesni oblasti. Pro Oblast 17b je to tedy to becko. > >> Muze nabyvat hodnot a,b,c,d. > >> PLOCHA je plocha a doufam, ze v ha. > >> > >> Zde se da najit taky vysvetleni vsemoznych cisel :) > >> ftp://ftp.uhul.cz/Public/IStandard/2006/OPRL/ISLH_CISELNIKY_OPRL_2006.xls > >> > > *** vyborne! navrhuji teda pridat plose tagy: > > * "ID", pro pozdejsi pouziti GIS uzivatelu, id="1256666" > > > > * zjednodusit "SLT" na zakladni druhy porostu jako napr. smrk, jedle, > > dub... (poprosim naproti u biologu...) . Jak ale vysledek ulozit? v > > CZ/EN? pouzit nejaky neplatny tag, jako se to dela jinde pri importech? > > > > * "source:topoUhulWFS" (nebo obdobny konstrukt) > > > > ha > > hanoj > > > > _______________________________________________ > > Talk-cz mailing list > > Talk-cz na openstreetmap.org > > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > > > Na uhulu maji ty typy porostu taky v ciselniku. Bratranek je drevar, > takze kdyztak muze radit :] viz. http://dreviny.kbx.cz > > K > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

> Ahoj, > > co kdybychom pomoci WFS importovali hranice lesu do OSM? Polygony by > mely byt v epsg:2065, ale nevim, jak se tato projekce prekloip do GPS. > Kdyby byl nekdo schopen mi dodat rutinu, kterou se to udela, tak je > mozne zahajit poloautomaticky import (napsal bych JOSM plugin). > > Plugin bych take mohl udelat pro rucni import z te databaze, co psal > Pavel - automaticky by to delalo body s nazvy a populaci... > > Diky za vyjadreni, > > K > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz

> Ahoj, > > nakonec jsem vzdal XSL transformace pomoci sablon, protoze to neni > prilis pruzne a to XML, ktere leze z WFS neni prilis dobre > sablonovatelne. Navic XML pro celou republiku by bylo enormne velike > (stahl jsem pres 500MB a stale to jelo, takze jsem to zavrhl). > Udelal jsem kompletni program v Jave, ktery po ctvercich stahuje celou > republiku, prevadi se to do OSM. Nize najdete odkaz, kde jsou uz hotova > data pripravena pro import. Nahodne jsem je kontroloval a vypada to > pomerne presne. Spatna situace je zatim v Krusnych horach, kde to moc > nesedi vubec, ale je to mozna tim, ze za poslednich 10 let se tam ten > lesni porost hodne zmenil. > > Pripadne pripominky k tagum atp., prosim, sem. Soubory jsou cislovany > souradnicemi BBoxu v puvodni projekci a jeden ctverec je 6000x6000 tech > jednotek :). > > http://kubajz.kbx.cz/junk/uhul/

> On Fri 2007-10-05 00:31:26, Jakub Sykora wrote: >> Ahoj, >> >> nakonec jsem vzdal XSL transformace pomoci sablon, protoze to neni >> prilis pruzne a to XML, ktere leze z WFS neni prilis dobre >> sablonovatelne. Navic XML pro celou republiku by bylo enormne velike >> (stahl jsem pres 500MB a stale to jelo, takze jsem to zavrhl). >> Udelal jsem kompletni program v Jave, ktery po ctvercich stahuje celou >> republiku, prevadi se to do OSM. Nize najdete odkaz, kde jsou uz hotova >> data pripravena pro import. Nahodne jsem je kontroloval a vypada to >> pomerne presne. Spatna situace je zatim v Krusnych horach, kde to moc >> nesedi vubec, ale je to mozna tim, ze za poslednich 10 let se tam ten >> lesni porost hodne zmenil. >> >> Pripadne pripominky k tagum atp., prosim, sem. Soubory jsou cislovany >> souradnicemi BBoxu v puvodni projekci a jeden ctverec je 6000x6000 tech >> jednotek :). >> >> http://kubajz.kbx.cz/junk/uhul/ > > Nemely by id-cka byt zaporna, aby to slo uploadovat? > > Mozna by bylo hezci mit jmena podle wgs84 souradnic, takhle je docela > tezky vybrat si zajimavou oblast... ale pokud se udela import bude to > dost jedno. > > Jinak to vypada dobre... > Pavel >

> S tema idckama jsem to tak mel a nevim, proc uz to tak zase nemam...

> Radeji to predelam a pregeneruju. Mrsknu to nekam na server, protoze uz > to jede dve hodiny a zdaleka nejsem ani v pulce :] Ty lesy jsou totiz > strasne bodozni, ale asi ne vic, nez bych je delal ja.

> Pokud chces nejakou zajimavou oblast, tak Ti muzu poslat zdrojak te > Javy. Tam si zadas souradnice a vyplivne to konkretne...

> Ahoj, > > co kdybychom pomoci WFS importovali hranice lesu do OSM? Polygony by > mely byt v epsg:2065, ale nevim, jak se tato projekce prekloip do GPS. > Kdyby byl nekdo schopen mi dodat rutinu, kterou se to udela, tak je > mozne zahajit poloautomaticky import (napsal bych JOSM plugin). > > Plugin bych take mohl udelat pro rucni import z te databaze, co psal > Pavel - automaticky by to delalo body s nazvy a populaci... > > Diky za vyjadreni, > > K > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz

> Ahoj, > > jsem rĂĄd, Ĺže to postupuje. Jenom dotaz: pĹ&#65533;ehlĂŠdl jsem, jestli

> nÄ&#65533;kde > odsouhlaseno UHULem, Ĺže mĹŻĹžeme jejich WFS pouŞít(?). WMS a WFS jsou > pĹ&#65533;ece jen "trochu jinĂĄ data" ... > > JĂĄchym > > Jakub Sykora pĂ­ĹĄe v Po 10. 09. 2007 v 12:20 +0200: >> Ahoj, >> >> co kdybychom pomoci WFS importovali hranice lesu do OSM? Polygony by >> mely byt v epsg:2065, ale nevim, jak se tato projekce prekloip do GPS. >> Kdyby byl nekdo schopen mi dodat rutinu, kterou se to udela, tak je >> mozne zahajit poloautomaticky import (napsal bych JOSM plugin). >> >> Plugin bych take mohl udelat pro rucni import z te databaze, co psal >> Pavel - automaticky by to delalo body s nazvy a populaci... >> >> Diky za vyjadreni, >> >> K >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > -- > Jachym Cepicky > e-mail: jachym.cepicky na gmail.com > URL: http://les-ejk.cz > GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

> nakonec jsem vzdal XSL transformace pomoci sablon, protoze to neni > prilis pruzne a to XML, ktere leze z WFS neni prilis dobre > sablonovatelne. Navic XML pro celou republiku by bylo enormne velike > (stahl jsem pres 500MB a stale to jelo, takze jsem to zavrhl).

> Udelal jsem kompletni program v Jave, ktery po ctvercich stahuje celou > republiku, prevadi se to do OSM. Nize najdete odkaz, kde jsou uz hotova > data pripravena pro import. Nahodne jsem je kontroloval a vypada to > pomerne presne. > Spatna situace je zatim v Krusnych horach, kde to moc > nesedi vubec, ale je to mozna tim, ze za poslednich 10 let se tam ten > lesni porost hodne zmenil.

> Pripadne pripominky k tagum atp., prosim, sem. Soubory jsou cislovany > souradnicemi BBoxu v puvodni projekci a jeden ctverec je 6000x6000 tech > jednotek :).

> <way id="-8236"> > <tag k="landuse" v="forest"/>

> <tag k="source" v="UHULtypoWFS"/> > <tag k="uhul:id" v="8236"/>

> <tag k="uhul:area" v="963.997322074138"/>

> <tag k="uhul:slt" v="Svěží jedlová bučina"/>

> <tag k="is_in" v="Českomoravská vrchovina"/>

> </way>

>> nakonec jsem vzdal XSL transformace pomoci sablon, protoze to neni >> prilis pruzne a to XML, ktere leze z WFS neni prilis dobre >> sablonovatelne. Navic XML pro celou republiku by bylo enormne velike >> (stahl jsem pres 500MB a stale to jelo, takze jsem to zavrhl). > *** Pekna prace!

> >> Udelal jsem kompletni program v Jave, ktery po ctvercich stahuje celou >> republiku, prevadi se to do OSM. Nize najdete odkaz, kde jsou uz hotova >> data pripravena pro import. Nahodne jsem je kontroloval a vypada to >> pomerne presne. >> Spatna situace je zatim v Krusnych horach, kde to moc >> nesedi vubec, ale je to mozna tim, ze za poslednich 10 let se tam ten >> lesni porost hodne zmenil. > *** otazka s cim srovnavame. OrtofotoUHUL je stare okolo 7mi let. Je pravdepodobnejsi ze TypoWFS je aktualizovan, nebo jeste starsi...

> >> Pripadne pripominky k tagum atp., prosim, sem. Soubory jsou cislovany >> souradnicemi BBoxu v puvodni projekci a jeden ctverec je 6000x6000 tech >> jednotek :). > *** metry!

> > *** K tagum >> <way id="-8236"> >> <tag k="landuse" v="forest"/> > *** nebude problem s renderovanim? Doposavad jsem uzival "nature=wood"

> > >> <tag k="source" v="UHULtypoWFS"/> >> <tag k="uhul:id" v="8236"/> > *** zda se ze je tag unikatni na cele CR?

> >> <tag k="uhul:area" v="963.997322074138"/> > *** nezaokrouhlit na jednotky m2? Nebo vubec vyhodit?

> >> <tag k="uhul:slt" v="Svěží jedlová bučina"/> > *** nenechat ten tag v puvodnim cisle ciselniku UHUL. Tomuto textu rozumi tak nejvyse jachym.

> *** pridat tag trebas: <tag k="description" v="Jedle"/>

> *** Jestli jsem slibil preklad do jednoslovnych nazvu, tak jsem nic pro to neudelal. Je mozno to prehrnout na tveho bratrance lesaka?

> >> <tag k="is_in" v="Českomoravská vrchovina"/> > *** OK >> </way> > > zdravi > > Hanoj

> > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz

> snad bych mohl taky sem tam poradit, .... > > j > > 29.9.07, Jakub Sykora <kubajz na kbx.cz>: >> hanoj napsal(a): >>>> Tak pomoci informaci na webu jsem zatim dospel k nasledujicimu: >>>> >>>> PLO_KOD odpovida kodu Prirodni Lesni Oblasti podle tabulky uvedene v >>>> technickem listu OPRL. Na prikladovych datech je to 17, coz znaci >>>> Polabi. Zatim to take vypada, ze hodnota je stejna s LES_OBL. >>>> LT znaci Lesni Typ a je to kompletni kod SLT+cislo, ktere zatim nevim, >>>> co znamena, ale tipl bych nejakou hustotu porostu nebo tak... >>>> SLT znaci Soubor Lesnich typu a udava jaky porost je v dane >>>> oblasti viz: http://www.uhul.cz/ssl/techlisty/03oprl/tabulka.htm >>>> LO_CAST znaci podcast lesni oblasti. Pro Oblast 17b je to tedy to becko. >>>> Muze nabyvat hodnot a,b,c,d. >>>> PLOCHA je plocha a doufam, ze v ha. >>>> >>>> Zde se da najit taky vysvetleni vsemoznych cisel :) >>>> ftp://ftp.uhul.cz/Public/IStandard/2006/OPRL/ISLH_CISELNIKY_OPRL_2006.xls >>>> >>> *** vyborne! navrhuji teda pridat plose tagy: >>> * "ID", pro pozdejsi pouziti GIS uzivatelu, id="1256666" >>> >>> * zjednodusit "SLT" na zakladni druhy porostu jako napr. smrk, jedle, >>> dub... (poprosim naproti u biologu...) . Jak ale vysledek ulozit? v >>> CZ/EN? pouzit nejaky neplatny tag, jako se to dela jinde pri importech? >>> >>> * "source:topoUhulWFS" (nebo obdobny konstrukt) >>> >>> ha >>> hanoj >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>> >> Na uhulu maji ty typy porostu taky v ciselniku. Bratranek je drevar, >> takze kdyztak muze radit :] viz. http://dreviny.kbx.cz >> >> K >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> > >

> Jo bylo to docela zabavny. Zvlast jak jsem se postupne presouval od > jednoduchych nastroju jako BASH skripty pres XSLT az jsem skoncil u Javy > a cele to parsuju SAXem... >

> > > >> Udelal jsem kompletni program v Jave, ktery po ctvercich stahuje celou > >> republiku, prevadi se to do OSM. Nize najdete odkaz, kde jsou uz hotova > >> data pripravena pro import. Nahodne jsem je kontroloval a vypada to > >> pomerne presne. > >> Spatna situace je zatim v Krusnych horach, kde to moc > >> nesedi vubec, ale je to mozna tim, ze za poslednich 10 let se tam ten > >> lesni porost hodne zmenil. > > *** otazka s cim srovnavame. OrtofotoUHUL je stare okolo 7mi let. Je pravdepodobnejsi ze TypoWFS je aktualizovan, nebo jeste starsi... > > Typo WFS by snad mela byt mladsi - podle popisu na webu by mela byt > hodne aktualni. V Krusnych horach je WFS ridsi nez ofoto, takze bych > usuzoval, ze je to spravne :]

> > > >> Pripadne pripominky k tagum atp., prosim, sem. Soubory jsou cislovany > >> souradnicemi BBoxu v puvodni projekci a jeden ctverec je 6000x6000 tech > >> jednotek :). > > *** metry! > > Tahle projekce je v metrech? To jsou mi novinky :] Tak je to 6x6km... > Porad rikam, ze jsem akorat tupej vyvojar...

> > > >> <tag k="uhul:slt" v="Svěží jedlová bučina"/> > > *** nenechat ten tag v puvodnim cisle ciselniku UHUL. Tomuto textu rozumi tak nejvyse jachym. >

> IMO cislu z ciselniku uz nebude rozumet treba ani Jachym :] A nevim, co > je na tom k nepochopeni. Proste je to svezi les s prevladajicim bukovym > porostem a zamichanymi jedlemi... Mozna je to i jinak...

> > > *** pridat tag trebas: <tag k="description" v="Jedle"/>

> > A to bude delat kdo? Tech cisel z ciselniku je 180 a v podstate je to > asi nejake standardni trideni. Takova jedlova bucina nejsou ani jedle > ani buky. > > > *** Jestli jsem slibil preklad do jednoslovnych nazvu, tak jsem nic pro to neudelal. Je mozno to prehrnout na tveho bratrance lesaka? >

> > > *** pridat tag trebas: <tag k="description" v="Jedle"/> > > to ma znazornovat prevladajici drevinu ? prirozene nebo momentalne? > protoze SLT popisuji jak by to byt "melo" (mohlo) ale ne, jak to je > > > > > A to bude delat kdo? Tech cisel z ciselniku je 180 a v podstate je to > > asi nejake standardni trideni. Takova jedlova bucina nejsou ani jedle > > ani buky. > > > > > *** Jestli jsem slibil preklad do jednoslovnych nazvu, tak jsem nic pro to > neudelal. Je mozno to prehrnout na tveho bratrance lesaka? > > > ja bych to proste vynechal. je to pro lesaky, prirodovedce. nechal bych > to byt. description="les" a hotovo > > pokud byste chteli mermomoci mit presnejsi popis typu lesa, muzem se > domluvit na nejakym prevodniku na <10 kategorii podle prevladajici > dreviny (borovice, dub, buk, smrk, klec, bezlesi) ale znovu opakuju: LVS > neznamena, ze to tam je, ale ze by to tam byt asi melo

>>>>(borovice, dub, buk, smrk, klec, bezlesi)<<<<<

> > <tag k="source" v="UHULtypoWFS"/> > > <tag k="uhul:id" v="8236"/> > *** zda se ze je tag unikatni na cele CR? > > > <tag k="uhul:area" v="963.997322074138"/> > *** nezaokrouhlit na jednotky m2? Nebo vubec vyhodit? > > > <tag k="uhul:slt" v="Svěží jedlová bučina"/> > *** nenechat ten tag v puvodnim cisle ciselniku UHUL. Tomuto textu > rozumi tak nejvyse jachym.

> ahoj, > > Jakub Sykora píše v Pá 05. 10. 2007 v 12:21 +0200: > >> Jo bylo to docela zabavny. Zvlast jak jsem se postupne presouval od >> jednoduchych nastroju jako BASH skripty pres XSLT az jsem skoncil u Javy >> a cele to parsuju SAXem... >> > > nebyl by snazsi dom? ale nic nerikam, nic jsem neudelal

> >>>> Udelal jsem kompletni program v Jave, ktery po ctvercich stahuje celou >>>> republiku, prevadi se to do OSM. Nize najdete odkaz, kde jsou uz hotova >>>> data pripravena pro import. Nahodne jsem je kontroloval a vypada to >>>> pomerne presne. >>>> Spatna situace je zatim v Krusnych horach, kde to moc >>>> nesedi vubec, ale je to mozna tim, ze za poslednich 10 let se tam ten >>>> lesni porost hodne zmenil. >>> *** otazka s cim srovnavame. OrtofotoUHUL je stare okolo 7mi let. Je pravdepodobnejsi ze TypoWFS je aktualizovan, nebo jeste starsi... >> Typo WFS by snad mela byt mladsi - podle popisu na webu by mela byt >> hodne aktualni. V Krusnych horach je WFS ridsi nez ofoto, takze bych >> usuzoval, ze je to spravne :] > > je to jedno. typologicke mapy se taky neaktualizuji kazdych deset let. > nehlede k tomu, ze se to kresli vlastne v ruce a vysledna kvalita je > dost idndividalani (polohopisna i obsahova) > >>>> Pripadne pripominky k tagum atp., prosim, sem. Soubory jsou cislovany >>>> souradnicemi BBoxu v puvodni projekci a jeden ctverec je 6000x6000 tech >>>> jednotek :). >>> *** metry! >> Tahle projekce je v metrech? To jsou mi novinky :] Tak je to 6x6km... >> Porad rikam, ze jsem akorat tupej vyvojar... > >>>> <tag k="uhul:slt" v="Svěží jedlová bučina"/> >>> *** nenechat ten tag v puvodnim cisle ciselniku UHUL. Tomuto textu rozumi tak nejvyse jachym. > > slt = soubor lesnich typu > 5S - paty lesni vegetacni stupen, s - kategorie svezi, takze trochu > kyselejsi pudy atd atd. > >> IMO cislu z ciselniku uz nebude rozumet treba ani Jachym :] A nevim, co >> je na tom k nepochopeni. Proste je to svezi les s prevladajicim bukovym >> porostem a zamichanymi jedlemi... Mozna je to i jinak... > > s tim "svezi les" bych moc neoperoval. IMHO je to uplne zbytecne > >>> *** pridat tag trebas: <tag k="description" v="Jedle"/> > > to ma znazornovat prevladajici drevinu ? prirozene nebo momentalne? > protoze SLT popisuji jak by to byt "melo" (mohlo) ale ne, jak to je > >> A to bude delat kdo? Tech cisel z ciselniku je 180 a v podstate je to >> asi nejake standardni trideni. Takova jedlova bucina nejsou ani jedle >> ani buky. >> >>> *** Jestli jsem slibil preklad do jednoslovnych nazvu, tak jsem nic pro to neudelal. Je mozno to prehrnout na tveho bratrance lesaka? > ja bych to proste vynechal. je to pro lesaky, prirodovedce. nechal bych > to byt. description="les" a hotovo > > pokud byste chteli mermomoci mit presnejsi popis typu lesa, muzem se > domluvit na nejakym prevodniku na <10 kategorii podle prevladajici > dreviny (borovice, dub, buk, smrk, klec, bezlesi) ale znovu opakuju: LVS > neznamena, ze to tam je, ale ze by to tam byt asi melo > > jachym > > > ------------------------------------------------------------------------ > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz

> Ahoj! > >>> <tag k="source" v="UHULtypoWFS"/> >>> <tag k="uhul:id" v="8236"/> >> *** zda se ze je tag unikatni na cele CR? >> >>> <tag k="uhul:area" v="963.997322074138"/> >> *** nezaokrouhlit na jednotky m2? Nebo vubec vyhodit? >> >>> <tag k="uhul:slt" v="Svěží jedlová bučina"/> >> *** nenechat ten tag v puvodnim cisle ciselniku UHUL. Tomuto textu >> rozumi tak nejvyse jachym. > > Ja bych to nechal v puvodnim tvaru. Mozna ze tomu rozumi nejvyse > jachym, ale poznat od sebe dva ruzny porosty uz neni nijak tezky, a > nekdy se to opravdu pouziva pro orientaci -- v mapach pro OB se > vyznacuje "rozhrani porostu". > Pavel

> Asi uz to predelavat nebudu. Nechame to, co by tam melo byt a mozna ani > neni. Pouzivat to muze kdo chce a k jakemukoliv ucelu. > Nejvetsi problem s importovanymi daty je asi s dirami v polygonech i > kdyz jsem se snazil to co mozna nejlepe vyresit. > > K >

> On 10/5/07, Jakub Sykora <kubajz na kbx.cz> wrote: >> Asi uz to predelavat nebudu. Nechame to, co by tam melo byt a mozna ani >> neni. Pouzivat to muze kdo chce a k jakemukoliv ucelu. >> Nejvetsi problem s importovanymi daty je asi s dirami v polygonech i >> kdyz jsem se snazil to co mozna nejlepe vyresit. >> >> K >> > > jak to vlastne s tim lesem dopadlo? da se nekde ten import stahnout? > je to http://kubajz.kbx.cz/junk/uhul/ finalni verze konverze? > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz

> jsem ted trochu zavalenej, takze se omlouvam, ze to jeste neni. Zjistil > jsem pak jeste trochu problem ohledne duplicit atp., takze musim > implementovat skip list. > Doufam, ze to sithnu uz do konce tohoto tydne. Na webu je ted buhvico, > ale spis nepouzitelny...

> Ahoj! > > >> jsem ted trochu zavalenej, takze se omlouvam, ze to jeste neni. Zjistil >> jsem pak jeste trochu problem ohledne duplicit atp., takze musim >> implementovat skip list. >> Doufam, ze to sithnu uz do konce tohoto tydne. Na webu je ted buhvico, >> ale spis nepouzitelny... >> > > skip list? Masiny jsou rychly, pujde to bez nej, ne? :-). > Pavel > >

> >> jsem ted trochu zavalenej, takze se omlouvam, ze to jeste neni. Zjistil > >> jsem pak jeste trochu problem ohledne duplicit atp., takze musim > >> implementovat skip list. > >> Doufam, ze to sithnu uz do konce tohoto tydne. Na webu je ted buhvico, > >> ale spis nepouzitelny... > > > > skip list? Masiny jsou rychly, pujde to bez nej, ne? :-).

> Ahoj, > > 1. ty polygony jsou celkem huste a jejich konverze zabere kolem 10ti > sekund pro kazdeho na mem stroji. > 2. jde o to, abych je dvakrat neuploadoval - to by bylo dost strasny > 3. proc to neudelat efektivneji? :)

>> 1. ty polygony jsou celkem huste a jejich konverze zabere kolem 10ti >> sekund pro kazdeho na mem stroji. >> 2. jde o to, abych je dvakrat neuploadoval - to by bylo dost strasny >> 3. proc to neudelat efektivneji? :) > > No, je to samozrejme na tobe, jen... > > 10sekund na polygon mi neprijde nijak strasnejch, stejne se to bude > uploadovat tak 10 sekund kazdej kus.. takze moje reseni by bylo pustit > pres noc vypocet, a potom pres noc upload :-).

>>> 1. ty polygony jsou celkem huste a jejich konverze zabere kolem 10ti >>> sekund pro kazdeho na mem stroji. >>> 2. jde o to, abych je dvakrat neuploadoval - to by bylo dost strasny >>> 3. proc to neudelat efektivneji? :) >> No, je to samozrejme na tobe, jen... >> >> 10sekund na polygon mi neprijde nijak strasnejch, stejne se to bude >> uploadovat tak 10 sekund kazdej kus.. takze moje reseni by bylo pustit >> pres noc vypocet, a potom pres noc upload :-). > > *** ja bych rekl, no hurry, celkem nerad bych zase odmazaval vsechny > name="_" a way o jednom nodu, ktere potkam. U lesa je minimalni > zavislost na nase bezne mapovani. > > hanoj > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz