« 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>
1056 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>
1056 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 ------------- další část --------------- #!/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>
515
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>
1056 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 ------------- další část --------------- #!/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>
1056 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>
515
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>
515
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>
170 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>
1056 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>
1056 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>
415 1552
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 na 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 na openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz

21.7.2014 02:50:39 (#12)
gravatar

Dalibor Jelínek

<dalibor at dalibor.cz>
415 1552
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 na 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 na openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz

21.7.2014 03:38:34 (#13)
gravatar

Pavel Machek

<pavel at ucw.cz>
1056 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>
2385 2735
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 na 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>
2385 2735
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 na 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: <https://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>
1056 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 ------------- další část --------------- A non-text attachment was scrubbed... Name: trn-lpis.py Type: text/x-python Size: 1583 bytes Desc: [žádný popis není k dispozici] URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20140803/e49fc9ee/attachment.py> ------------- další část --------------- A non-text attachment was scrubbed... Name: CiselnikyXLPIS.doc Type: application/msword Size: 141312 bytes Desc: [žádný popis není k dispozici] URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20140803/e49fc9ee/attachment.doc>

3.8.2014 08:53:47 (#18)
gravatar

Marián Kyral

<mkyral at email.cz>
2385 2735
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>
2385 2735
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: <https://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>
2385 2735
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 na openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz
------------- dal?í ?ást --------------- HTML p?íloha byla odstran?na... URL: <https://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 na 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 5000
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: <https://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>
1056 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>
556
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>
1056 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>
170 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 na maatts.cz> Komu: OpenStreetMap Czech Republic <talk-cz na 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 na openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz" ------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20150615/4202fa5d/attachment.html>

15.6.2015 05:56:09 (#29)
gravatar

xkomczax na centrum.cz

<xkomczax at centrum.cz>
213 2794
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 na seznam.cz> > Komu: <talk-cz na 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 na openstreetmap.org >https://lists.openstreetmap.org/listinfo/talk-cz >

31.7.2015 12:30:41 (#30)
gravatar

Jakub Těšínský

<osm at kub.cz>
83
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>
2385 2735
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>
83
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>
2385 2735
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 na openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz
Martin

1.8.2015 07:33:04 (#35)
gravatar

Pavel Machek

<pavel at ucw.cz>
1056 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>
2385 2735
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