Import dibavodu na Talk-cz - OpenStreetMap.cz

Pavel Machek pavel na ucw.cz #m4e7568 16. 1. 2010 21:56

Ahoj! Kdysi davno jsi psal:

- Importovany linie jednotlivych toku 5.212.525 bodu 250.612 linii - Importovany nadrze 1.486.406 bodu 72.026 ploch 822 multipolygonu z toho 1.522 der (ostrovu) - Importovany nazvy vcetne identifikatoru pro pripadny merge v - budoucnu - Sjednoceny sdilene nody (stejna lokace), ktere neni mozne simplifikovat 187.921 bodu - Export relaci pro polygony. Smer polygonu urcuje outer/inner. - Simplifikace dle zadane hodnoty

Subject byl "import dat povodi Labe" -- jsou to ta sama data jako dibavod (http://www.dibavod.cz/index.php?id=27) nebo ne? Python skripty jsem rozchodil, ale ony na vstupu potrebuji .sqlite, a ja to neumim ze shapefilu do .sqlite dostat :-(. Podle nejakyho navodu jsem zkusil: spatialite> .loadshp A04zvm_Melioracni_kanaly A04 UTF-8 2065 the_geom load shapefile error: cannot open shapefile 'A04zvm_Melioracni_kanaly' cause: 'A04zvm_Melioracni_kanaly.dbf' contains unsupported data types spatialite>

Jeste me napadlo oficialne kontaktovat urad s dotazem o tom zakonu. Oni musi oficialne odpovedet a pak bysme 100% vedeli jak to tedy je. Mohl by se toho nekdo ujmout?

Zda se ze tohle zvladnul hanoj :). Pavel

hanoj ehanoj na gmail.com #md28318 16. 1. 2010 22:02

- Importovany linie jednotlivych toku 5.212.525 bodu 250.612 linii - Importovany nadrze 1.486.406 bodu 72.026 ploch 822 multipolygonu z toho 1.522 der (ostrovu) - Importovany nazvy vcetne identifikatoru pro pripadny merge v - budoucnu - Sjednoceny sdilene nody (stejna lokace), ktere neni mozne simplifikovat 187.921 bodu - Export relaci pro polygony. Smer polygonu urcuje outer/inner. - Simplifikace dle zadane hodnoty
Subject byl "import dat povodi Labe" -- jsou to ta sama data jako dibavod (http://www.dibavod.cz/index.php?id=27) nebo ne?

v podstate ano http://www.pla.cz/planet/ram.aspx?id=21 Libilo by se mi staniceni na te rece - na dalnici mame exity, jsou na to nejake tagy OSM? hanoj

Tomas Kolda kolda na web2net.cz #mb76adc 17. 1. 2010 13:19

Ahoj, ten sqlite neni zadnej standard, to jsem si udelal vlastni format, aby se s tim dalo lepe pracovat... To co je v priloze jsem jeste nekde na disku nasel. Nemam se toho ujmout? Nerad bych, aby to dopadlo spatne. Ted se mi to nechce cist jestli uz to delas, ale jestli budes chtit muzu se na to podivat. Jinak ano byl to dibavod. Take jsem premyslel o tom oznaceni vod, ktere jsou v pruniku. Asi by to nemusel byt problem. Slo by to udelat tak, ze nactu vsechny vody v cechach a pres nejaky ctvereckovy spatialindex se udela prunik. Pokud bude prunik s dibavod, muze se entita oznacit nejakym atributem (obsolete=true), ktery si pak kazdy muze vyfiltrovat a pripadne smazat nebo naopak atribut odstranit. To bych take asi mohl udelat. Tomas

Ahoj! Kdysi davno jsi psal:
- Importovany linie jednotlivych toku 5.212.525 bodu 250.612 linii - Importovany nadrze 1.486.406 bodu 72.026 ploch 822 multipolygonu z toho 1.522 der (ostrovu) - Importovany nazvy vcetne identifikatoru pro pripadny merge v - budoucnu - Sjednoceny sdilene nody (stejna lokace), ktere neni mozne simplifikovat 187.921 bodu - Export relaci pro polygony. Smer polygonu urcuje outer/inner. - Simplifikace dle zadane hodnoty
Subject byl "import dat povodi Labe" -- jsou to ta sama data jako dibavod (http://www.dibavod.cz/index.php?id=27) nebo ne? Python skripty jsem rozchodil, ale ony na vstupu potrebuji .sqlite, a ja to neumim ze shapefilu do .sqlite dostat :-(. Podle nejakyho navodu jsem zkusil: spatialite> .loadshp A04zvm_Melioracni_kanaly A04 UTF-8 2065 the_geom load shapefile error: cannot open shapefile 'A04zvm_Melioracni_kanaly' cause: 'A04zvm_Melioracni_kanaly.dbf' contains unsupported data types spatialite>
Jeste me napadlo oficialne kontaktovat urad s dotazem o tom zakonu. Oni musi oficialne odpovedet a pak bysme 100% vedeli jak to tedy je. Mohl by se toho nekdo ujmout?
Zda se ze tohle zvladnul hanoj :). Pavel

An embedded and charset-unspecified text was scrubbed... An embedded and charset-unspecified text was scrubbed... An embedded and charset-unspecified text was scrubbed...

Ahoj, ten sqlite neni zadnej standard, to jsem si udelal vlastni format, aby se s tim dalo lepe pracovat... To co je v priloze jsem jeste nekde na disku nasel. Nemam se toho ujmout? Nerad bych, aby to dopadlo spatne. Ted se mi to nechce cist jestli uz to delas, ale jestli budes chtit muzu se na to podivat. Jinak ano byl to dibavod. Take jsem premyslel o tom oznaceni vod, ktere jsou v pruniku. Asi by to nemusel byt problem. Slo by to udelat tak, ze nactu vsechny vody v cechach a pres nejaky ctvereckovy spatialindex se udela prunik. Pokud bude prunik s dibavod, muze se entita oznacit nejakym atributem (obsolete=true), ktery si pak kazdy muze vyfiltrovat a pripadne smazat nebo naopak atribut odstranit. To bych take asi mohl udelat. Tomas Pavel Machek napsal(a):

Ahoj! Kdysi davno jsi psal:
- Importovany linie jednotlivych toku 5.212.525 bodu 250.612 linii - Importovany nadrze 1.486.406 bodu 72.026 ploch 822 multipolygonu z toho 1.522 der (ostrovu) - Importovany nazvy vcetne identifikatoru pro pripadny merge v - budoucnu - Sjednoceny sdilene nody (stejna lokace), ktere neni mozne simplifikovat 187.921 bodu - Export relaci pro polygony. Smer polygonu urcuje outer/inner. - Simplifikace dle zadane hodnoty
Subject byl "import dat povodi Labe" -- jsou to ta sama data jako dibavod (http://www.dibavod.cz/index.php?id=27) nebo ne? Python skripty jsem rozchodil, ale ony na vstupu potrebuji .sqlite, a ja to neumim ze shapefilu do .sqlite dostat :-(. Podle nejakyho navodu jsem zkusil: spatialite> .loadshp A04zvm_Melioracni_kanaly A04 UTF-8 2065 the_geom load shapefile error: cannot open shapefile 'A04zvm_Melioracni_kanaly' cause: 'A04zvm_Melioracni_kanaly.dbf' contains unsupported data types spatialite>
Jeste me napadlo oficialne kontaktovat urad s dotazem o tom zakonu. Oni musi oficialne odpovedet a pak bysme 100% vedeli jak to tedy je. Mohl by se toho nekdo ujmout?
Zda se ze tohle zvladnul hanoj :). Pavel

------------- dal?í ?ást --------------- HTML p?íloha byla odstran?na... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20100117/360f6806/attachment.htm> ------------- dal?í ?ást --------------- An embedded and charset-unspecified text was scrubbed... Name: dbf.py URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20100117/360f6806/attachment.ksh> ------------- dal?í ?ást --------------- An embedded and charset-unspecified text was scrubbed... Name: shapefile.py URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20100117/360f6806/attachment-0001.ksh> ------------- dal?í ?ást --------------- An embedded and charset-unspecified text was scrubbed... Name: vody.py URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20100117/360f6806/attachment-0002.ksh>

Pavel Machek pavel na ucw.cz #m7e0c79 17. 1. 2010 14:22

Ahoj!

ten sqlite neni zadnej standard, to jsem si udelal vlastni format, aby se s tim dalo lepe pracovat... To co je v priloze jsem jeste nekde na disku nasel. Nemam se toho ujmout? Nerad bych, aby to dopadlo spatne. Ted se mi to nechce cist jestli uz to delas, ale jestli budes chtit muzu se na to podivat.

Jestli to udelas budu velmi rad. Nakonec bych to asi zvladnul, ale Ty s tim mas podstatne vic zkusenosti.

Take jsem premyslel o tom oznaceni vod, ktere jsou v pruniku. Asi by to nemusel byt problem. Slo by to udelat tak, ze nactu vsechny vody v cechach a pres nejaky ctvereckovy spatialindex se udela prunik. Pokud bude prunik s dibavod, muze se entita oznacit nejakym atributem (obsolete=true), ktery si pak kazdy muze vyfiltrovat a pripadne smazat nebo naopak atribut odstranit. To bych take asi mohl udelat.

Ja myslim ze to oznaceni duplicit je dalsi krok ktery pujde udelat pres xapi kdykoliv pozdejc... a mozna bych s tim import nezdrzoval... Pavel

Tomas Kolda kolda na web2net.cz #m8cf4cc 17. 1. 2010 23:00

Ahoj, tak jsem na to koukal a nebude to tak jednoduche jak si asi vsichni myslime. OSM nejak strasne moc pokrocilo, protoze co jsem tak nahodne koukal tak vetsi nadrze uz tam skoro vsechny jsou. Bude to myslim velka prace to procistit. Chceme tedy import delat drive nez nejakou tu detekci hotoveho? Asi by bylo dobre udelat 2 datasety. Jeden kde se nic neprotina se muze naimportovat ihned a druhy se muze po castech rucne zkontrolovat a az pote importovat. Jinak kvalitativne mi prisel lepsi Dibavod, kdyz jsem videl to same v OSM, ale tezko rict. Dale tagy davam k way takoveto (pro nadrze): <tag k="source" v="Dibavod A05" /> <tag k="landuse" v="reservoir" /> <tag k="dibavod:id" v="109020210017" /> Prijde mi dobre dat tam i to A05, ale neni to asi nutnost kdyz se bude hledat i podle reservoir. Co myslite? Jinak reky budou velky problem, ktery zatim netusim jak udelat. Waterway je ok, ale riverbank oni nemaji. Maji skutecne jen linie brehu a jeste jsem nevykoukal jak je spojit dohromady do polygonu. Nevidim tam relace. Takze bych urcite zacal nadrzemi, tam je polygonu 71922 a 1483946 nodu. Reknete co s tou duplicitou. Tomas

Ahoj, tak jsem na to koukal a nebude to tak jednoduche jak si asi vsichni myslime. OSM nejak strasne moc pokrocilo, protoze co jsem tak nahodne koukal tak vetsi nadrze uz tam skoro vsechny jsou. Bude to myslim velka prace to procistit. Chceme tedy import delat drive nez nejakou tu detekci hotoveho? Asi by bylo dobre udelat 2 datasety. Jeden kde se nic neprotina se muze naimportovat ihned a druhy se muze po castech rucne zkontrolovat a az pote importovat. Jinak kvalitativne mi prisel lepsi Dibavod, kdyz jsem videl to same v OSM, ale tezko rict. Dale tagy davam k way takoveto (pro nadrze): <tag k="source" v="Dibavod A05" /> <tag k="landuse" v="reservoir" /> <tag k="dibavod:id" v="109020210017" /> Prijde mi dobre dat tam i to A05, ale neni to asi nutnost kdyz se bude hledat i podle reservoir. Co myslite? Jinak reky budou velky problem, ktery zatim netusim jak udelat. Waterway je ok, ale riverbank oni nemaji. Maji skutecne jen linie brehu a jeste jsem nevykoukal jak je spojit dohromady do polygonu. Nevidim tam relace. Takze bych urcite zacal nadrzemi, tam je polygonu 71922 a 1483946 nodu. Reknete co s tou duplicitou. Tomas Pavel Machek napsal(a):

Ahoj!
ten sqlite neni zadnej standard, to jsem si udelal vlastni format, aby se s tim dalo lepe pracovat... To co je v priloze jsem jeste nekde na disku nasel. Nemam se toho ujmout? Nerad bych, aby to dopadlo spatne. Ted se mi to nechce cist jestli uz to delas, ale jestli budes chtit muzu se na to podivat.
Jestli to udelas budu velmi rad. Nakonec bych to asi zvladnul, ale Ty s tim mas podstatne vic zkusenosti.
Take jsem premyslel o tom oznaceni vod, ktere jsou v pruniku. Asi by to nemusel byt problem. Slo by to udelat tak, ze nactu vsechny vody v cechach a pres nejaky ctvereckovy spatialindex se udela prunik. Pokud bude prunik s dibavod, muze se entita oznacit nejakym atributem (obsolete=true), ktery si pak kazdy muze vyfiltrovat a pripadne smazat nebo naopak atribut odstranit. To bych take asi mohl udelat.
Ja myslim ze to oznaceni duplicit je dalsi krok ktery pujde udelat pres xapi kdykoliv pozdejc... a mozna bych s tim import nezdrzoval... Pavel

------------- dal?í ?ást --------------- HTML p?íloha byla odstran?na... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20100117/2e630e20/attachment.htm>

hanoj ehanoj na gmail.com #me982ed 18. 1. 2010 0:57

tak jsem na to koukal a nebude to tak jednoduche jak si asi vsichni myslime. OSM nejak strasne moc pokrocilo, protoze co jsem tak nahodne koukal tak vetsi nadrze uz tam skoro vsechny jsou. Bude to myslim velka prace to procistit. Chceme tedy import delat drive nez nejakou tu detekci hotoveho?

*** Pavel rad skace po hlave do metrove vody.

Asi by bylo dobre udelat 2 datasety. Jeden kde se nic neprotina se muze naimportovat ihned a druhy se muze po castech rucne zkontrolovat a az pote importovat. Jinak kvalitativne mi prisel lepsi Dibavod, kdyz jsem videl to same v OSM, ale tezko rict.

**** 2 sety dobra cesta zdravi hanoj

Pavel Machek pavel na ucw.cz #m2f52cd 18. 1. 2010 8:43

Ahoj!

tak jsem na to koukal a nebude to tak jednoduche jak si asi vsichni myslime. OSM nejak strasne moc pokrocilo, protoze co jsem tak nahodne koukal tak vetsi nadrze uz tam skoro vsechny jsou. Bude to myslim velka prace to procistit. Chceme tedy import delat drive nez nejakou tu detekci

Ony vetsi veci jsou vzdycky 'jednodussi' -- je jich malo.

hotoveho? Asi by bylo dobre udelat 2 datasety. Jeden kde se nic neprotina se muze naimportovat ihned a druhy se muze po castech rucne zkontrolovat a az pote importovat. Jinak kvalitativne mi prisel lepsi Dibavod, kdyz jsem videl to same v OSM, ale tezko rict.

Jestli to neni problem rozdelit tak proc ne... smazat rucne duplicity taky neni velky problem...

Dale tagy davam k way takoveto (pro nadrze): <tag k="source" v="Dibavod A05" /> <tag k="landuse" v="reservoir" /> <tag k="dibavod:id" v="109020210017" /> Prijde mi dobre dat tam i to A05, ale neni to asi nutnost kdyz se bude hledat i podle reservoir. Co myslite?

Myslim ze a05 je dobre.

Jinak reky budou velky problem, ktery zatim netusim jak udelat. Waterway je ok, ale riverbank oni nemaji. Maji skutecne jen linie brehu a jeste jsem nevykoukal jak je spojit dohromady do polygonu. Nevidim tam relace.

Mozna se to da udelat rucne...?

Takze bych urcite zacal nadrzemi, tam je polygonu 71922 a 1483946 nodu. Reknete co s tou duplicitou.

Ok :). Pavel

Tomas Kolda kolda na web2net.cz #mddbc60 18. 1. 2010 18:57

Prosimte nejak jsem nepochopil co tedy nepouzit :) Muzes mi naopak napsat presne co pouzit? Ja tychle veci moc neresim, takze nevim co je nejvice vypovidajici. Tag pro timestamp by se take hodil... Dik Tomas