« zpět na výpis měsíce |

[Talk-cz] LPIS import

Vlákno 20.7.2014 - 1.8.2015, počet zpráv: 36


20.7.2014 11:53:26 (#1)
gravatar

Pavel Machek

<pavel at ucw.cz>
1034 1226
Ahoj! V priloze je skript na import zemedelske pudy z LPIS. Bohuzel, tak jak to je, tak jsou data posunuta cca o 100 metru. Netusite nekdo, cim by to mohlo byt? (Na druhou stranu, asi nebude problem posunout to zpet pokud je posun tak nejak konstantni...) Mejte se, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

20.7.2014 11:53:53 (#2)
gravatar

Pavel Machek

<pavel at ucw.cz>
1034 1226
On Sun 2014-07-20 23:53:26, Pavel Machek wrote: zobrazit citaci
> Ahoj! > > V priloze je skript na import zemedelske pudy z LPIS.
A ted ten skript. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -------------- next part -------------- #!/usr/bin/python import shapefile from pyproj import * print "<?xml version='1.0' encoding='UTF-8'?>" print "<osm version='0.6' generator='pyshp'>" #p1 = Proj(init='my:2065') p1 = Proj(init='esri:102067') #p1 = Proj(init='EPSG:4326') p2 = Proj(init='EPSG:4326') sf = shapefile.Reader("PLPIS_223941_KU_KOD_631035") global field field = {} def a_field(num, name): global field i1, i2, i3, i4 = sf.fields[num] if name != i1: print 'Unexpected field name <', name field[name] = num a_field(1, 'ID_FB') a_field(3, 'NKODFB') a_field(6, 'PLATNYOD') a_field(7, 'VYMERAM') a_field(8, 'KULTURA') a_field(9, 'KULTURA_KL') a_field(10, 'KULTURAOD') a_field(11, 'EKO') a_field(21, 'VYSKA') a_field(22, 'SVAZITOST') a_field(26, 'KU_KOD') global nodeid nodeid = 0 def convert(point): lon, lat = point lon, lat = transform(p1, p2, lon, lat) return lon, lat def write_point(point): global nodeid lon, lat = convert(point) tags = '<tag k="created_by" v="shpupload"/>' tags += '<tag k="source" v="lpis"/>' nodeid -= 1 print '<node id="%d" lon="%f" lat="%f\">%s</node>' % ( nodeid, lon, lat, tags ) return nodeid def attr(shrec, name): return shrec.record[field[name]] for shrec in sf.shapeRecords(): shape = shrec.shape pts = [] for point in shape.points: pts += [ write_point(point) ] nodeid -= 1 print '<way id="%d">' % nodeid print ' <tag k="created_by" v="pyshp"/>' print ' <tag k="id_fb" v="%s"/>' % attr(shrec, 'ID_FB') print ' <tag k="source" v="lpis"/>' kul = attr(shrec, 'KULTURA') if kul == 2: print ' <tag k="landuse" v="farmland"/>' elif kul == 3: print ' <tag k="landuse" v="hop_field"/>' elif kul == 30: print ' <tag k="landuse" v="hop_field"/>' elif kul == 31: print ' <tag k="landuse" v="hop_field"/><tag k="crop" v="hop"/>' elif kul == 41: print ' <tag k="landuse" v="vineyard"/><tag k="barrier" v="fence"/>' elif kul == 61: print ' <tag k="landuse" v="orchard"/><tag k="barrier" v="fence"/>' elif kul == 62: print ' <tag k="landuse" v="orchard"/>' elif kul == 7: print ' <tag k="landuse" v="meadow"/>' elif kul == 71: print ' <tag k="landuse" v="meadow"/><tag k="barrier" v="fence"/>' elif kul == 72: print ' <tag k="landuse" v="meadow"/>' elif kul == 91: print ' <tag k="landuse" v="forest"/><tag k="barrier" v="fence"/>' elif kul == 92: print ' <tag k="landuse" v="farm"/><tag k="crop" v="vegetables"/>' elif kul == 97: print ' <tag k="landuse" v="reservoir"/>' elif kul == 98: print ' <tag k="landuse" v="forest"/><tag k="note" v="rychle rostouci dreviny"/>' elif kul == 99: print ' <tag k="landuse" v="forest"/>' else: print ' <tag k="landuse" v="unknown_farmland_%d"/>' % kul for pt in pts: print ' <nd ref="%d"/>' % pt print '</way>' print '</osm>'

21.7.2014 12:33:50 (#3)
gravatar

Petr Vejsada

<osm at propsychology.cz>
507
Ahoj, Dne Ne 20. ?ervence 2014 23:53:53, Pavel Machek napsal(a): zobrazit citaci
> A ted ten skript.
:-), norm?lka ;). Landuse je opravdu hodn? pot?eba. V?dycky tak trochu "z?vid?m" karvi??k?m tu jejich barevnou mapu. P?em??lel jsem o mo?nosti vyu??t parcely z RUIAN. Tam je nejen zem?d?lsk? p?da, ale i leccos ostatn?ho - zastav?n? plocha, silnice, d?lnice a co j? v?m, co je?t?. Zem?d?lsk? p?da tam ur?it? nen? tak podrobn? jako v eagri/lpis. M?? p?edstavu, nakolik jsou ?daje trvanliv?, t.j. zda p???t? rok je?t? budou platit? Jak aktualizovat? Jak to spojit s jin?m landuse, neb nejen zem?d?lskou p?dou povrch na?? mati?ky pokryt jest. Dle pr?v? proveden?ho v?po?tu m? v RUIAN digit?ln? mapu 64 procent ?zem? republiky, tak?e sice dobr?, ale ne dost. Ur?it? najdeme spoustu m?st, kde podle RUIAN je s?dli?t? a podle EAGRI louka ?i pole (po zku?enostech s importem adres ;-)). Nakolik budeme kter? data br?t jako referen?n? ?i jak se rozhodneme, co p?evezmeme. Mo?n? existuj? i dal?? zdroje pro landuse.? Co budeme d?lat se st?vaj?c?mi polygony landuse. D?lat d?ry v polygonech z EAGRI? Ot?zek bude jist? mnoho a mnoho, d?kuji, ?e jsi toto t?ma rozst?elil. Opravdu se t???m na barevnou mapu! -- Petr

21.7.2014 01:00:19 (#4)
gravatar

Pavel Machek

<pavel at ucw.cz>
1034 1226
Ahoj! zobrazit citaci
> > A ted ten skript.
Tak dobra zprava, ten web to umi dat we wgs-84. Spatna je, ze to posila mailem, dle cisla katastralniho uzemi. Aha, a ty cisla katastralnich uzemi jde dokonce vykoukat z osm, jako ref u boundary=administrative, admin_level=10. Bohuzel jsou to maly uzemi. zobrazit citaci
> :-), norm?lka ;). Landuse je opravdu hodn? pot?eba. V?dycky tak trochu > "z?vid?m" karvi??k?m tu jejich barevnou mapu. P?em??lel jsem o mo?nosti vyu??t > parcely z RUIAN. Tam je nejen zem?d?lsk? p?da, ale i leccos ostatn?ho - > zastav?n? plocha, silnice, d?lnice a co j? v?m, co je?t?. Zem?d?lsk? p?da tam > ur?it? nen? tak podrobn? jako v eagri/lpis.
zobrazit citaci
> M?? p?edstavu, nakolik jsou ?daje trvanliv?, t.j. zda p???t? rok je?t? budou > platit? Jak aktualizovat? Jak to spojit s jin?m landuse, neb nejen zem?d?lskou > p?dou povrch na?? mati?ky pokryt jest.
Maji tam klic podle kteryho to pujde aktualizovat, a normalne zemedelska puda relativne trvanliva je. Spojit s jinym landusem -- spis radej ne, ne? Maji to docela podrobny, tj pole zacina na kraji cesty. zobrazit citaci
> Dle pr?v? proveden?ho v?po?tu m? v RUIAN digit?ln? mapu 64 procent ?zem? > republiky, tak?e sice dobr?, ale ne dost. > > Ur?it? najdeme spoustu m?st, kde podle RUIAN je s?dli?t? a podle EAGRI louka > ?i pole (po zku?enostech s importem adres ;-)).
No, tohle bude krasne videt na bingu :-). zobrazit citaci
> Nakolik budeme kter? data br?t jako referen?n? ?i jak se rozhodneme, co > p?evezmeme. Mo?n? existuj? i dal?? zdroje pro landuse.? > > Co budeme d?lat se st?vaj?c?mi polygony landuse. D?lat d?ry v polygonech z > EAGRI?
No, asi zalezi co bude lepsi. V oblastech, co jsem mapoval ja, je LPIS lepsi nez rucni trasovani z ortofota... Takze pekne vymazat a nahrat znova. A ted.. umel by nekdo automaticky z mbox souboru s mailama vytahnout zip-ovy prilohy? Pavel (Aktualni verse importeru v priloze). -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -------------- next part -------------- #!/usr/bin/python # http://www.lpis.cz/index.html # Mapa: # http://eagri.cz/public/app/lpisext/lpis/verejny/ # Vyzadat data na: # http://eagri.cz/public/app/lpisext/lpis/verejny/exportDat.html # Vyzadat: Pudni bloky # Souradny systrem: wgs-84 # Aha, a ty cisla katastralnich uzemi jde dokonce vykoukat z osm, jako ref u boundary=administrative, admin_level=10 # A... nefunguje jim dobre captcha, takze jde stahnout vic uzemi jednim formularem. # doubek: 631035 # babice: 600601 # for A in *.zip; do unzip $A; done import sys import shapefile from pyproj import * print "<?xml version='1.0' encoding='UTF-8'?>" print "<osm version='0.6' generator='pyshp'>" #p1 = Proj(init='esri:102067') p1 = Proj(init='EPSG:4326') p2 = Proj(init='EPSG:4326') sf = shapefile.Reader(sys.argv[1]) global field field = {} def a_field(num, name): global field i1, i2, i3, i4 = sf.fields[num] if name != i1: print 'Unexpected field name <', name field[name] = num a_field(1, 'ID_FB') a_field(3, 'NKODFB') a_field(6, 'PLATNYOD') a_field(7, 'VYMERAM') a_field(8, 'KULTURA') a_field(9, 'KULTURA_KL') a_field(10, 'KULTURAOD') a_field(11, 'EKO') a_field(21, 'VYSKA') a_field(22, 'SVAZITOST') a_field(26, 'KU_KOD') global nodeid nodeid = 0 def convert(point): lon, lat = point lon, lat = transform(p1, p2, lon, lat) #lat += 50.013082018919185-50.013834 #lon += 14.748617781670555-14.749757 return lon, lat def write_point(point): global nodeid lon, lat = convert(point) tags = '<tag k="created_by" v="shpupload"/>' tags += '<tag k="source" v="lpis"/>' nodeid -= 1 print '<node id="%d" lon="%f" lat="%f\">%s</node>' % ( nodeid, lon, lat, tags ) return nodeid def attr(shrec, name): return shrec.record[field[name]] for shrec in sf.shapeRecords(): shape = shrec.shape pts = [] for point in shape.points: pts += [ write_point(point) ] nodeid -= 1 print '<way id="%d">' % nodeid print ' <tag k="created_by" v="pyshp"/>' print ' <tag k="id_fb" v="%s"/>' % attr(shrec, 'ID_FB') print ' <tag k="source" v="lpis"/>' print ' <tag k="lpis:kultura" v="%d"/>' % attr(shrec, 'KULTURA') kul = attr(shrec, 'KULTURA') if kul == 2: print ' <tag k="landuse" v="farmland"/>' elif kul == 3: print ' <tag k="landuse" v="hop_field"/>' elif kul == 30: print ' <tag k="landuse" v="hop_field"/>' elif kul == 31: print ' <tag k="landuse" v="hop_field"/><tag k="crop" v="hop"/>' elif kul == 41: print ' <tag k="landuse" v="vineyard"/><tag k="barrier" v="fence"/>' elif kul == 61: print ' <tag k="landuse" v="orchard"/><tag k="barrier" v="fence"/>' elif kul == 62: print ' <tag k="landuse" v="orchard"/>' elif kul == 7: print ' <tag k="landuse" v="meadow"/><tag k="meadow" v="agricultural"/>' elif kul == 71: print ' <tag k="landuse" v="meadow"/><tag k="meadow" v="agricultural"/><tag k="barrier" v="fence"/>' elif kul == 72: print ' <tag k="landuse" v="meadow"/><tag k="meadow" v="agricultural"/>' elif kul == 91: print ' <tag k="landuse" v="forest"/><tag k="barrier" v="fence"/>' elif kul == 92: print ' <tag k="landuse" v="farm"/><tag k="crop" v="vegetables"/>' elif kul == 97: print ' <tag k="landuse" v="reservoir"/>' elif kul == 98: print ' <tag k="landuse" v="forest"/><tag k="note" v="rychle rostouci dreviny"/>' elif kul == 99: print ' <tag k="landuse" v="forest"/>' else: print ' <tag k="landuse" v="unknown_farmland_%d"/>' % kul print ' <tag k="ele" v="%d"/>' % attr(shrec, 'VYSKA') print ' <tag k="ref" v="%s"/>' % attr(shrec, 'NKODFB') for pt in pts: print ' <nd ref="%d"/>' % pt print '</way>' print '</osm>'

21.7.2014 01:10:53 (#5)
gravatar

Pavel Machek

<pavel at ucw.cz>
1034 1226
Ahoj! zobrazit citaci
> A ted.. umel by nekdo automaticky z mbox souboru s mailama vytahnout > zip-ovy prilohy?
Dalsi vec co by se hodila.. vytahnout nejakym xapi seznam vsech ref od boundary=administrative, admin_level=10 . To se potom zadava do jejich webu... Ja bych na to asi casem prisel, ale pro dnesek bylo dost programovani... Dobrou noc, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

21.7.2014 01:23:03 (#6)
gravatar

Petr Vejsada

<osm at propsychology.cz>
507
Ahoj, Dne Po 21. ?ervence 2014 01:10:53, Pavel Machek napsal(a): zobrazit citaci
> > A ted.. umel by nekdo automaticky z mbox souboru s mailama vytahnout > > zip-ovy prilohy?
ano, ripmime, cel? roky jsem si takhle pos?lal mailem data z meteostanice na zahrad?. Na server p?i?el od meteostanice mail s p??lohou, server p?edhodil mail ripmime, ten to rozbalil a nahr?l do Postgresu. Nen? t?eba to tahat z mboxu, ale mailer (v m?m p??pad? sendmail/procmail, nesm?jte se, no) to rovnou p?edhod? ripmime a rovnou d?l, tedy zpracov?n? okam?it?. zobrazit citaci
> Dalsi vec co by se hodila.. vytahnout nejakym xapi seznam vsech ref od > > boundary=administrative, admin_level=10 . To se potom zadava do jejich > webu...
Origin?l je v RUIAN, seznam katastr?ln?ch ?zem?, je jich n?co p?es 13 tis?c. Je to tot??, co admin-level 10. Nen? probl?m. zobrazit citaci
> Dobrou noc,
Brou! -- Petr

21.7.2014 01:32:36 (#7)
gravatar

Petr Vejsada

<osm at propsychology.cz>
507
Ahoj, Dne Po 21. ?ervence 2014 01:00:19, Pavel Machek napsal(a): zobrazit citaci
> Maji tam klic podle kteryho to pujde aktualizovat, a normalne > zemedelska puda relativne trvanliva je. Spojit s jinym landusem -- > spis radej ne, ne? Maji to docela podrobny, tj pole zacina na kraji cesty.
no to asi jo, kde je pole, tam bude pole, dokud n?jak? developer neuplat? ??edn?ky a nepostav? tam mrakodrapy. Myslel jsem sp?? prom?ny p?stovan?ch plodin,ale to asi do OSM d?vat nebudeme. Prost? pole je pole a hotovo. Spojovat s jin?m landuse - no vlastn? to, co navrhuje?, t.j. jen zem?d?lskou p?du, to nen? ?patn? ?e?en?.. Na? si komplikovat ?ivot. Asi u? je opravdu ?as, abych ud?lal TMS vrstvu landuse z dat z RUIAN. Jen tak si to vizualizovat a teprve uvid?me podle obr?zk?, zda by to k n??emu mohlo b?t dobr?. zobrazit citaci
> > Ur?it? najdeme spoustu m?st, kde podle RUIAN je s?dli?t? a podle EAGRI > > louka ?i pole (po zku?enostech s importem adres ;-)). > > No, tohle bude krasne videt na bingu :-).
Zn? v?bec n?kdo zpo?d?n? Bingu? T.j. zda lze zjistit datum sn?mk?? Mo?n? je to trivi?ln?, ale te? nev?m. zobrazit citaci
> > > Nakolik budeme kter? data br?t jako referen?n? ?i jak se rozhodneme, co > > p?evezmeme. Mo?n? existuj? i dal?? zdroje pro landuse.? > > > > Co budeme d?lat se st?vaj?c?mi polygony landuse. D?lat d?ry v polygonech z > > EAGRI? > > No, asi zalezi co bude lepsi. V oblastech, co jsem mapoval ja, je LPIS > lepsi nez rucni trasovani z ortofota... Takze pekne vymazat a nahrat > znova.
No tady naraz?me na to, ?e ne v?e je zem?d?lsk? p?da. Mysl?? vymazat landuse=residential ?i industrial? Asi ne. -- Petr

21.7.2014 10:21:22 (#8)
gravatar

Michal Pustějovský

<Michal.Pustejovsky at seznam.cz>
162 2646
On 21. 7. 2014 1:32, Petr Vejsada wrote: zobrazit citaci
> Zn? v?bec n?kdo zpo?d?n? Bingu? T.j. zda lze zjistit datum sn?mk?? Mo?n? je to > trivi?ln?, ale te? nev?m.
Datumy bingu lze naj?t tady: http://mvexel.dev.openstreetmap.org/bing/ Funguje pro v?echny zoomy.

21.7.2014 02:20:11 (#9)
gravatar

Pavel Machek

<pavel at ucw.cz>
1034 1226
On Mon 2014-07-21 01:23:03, Petr Vejsada wrote: zobrazit citaci
> Ahoj, > > Dne Po 21. ?ervence 2014 01:10:53, Pavel Machek napsal(a): > > > > A ted.. umel by nekdo automaticky z mbox souboru s mailama vytahnout > > > zip-ovy prilohy? > > ano, ripmime, cel? roky jsem si takhle pos?lal mailem data z meteostanice na > zahrad?. Na server p?i?el od meteostanice mail s p??lohou, server p?edhodil > mail ripmime, ten to rozbalil a nahr?l do Postgresu. > > Nen? t?eba to tahat z mboxu, ale mailer (v m?m p??pad? sendmail/procmail, > nesm?jte se, no) to rovnou p?edhod? ripmime a rovnou d?l, tedy zpracov?n? > okam?it?.
Ono by to bylo lepsi z mailboxu abych kvuli tomu nemusel zakladat dalsi adresu... zobrazit citaci
> > boundary=administrative, admin_level=10 . To se potom zadava do jejich > > webu... > > Origin?l je v RUIAN, seznam katastr?ln?ch ?zem?, je jich n?co p?es 13 tis?c. > Je to tot??, co admin-level 10. Nen? probl?m.
Tak seznam uz mam, bude to 13000 mailu. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

21.7.2014 02:22:08 (#10)
gravatar

Pavel Machek

<pavel at ucw.cz>
1034 1226
Ahoj! zobrazit citaci
> Dne Po 21. ?ervence 2014 01:00:19, Pavel Machek napsal(a): > > > Maji tam klic podle kteryho to pujde aktualizovat, a normalne > > zemedelska puda relativne trvanliva je. Spojit s jinym landusem -- > > spis radej ne, ne? Maji to docela podrobny, tj pole zacina na kraji cesty. > > no to asi jo, kde je pole, tam bude pole, dokud n?jak? developer neuplat? > ??edn?ky a nepostav? tam mrakodrapy. Myslel jsem sp?? prom?ny p?stovan?ch > plodin,ale to asi do OSM d?vat nebudeme. Prost? pole je pole a hotovo.
V lpis ani tak velky detaily nejsou. Je tam: if kul == 2: print ' <tag k="landuse" v="farmland"/>' elif kul == 3: print ' <tag k="landuse" v="hop_field"/>' elif kul == 30: print ' <tag k="landuse" v="hop_field"/>' elif kul == 31: print ' <tag k="landuse" v="hop_field"/><tag k="crop" v="hop"/>' elif kul == 41: print ' <tag k="landuse" v="vineyard"/><tag k="barrier" v="fence"/>' elif kul == 61: print ' <tag k="landuse" v="orchard"/><tag k="barrier" v="fence"/>' elif kul == 62: print ' <tag k="landuse" v="orchard"/>' elif kul == 7: print ' <tag k="landuse" v="meadow"/><tag k="meadow" v="agricultural"/>' elif kul == 71: print ' <tag k="landuse" v="meadow"/><tag k="meadow" v="agricultural"/><tag k="barrier" v="fence"/>' elif kul == 72: print ' <tag k="landuse" v="meadow"/><tag k="meadow" v="agricultural"/>' elif kul == 91: print ' <tag k="landuse" v="forest"/><tag k="barrier" v="fence"/>' elif kul == 92: print ' <tag k="landuse" v="farm"/><tag k="crop" v="vegetables"/>' elif kul == 97: print ' <tag k="landuse" v="reservoir"/>' elif kul == 98: print ' <tag k="landuse" v="forest"/><tag k="note" v="rychle rostouci dreviny"/>' elif kul == 99: print ' <tag k="landuse" v="forest"/>' else: print ' <tag k="landuse" v="unknown_farmland_%d"/>' % kul zobrazit citaci
> Spojovat s jin?m landuse - no vlastn? to, co navrhuje?, t.j. jen zem?d?lskou > p?du, to nen? ?patn? ?e?en?.. Na? si komplikovat ?ivot.
Fajn. zobrazit citaci
> > > Nakolik budeme kter? data br?t jako referen?n? ?i jak se rozhodneme, co > > > p?evezmeme. Mo?n? existuj? i dal?? zdroje pro landuse.? > > > > > > Co budeme d?lat se st?vaj?c?mi polygony landuse. D?lat d?ry v polygonech z > > > EAGRI? > > > > No, asi zalezi co bude lepsi. V oblastech, co jsem mapoval ja, je LPIS > > lepsi nez rucni trasovani z ortofota... Takze pekne vymazat a nahrat > > znova. > > No tady naraz?me na to, ?e ne v?e je zem?d?lsk? p?da. Mysl?? vymazat > landuse=residential ?i industrial? Asi ne.
Ne-e. Spis jen vymazat kdyz se to s necim vylozene prekryva. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

21.7.2014 02:35:51 (#11)
gravatar

Dalibor Jelínek

<dalibor at dalibor.cz>
408 1253
Ahoj, zobrazit citaci
> elif kul == 98: print ' <tag k="landuse" v="forest"/><tag k="note" v="rychle > rostouci dreviny"/>'
nebude tohle spise "scrub"? Dalibor zobrazit citaci
> -----Original Message----- > From: Pavel Machek [mailto:pavel at ucw.cz] > Sent: Monday, July 21, 2014 2:22 PM > To: OpenStreetMap Czech Republic > Subject: Re: [Talk-cz] LPIS import > > Ahoj! > > > Dne Po 21. ?ervence 2014 01:00:19, Pavel Machek napsal(a): > > > > > Maji tam klic podle kteryho to pujde aktualizovat, a normalne > > > zemedelska puda relativne trvanliva je. Spojit s jinym landusem -- > > > spis radej ne, ne? Maji to docela podrobny, tj pole zacina na kraji cesty. > > > > no to asi jo, kde je pole, tam bude pole, dokud n?jak? developer > > neuplat? ??edn?ky a nepostav? tam mrakodrapy. Myslel jsem sp?? prom?ny > > p?stovan?ch plodin,ale to asi do OSM d?vat nebudeme. Prost? pole je pole > a hotovo. > > V lpis ani tak velky detaily nejsou. Je tam: > > if kul == 2: print ' <tag k="landuse" v="farmland"/>' > elif kul == 3: print ' <tag k="landuse" v="hop_field"/>' > elif kul == 30: print ' <tag k="landuse" v="hop_field"/>' > elif kul == 31: print ' <tag k="landuse" v="hop_field"/><tag k="crop" > v="hop"/>' > elif kul == 41: print ' <tag k="landuse" v="vineyard"/><tag k="barrier" > v="fence"/>' > elif kul == 61: print ' <tag k="landuse" v="orchard"/><tag k="barrier" > v="fence"/>' > elif kul == 62: print ' <tag k="landuse" v="orchard"/>' > elif kul == 7: print ' <tag k="landuse" v="meadow"/><tag k="meadow" > v="agricultural"/>' > elif kul == 71: print ' <tag k="landuse" v="meadow"/><tag k="meadow" > v="agricultural"/><tag k="barrier" v="fence"/>' > elif kul == 72: print ' <tag k="landuse" v="meadow"/><tag k="meadow" > v="agricultural"/>' > elif kul == 91: print ' <tag k="landuse" v="forest"/><tag k="barrier" > v="fence"/>' > elif kul == 92: print ' <tag k="landuse" v="farm"/><tag k="crop" > v="vegetables"/>' > elif kul == 97: print ' <tag k="landuse" v="reservoir"/>' > elif kul == 98: print ' <tag k="landuse" v="forest"/><tag k="note" v="rychle > rostouci dreviny"/>' > elif kul == 99: print ' <tag k="landuse" v="forest"/>' > else: print ' <tag k="landuse" v="unknown_farmland_%d"/>' % kul > > > > Spojovat s jin?m landuse - no vlastn? to, co navrhuje?, t.j. jen > > zem?d?lskou p?du, to nen? ?patn? ?e?en?.. Na? si komplikovat ?ivot. > > Fajn. > > > > Nakolik budeme kter? data br?t jako referen?n? ?i jak se > > > > rozhodneme, co p?evezmeme. Mo?n? existuj? i dal?? zdroje pro > landuse.? > > > > > > > > Co budeme d?lat se st?vaj?c?mi polygony landuse. D?lat d?ry v > > > > polygonech z EAGRI? > > > > > > No, asi zalezi co bude lepsi. V oblastech, co jsem mapoval ja, je > > > LPIS lepsi nez rucni trasovani z ortofota... Takze pekne vymazat a > > > nahrat znova. > > > > No tady naraz?me na to, ?e ne v?e je zem?d?lsk? p?da. Mysl?? vymazat > > landuse=residential ?i industrial? Asi ne. > > Ne-e. Spis jen vymazat kdyz se to s necim vylozene prekryva. > > 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 at openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz

21.7.2014 02:50:39 (#12)
gravatar

Dalibor Jelínek

<dalibor at dalibor.cz>
408 1253
Ahoj, jeste jedna drobnost zobrazit citaci
> elif kul == 3: print ' <tag k="landuse" v="hop_field"/>'
hop_field se vubec nepouziva. Navrhoval jsem hop_garden, ale moc nadseni jsem tim nevzbudil. Viz tady http://wiki.openstreetmap.org/wiki/Tag:landuse%3Dhop_garden Doporuceni bylo spise pouzit landuse=farmland + crop=hop nebo landuse=farmland + farm=hop_garden + crop=hop Dalibor zobrazit citaci
> -----Original Message----- > From: Pavel Machek [mailto:pavel at ucw.cz] > Sent: Monday, July 21, 2014 2:22 PM > To: OpenStreetMap Czech Republic > Subject: Re: [Talk-cz] LPIS import > > Ahoj! > > > Dne Po 21. ?ervence 2014 01:00:19, Pavel Machek napsal(a): > > > > > Maji tam klic podle kteryho to pujde aktualizovat, a normalne > > > zemedelska puda relativne trvanliva je. Spojit s jinym landusem -- > > > spis radej ne, ne? Maji to docela podrobny, tj pole zacina na kraji cesty. > > > > no to asi jo, kde je pole, tam bude pole, dokud n?jak? developer > > neuplat? ??edn?ky a nepostav? tam mrakodrapy. Myslel jsem sp?? prom?ny > > p?stovan?ch plodin,ale to asi do OSM d?vat nebudeme. Prost? pole je pole > a hotovo. > > V lpis ani tak velky detaily nejsou. Je tam: > > if kul == 2: print ' <tag k="landuse" v="farmland"/>' > elif kul == 3: print ' <tag k="landuse" v="hop_field"/>' > elif kul == 30: print ' <tag k="landuse" v="hop_field"/>' > elif kul == 31: print ' <tag k="landuse" v="hop_field"/><tag k="crop" > v="hop"/>' > elif kul == 41: print ' <tag k="landuse" v="vineyard"/><tag k="barrier" > v="fence"/>' > elif kul == 61: print ' <tag k="landuse" v="orchard"/><tag k="barrier" > v="fence"/>' > elif kul == 62: print ' <tag k="landuse" v="orchard"/>' > elif kul == 7: print ' <tag k="landuse" v="meadow"/><tag k="meadow" > v="agricultural"/>' > elif kul == 71: print ' <tag k="landuse" v="meadow"/><tag k="meadow" > v="agricultural"/><tag k="barrier" v="fence"/>' > elif kul == 72: print ' <tag k="landuse" v="meadow"/><tag k="meadow" > v="agricultural"/>' > elif kul == 91: print ' <tag k="landuse" v="forest"/><tag k="barrier" > v="fence"/>' > elif kul == 92: print ' <tag k="landuse" v="farm"/><tag k="crop" > v="vegetables"/>' > elif kul == 97: print ' <tag k="landuse" v="reservoir"/>' > elif kul == 98: print ' <tag k="landuse" v="forest"/><tag k="note" v="rychle > rostouci dreviny"/>' > elif kul == 99: print ' <tag k="landuse" v="forest"/>' > else: print ' <tag k="landuse" v="unknown_farmland_%d"/>' % kul > > > > Spojovat s jin?m landuse - no vlastn? to, co navrhuje?, t.j. jen > > zem?d?lskou p?du, to nen? ?patn? ?e?en?.. Na? si komplikovat ?ivot. > > Fajn. > > > > Nakolik budeme kter? data br?t jako referen?n? ?i jak se > > > > rozhodneme, co p?evezmeme. Mo?n? existuj? i dal?? zdroje pro > landuse.? > > > > > > > > Co budeme d?lat se st?vaj?c?mi polygony landuse. D?lat d?ry v > > > > polygonech z EAGRI? > > > > > > No, asi zalezi co bude lepsi. V oblastech, co jsem mapoval ja, je > > > LPIS lepsi nez rucni trasovani z ortofota... Takze pekne vymazat a > > > nahrat znova. > > > > No tady naraz?me na to, ?e ne v?e je zem?d?lsk? p?da. Mysl?? vymazat > > landuse=residential ?i industrial? Asi ne. > > Ne-e. Spis jen vymazat kdyz se to s necim vylozene prekryva. > > 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 at openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz

21.7.2014 03:38:34 (#13)
gravatar

Pavel Machek

<pavel at ucw.cz>
1034 1226
On Mon 2014-07-21 14:50:39, Dalibor Jel?nek wrote: zobrazit citaci
> Ahoj, > jeste jedna drobnost > > elif kul == 3: print ' <tag k="landuse" v="hop_field"/>' > hop_field se vubec nepouziva. > Navrhoval jsem hop_garden, ale moc nadseni jsem tim nevzbudil. > Viz tady > http://wiki.openstreetmap.org/wiki/Tag:landuse%3Dhop_garden > > Doporuceni bylo spise pouzit > landuse=farmland + crop=hop
Pouzil jsem tohle, a udelal jsem forest->scrub pro rychle rostouci dreviny. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

23.7.2014 07:08:02 (#14)
gravatar

Marián Kyral

<mkyral at email.cz>
2228 2371
Ahoj, kouk?m, ?e chv?li jsem mimo a tady se to mezit?m p?kn? rozjelo. Z mobilu se mi to blb? komentuje, tak zat?m jen toto: P?ed odjezdem na dovolenou jsem si trochu hr?l a za?al jsem s LPIS modulem pro tracer. Zat?m to teda um? jen poslat dotaz a parsovat odpov??. Zat?m jsem ne?e?il vytvo?en? plochy a kolize s ostatn?mi plochami. Taky je trochu probl?m, ?e WFS neobsahuje informaci zda se jedn? o louku, pole nebo n?co jin?ho. Pr? se na to pod?vaj?, nicm?n? i tak to je ?e?iteln? pou?it?m url z toho jejich mapov?ho port?lu, kde ta informace je. V souvislosti s roz???en?m traceru mne je?t? napadlo, ?e by to cht?lo p?ed?lat i zap?n?n? tracer re?imu. Moment?ln? m? ka?d? tracer re?im vlastn? kl?vesovou zkratku a t?ch je m?lo. Nov? by to bylo tak, ?e by se pou?ilo pouze "T" a p?i ka?d?m stisku "T" by se p?eplo na dal?? re?im - p?vodn? tracer, RUIAN a LPIS. V konfiguraci by se pak daly vybrat jen moduly, kter? mne zaj?maj? a zda se m? v?dy za??nat od konkr?tn?ho modulu nebo od toho posledn?ho. Jak to vid?te? M? tenhle modul v?bec smysl, kdy? se te? rozjel hromadn? import? Mo?n? by to cht?lo sp??e n?jak? n?stroje na jednodu??? ?e?en? konflikt? oblast? - ur?it p?esn?j?? plochu a k t? p?ichytit dal??, t?eba p?esahuj?c? plochu. Mari?n On 20. ?ervence 2014 23:53:26 CEST, Pavel Machek <pavel at ucw.cz> wrote: zobrazit citaci
>Ahoj! > >V priloze je skript na import zemedelske pudy z LPIS. > >Bohuzel, tak jak to je, tak jsou data posunuta cca o 100 >metru. Netusite nekdo, cim by to mohlo byt? > >(Na druhou stranu, asi nebude problem posunout to zpet pokud je posun >tak nejak konstantni...) > >Mejte se, > Pavel
-- Odesl?no z m?ho telefonu s Androidem pomoc? po?ty K-9 Mail. Omluvte pros?m moji stru?nost.

23.7.2014 12:36:53 (#15)
gravatar

Martin Švec - OSM

<osm at maatts.cz>
109
Dne 23.7.2014 7:08, Mari?n Kyral napsal(a): zobrazit citaci
> Jak to vid?te? M? tenhle modul v?bec smysl, kdy? se te? rozjel hromadn? import?
Neh?zel bych flintu do ?ita :-) Ten Pavl?v skript mi zat?m p?ijde sp?? jako u?ite?n? pom?cka pro ru?n? kreslen?. Ve slo?it?j??ch K? vyr?b? stovky error? a warning?. zobrazit citaci
> Mo?n? by to cht?lo sp??e n?jak? n?stroje na jednodu??? ?e?en? konflikt? oblast? - ur?it p?esn?j?? plochu a k t? p?ichytit dal??, t?eba p?esahuj?c? plochu.
Tohle by bylo super!! Bojuju v JOSM se z?kladn? ?lohou: "Jsou d?ny dva polygony (cesty). V prvn?m polygonu zru?/odpoj v?echny existuj?c? uzly mezi A a? B a m?sto nich se p?ilep na uzly od X po Y z druh?ho polygonu." M?te na to n?kdo n?jakou fintu/plugin? Martin

1.8.2014 09:56:00 (#16)
gravatar

Marián Kyral

<mkyral at email.cz>
2228 2371
Tak?e update: dnes mi z MZe odpov?d?li, ?e po konzultaci s CPR MZe (to nev?m co je :-) ) pole kultura p?idali. Tak?e super, nemus?m to hledat n?kde po v?ech ?ertech. V souvislosti s t?m - bylo by mo?n? doplnit tu wiki str?nku pro import ( http://wiki.openstreetmaps.org/wiki/LPIS ) a popsat tam jak? kultury se importuj? a jak se mapuj?? J? jen, abych to m?l stejn?. Trochu blb? je, ?e j? dostanu slovn? vyj?d?en? - tedy nap??klad: <ms:kultura>travn? porost</ms:kultura>, kde?to skript jede podle ID. Je n?kde dokumentace popisuj?c? form?t souboru a povolen? hodnoty? J? na?el jen toto: kultura:orn? p?da kultura:chmelnice kultura:vinice kultura:ovocn? sad kultura:travn? porost kultura:porost RRD kultura:zalesn?no kultura:rybn?k kultura:jin? kultura kultura:jin? kultura (?kolka) kultura:jin? kultura (zelin??sk? zahrada) Mari?n Dne 23.7.2014 07:08, Mari?n Kyral napsal(a): zobrazit citaci
> Ahoj, kouk?m, ?e chv?li jsem mimo a tady se to mezit?m p?kn? rozjelo. Z mobilu se mi to blb? komentuje, tak zat?m jen toto: > > P?ed odjezdem na dovolenou jsem si trochu hr?l a za?al jsem s LPIS modulem pro tracer. Zat?m to teda um? jen poslat dotaz a parsovat odpov??. Zat?m jsem ne?e?il vytvo?en? plochy a kolize s ostatn?mi plochami. Taky je trochu probl?m, ?e WFS neobsahuje informaci zda se jedn? o louku, pole nebo n?co jin?ho. Pr? se na to pod?vaj?, nicm?n? i tak to je ?e?iteln? pou?it?m url z toho jejich mapov?ho port?lu, kde ta informace je. > > V souvislosti s roz???en?m traceru mne je?t? napadlo, ?e by to cht?lo p?ed?lat i zap?n?n? tracer re?imu. Moment?ln? m? ka?d? tracer re?im vlastn? kl?vesovou zkratku a t?ch je m?lo. > > Nov? by to bylo tak, ?e by se pou?ilo pouze "T" a p?i ka?d?m stisku "T" by se p?eplo na dal?? re?im - p?vodn? tracer, RUIAN a LPIS. V konfiguraci by se pak daly vybrat jen moduly, kter? mne zaj?maj? a zda se m? v?dy za??nat od konkr?tn?ho modulu nebo od toho posledn?ho. > > Jak to vid?te? M? tenhle modul v?bec smysl, kdy? se te? rozjel hromadn? import? Mo?n? by to cht?lo sp??e n?jak? n?stroje na jednodu??? ?e?en? konflikt? oblast? - ur?it p?esn?j?? plochu a k t? p?ichytit dal??, t?eba p?esahuj?c? plochu. > > Mari?n > > > > On 20. ?ervence 2014 23:53:26 CEST, Pavel Machek <pavel at ucw.cz> wrote: >> Ahoj! >> >> V priloze je skript na import zemedelske pudy z LPIS. >> >> Bohuzel, tak jak to je, tak jsou data posunuta cca o 100 >> metru. Netusite nekdo, cim by to mohlo byt? >> >> (Na druhou stranu, asi nebude problem posunout to zpet pokud je posun >> tak nejak konstantni...) >> >> Mejte se, >> Pavel
------------- dal?? ??st --------------- HTML p??loha byla odstran?na... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20140801/e6af4d2d/attachment.html>

3.8.2014 09:52:52 (#17)
gravatar

Pavel Machek

<pavel at ucw.cz>
1034 1226
Ahoj! zobrazit citaci
> dnes mi z MZe odpov?d?li, ?e po konzultaci s CPR MZe (to nev?m co je :-) > ) pole kultura p?idali. Tak?e super, nemus?m to hledat n?kde po v?ech > ?ertech. > V souvislosti s t?m - bylo by mo?n? doplnit tu wiki str?nku pro import ( > http://wiki.openstreetmaps.org/wiki/LPIS ) a popsat tam jak? kultury > se
Casem pridam, zatim je v priloze konverzni skript. zobrazit citaci
> importuj? a jak se mapuj?? J? jen, abych to m?l stejn?. Trochu blb? je, > ?e j? dostanu slovn? vyj?d?en? - tedy nap??klad: <ms:kultura>travn? > porost</ms:kultura>, kde?to skript jede podle ID. > Je n?kde dokumentace popisuj?c? form?t souboru a povolen? hodnoty?
Je, s kazdym stazenym blokem se stahne i .doc soubor. je v priloze. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -------------- next part -------------- A non-text attachment was scrubbed... Name: trn-lpis.py Type: text/x-python Size: 1583 bytes Desc: not available URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20140803/e49fc9ee/attachment-0001.py> -------------- next part -------------- A non-text attachment was scrubbed... Name: CiselnikyXLPIS.doc Type: application/msword Size: 141312 bytes Desc: not available URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20140803/e49fc9ee/attachment-0001.doc>

3.8.2014 08:53:47 (#18)
gravatar

Marián Kyral

<mkyral at email.cz>
2228 2371
Dne 3.8.2014 09:52, Pavel Machek napsal(a): zobrazit citaci
> Ahoj! > >> dnes mi z MZe odpov?d?li, ?e po konzultaci s CPR MZe (to nev?m co je :-) >> ) pole kultura p?idali. Tak?e super, nemus?m to hledat n?kde po v?ech >> ?ertech. >> V souvislosti s t?m - bylo by mo?n? doplnit tu wiki str?nku pro import ( >> http://wiki.openstreetmaps.org/wiki/LPIS ) a popsat tam jak? kultury >> se > Casem pridam, zatim je v priloze konverzni skript. > >> importuj? a jak se mapuj?? J? jen, abych to m?l stejn?. Trochu blb? je, >> ?e j? dostanu slovn? vyj?d?en? - tedy nap??klad: <ms:kultura>travn? >> porost</ms:kultura>, kde?to skript jede podle ID. >> Je n?kde dokumentace popisuj?c? form?t souboru a povolen? hodnoty? > Je, s kazdym stazenym blokem se stahne i .doc soubor. je v priloze. > >
Super d?ky. ?koda, ?e k WFS nic takov?ho nen?. Mari?n

4.8.2014 06:30:56 (#19)
gravatar

Marián Kyral

<mkyral at email.cz>
2228 2371
Dne 3.8.2014 09:52, Pavel Machek napsal(a): zobrazit citaci
> Ahoj! > >> dnes mi z MZe odpove(de(li, z(e po konzultaci s CPR MZe (to nev?m co je :-) >> ) pole kultura pr(idali. Takz(e super, nemus?m to hledat ne(kde po vs(ech >> c(ertech. >> V souvislosti s t?m - bylo by moz(n? doplnit tu wiki str?nku pro import ( >> http://wiki.openstreetmaps.org/wiki/LPIS ) a popsat tam jak? kultury >> se > Casem pridam, zatim je v priloze konverzni skript.
Tak to ted( pr(ede(l?v?m a tohle se mi furt nel?b?: *note="rychle rostouci dreviny"* Co tr(eba: *crop=fast_growing_wood* Mari?n ------------- dal?? ??st --------------- HTML p??loha byla odstran?na... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20140804/acb31b01/attachment.html>

4.8.2014 06:38:05 (#20)
gravatar

Marián Kyral

<mkyral at email.cz>
2228 2371
Dne 4.8.2014 18:30, Mari?n Kyral napsal(a): zobrazit citaci
> Dne 3.8.2014 09:52, Pavel Machek napsal(a): >> Ahoj! >> >>> dnes mi z MZe odpove(de(li, z(e po konzultaci s CPR MZe (to nev?m co je :-) >>> ) pole kultura pr(idali. Takz(e super, nemus?m to hledat ne(kde po vs(ech >>> c(ertech. >>> V souvislosti s t?m - bylo by moz(n? doplnit tu wiki str?nku pro import ( >>> http://wiki.openstreetmaps.org/wiki/LPIS ) a popsat tam jak? kultury >>> se >> Casem pridam, zatim je v priloze konverzni skript. > > Tak to ted( pr(ede(l?v?m a tohle se mi furt nel?b?: *note="rychle > rostouci dreviny"* > Co tr(eba: *crop=fast_growing_wood*
A jes(te( k *landuse=reservoir* Dle http://wiki.openstreetmap.org/wiki/Cs:Map_Features /V C(R byly takto oznac(eny i rybn?ky. Nove( doporuc(ovan? znac(en? rybn?ka je //natural <http://wiki.openstreetmap.org/wiki/Cs:Key:natural>=water <http://wiki.openstreetmap.org/wiki/Tag:natural%3Dwater>//+ //water <http://wiki.openstreetmap.org/wiki/Key:water>=pond <http://wiki.openstreetmap.org/wiki/Tag:water%3Dpond>//. / Mari?n zobrazit citaci
> Mari?n > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz
------------- dal?? ??st --------------- HTML p??loha byla odstran?na... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20140804/28a7c50d/attachment.html>

8.8.2014 09:22:59 (#21)
gravatar

Petr Souček

<soucekp at atlas.cz>
69
Dobr? den, zobrazit citaci
> Dle pr?v? proveden?ho v?po?tu m? v RUIAN digit?ln? mapu 64 procent > ?zem? republiky, tak?e sice dobr?, ale ne dost.
... aktu?ln? procento digit?ln? mapy v R?IAN je stejn? jako pokryt? INSPIRE t?matu CP (katastr?ln? mapa), tj. 69,86% a to m??ete sledovat v metadatech na Geoport?lu ??ZK, viz http://geoportal.cuzk.cz/%28S%283sujbqj40uy1nobcdnbdvroc%29%29/Default.aspx?mode=TextMeta&side=INSPIRE_dSady&metadataID=CZ-CUZK-CP&metadataXSL=INSPIRE_Kat_par&head_tab=sekce-04-gp&menu=416 (aktualizace prob?h? 1x t?dn?) Pokud jste se n?kde do?etli o ?daji, ?e digit?ln? mapu m?me na v?ce ne? 80% ?zem? ?R, tak tento rozd?l je zp?soben t?m, ?e v R?IAN (ani INSPIRE) nejsou polygony z ?zem?, kde je vedena mapa ve form? KM-D, katastr?ln? mapa digitalizovan?. Jsou to ?zem? zobrazen? zelenou barvou, viz nap?. ?zem? kolem Prachatic, http://katastralnimapy-new.cuzk.cz/?MarUid=2B3157D2%2057834AB5%20F6D3536A%20BED2F8A9&MarUidi=BED2F8A9&MarMiddlePoint=-800577.0981408213%20-1161150.6512377018&MarScale=360628 Petr Sou?ek

8.8.2014 09:40:20 (#22)
gravatar

Petr Souček

<soucekp at atlas.cz>
69
Dobr? den, jen bych cht?l poznamenat, ?e ?daje o druhu pozemku a zp?sobu vyu?it? pozemku se do R?IAN p?en??? z Katastru nemovitost?. V katastru nemovitost? je evidov?n pr?vn? stav a stav takov?, kter? n?m vlastn?ci ohl?s? (a dolo?? p??slu?nou listinu). Z toho asi tu??te, ?e ne v?echno bude evidov?no spr?vn?. Pokud n?komu zaroste louka (a na ortofotu je evidentn? hust? les) a vlastn?k tuto zm?nu nenahl?s?, tak v KN bude d?le louka. M?j soukrom? odhad je cca 10-15% chybn? evidovan?ch druh? pozemk? ... Petr Sou?ek
-----Original Message----- From: Petr Vejsada [mailto:osm at propsychology.cz] Sent: Monday, July 21, 2014 12:34 AM To: OpenStreetMap Czech Republic Subject: Re: [Talk-cz] LPIS import Ahoj, Dne Ne 20. ?ervence 2014 23:53:53, Pavel Machek napsal(a): zobrazit citaci
> A ted ten skript.
:-), norm?lka ;). Landuse je opravdu hodn? pot?eba. V?dycky tak trochu "z?vid?m" karvi??k?m tu jejich barevnou mapu. P?em??lel jsem o mo?nosti vyu??t parcely z RUIAN. Tam je nejen zem?d?lsk? p?da, ale i leccos ostatn?ho - zastav?n? plocha, silnice, d?lnice a co j? v?m, co je?t?. Zem?d?lsk? p?da tam ur?it? nen? tak podrobn? jako v eagri/lpis. M?? p?edstavu, nakolik jsou ?daje trvanliv?, t.j. zda p???t? rok je?t? budou platit? Jak aktualizovat? Jak to spojit s jin?m landuse, neb nejen zem?d?lskou p?dou povrch na?? mati?ky pokryt jest. Dle pr?v? proveden?ho v?po?tu m? v RUIAN digit?ln? mapu 64 procent ?zem? republiky, tak?e sice dobr?, ale ne dost. Ur?it? najdeme spoustu m?st, kde podle RUIAN je s?dli?t? a podle EAGRI louka ?i pole (po zku?enostech s importem adres ;-)). Nakolik budeme kter? data br?t jako referen?n? ?i jak se rozhodneme, co p?evezmeme. Mo?n? existuj? i dal?? zdroje pro landuse.? Co budeme d?lat se st?vaj?c?mi polygony landuse. D?lat d?ry v polygonech z EAGRI? Ot?zek bude jist? mnoho a mnoho, d?kuji, ?e jsi toto t?ma rozst?elil. Opravdu se t???m na barevnou mapu! -- Petr

13.6.2015 07:12:59 (#23)
gravatar

Pavel Kwiecien

<pavel.kwiecien at seznam.cz>
48 4954
Ahoj, při pohledu na mapu jsem již nenašel žádné rozsáhlé místo, kde by by nebyly LPIS data nebo předešlá pole. Jednotlivosti se určitě najdou, ale zdá se, že import LPIS dat je téměř kompletní. Nyní tedy bude potřeba aktualizovat a upravovat LPIS data a případně nahrazovat předchozí pole LPIS daty. Zdraví Pavel Kwiecien ------------- další část --------------- HTML příloha byla odstraněna... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20150613/1cb09aa9/attachment.html>

14.6.2015 10:51:17 (#24)
gravatar

Pavel Machek

<pavel at ucw.cz>
1034 1226
Ahoj! zobrazit citaci
> Ahoj, při pohledu na mapu jsem již nenašel žádné rozsáhlé místo, kde by by > nebyly LPIS data nebo předešlá pole. Jednotlivosti se určitě najdou, ale zdá > se, že import LPIS dat je téměř kompletní. Nyní tedy bude potřeba > aktualizovat a upravovat LPIS data a případně nahrazovat předchozí pole LPIS > daty.
Gratulace! :-). Uvazuju... nedavalo by smysl udelat znovu import lesu z UHULu? Provedla se tam prilisna generalizace, takze lesy jsou fakt divne, a ztratili jsme informace o rozhranich porostu a listnate/jehlicnate... Na rozhranich mezi lesem a loukama je ta nepresnost hodne videt... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

15.6.2015 01:58:26 (#25)
gravatar

jzvc

<jzvc at tpfree.net>
527
Dne 14.6.2015 v 22:51 Pavel Machek napsal(a): zobrazit citaci
> Ahoj! > >> Ahoj, při pohledu na mapu jsem již nenašel žádné rozsáhlé místo, kde by by >> nebyly LPIS data nebo předešlá pole. Jednotlivosti se určitě najdou, ale zdá >> se, že import LPIS dat je téměř kompletní. Nyní tedy bude potřeba >> aktualizovat a upravovat LPIS data a případně nahrazovat předchozí pole LPIS >> daty. > > Gratulace! :-). > > Uvazuju... nedavalo by smysl udelat znovu import lesu z UHULu? > Provedla se tam prilisna generalizace, takze lesy jsou fakt divne, a > ztratili jsme informace o rozhranich porostu a > listnate/jehlicnate... Na rozhranich mezi lesem a loukama je ta > nepresnost hodne videt... > > Pavel >
Cus, a nebylo by lepsi to zaradit podobne jako lpis do traceru? Pokud lesy totiz smaznes a reimportujes tak zaroven zlikvidujes spoustu rucni prace. Jinak nevim jak moc presny ty lesy jsou ted, ale to co se naimportovalo je teda hodne +- autobus sem nebo tam ... Totez ostatne plati i pro importovany vodni toky - zrovna nedavno sem narazil i na rekach, kde bych cekal jakou takous vernost, jsou koryta tam, kde byla mozna pred 30ti lety. U ruznych potucku si pak nedelam iluze vubec zadny.

15.6.2015 02:52:13 (#26)
gravatar

Pavel Machek

<pavel at ucw.cz>
1034 1226
On Mon 2015-06-15 13:58:26, jzvc wrote: zobrazit citaci
> Dne 14.6.2015 v 22:51 Pavel Machek napsal(a): > >Ahoj! > > > >>Ahoj, při pohledu na mapu jsem již nenašel žádné rozsáhlé místo, kde by by > >>nebyly LPIS data nebo předešlá pole. Jednotlivosti se určitě najdou, ale zdá > >>se, že import LPIS dat je téměř kompletní. Nyní tedy bude potřeba > >>aktualizovat a upravovat LPIS data a případně nahrazovat předchozí pole LPIS > >>daty. > > > >Gratulace! :-). > > > >Uvazuju... nedavalo by smysl udelat znovu import lesu z UHULu? > >Provedla se tam prilisna generalizace, takze lesy jsou fakt divne, a > >ztratili jsme informace o rozhranich porostu a > >listnate/jehlicnate... Na rozhranich mezi lesem a loukama je ta > >nepresnost hodne videt... > > Cus, a nebylo by lepsi to zaradit podobne jako lpis do traceru? Pokud lesy > totiz smaznes a reimportujes tak zaroven zlikvidujes spoustu rucni > prace.
No, myslim ze i smazat a reimportovat by bylo zlepseni proti soucasnymu stavu, ale zarazeni do tracerou by asi byla schudnejsi cesta. zobrazit citaci
> Jinak nevim jak moc presny ty lesy jsou ted, ale to co se naimportovalo je > teda hodne +- autobus sem nebo tam ... Totez ostatne plati i pro > importovany
My jsme bohuzel ty data dost ponicili generalizaci (mozna to byla vzhledem k datu importu nutnost). Ten LPIS ma moc pekny data, doufam, ze by to mohlo byt tak nejak podobny. zobrazit citaci
> vodni toky - zrovna nedavno sem narazil i na rekach, kde bych cekal jakou > takous vernost, jsou koryta tam, kde byla mozna pred 30ti lety. U ruznych > potucku si pak nedelam iluze vubec zadny.
No, ona GPSka nema v lese taky kdovijakou presnost ;-). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

15.6.2015 02:57:59 (#27)
gravatar

Martin Švec - OSM

<osm at maatts.cz>
109
Dne 15.6.2015 v 13:58 jzvc napsal(a): zobrazit citaci
> Dne 14.6.2015 v 22:51 Pavel Machek napsal(a): >> Ahoj! >> >>> Ahoj, při pohledu na mapu jsem již nenašel žádné rozsáhlé místo, kde by by >>> nebyly LPIS data nebo předešlá pole. Jednotlivosti se určitě najdou, ale zdá >>> se, že import LPIS dat je téměř kompletní. Nyní tedy bude potřeba >>> aktualizovat a upravovat LPIS data a případně nahrazovat předchozí pole LPIS >>> daty. >> >> Gratulace! :-). >> >> Uvazuju... nedavalo by smysl udelat znovu import lesu z UHULu? >> Provedla se tam prilisna generalizace, takze lesy jsou fakt divne, a >> ztratili jsme informace o rozhranich porostu a >> listnate/jehlicnate... Na rozhranich mezi lesem a loukama je ta >> nepresnost hodne videt... >> >> Pavel >> > > Cus, a nebylo by lepsi to zaradit podobne jako lpis do traceru? Pokud lesy totiz smaznes a > reimportujes tak zaroven zlikvidujes spoustu rucni prace. > > Jinak nevim jak moc presny ty lesy jsou ted, ale to co se naimportovalo je teda hodne +- autobus > sem nebo tam ... Totez ostatne plati i pro importovany vodni toky - zrovna nedavno sem narazil i > na rekach, kde bych cekal jakou takous vernost, jsou koryta tam, kde byla mozna pred 30ti lety. U > ruznych potucku si pak nedelam iluze vubec zadny. >
Před pár dny jsem se pro zajímavost díval na WMS vrstvy z http://geoportal.uhul.cz, kvalita geometrie lesů mi nepřišla o moc lepší než co máme v OSM (nebo jsem nenašel tu správnou vrstvu). Technická realizace by byla pořádný sousto i pro tracer, s tím množstvím ručních zásahů co se do lesů už provedly. Martin

15.6.2015 03:48:34 (#28)
gravatar

Michal Pustějovský

<Michal.Pustejovsky at seznam.cz>
162 2646
Já bych s tím importem byl opatrný, dle mého názoru by se hodila spíše nějaká poloautomatické oprava s využitím přesných dat z lpisu (např. metodou dilatace). Na druhou stranu, ono by se i v již opravených lesích hodilo "klikátko", které by dokázalo doplnit další informace (leaf_type, leaf_cycle), pokud v UHULu jsou. Michal
---------- Původní zpráva ---------- Od: Martin Švec - OSM <osm at maatts.cz> Komu: OpenStreetMap Czech Republic <talk-cz at openstreetmap.org> Datum: 15. 6. 2015 14:59:25 Předmět: Re: [Talk-cz] Lesy (was Re: LPIS import) "Dne 15.6.2015 v 13:58 jzvc napsal(a): zobrazit citaci
> Dne 14.6.2015 v 22:51 Pavel Machek napsal(a): >> Ahoj! >> >>> Ahoj, při pohledu na mapu jsem již nenašel žádné rozsáhlé místo, kde by
by zobrazit citaci
>>> nebyly LPIS data nebo předešlá pole. Jednotlivosti se určitě najdou, ale
zdá zobrazit citaci
>>> se, že import LPIS dat je téměř kompletní. Nyní tedy bude potřeba >>> aktualizovat a upravovat LPIS data a případně nahrazovat předchozí pole
LPIS zobrazit citaci
>>> daty. >> >> Gratulace! :-). >> >> Uvazuju... nedavalo by smysl udelat znovu import lesu z UHULu? >> Provedla se tam prilisna generalizace, takze lesy jsou fakt divne, a >> ztratili jsme informace o rozhranich porostu a >> listnate/jehlicnate... Na rozhranich mezi lesem a loukama je ta >> nepresnost hodne videt... >> >> Pavel >> > > Cus, a nebylo by lepsi to zaradit podobne jako lpis do traceru? Pokud lesy
totiz smaznes a zobrazit citaci
> reimportujes tak zaroven zlikvidujes spoustu rucni prace. > > Jinak nevim jak moc presny ty lesy jsou ted, ale to co se naimportovalo je
teda hodne +- autobus zobrazit citaci
> sem nebo tam ... Totez ostatne plati i pro importovany vodni toky - zrovna
nedavno sem narazil i zobrazit citaci
> na rekach, kde bych cekal jakou takous vernost, jsou koryta tam, kde byla
mozna pred 30ti lety. U zobrazit citaci
> ruznych potucku si pak nedelam iluze vubec zadny. >
Před pár dny jsem se pro zajímavost díval na WMS vrstvy z http://geoportal. uhul.cz, kvalita geometrie lesů mi nepřišla o moc lepší než co máme v OSM (nebo jsem nenašel tu správnou vrstvu). Technická realizace by byla pořádný sousto i pro tracer, s tím množstvím ručních zásahů co se do lesů už provedly. Martin _______________________________________________ Talk-cz mailing list Talk-cz at openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz" -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20150615/4202fa5d/attachment.html>

15.6.2015 05:56:09 (#29)
gravatar

xkomczax at centrum.cz

<xkomczax at centrum.cz>
188 2126
Super a všem zúčastněným velké díky! :-) Co se úvah o dalších importech týká, rád bych opět navrhl re-import chráněných území. Mnohá totiž za ta léta přibyla, některá změnila své hranice, jiná zanikla (u nich bych prosil nechat v OSM databázi a pouze je "zneviditelnit" přidáním předpony abandon) a u dalších byly neopatrnými úpravami poškozeny jejich hranice (viz CHKO Šumava). xkomczax ______________________________________________________________ zobrazit citaci
> Od: "Pavel Kwiecien" <pavel.kwiecien at seznam.cz> > Komu: <talk-cz at openstreetmap.org> > Datum: 13.06.2015 19:14 > Předmět: [Talk-cz] LPIS import > >Ahoj, při pohledu na mapu jsem již nenašel žádné rozsáhlé místo, kde by by >nebyly LPIS data nebo předešlá pole. Jednotlivosti se určitě najdou, ale zdá >se, že import LPIS dat je téměř kompletní. Nyní tedy bude potřeba >aktualizovat a upravovat LPIS data a případně nahrazovat předchozí pole LPIS >daty. > >Zdraví Pavel Kwiecien >= > >---------- > >_______________________________________________ >Talk-cz mailing list >Talk-cz at openstreetmap.org >https://lists.openstreetmap.org/listinfo/talk-cz >

31.7.2015 12:30:41 (#30)
gravatar

Jakub Těšínský

<osm at kub.cz>
72
Gratuluji vsem kdo se na importu podileli. Pri mapovani polnacek a turistickych znacek mi LIPS data hodne pomahaji v tom, ze je krasne videt kudz potencialne muze vest cesta. Na druhou stranu jsem na sobe uz pocitil urcite psychologicke negativum tohoto importu. Myslim ze je to vanilla verzu urciteho smiseneho efektu importu TIger dat v USA (viz napriklad zde http://flrec.ifas.ufl.edu/geomatics/wp-content/uploads/2012/02/tgis12037.pdf). Jde o to, ze automatizovany import muze demotivovat lidke mappery v zlepsovani dat. Zcela konkretne: Kouknu na proslou trasu na vylete a zda se mi ze nejaka pole jsou trochu blbe. Pole ale u sebe maji nejaky LPSI id cilso, cele to vypada desne "oficialne" a "spravne" atd, a vlastne ani nevim co presne ta cisla znamenaji, abych pri aktualizaci poli neudelal vic skody nez uzitku ... bla, bla, bla, proste to radsi nechm byt na pokoji. Takze jasny dotaz na ty kdo import provadeli (jeste jednou gratuluji). Maji se editovat tvary poli? Pokud pole nebou louku zedituju, mam zachoval lips id? Cokdyz spojim dve pole (vedla tam kdysi cesta uz nevede), jake to pak ma cislo? Moc bych se primlouval za to aby tyhle jasne pokyny visely na wiki, aby to kazdy moh doledat. Zadne douhe teoretizovani, jasny pokyn pro blbce stylu - "lips cisla jsou skoro k nicemu, muzete je mazat" nebo "naimportovana pole klidne editujte, je to jen vychozi stav" nebo "kazde 2 roky budeme delat reimport za techto a techto podminek". Dekuju J. -- Jakub Těšínský Mapping OSM since 2007

31.7.2015 07:25:35 (#31)
gravatar

Marián Kyral

<mkyral at email.cz>
2228 2371
Dne 31.7.2015 v 00:30 Jakub Těšínský napsal(a): zobrazit citaci
> Gratuluji vsem kdo se na importu podileli. Pri mapovani polnacek a > turistickych znacek mi LIPS data hodne pomahaji v tom, ze je krasne > videt kudz potencialne muze vest cesta. Na druhou stranu jsem na sobe > uz pocitil urcite psychologicke negativum tohoto importu. Myslim ze je > to vanilla verzu urciteho smiseneho efektu importu TIger dat v USA > (viz napriklad zde > http://flrec.ifas.ufl.edu/geomatics/wp-content/uploads/2012/02/tgis12037.pdf). > Jde o to, ze automatizovany import muze demotivovat lidke mappery v > zlepsovani dat. > > Zcela konkretne: Kouknu na proslou trasu na vylete a zda se mi ze > nejaka pole jsou trochu blbe. Pole ale u sebe maji nejaky LPSI id > cilso, cele to vypada desne "oficialne" a "spravne" atd, a vlastne ani > nevim co presne ta cisla znamenaji, abych pri aktualizaci poli > neudelal vic skody nez uzitku ... bla, bla, bla, proste to radsi nechm > byt na pokoji. > > Takze jasny dotaz na ty kdo import provadeli (jeste jednou gratuluji). > Maji se editovat tvary poli? Pokud pole nebou louku zedituju, mam > zachoval lips id? Cokdyz spojim dve pole (vedla tam kdysi cesta uz > nevede), jake to pak ma cislo? Moc bych se primlouval za to aby tyhle > jasne pokyny visely na wiki, aby to kazdy moh doledat. Zadne douhe > teoretizovani, jasny pokyn pro blbce stylu - "lips cisla jsou skoro k > nicemu, muzete je mazat" nebo "naimportovana pole klidne editujte, je > to jen vychozi stav" nebo "kazde 2 roky budeme delat reimport za > techto a techto podminek". > > > Dekuju J. >
Ahoj, jen krátce. - Žádné velké přetrasování se neplánuje. Pouze nepravidelné aktualizace v rámci místních editací. Například, kus pole byl změněn na obytnou plochu a tvar pole se změnil. - Při editaci doporučuji dát si jako podklad LPIS wms vrstvu. Pak uvidíš, zda se dané pole v LPIS změnilo nebo ne. - Polní cesta může vést po poli a pole nemusí být v daném místě rozděleno na dvě. Hodně to záleží na tom, kdo ta pole zakresloval. Různí lidé to dělají různě. Někdo poctivě vykresluje všechny ostrůvky, jiný se na to vybodne a udělá to jako jednolité pole. - V případě nejasností kouknout na nejnovější ortofoto. CUZK nebo mapy.cz. Dle všeho ta pole vznikají na základě cuzk:ortofoto. - Co je LPIS id není jasné. Někdy se to pole změní a ID zůstane, jindy je nahrazeno novým. - Pole neslučovat. Na každém může být za rok něco jiného. Třeba travní porost. To se řešilo už při importu. - Malá editace polí není problém, ale může se stát, že o úpravy přijdeš, když to někdo přetrasuje a nevšimne si, že tam je editace. Typicky, dvě velká pole, která se v LPIS sloučila do jednoho. - Na editaci doporučuji JOSM s pluginy: Tracer-testing, ContourMerge, a utilsplugin2 (hlavně příkaz: "Nahradit geometrii") Mám v plánu jednou nějaké základní tipy na editaci sepsat, ale znáš to. Marián

1.8.2015 03:05:10 (#32)
gravatar

Jakub Těšínský

<osm at kub.cz>
72
Paráda, děkuju za odpovědi. Pár nejasností ještě mám zobrazit citaci
> - V případě nejasností kouknout na nejnovější ortofoto. CUZK nebo > mapy.cz. Dle všeho ta pole vznikají na základě cuzk:ortofoto.
já mapuju většinou tyhle věci jen přímo z terénu, takže ortofoto moc nepotřebuju. Mimochodem mapy.cz jsou volný zdroj? zobrazit citaci
> - Co je LPIS id není jasné. Někdy se to pole změní a ID zůstane, jindy > je nahrazeno novým.
Zvědavost mi nedá, proč ho teda máme v OSM? :) zobrazit citaci
> - Pole neslučovat. Na každém může být za rok něco jiného. Třeba travní > porost. To se řešilo už při importu.
Mě se jedná napři o tuto situaci http://osm.org/go/0Jaa4p5YF-?layers=N&m= značka ukazuje na mezeru mezi loukou 12908950 a 12908957. V realitě tam nic takového není. Možná že někdy tou mezerou vedla cesta, ale teď je to jedna louka. Kdyby to nebylo naimportování z LIPS ale někdo to tam dal ručně dle skutečnosti, bez skrupují ty dvě louky spojím a zlepším mapu. Nevím jak ale spojit ref tagy, kterým nerozumím, takže to raděj nechám bejt, abych něco nezkazil. Bohužel tím mapa přichází o edity (tohle je efekt který je reálný, viz ten americkej import). Chtělo by to prostě nějaký pokyn jak tohle řešit. Např tím, že kdykoli budu editovat něco s lips refem tak ten ref smažu aby to nevypadalo, že můj edit je z lips zdrojů. Nevím. Právě proto jsem se ptal jesli ten lips ref je na něco. zobrazit citaci
> - Malá editace polí není problém, ale může se stát, že o úpravy přijdeš, > když to někdo přetrasuje a nevšimne si, že tam je editace. Typicky, dvě > velká pole, která se v LPIS sloučila do jednoho.
Nerozumím? Mě přijde že právě malé editace tvatu podle polí by se při jakémkoli reimportu měly respektovat, protože nejspíš mají nějaký důvod. To se nedělá? zobrazit citaci
> - Na editaci doporučuji JOSM s pluginy: Tracer-testing, ContourMerge, a > utilsplugin2 (hlavně příkaz: "Nahradit geometrii") > > > Mám v plánu jednou nějaké základní tipy na editaci sepsat, ale znáš to.
Jo znám :) ... třeba ti odpovědi na moje otázky poslouží jako základ té wiki stránky :) zobrazit citaci
> Marián >
-- Jakub Těšínský Mapping OSM since 2007

1.8.2015 07:47:00 (#33)
gravatar

Marián Kyral

<mkyral at email.cz>
2228 2371
Ahoj, Dne 1.8.2015 v 03:05 Jakub Těšínský napsal(a): zobrazit citaci
> Paráda, děkuju za odpovědi. Pár nejasností ještě mám > >> - V případě nejasností kouknout na nejnovější ortofoto. CUZK nebo >> mapy.cz. Dle všeho ta pole vznikají na základě cuzk:ortofoto. > > já mapuju většinou tyhle věci jen přímo z terénu, takže ortofoto moc > nepotřebuju. Mimochodem mapy.cz jsou volný zdroj?
Volný ne. Ale ověřovací by být mohl. Myslím teda letecké mapy od seznamu. Ne přímo jejich mapy. zobrazit citaci
>> - Co je LPIS id není jasné. Někdy se to pole změní a ID zůstane, jindy >> je nahrazeno novým. > > Zvědavost mi nedá, proč ho teda máme v OSM? :)
Protože jsme předpokládali, že jej budeme potřebovat. Jak probíhají aktualizace jsme nevěděli. Stačí si dohledat patřičnou diskuzi tady v archivu. zobrazit citaci
>> - Pole neslučovat. Na každém může být za rok něco jiného. Třeba travní >> porost. To se řešilo už při importu. > > Mě se jedná napři o tuto situaci > http://osm.org/go/0Jaa4p5YF-?layers=N&m= značka ukazuje na mezeru mezi > loukou 12908950 a 12908957. V realitě tam nic takového není. Možná že > někdy tou mezerou vedla cesta, ale teď je to jedna louka. Kdyby to > nebylo naimportování z LIPS ale někdo to tam dal ručně dle > skutečnosti, bez skrupují ty dvě louky spojím a zlepším mapu. Nevím > jak ale spojit ref tagy, kterým nerozumím, takže to raděj nechám bejt, > abych něco nezkazil. Bohužel tím mapa přichází o edity (tohle je efekt > který je reálný, viz ten americkej import). Chtělo by to prostě nějaký > pokyn jak tohle řešit. Např tím, že kdykoli budu editovat něco s lips > refem tak ten ref smažu aby to nevypadalo, že můj edit je z lips > zdrojů. Nevím. Právě proto jsem se ptal jesli ten lips ref je na něco. >
V tomto případě bych obě ID zahodil. Ale ostatní mají třeba jiný názor (ale asi jsou na dovolené ;-) ). A mimochodem, to že tam momentálně není žádná cesta ještě nic neznamená. Může se tam zase objevit. zobrazit citaci
>> - Malá editace polí není problém, ale může se stát, že o úpravy přijdeš, >> když to někdo přetrasuje a nevšimne si, že tam je editace. Typicky, dvě >> velká pole, která se v LPIS sloučila do jednoho. > Nerozumím? Mě přijde že právě malé editace tvatu podle polí by se při > jakémkoli reimportu měly respektovat, protože nejspíš mají nějaký > důvod. To se nedělá?
Myslel jsem to tak, že ten, kdo bude dělat aktualizaci toho pole, si nemusí všimnout tvých změn, zobrazit citaci
>> - Na editaci doporučuji JOSM s pluginy: Tracer-testing, ContourMerge, a >> utilsplugin2 (hlavně příkaz: "Nahradit geometrii") >> >> >> Mám v plánu jednou nějaké základní tipy na editaci sepsat, ale znáš to. > Jo znám :) ... třeba ti odpovědi na moje otázky poslouží jako základ > té wiki stránky :) >
No můžeš začít tím, že tu stránku s otázkami vytvoříš :-D Marián

1.8.2015 11:58:46 (#34)
gravatar

Martin Švec - OSM

<osm at maatts.cz>
109
Ahoj, za prvé, souhlasím a podepisuji odpovědi od Mariána :-) On 1.8.2015 07:47, Marián Kyral wrote: zobrazit citaci
> Ahoj, > > Dne 1.8.2015 v 03:05 Jakub Těšínský napsal(a): >> Paráda, děkuju za odpovědi. Pár nejasností ještě mám >> >>> - V případě nejasností kouknout na nejnovější ortofoto. CUZK nebo >>> mapy.cz. Dle všeho ta pole vznikají na základě cuzk:ortofoto. >> já mapuju většinou tyhle věci jen přímo z terénu, takže ortofoto moc >> nepotřebuju. Mimochodem mapy.cz jsou volný zdroj? > Volný ne. Ale ověřovací by být mohl. Myslím teda letecké mapy od > seznamu. Ne přímo jejich mapy.
Jako zdroj pro mapování v žádném případě. Ale když je rozpor mezi volnými zdroji, pomůže ti v rozhodování co z nich (ne)použít. zobrazit citaci
>>> - Co je LPIS id není jasné. Někdy se to pole změní a ID zůstane, jindy >>> je nahrazeno novým. >> Zvědavost mi nedá, proč ho teda máme v OSM? :) > Protože jsme předpokládali, že jej budeme potřebovat. Jak probíhají > aktualizace jsme nevěděli. Stačí si dohledat patřičnou diskuzi tady v > archivu. > >>> - Pole neslučovat. Na každém může být za rok něco jiného. Třeba travní >>> porost. To se řešilo už při importu. >> Mě se jedná napři o tuto situaci >> http://osm.org/go/0Jaa4p5YF-?layers=N&m= značka ukazuje na mezeru mezi >> loukou 12908950 a 12908957. V realitě tam nic takového není. Možná že >> někdy tou mezerou vedla cesta, ale teď je to jedna louka. Kdyby to >> nebylo naimportování z LIPS ale někdo to tam dal ručně dle >> skutečnosti, bez skrupují ty dvě louky spojím a zlepším mapu. Nevím >> jak ale spojit ref tagy, kterým nerozumím, takže to raděj nechám bejt, >> abych něco nezkazil. Bohužel tím mapa přichází o edity (tohle je efekt >> který je reálný, viz ten americkej import). Chtělo by to prostě nějaký >> pokyn jak tohle řešit. Např tím, že kdykoli budu editovat něco s lips >> refem tak ten ref smažu aby to nevypadalo, že můj edit je z lips >> zdrojů. Nevím. Právě proto jsem se ptal jesli ten lips ref je na něco. >> > V tomto případě bych obě ID zahodil. Ale ostatní mají třeba jiný názor > (ale asi jsou na dovolené ;-) ). > A mimochodem, to že tam momentálně není žádná cesta ještě nic neznamená. > Může se tam zase objevit.
Musíš si zapnout LPIS WMS vrstvu :-) Pak uvidíš, že mezeru mezitím opravili přímo v LPISu, stačilo pole přetrasovat a doladit škvíru (což jsem udělal). wms:http://eagri.cz/public/app/wms/plpis.fcgi?language=eng&FORMAT=image/png&TRANSPARENT=TRUE&VERSION=1.1.1&SERVICE=WMS&REQUEST=GetMap&LAYERS=LPIS_FB_KUL&STYLES=&SRS={proj}&WIDTH={width}&HEIGHT={height}&BBOX={bbox} zobrazit citaci
>>> - Malá editace polí není problém, ale může se stát, že o úpravy přijdeš, >>> když to někdo přetrasuje a nevšimne si, že tam je editace. Typicky, dvě >>> velká pole, která se v LPIS sloučila do jednoho. >> Nerozumím? Mě přijde že právě malé editace tvatu podle polí by se při >> jakémkoli reimportu měly respektovat, protože nejspíš mají nějaký >> důvod. To se nedělá? > Myslel jsem to tak, že ten, kdo bude dělat aktualizaci toho pole, si > nemusí všimnout tvých změn,
Taktak, bez zkoumání historie editací je IMHO nereálné si ručních změn všimnout. LPIS pole mají podrobnou geometrii samy o sobě a rychle se mění přímo v LPIS registru. Je to krásně vidět u starších natrasovaných polí vůči LPIS WMS vrstvě. Proto je potřeba při přetrasování přemýšlet a porovnávat co nejvíc zdrojů. zobrazit citaci
> >>> - Na editaci doporučuji JOSM s pluginy: Tracer-testing, ContourMerge, a >>> utilsplugin2 (hlavně příkaz: "Nahradit geometrii") >>> >>> >>> Mám v plánu jednou nějaké základní tipy na editaci sepsat, ale znáš to. >> Jo znám :) ... třeba ti odpovědi na moje otázky poslouží jako základ >> té wiki stránky :) >> > No můžeš začít tím, že tu stránku s otázkami vytvoříš :-D > > Marián > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz
Martin

1.8.2015 07:33:04 (#35)
gravatar

Pavel Machek

<pavel at ucw.cz>
1034 1226
On Fri 2015-07-31 00:30:41, Jakub Těšínský wrote: zobrazit citaci
> Gratuluji vsem kdo se na importu podileli. Pri mapovani polnacek a > turistickych znacek mi LIPS data hodne pomahaji v tom, ze je krasne videt > kudz potencialne muze vest cesta. Na druhou stranu jsem na sobe uz pocitil > urcite psychologicke negativum tohoto importu. Myslim ze je to vanilla verzu > urciteho smiseneho efektu importu TIger dat v USA (viz napriklad zde http://flrec.ifas.ufl.edu/geomatics/wp-content/uploads/2012/02/tgis12037.pdf). > Jde o to, ze automatizovany import muze demotivovat lidke mappery v > zlepsovani dat. > > Zcela konkretne: Kouknu na proslou trasu na vylete a zda se mi ze nejaka > pole jsou trochu blbe. Pole ale u sebe maji nejaky LPSI id cilso, cele to > vypada desne "oficialne" a "spravne" atd, a vlastne ani nevim co presne ta > cisla znamenaji, abych pri aktualizaci poli neudelal vic skody nez uzitku > ... bla, bla, bla, proste to radsi nechm byt na pokoji.
No, co jsem zatim videl, tak LPIS sedel velmi hezky (a spatne byly ty lesy okolo), takze doporucuju opatrnost. Pokud je tam opravdu zmena proti minulosti, pouvazoval bych nad pretrasovanim podle nove verse LPISu... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

1.8.2015 08:47:40 (#36)
gravatar

Marián Kyral

<mkyral at email.cz>
2228 2371
Dne 1.8.2015 v 11:58 Martin Švec - OSM napsal(a): zobrazit citaci
> > Musíš si zapnout LPIS WMS vrstvu :-) Pak uvidíš, že mezeru mezitím > opravili přímo v LPISu, stačilo pole přetrasovat a doladit škvíru (což > jsem udělal). > > wms:http://eagri.cz/public/app/wms/plpis.fcgi?language=eng&FORMAT=image/png&TRANSPARENT=TRUE&VERSION=1.1.1&SERVICE=WMS&REQUEST=GetMap&LAYERS=LPIS_FB_KUL&STYLES=&SRS={proj}&WIDTH={width}&HEIGHT={height}&BBOX={bbox} > >
Případně si aktuální stav můžeš porovnat na http://ruian.poloha.net/ (se zapnutou LPIS vrstvou) Marián

« zpět na výpis měsíce