Re: [Talk-cz] Tracer plugin - ruian update
Cus, hele a neni tam nahodou neco jako priorita/poradi? Mam pocit ze kdyz sem na to kdysi koukal, tak tam v pripade vice zaznamu byl jeden oznacen jako primarni. Pripadne, pokud vidim dobre ... (ale nevim zda je to pravidlem) 27767701 27767710 27767728 27767736 => nejnizsi cislo = to je to co dat na barak. V tomhle pripade Technická ul. Samo, idealni by byla adresa(y) jako relace ... ale to by vyzadovalo prekopat uplne vse (a nejen v CR). Dne 5.2.2014 8:53, Dalibor Jelínek napsal(a): No prave tady mi to prijde uplne jasne, jak jsem psal drive: cesta budovy: addr:place=Dejvice addr:city=Praha 6 (nebo Praha, tady nevim) addr:country=CZ addr:housenumber=2710 addr:conscriptionnumber=2710 ref:ruian=cislo stavebniho objektu bez ulice bez c.o. bez PSC 4x body nad vchody (ale soucasty cesy domu) to same, co je vyse, ovsem s addr:housenumber ve tvaru c.p./c.o. entrance=yes addr:street addr:streetnumber addr:postcode ref:ruian=cislo adresniho mista Tohle mi prijde, jako ze presne kopiruje maximum informaci, ktere z RUIAN mame a dava to nejvetsi smysl. Jedine, co tam takhle neni, je ta vazba mezi SO a AM (resp. je zakreslena v mape, ale to nekdy nemusi tak byt, a bude-li AM lezet mimo SO, pak tam zadna vazba neni, ovsem sla-by pridat, ale myslim, ze vlastne k nicemu neni) Jedina drobna chyba je, ze to v nekterych (ale podle me velmi ridkych) pripadech bude vest ke dvojimu zobrazeni cisla v mape. Ale jen pri velkem zvetseni, jinak je videt jen jedno cislo. Zkousel jsem to. Druha vetsi chybka je, ze to nejde aplikovat na to jedno procento s.o., ktere fakt maji vice c.p. nebo c.e. Sice by to slo v housenumber a consriptionnumber oddelovat strednikem, ale to je velka prasarna. Spise bych si myslel, ze by Trace v tohmle miste zobrazit informaci, ze SO ma vice c.p. nebo c.e. a rekl, ze je tudiz nenatagoval a doporucil uzivateli, aby dum rozdelil na adekvatni mensi casti, nebo tak neco. Treba tak (protoze ty priklady domu, ktere jsem zatim videl, tomu odpovidaly), ze celou cestu SO nakreslenou dle RUIAN oznaci jako building=terrace ci building=garages, a pak ji rozdelit na podbudovy building=house nebo building=garage a ty uz otagovat spravne i s housenumber a conscription number. Co jsem prehledl tentokrat? ;-) Zdravi, Dalibor Ano, v případě NTK jde o 1 č.p. a 4 čísla orientační. Ona ta struktura dat není vůbec jednoduchá... uvedu na příkladu NTK: Co nám říká stavební objekt 27239781: - kód městské části (Praha 6) - kód části obce (Dejvice) - čísla domovní (2710) - jedná se o budovu s č.p. K tomuto objektu se váží 4 adresní místa, která nesou informaci o: - kód stavebního objektu (27239781) - číslo domovní (2710) - kód ulice (4 různé hodnoty - Flemingovo nám., Studentská, Technická, Thákurova) - číslo orientační (4 různé hodnoty - 6, 1, 20, 13) - PSČ (16000) A teď zkuste někdo popsat, jakým způsobem z těchto dat dostat adresu, která by se měla umístit přímo na budovu v OSM. Zdraví, Petr Morávek aka Xificurk ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer plugin - ruian update
Dne 6.2.2014 13:46, o...@propsychology.cz napsal(a): Ahoj, On Thu, Feb 06, 2014 at 01:35:03PM +0100, Dalibor Jelínek wrote: Takze ted vim, ze v RUIAN máme i neviditelné budovy. Bezva! :-)) Treba kdyz se bude editovat v oblasti, kam uz nekdo pridal adresy dríve, tak by bylo fajn vedet, ?e podle RUIAN ta adresa uz neexistuje a tedy je ji mozno z OSM smazat. U adres nevim, ale u budov pozor - cetl jsem v nejakem dokumentu CUZK, ze smazani budovy z RUIAN v zadnem pripade nemusi znamenat jeji odstraneni z terenu. Je to treba tehdy, kdy se meni klasifikace budovy, nevim presne, nezajima. Podstatne je, je smazani z RUIAN != zbourani. Cus, to plati i naopak, to ze v RUIAN neco je, jeste neznanema, ze to tam je i v realu ... proto sem tu onehda mimo jine navrhoval, ze adresni bod davat tam, kde v terenu neni zjevna budova, jinde kreslit budovu a adresu dat na ni. Adresni bod nicemu nevadi, kdyby nekdo tu adresu, byt "neexistujici/nesmyslnou/..." hledal, tak ho to tam dovede. -- Petr ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer plugin - ruian update
Dne 10.2.2014 10:18, jzvc napsal: Dne 6.2.2014 13:46, o...@propsychology.cz napsal(a): Ahoj, On Thu, Feb 06, 2014 at 01:35:03PM +0100, Dalibor Jelínek wrote: Takze ted vim, ze v RUIAN máme i neviditelné budovy. Bezva! :-)) Treba kdyz se bude editovat v oblasti, kam uz nekdo pridal adresy dríve, tak by bylo fajn vedet, ?e podle RUIAN ta adresa uz neexistuje a tedy je ji mozno z OSM smazat. U adres nevim, ale u budov pozor - cetl jsem v nejakem dokumentu CUZK, ze smazani budovy z RUIAN v zadnem pripade nemusi znamenat jeji odstraneni z terenu. Je to treba tehdy, kdy se meni klasifikace budovy, nevim presne, nezajima. Podstatne je, je smazani z RUIAN != zbourani. Cus, to plati i naopak, to ze v RUIAN neco je, jeste neznanema, ze to tam je i v realu ... proto sem tu onehda mimo jine navrhoval, ze adresni bod davat tam, kde v terenu neni zjevna budova, jinde kreslit budovu a adresu dat na ni. Adresni bod nicemu nevadi, kdyby nekdo tu adresu, byt "neexistujici/nesmyslnou/..." hledal, tak ho to tam dovede. S tím mám trochu problém. Momentálně to v naprosté většině případů znamená, že v daném místě chybí budova a mám tendenci ji dokreslit. Marián ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer plugin - ruian update
Ahoj,
nechtěl bys o tom udělat prezentaci na konferenci GIVS 2014 [1] ?
Jsou tam lidi přímo z CUZK, myslím, že by je zajímalo, jak RUIAN používáme,
případně se s nimi pobavit o tom, co by mohlo být lepší...
Jáchym
[1] http://www.cagi.cz/konference-givs-2014
On Sun, Jan 26, 2014 at 10:48:02PM +0100, Marián Kyral wrote:
> Ahoj,
> Tak jsem se trochu vrtal v Tracer pluginu. Nejprve jsem chtěl jen
> změnit natvrdo zadrátovanou adresu serveru, abych se dokázal
> připojit na ruian server od Petra Vejsady. To se povedlo, takže jsem
> uvažoval nad forkem, ale nakonec jsem se rozhodl pro úpravu
> původního Tracer pluginu (zásuvného modulu :-D ).
>
> Předesílám, že nejsem java programátor, ve skutečnosti jsem se javě
> zatím úspěšně vyhýbal. O to to pak bylo horší :-D Výsledné řešení je
> inspirováno několika pluginy a různými příklady na webu.
>
> _Takže co se změnilo:_
> *) Původní funkcionalita zůstala zachována (klávesová zkratka "T")
> *) Přidal jsem "RUIAN" režim - dostupný z menu, nebo pod klávesovou
> zkratou "Ctrl+T"
> *) Z Tracer2 pluginu jsem použil vylepšenou třídu ConnectWays, která
> umí aktualizovat tvar současné budovy. Prosím nezneužívat - Petr má
> ohledně této funkce obavy :-D
> *) Při tracování z RUIAN se přidá ruian id a pokud je znám, tak i
> typ budovy. (pouze pokud je building=yes). Převod na OSM typy budov
> bude asi potřeba ještě trochu doladit.
> *) Přidal jsem konfiguraci. Dá se nastavit vlastní adresa serveru a
> případně i posunout polohu natrasované budovy. Třeba tady u nás v
> Beskydech je RUIAN oproti KM mírně posunutý (asi přepočet, ale je to
> mnohem lepší než KM). Pro RUIAN to funguje, u KM moc ne. Ten mi
> každou budovu vrátí s trochu jiným posunem :-(
>
> _Známé chyby:_
> *) U domů nalepených na sobě nebo třeba řadě garáží se generují
> duplicitní body. Ty je potřeba ručně sloučit. Pokusím se to nějak
> opravit, ale až tak tomu kódu zase nerozumím :-D
> *) Na rovných čarách se objevují nadbytečné body, zpravidla v
> místech, kde je v KM napojení další čáry, která není součástí
> budovy. Takhle to je už v RUIAN - s Petrem to plánujeme nějak
> odfiltrovat.
> *) Plugin neukazuje verzi - problém testovacího buildu, po nahrání
> do repozitáře JOSM by mělo být v pohodě. Možná to jde i jinak, ale s
> ANTem si zatím netykám.
> *) Zatím chybí překlad - i18n.pl má s mým .po souborem nějaký
> problém :-(
>
>
> Při práci s pluginem doporučuji jako podkladovou vrstvu Bing (pokud
> je v daném místě dostatečné rozlišení, pak RUIAN vrstvu od Petra (
> tms:http://tile.poloha.net/budovy/{zoom}/{x}/{y}.png ) a nahoru KM.
>
> Bohužel data v RUIAN nejsou až tak přesné. Někde budova chybí, jinde
> přebývá, případně má jiný tvar. Je třeba kontrolovat oproti KM a
> podezřelé případy pak ověřit i jinak.
>
> Plugin je ke stažení zde: http://www.kyralovi.cz/tmp/josm/tracer.jar
> Zdrojáky tady: https://github.com/mkyral/josm-tracer/commits/ruian
>
> A na závěr pár screenshotů:
>
> Budova před: http://www.kyralovi.cz/tmp/josm/tracer_before.png
> Menu: http://www.kyralovi.cz/tmp/josm/tracer_menu.png
> Trasování: http://www.kyralovi.cz/tmp/josm/tracer_trace.png
> Výsledek: http://www.kyralovi.cz/tmp/josm/tracer_result.png
> Nastavení: http://www.kyralovi.cz/tmp/josm/tracer_prefs.png
>
> Na výsledku je vidět, ruian ID i změna typu budovy z "building=yes"
> nad "building=house".
>
> Upozorňuji, že v příkladu používám posun. tvar budovy je získán z
> RUIANu (fialová čára), ale byl posunut na pozici dle KM (zelená
> čára).
>
> Prosím o otestování, kontrolu zdrojáků, nahlášení chyb, zaslání
> patchů, zaslání pěknější ikony ;-).
>
> Pokud nebudou výhrady, rád bych tuto změnu dostal v dohledné době do
> josm svn.
>
> Marián
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
--
Jachym Cepicky
URL: http://les-ejk.cz
e-mail: jachym.cepicky at gmail com
PGP: http://les-ejk.cz/pgp/JachymCepicky.pgp
@jachymc
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Rastr (hillshade) v pgsql a Mapnik
Jestli se nepletu, tak Paul Ramsay důrazně nedopurčoval, dávat do PostGISu rastry. To že něco jde ještě neznamená, že je to dobrej nápad. Zkuste to vyexportit to geotiffu a přistupovat k tomu z gdalu "normálně" J On Thu, Feb 06, 2014 at 12:26:43AM +0100, Petr Vejsada wrote: > Ahoj, > > už delší dobu se nemohu hnout z místa, tak se zeptám. Chtěl bych mít v > databázi rastrovou vrstvu pro reliéy/stínování a to pak zobrazovat Mapnikem. > > Mapnik přímo to v aktuální stabilní verzi (asi) nepodporuje, ale umí to GDAL > a > Mapnik zase umí GDAL. > > Zkusil jsem Mapniku podstrčit jako zdroj dat GDAL, jen jsem si 'trochu' > poupravil název souboru. Konfigurace vypadá takto: > > > gdal > PG:dbname=pedro port=5432 schema=gis > table=cz_hillshade mode=2 > tiff > > > Když zavolám Mapnik z Pythonu, použiji skripty na generování dlaždic nebo > obrázku generate_tiles.py nebo generate_image.py, tak vše funguje podle mých > představ. Data bere z postgresql a vykreslí, co chci. GDAL to, co je v > parametru vezme jako datasource z databáze a vše je OK. > > Pokud to chci dát do produkčního režimu, tedy přes Tirex a mod_tile, už se to > nezdaří. Do syslogu dostanu hlášku: > > Feb 5 21:08:52 propsy tirex-backend-mapnik[10981]: Renderer started > (name=mapnik) > Feb 5 21:08:57 propsy tirex-backend-mapnik[10981]: cannot add > /etc/tirex/renderer/mapnik/hill.conf > Feb 5 21:08:57 propsy tirex-backend-mapnik[10981]: > `/home/mapnik/layers/hill/PG:dbname=pedro port=54 > 32 schema=gis table=cz_hillshade mode=2' does not exist in the file system, > and > is not recognised as > a supported dataset name. encountered during parsing of layer 'hillshade' > in > Layer at line 5 of '/h > ome/mapnik/layers/hill/osm.xml' > > Nemohl jsem přijít na to, co vlastně tu hlášku "file ... does not exist in > the > file system, and is not recognised as a supported dataset name" způsobuje. > Pak > jsem vygrepoval, že je to GDAL. > > Otázkou je, proč GDAL při volání Mapniku z Pythonu ten parametr v pohodě > vezme > jako DB resource, kdežto při volání z Tirexu tvrdošíjně hledá soubor toho > názvu, co je v parametru . > > Tirex asi volá Mapnik jiným způsobem, nebo že by sám parsoval konfiguraci > Mapniku a testnul si GDAL, jestli bude s takovým souborem spokojený? > > Nesetkal jste se s tímto někdo? > > -- > Petr, p...@propsychology.cz > >p< > > > ___ > Talk-cz mailing list > Talk-cz@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz -- Jachym Cepicky URL: http://les-ejk.cz e-mail: jachym.cepicky at gmail com PGP: http://les-ejk.cz/pgp/JachymCepicky.pgp @jachymc ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] stav UHUL ortofoto
Vzhledem k tomu, jaké teď na UHULe panují poměry bych byl překvapený, kdyby to někdo kvůli OSM dal dohromady Obávám se, že jsme bez ortofota J On Sat, Feb 08, 2014 at 10:33:48AM +0100, Kasparek Tomas wrote: > On Fri, Feb 07, 2014 at 10:44:10PM +0100, Pavel Machek wrote: > > > mate predstavu, co se stalo s UHUL:ortofoto a jestli ji budeme > > > mit jeste dotupnou? Pokud pouziji URL prednastavene v JOSM, tedy > > > > Mam lokalni kopii UHUL:ortofoto; chvili byla i na openaerialmap. Takze > > kdyby byl zajem, slo by to nekde zprovoznit. Licence to tusim > > dovoluje. > > Zajem by byl, kdyby bylo treba i nejake zelezo na umisteni. Nebo vite o > nejake jine kvalitni ortofoto pro JOSM? > > -- > > Tomas Kasparek E-mail: kaspa...@fit.vutbr.cz > CVT FIT VUT Brno, L127 Web:http://www.fit.vutbr.cz/~kasparek > Bozetechova 1, 612 66Fax:+420 54114-1270 > Brno, Czech Republic Phone: +420 54114-1220 > > jabber: tomas.kaspa...@jabber.cz > GPG:2F1E 1AAF FD3B CFA3 1537 63BD DCBE 18FF A035 53BC > > May the command line live forever! > ___ > Talk-cz mailing list > Talk-cz@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz -- Jachym Cepicky URL: http://les-ejk.cz e-mail: jachym.cepicky at gmail com PGP: http://les-ejk.cz/pgp/JachymCepicky.pgp @jachymc ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] stav UHUL ortofoto
> > mate predstavu, co se stalo s UHUL:ortofoto a jestli ji budeme > > mit jeste dotupnou? Pokud pouziji URL prednastavene v JOSM, tedy > > Mam lokalni kopii UHUL:ortofoto; chvili byla i na openaerialmap. Takze > kdyby byl zajem, slo by to nekde zprovoznit. Licence to tusim > dovoluje. *** Zadnou licenci k UHUL:ortofoto nedisponujeme, UHUL to poskytoval na dobre slovo. I proto to bylo v rozporu s podminkami nekdejsiho openaerialmap.org ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer plugin - ruian update
Cus,
lehce sem plugin otestoval ... takze si dovolim par pripominek/podnetu.
1) Pri aktualizaci budov to odpoji budovy okolni. To by v zasade
nevadilo ... pokud to jsou budovy, ktere jsou v ruian, pak se to spravi
jejich aktualizaci. Jenze ony to mohou byt ruzne pristavky ...
Mozna by bylo dobre v tomhle pripade delat merge nejblizsich bodu na ty
z ruian (do nejaky vzdalenosti - rekneme metr), pripadne (pri vetsi
vzdalenosti) body okolnich budov napojit na cestu v nejblizsim miste (do
nejakyho maxima - rekneme 2 metry) - samo, konfigurovatelne, ty
vzdalenosti strilim podle oka jak vidim ze tam je +- v relativne presne
udelanym podkladu podle KM.
2) v RUIANu nejsou ty pristavky co sou v KM? Pripadne odkud se v KM
berou? Protoze ty to rozhodne netrasuje. Pokud by trasovalo, byl by asi
vyresen problem vejs.
Jinak co se diskutovany presnosti tejce, vidim tam posun vuci KM o cca
10 cm ... coz neni nic tragickyho, ale zajimavy to teda je.
Dne 26.1.2014 22:48, Marián Kyral napsal(a):
Ahoj,
Tak jsem se trochu vrtal v Tracer pluginu. Nejprve jsem chtěl jen změnit
natvrdo zadrátovanou adresu serveru, abych se dokázal připojit na ruian
server od Petra Vejsady. To se povedlo, takže jsem uvažoval nad forkem,
ale nakonec jsem se rozhodl pro úpravu původního Tracer pluginu
(zásuvného modulu :-D ).
Předesílám, že nejsem java programátor, ve skutečnosti jsem se javě
zatím úspěšně vyhýbal. O to to pak bylo horší :-D Výsledné řešení je
inspirováno několika pluginy a různými příklady na webu.
_Takže co se změnilo:_
*) Původní funkcionalita zůstala zachována (klávesová zkratka "T")
*) Přidal jsem "RUIAN" režim - dostupný z menu, nebo pod klávesovou
zkratou "Ctrl+T"
*) Z Tracer2 pluginu jsem použil vylepšenou třídu ConnectWays, která umí
aktualizovat tvar současné budovy. Prosím nezneužívat - Petr má ohledně
této funkce obavy :-D
*) Při tracování z RUIAN se přidá ruian id a pokud je znám, tak i typ
budovy. (pouze pokud je building=yes). Převod na OSM typy budov bude asi
potřeba ještě trochu doladit.
*) Přidal jsem konfiguraci. Dá se nastavit vlastní adresa serveru a
případně i posunout polohu natrasované budovy. Třeba tady u nás v
Beskydech je RUIAN oproti KM mírně posunutý (asi přepočet, ale je to
mnohem lepší než KM). Pro RUIAN to funguje, u KM moc ne. Ten mi každou
budovu vrátí s trochu jiným posunem :-(
_Známé chyby:_
*) U domů nalepených na sobě nebo třeba řadě garáží se generují
duplicitní body. Ty je potřeba ručně sloučit. Pokusím se to nějak
opravit, ale až tak tomu kódu zase nerozumím :-D
*) Na rovných čarách se objevují nadbytečné body, zpravidla v místech,
kde je v KM napojení další čáry, která není součástí budovy. Takhle to
je už v RUIAN - s Petrem to plánujeme nějak odfiltrovat.
*) Plugin neukazuje verzi - problém testovacího buildu, po nahrání do
repozitáře JOSM by mělo být v pohodě. Možná to jde i jinak, ale s ANTem
si zatím netykám.
*) Zatím chybí překlad - i18n.pl má s mým .po souborem nějaký problém :-(
Při práci s pluginem doporučuji jako podkladovou vrstvu Bing (pokud je v
daném místě dostatečné rozlišení, pak RUIAN vrstvu od Petra (
tms:http://tile.poloha.net/budovy/{zoom}/{x}/{y}.png ) a nahoru KM.
Bohužel data v RUIAN nejsou až tak přesné. Někde budova chybí, jinde
přebývá, případně má jiný tvar. Je třeba kontrolovat oproti KM a
podezřelé případy pak ověřit i jinak.
Plugin je ke stažení zde: http://www.kyralovi.cz/tmp/josm/tracer.jar
Zdrojáky tady: https://github.com/mkyral/josm-tracer/commits/ruian
A na závěr pár screenshotů:
Budova před: http://www.kyralovi.cz/tmp/josm/tracer_before.png
Menu: http://www.kyralovi.cz/tmp/josm/tracer_menu.png
Trasování: http://www.kyralovi.cz/tmp/josm/tracer_trace.png
Výsledek: http://www.kyralovi.cz/tmp/josm/tracer_result.png
Nastavení: http://www.kyralovi.cz/tmp/josm/tracer_prefs.png
Na výsledku je vidět, ruian ID i změna typu budovy z "building=yes" nad
"building=house".
Upozorňuji, že v příkladu používám posun. tvar budovy je získán z RUIANu
(fialová čára), ale byl posunut na pozici dle KM (zelená čára).
Prosím o otestování, kontrolu zdrojáků, nahlášení chyb, zaslání patchů,
zaslání pěknější ikony ;-).
Pokud nebudou výhrady, rád bych tuto změnu dostal v dohledné době do
josm svn.
Marián
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer plugin - ruian update
> Jinak co se diskutovany presnosti tejce, vidim tam posun vuci KM o cca 10 cm ... coz neni nic tragickyho, ale zajimavy to teda je. *** uz se prosim nedivme, ale chapejme: http://grass.fsv.cvut.cz/gwiki/Chyba_p%C5%99i_transformaci_z_WGS84_do_S-JTSK ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer plugin - ruian update
Dne 10.2.2014 13:56, jzvc napsal:
Cus,
lehce sem plugin otestoval ... takze si dovolim par pripominek/podnetu.
1) Pri aktualizaci budov to odpoji budovy okolni. To by v zasade
nevadilo ... pokud to jsou budovy, ktere jsou v ruian, pak se to spravi
jejich aktualizaci. Jenze ony to mohou byt ruzne pristavky ...
Mozna by bylo dobre v tomhle pripade delat merge nejblizsich bodu na ty
z ruian (do nejaky vzdalenosti - rekneme metr), pripadne (pri vetsi
vzdalenosti) body okolnich budov napojit na cestu v nejblizsim miste
(do
nejakyho maxima - rekneme 2 metry) - samo, konfigurovatelne, ty
vzdalenosti strilim podle oka jak vidim ze tam je +- v relativne presne
udelanym podkladu podle KM.
Jo, o tom vím a pokusím se to v budoucnu nějak vyřešit. Ten merge jsme
převzal z Tracer2 pluginu a zatím to beru jako blackbox, který nějak
(ne právě ideálně funguje). Nejdříve musím pochopit princip a pak se to
můžu pokusit opravit.
Ono vůbec se při práci s pluginem někdy dějí věci. Třeba mi JOSM nahlásí
konflikt, že na serveru jsou nějaké body, které jsem na lokále smazal,
ale na přesně stejném místě se vytvořily jiné body. Mám pocit, že to
vznikne, když zkusím budovu tracovat víckrát. Musím to prozkoumat.
Ovšem momentálně se věnuji PointInfo pluginu ;-)
2) v RUIANu nejsou ty pristavky co sou v KM? Pripadne odkud se v KM
berou? Protoze ty to rozhodne netrasuje. Pokud by trasovalo, byl by asi
vyresen problem vejs.
Nejsou, nejsou. Když si zapneš tu vrstvu budov od Petra Vejsady a přes
to
si dáš vrstvu KM, tak uvidíš, že ty přístavky jsou dělány tenčí čarou a
třeba původní tracer server je nevidí = je to v jiné vrstvě KM. (ale
záleží
na konfiguraci Tracer Serveru)
Marián
Jinak co se diskutovany presnosti tejce, vidim tam posun vuci KM o cca
10 cm ... coz neni nic tragickyho, ale zajimavy to teda je.
Dne 26.1.2014 22:48, Marián Kyral napsal(a):
Ahoj,
Tak jsem se trochu vrtal v Tracer pluginu. Nejprve jsem chtěl jen
změnit
natvrdo zadrátovanou adresu serveru, abych se dokázal připojit na
ruian
server od Petra Vejsady. To se povedlo, takže jsem uvažoval nad
forkem,
ale nakonec jsem se rozhodl pro úpravu původního Tracer pluginu
(zásuvného modulu :-D ).
Předesílám, že nejsem java programátor, ve skutečnosti jsem se javě
zatím úspěšně vyhýbal. O to to pak bylo horší :-D Výsledné řešení je
inspirováno několika pluginy a různými příklady na webu.
_Takže co se změnilo:_
*) Původní funkcionalita zůstala zachována (klávesová zkratka "T")
*) Přidal jsem "RUIAN" režim - dostupný z menu, nebo pod klávesovou
zkratou "Ctrl+T"
*) Z Tracer2 pluginu jsem použil vylepšenou třídu ConnectWays, která
umí
aktualizovat tvar současné budovy. Prosím nezneužívat - Petr má
ohledně
této funkce obavy :-D
*) Při tracování z RUIAN se přidá ruian id a pokud je znám, tak i typ
budovy. (pouze pokud je building=yes). Převod na OSM typy budov bude
asi
potřeba ještě trochu doladit.
*) Přidal jsem konfiguraci. Dá se nastavit vlastní adresa serveru a
případně i posunout polohu natrasované budovy. Třeba tady u nás v
Beskydech je RUIAN oproti KM mírně posunutý (asi přepočet, ale je to
mnohem lepší než KM). Pro RUIAN to funguje, u KM moc ne. Ten mi každou
budovu vrátí s trochu jiným posunem :-(
_Známé chyby:_
*) U domů nalepených na sobě nebo třeba řadě garáží se generují
duplicitní body. Ty je potřeba ručně sloučit. Pokusím se to nějak
opravit, ale až tak tomu kódu zase nerozumím :-D
*) Na rovných čarách se objevují nadbytečné body, zpravidla v místech,
kde je v KM napojení další čáry, která není součástí budovy. Takhle to
je už v RUIAN - s Petrem to plánujeme nějak odfiltrovat.
*) Plugin neukazuje verzi - problém testovacího buildu, po nahrání do
repozitáře JOSM by mělo být v pohodě. Možná to jde i jinak, ale s
ANTem
si zatím netykám.
*) Zatím chybí překlad - i18n.pl má s mým .po souborem nějaký problém
:-(
Při práci s pluginem doporučuji jako podkladovou vrstvu Bing (pokud je
v
daném místě dostatečné rozlišení, pak RUIAN vrstvu od Petra (
tms:http://tile.poloha.net/budovy/{zoom}/{x}/{y}.png ) a nahoru KM.
Bohužel data v RUIAN nejsou až tak přesné. Někde budova chybí, jinde
přebývá, případně má jiný tvar. Je třeba kontrolovat oproti KM a
podezřelé případy pak ověřit i jinak.
Plugin je ke stažení zde: http://www.kyralovi.cz/tmp/josm/tracer.jar
Zdrojáky tady: https://github.com/mkyral/josm-tracer/commits/ruian
A na závěr pár screenshotů:
Budova před: http://www.kyralovi.cz/tmp/josm/tracer_before.png
Menu: http://www.kyralovi.cz/tmp/josm/tracer_menu.png
Trasování: http://www.kyralovi.cz/tmp/josm/tracer_trace.png
Výsledek: http://www.kyralovi.cz/tmp/josm/tracer_result.png
Nastavení: http://www.kyralovi.cz/tmp/josm/tracer_prefs.png
Na výsledku je vidět, ruian ID i změna typu budovy z "building=yes"
nad
"building=house".
Upozorňuji, že v příkladu používám posun. tvar budovy je získán z
RUIANu
(fialová čára), ale byl posunut na pozici dle KM (zelená čára).
Prosím o otestování, kontrolu zdrojáků, nahlášení chyb, zaslání
p
Re: [Talk-cz] Tracer plugin - ruian update
Dne 10.2.2014 13:15, Jachym Cepicky napsal:
Ahoj,
nechtěl bys o tom udělat prezentaci na konferenci GIVS 2014 [1] ?
Jsou tam lidi přímo z CUZK, myslím, že by je zajímalo, jak RUIAN
používáme,
případně se s nimi pobavit o tom, co by mohlo být lepší...
Jáchym
[1] http://www.cagi.cz/konference-givs-2014
Uff, až tak?
No zkusím to promyslet.
Marián
On Sun, Jan 26, 2014 at 10:48:02PM +0100, Marián Kyral wrote:
Ahoj,
Tak jsem se trochu vrtal v Tracer pluginu. Nejprve jsem chtěl jen
změnit natvrdo zadrátovanou adresu serveru, abych se dokázal
připojit na ruian server od Petra Vejsady. To se povedlo, takže jsem
uvažoval nad forkem, ale nakonec jsem se rozhodl pro úpravu
původního Tracer pluginu (zásuvného modulu :-D ).
Předesílám, že nejsem java programátor, ve skutečnosti jsem se javě
zatím úspěšně vyhýbal. O to to pak bylo horší :-D Výsledné řešení je
inspirováno několika pluginy a různými příklady na webu.
_Takže co se změnilo:_
*) Původní funkcionalita zůstala zachována (klávesová zkratka "T")
*) Přidal jsem "RUIAN" režim - dostupný z menu, nebo pod klávesovou
zkratou "Ctrl+T"
*) Z Tracer2 pluginu jsem použil vylepšenou třídu ConnectWays, která
umí aktualizovat tvar současné budovy. Prosím nezneužívat - Petr má
ohledně této funkce obavy :-D
*) Při tracování z RUIAN se přidá ruian id a pokud je znám, tak i
typ budovy. (pouze pokud je building=yes). Převod na OSM typy budov
bude asi potřeba ještě trochu doladit.
*) Přidal jsem konfiguraci. Dá se nastavit vlastní adresa serveru a
případně i posunout polohu natrasované budovy. Třeba tady u nás v
Beskydech je RUIAN oproti KM mírně posunutý (asi přepočet, ale je to
mnohem lepší než KM). Pro RUIAN to funguje, u KM moc ne. Ten mi
každou budovu vrátí s trochu jiným posunem :-(
_Známé chyby:_
*) U domů nalepených na sobě nebo třeba řadě garáží se generují
duplicitní body. Ty je potřeba ručně sloučit. Pokusím se to nějak
opravit, ale až tak tomu kódu zase nerozumím :-D
*) Na rovných čarách se objevují nadbytečné body, zpravidla v
místech, kde je v KM napojení další čáry, která není součástí
budovy. Takhle to je už v RUIAN - s Petrem to plánujeme nějak
odfiltrovat.
*) Plugin neukazuje verzi - problém testovacího buildu, po nahrání
do repozitáře JOSM by mělo být v pohodě. Možná to jde i jinak, ale s
ANTem si zatím netykám.
*) Zatím chybí překlad - i18n.pl má s mým .po souborem nějaký
problém :-(
Při práci s pluginem doporučuji jako podkladovou vrstvu Bing (pokud
je v daném místě dostatečné rozlišení, pak RUIAN vrstvu od Petra (
tms:http://tile.poloha.net/budovy/{zoom}/{x}/{y}.png ) a nahoru KM.
Bohužel data v RUIAN nejsou až tak přesné. Někde budova chybí, jinde
přebývá, případně má jiný tvar. Je třeba kontrolovat oproti KM a
podezřelé případy pak ověřit i jinak.
Plugin je ke stažení zde: http://www.kyralovi.cz/tmp/josm/tracer.jar
Zdrojáky tady: https://github.com/mkyral/josm-tracer/commits/ruian
A na závěr pár screenshotů:
Budova před: http://www.kyralovi.cz/tmp/josm/tracer_before.png
Menu: http://www.kyralovi.cz/tmp/josm/tracer_menu.png
Trasování: http://www.kyralovi.cz/tmp/josm/tracer_trace.png
Výsledek: http://www.kyralovi.cz/tmp/josm/tracer_result.png
Nastavení: http://www.kyralovi.cz/tmp/josm/tracer_prefs.png
Na výsledku je vidět, ruian ID i změna typu budovy z "building=yes"
nad "building=house".
Upozorňuji, že v příkladu používám posun. tvar budovy je získán z
RUIANu (fialová čára), ale byl posunut na pozici dle KM (zelená
čára).
Prosím o otestování, kontrolu zdrojáků, nahlášení chyb, zaslání
patchů, zaslání pěknější ikony ;-).
Pokud nebudou výhrady, rád bych tuto změnu dostal v dohledné době do
josm svn.
Marián
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer plugin - ruian update
Zdravím všechny, před časem se tu mluvilo o transformaci z/do S-JTSK. Kolega mi odpověděl na dotaz - je to tak, že transformační program od VÚGTK, zmíněný na http://www. cuzk.cz/Zememerictvi/Geodeticke-zaklady-na-uzemi-CR/GNSS/Nova-realizace- systemu-ETRS89-v-CR.aspx, je placený a tedy ani není možné získat jeho fortranovský zdroják, o kterém se píše v "Metodice převodu" (odkaz na konci zmíněné stránky). Případné dotazy směrujte přímo na VÚGTK (http://www.vugtk. cz) :-). K té přesnosti - tohle je přesně ten důvod, proč neexistuje jednoznačný matematický vztah pro transformaci mezi S-JTSK a ETRS89 (WGS84). Odchylky se řeší interpolací oprav podle zveřejněné tabulky odchylek mezi S-JTSK/95 a S- JTSK. Rozdíl proti odkazu dole je, že se do výpočtu matice ochylek braly nejen body DOPNUL, ale i další body základního polohového bodového pole a zhušťovací body, na kterých byly určeny souřadnice jak v S-JTSK, tak v ETRS 89. Matice odchylek je volně dostupná a lze ji využít v libovolném transformačním programu. Schválení ČÚZK podléhají pouze ty transformační programy, které se používají k předávání výsledků zeměměřických činností (zjednodušeně řečeno). J. Veselý -- Původní zpráva -- Od: hanoj Datum: 10. 2. 2014 Předmět: Re: [Talk-cz] Tracer plugin - ruian update " > Jinak co se diskutovany presnosti tejce, vidim tam posun vuci KM o cca 10 cm ... coz neni nic tragickyho, ale zajimavy to teda je. *** uz se prosim nedivme, ale chapejme: http://grass.fsv.cvut.cz/gwiki/Chyba_p%C5%99i_transformaci_z_WGS84_do_S-JTSK (http://grass.fsv.cvut.cz/gwiki/Chyba_p%C5%99i_transformaci_z_WGS84_do_S-JTSK) ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz";___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer plugin - ruian update
Ahoj, Dne 10.2.2014 14:24, Marián Kyral napsal(a): > Dne 10.2.2014 13:56, jzvc napsal: >> 2) v RUIANu nejsou ty pristavky co sou v KM? Pripadne odkud se v KM >> berou? Protoze ty to rozhodne netrasuje. Pokud by trasovalo, byl by asi >> vyresen problem vejs. > > Nejsou, nejsou. Když si zapneš tu vrstvu budov od Petra Vejsady a přes to > si dáš vrstvu KM, tak uvidíš, že ty přístavky jsou dělány tenčí čarou a > třeba původní tracer server je nevidí = je to v jiné vrstvě KM. (ale záleží > na konfiguraci Tracer Serveru) Většinou jsou uvedeny v tabulce parcela jako zastavěná plocha (druh_pozemku_kod = 13). Problém je, že do téhle kategorie spadá všechno možné - od parkovací plochy po normální dům. Např. toto: http://vdp.cuzk.cz/vdp/ruian/parcely/2430440606 zahrnuje na východní straně i venkovní schody k zadnímu vchodu do sklepa a přitom odpovídající stavební objekt: http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/7666926 má hranice odpovídající jen jednomu vchodu z pěti Zdraví, Petr Morávek aka Xificurk ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] stav UHUL ortofoto
On Mon 2014-02-10 13:51:07, hanoj wrote: > > > mate predstavu, co se stalo s UHUL:ortofoto a jestli ji budeme > > > mit jeste dotupnou? Pokud pouziji URL prednastavene v JOSM, tedy > > > > Mam lokalni kopii UHUL:ortofoto; chvili byla i na openaerialmap. Takze > > kdyby byl zajem, slo by to nekde zprovoznit. Licence to tusim > > dovoluje. > *** Zadnou licenci k UHUL:ortofoto nedisponujeme, UHUL to poskytoval na > dobre slovo. I proto to bylo v rozporu s podminkami nekdejsiho > openaerialmap.org http://wiki.openstreetmap.org/wiki/En:WikiProject_Czech_Republic/freemap se tvari ze UHUL ortofoto je oficialni dilo a tutiz na to zadnou licenci nepotrebujem... 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@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] stav UHUL ortofoto
On Mon 2014-02-10 13:32:24, Jachym Cepicky wrote: > Vzhledem k tomu, jaké teď na UHULe panují poměry bych byl překvapený, kdyby to > někdo kvůli OSM dal dohromady > > Obávám se, že jsme bez ortofota Jak rikam, mam lokalni kopii. Ani neni tak velka (1.6GB). Pak mam taky notebooka a ADSL, coz znamena, ze se mi asi neche pustit tileserver doma. Na druhou stranu, nekdo tu trema ma pocitac na silny lince s 1.6GB mista? 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@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] stav UHUL ortofoto
Dne 10.2.2014 21:33, Pavel Machek napsal(a): On Mon 2014-02-10 13:51:07, hanoj wrote: mate predstavu, co se stalo s UHUL:ortofoto a jestli ji budeme mit jeste dotupnou? Pokud pouziji URL prednastavene v JOSM, tedy Mam lokalni kopii UHUL:ortofoto; chvili byla i na openaerialmap. Takze kdyby byl zajem, slo by to nekde zprovoznit. Licence to tusim dovoluje. *** Zadnou licenci k UHUL:ortofoto nedisponujeme, UHUL to poskytoval na dobre slovo. I proto to bylo v rozporu s podminkami nekdejsiho openaerialmap.org http://wiki.openstreetmap.org/wiki/En:WikiProject_Czech_Republic/freemap se tvari ze UHUL ortofoto je oficialni dilo a tutiz na to zadnou licenci nepotrebujem... Pavel A neni nahodou orthofoto cuzk presne totez? Tedy tzv "uredni dilo"? http://geoportal.cuzk.cz/Default.aspx?mode=TextMeta&side=wms.verejne&metadataID=CZ-CUZK-WMS-ORTOFOTO-P&metadataXSL=metadata.sluzba&menu=3118 "Podmínky užití - zpoplatnění služby Žádné podmínky neplatí." => primo na webu povoleno zcela bezpodminecne pouzivani. Jinak AZ (dovolim si myslet, ze jde o verejnou listinu a rejstrik, pripadne uredni dokumentaci slouzici jako podklad + verejny zajem by tu jiste byl taky): "Ochrana podle práva autorského se nevztahuje na a) úřední dílo, jímž je právní předpis, rozhodnutí, opatření obecné povahy, veřejná listina, veřejně přístupný rejstřík a sbírka jeho listin, jakož i úřední návrh úředního díla a jiná přípravná úřední dokumentace, včetně úředního překladu takového díla, sněmovní a senátní publikace, pamětní knihy obecní (obecní kroniky), státní symbol a symbol jednotky územní samosprávy a jiná taková díla, u nichž je veřejný zájem na vyloučení z ochrany" ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] stav UHUL ortofoto
On 10.2.2014 21:39, Pavel Machek wrote: Jak rikam, mam lokalni kopii. Ani neni tak velka (1.6GB). Pak mam taky notebooka a ADSL, coz znamena, ze se mi asi neche pustit tileserver doma. Na druhou stranu, nekdo tu trema ma pocitac na silny lince s 1.6GB mista? Pavel Ahoj, co by tileserver obnášel? Jde jen o distribuci vygenerovaných dlaždic, nebo ty se generují on-demand skriptem z databáze? LuKo ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] stav UHUL ortofoto
On Mon 2014-02-10 22:39:52, Lukas Kohout wrote: > On 10.2.2014 21:39, Pavel Machek wrote: > >Jak rikam, mam lokalni kopii. Ani neni tak velka (1.6GB). Pak mam taky > >notebooka a ADSL, coz znamena, ze se mi asi neche pustit tileserver > >doma. Na druhou stranu, nekdo tu trema ma pocitac na silny lince s > >1.6GB mista? > > > > Pavel > Ahoj, co by tileserver obnášel? Jde jen o distribuci vygenerovaných > dlaždic, nebo ty se generují on-demand skriptem z databáze? Jen distribuce vygenerovanych dlazdic, zda se ze je to tohle: http://tilecache.org/ . 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@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] stav UHUL ortofoto
Spíše jen něco jako klasický webserver. TileCache mi přijde pro tento účel příliš složitá věc, která řeší generování v případě, že dlaždice není v cache apod. Dlaždice zřejmě budou samostatné jpg (příp. png/gif) soubory v nějaké adresářové struktuře, aby jich nebylo mnoho v jednom adresáři. A jediné, co je potřeba, tak je umožnění přístupu k nim přes HTTP protokol. Šlo by ty dlaždice ve formě nějakého archivu někam veřejně nahrát a dát se odkaz? Honza Dne 10. února 2014 23:48 Pavel Machek napsal(a): > On Mon 2014-02-10 22:39:52, Lukas Kohout wrote: > > On 10.2.2014 21:39, Pavel Machek wrote: > > >Jak rikam, mam lokalni kopii. Ani neni tak velka (1.6GB). Pak mam taky > > >notebooka a ADSL, coz znamena, ze se mi asi neche pustit tileserver > > >doma. Na druhou stranu, nekdo tu trema ma pocitac na silny lince s > > >1.6GB mista? > > > > > > Pavel > > Ahoj, co by tileserver obnášel? Jde jen o distribuci vygenerovaných > > dlaždic, nebo ty se generují on-demand skriptem z databáze? > > Jen distribuce vygenerovanych dlazdic, zda se ze je to tohle: > http://tilecache.org/ . > > > 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@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz > ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] stav UHUL ortofoto
zdar, > Na druhou stranu, nekdo tu trema ma pocitac na silny lince silný? - no ... co Netbox dá za nejmíň peněz ... > s 1.6GB mista? to je ten menší problém pošli mi svůj veřejnej klíč, jestli seš ochoten mi to tam SCoPírovat :-) K. ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
[Talk-cz] Adresy z RUIAN
Ahoj, také jsem pilný a zdá se, že nástroj na nahrávání adres z RUIAN je hotov. Funguje tak, že se vybere oblast, pustí se SQL skript a za pár (desítek) minut je připravený changeset pro JOSM. K tomu z toho vypadnou varovací tabulky se seznamem míst, kde si to neporadilo a chce to lidský průzkum. Počet vět v těchto tabulkách je nepřímo úměrný kvalitě dat v RUIAN v dané oblasti ;-) Podle tabulek s problémy se pak dají patřičná místa pravit v JOSM před uploadem. Potřebuji se domluvit na podobě dat. Tyto tagy se zpracovávají: addr:city - obec addr:conscriptionnumber - číslo popisné addr:housenumber - složenina, jak je popsaná na Wiki, tedy ev. či / atd, addr:provisionalnumber - evidenční číslo addr:streetnumber - číslo orientační addr:place - část obce addr:street - ulice addr:postcode - PSČ source:addr=cuzk:ruian ref:ruian= Na ostatní tagy nesahám, tedy nesahám ani na is_in, source, addr:country či další addr: či ne-addr:. Nesahám ani na souřadnice. Algoritmus je osmiprůchodový, z toho 6 průchodů je na vlastní přiřazení a zbylé 2 jsou na generování varovných tabulek. Zdrojáky tajné nejsou, je to 100% plpgsql/postgis, nicméně netvořil jsem to pro uživatele, ale pro sebe a tak kód odráží moji místní situaci - vyžaduje schema RUIAN, OSM APIDB (nikoli samotné API, jen databázové schema) a Mapnik schema. Urcite by slo predelat pro snapshot schema, které má sympatický HSTORE, ale v tuto chvíli to tak není hlavně proto, protože snapshot schema nemám. Pracuje to se všemi typy entit - s body, cestami/polygony i relacemi. Nalezne- li entitu s adresou (což nalezne skoro vždy), upraví ji tak, že nahradí výše zmíněné tagy a ostatních si nevšímá. Nenalezne-li, vytvoří nový adresní bod se souřadnicemi z RUIAN, a to buď deiniční bod adresního místa, není-li, pak deiniční bod stavebního objektu, není-li tak st_centroid stavebního objektu. Není-li, tak nic; na parcelu už jsem nešel, mohlo by to být geometricky dost mimo. Co se týká mazání, tak momentálně se nic nemaže. Pamatuji si, který den to zpracuje která data a může pak porovnávat s RUIAN a mazat by se mohlo tehdy, kdy se adresa smaže z RUIAN a zároveň bylo toto místo zpracováno. Zásadní otázka č.1 - co s tagy addr:country a is_in? Možnosti jsou ponechat, mazat či nahrazovat. Jaký máte názor? Zásadní otázka č.2 - zda do toho vůbec jít, tedy začít probírat celou republiku a pokud ano, co je třeba předtím udělat? O pravidlech pro importy ponětí mám a tak zahajuji diskusi s místní komunitou ;-). Mojí motivací bylo a je hlavně to, že Nominatim ve stávajících datech moc hledat neumí, protože is_in ho vůbec nezajímá, takže hlavně přidat addr:place, sjednotit vše a snad tedy zlepšit. -- Petr, p...@propsychology.cz >p< ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Rastr (hillshade) v pgsql a Mapnik
Zdravím, Dne Po 10. února 2014 13:30:57, Jachym Cepicky napsal(a): > Jestli se nepletu, tak Paul Ramsay důrazně nedopurčoval, dávat do PostGISu > rastry. To že něco jde ještě neznamená, že je to dobrej nápad. Zkuste to > vyexportit to geotiffu a přistupovat k tomu z gdalu "normálně" no já to právě v geotiffu teď mám a chtěl jsem do Postgisu, protože se snáze přidávají a ubírají územní části. Asi mi nezbude než to tak nechat. Pravda, Postgis je o něco pomalejší. Už jsem přišel na to, proč ta chyba, ovšem nevím řešení. Je to proto, protože z Pythonu je cesta k osm.xml relativní (je v ./) a tak ta definice souboru, kde je DB zdroj, zůstane nedotčena, kdežto při při volání z mod_tile je cesta absolutní a pak z toho vznikne to /home/mapnik/.../PG: OK, tak alespoň mám důvod se přestat snažit. > > J > > On Thu, Feb 06, 2014 at 12:26:43AM +0100, Petr Vejsada wrote: > > Ahoj, > > > > už delší dobu se nemohu hnout z místa, tak se zeptám. Chtěl bych mít v > > databázi rastrovou vrstvu pro reliéy/stínování a to pak zobrazovat > > Mapnikem. > > > > Mapnik přímo to v aktuální stabilní verzi (asi) nepodporuje, ale umí to > > GDAL a Mapnik zase umí GDAL. > > > > Zkusil jsem Mapniku podstrčit jako zdroj dat GDAL, jen jsem si 'trochu' > > > > poupravil název souboru. Konfigurace vypadá takto: > > > > > > gdal > > PG:dbname=pedro port=5432 schema=gis > > > > table=cz_hillshade mode=2 > > > > tiff > > > > > > > > Když zavolám Mapnik z Pythonu, použiji skripty na generování dlaždic nebo > > obrázku generate_tiles.py nebo generate_image.py, tak vše funguje podle > > mých představ. Data bere z postgresql a vykreslí, co chci. GDAL to, co je > > v parametru vezme jako datasource z databáze a vše je OK. > > > > Pokud to chci dát do produkčního režimu, tedy přes Tirex a mod_tile, už se > > to nezdaří. Do syslogu dostanu hlášku: > > > > Feb 5 21:08:52 propsy tirex-backend-mapnik[10981]: Renderer started > > (name=mapnik) > > Feb 5 21:08:57 propsy tirex-backend-mapnik[10981]: cannot add > > /etc/tirex/renderer/mapnik/hill.conf > > Feb 5 21:08:57 propsy tirex-backend-mapnik[10981]: > > `/home/mapnik/layers/hill/PG:dbname=pedro port=54 > > 32 schema=gis table=cz_hillshade mode=2' does not exist in the file > > system, and is not recognised as > > a supported dataset name. encountered during parsing of layer > > 'hillshade' in Layer at line 5 of '/h > > ome/mapnik/layers/hill/osm.xml' > > > > Nemohl jsem přijít na to, co vlastně tu hlášku "file ... does not exist in > > the file system, and is not recognised as a supported dataset name" > > způsobuje. Pak jsem vygrepoval, že je to GDAL. > > > > Otázkou je, proč GDAL při volání Mapniku z Pythonu ten parametr v pohodě > > vezme jako DB resource, kdežto při volání z Tirexu tvrdošíjně hledá > > soubor toho názvu, co je v parametru . > > > > Tirex asi volá Mapnik jiným způsobem, nebo že by sám parsoval konfiguraci > > Mapniku a testnul si GDAL, jestli bude s takovým souborem spokojený? > > > > Nesetkal jste se s tímto někdo? > > > > -- > > Petr, p...@propsychology.cz > > > > >p< > > > > ___ > > Talk-cz mailing list > > Talk-cz@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Adresy z RUIAN
Dne 11.2.2014 01:06, Petr Vejsada napsal: Ahoj, také jsem pilný a zdá se, že nástroj na nahrávání adres z RUIAN je hotov. Funguje tak, že se vybere oblast, pustí se SQL skript a za pár (desítek) minut je připravený changeset pro JOSM. K tomu z toho vypadnou varovací tabulky se seznamem míst, kde si to neporadilo a chce to lidský průzkum. Počet vět v těchto tabulkách je nepřímo úměrný kvalitě dat v RUIAN v dané oblasti ;-) Podle tabulek s problémy se pak dají patřičná místa pravit v JOSM před uploadem. Ty tabulky mají stejný formát jako to csv co jsi posílal? Nebylo by lepší ty sporné body nějak označit? Třeba tagem fixme. Líp se to pak bude v JSOM hledat/opravovat. Potřebuji se domluvit na podobě dat. Tyto tagy se zpracovávají: addr:city - obec addr:conscriptionnumber - číslo popisné addr:housenumber - složenina, jak je popsaná na Wiki, tedy ev. či / atd, addr:provisionalnumber - evidenční číslo addr:streetnumber - číslo orientační addr:place - část obce addr:street - ulice addr:postcode - PSČ source:addr=cuzk:ruian ref:ruian= Na ostatní tagy nesahám, tedy nesahám ani na is_in, source, addr:country či další addr: či ne-addr:. Nesahám ani na souřadnice. Algoritmus je osmiprůchodový, z toho 6 průchodů je na vlastní přiřazení a zbylé 2 jsou na generování varovných tabulek. Zdrojáky tajné nejsou, je to 100% plpgsql/postgis, nicméně netvořil jsem to pro uživatele, ale pro sebe a tak kód odráží moji místní situaci - vyžaduje schema RUIAN, OSM APIDB (nikoli samotné API, jen databázové schema) a Mapnik schema. Urcite by slo predelat pro snapshot schema, které má sympatický HSTORE, ale v tuto chvíli to tak není hlavně proto, protože snapshot schema nemám. Udělej tomu nějakou konfiguraci, případně by mohlo nastavit si nějaká ta synonyma. Koukal jsem, že postgresql by to měl umět. Myslím, že třeba pro studijní by se to mohlo hodit. Pracuje to se všemi typy entit - s body, cestami/polygony i relacemi. Nalezne- li entitu s adresou (což nalezne skoro vždy), upraví ji tak, že nahradí výše zmíněné tagy a ostatních si nevšímá. Nenalezne-li, vytvoří nový adresní bod se souřadnicemi z RUIAN, a to buď deiniční bod adresního místa, není-li, pak deiniční bod stavebního objektu, není-li tak st_centroid stavebního objektu. Není-li, tak nic; na parcelu už jsem nešel, mohlo by to být geometricky dost mimo. Co se týká mazání, tak momentálně se nic nemaže. Pamatuji si, který den to zpracuje která data a může pak porovnávat s RUIAN a mazat by se mohlo tehdy, kdy se adresa smaže z RUIAN a zároveň bylo toto místo zpracováno. Zásadní otázka č.1 - co s tagy addr:country a is_in? Možnosti jsou ponechat, mazat či nahrazovat. Jaký máte názor? Určitě nechat, případně opravit, ať je to aktuální. Když to tam zůstane, tak se nic strašného nestane. Zásadní otázka č.2 - zda do toho vůbec jít, tedy začít probírat celou republiku a pokud ano, co je třeba předtím udělat? O pravidlech pro importy ponětí mám a tak zahajuji diskusi s místní komunitou ;-). Nebylo by škoda teď skončit, když už jsi tomu věnoval tolik času a energie? V nejhorším bych mohl udělal nějaký plugin, který by to dokázal využít. BTW: czechaddress plugin by asi chtěl taky opravit. Přidat možnost doplnit chybějící údaje z RUIAN (pokud jsou k dispozici). BTW 2: na Slovenském mailing listu je teď taky zajímavá debata o odresách: https://groups.google.com/forum/#!topic/osm_sk/YJr78HvG2TA Marián Mojí motivací bylo a je hlavně to, že Nominatim ve stávajících datech moc hledat neumí, protože is_in ho vůbec nezajímá, takže hlavně přidat addr:place, sjednotit vše a snad tedy zlepšit. -- Petr, p...@propsychology.cz p< ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Adresy z RUIAN
Dne 11.2.2014 06:07, Marián Kyral napsal: Dne 11.2.2014 01:06, Petr Vejsada napsal: Zásadní otázka č.2 - zda do toho vůbec jít, tedy začít probírat celou republiku a pokud ano, co je třeba předtím udělat? O pravidlech pro importy ponětí mám a tak zahajuji diskusi s místní komunitou ;-). Nebylo by škoda teď skončit, když už jsi tomu věnoval tolik času a energie? V nejhorším bych mohl udělal nějaký plugin, který by to dokázal využít. Tak mně tak napadá, nedalo by se to brát jako součást/rozšíření projektu Import Adres ČR? ( http://wiki.openstreetmap.org/wiki/Import_Adres_%C4%8CR ). Pak by celá ta procedura mohla být jednodušší. Marián ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] stav UHUL ortofoto
On Mon, Feb 10, 2014 at 09:39:35PM +0100, Pavel Machek wrote: > On Mon 2014-02-10 13:32:24, Jachym Cepicky wrote: > > Vzhledem k tomu, jaké teď na UHULe panují poměry bych byl překvapený, kdyby > > to > > někdo kvůli OSM dal dohromady > > > > Obávám se, že jsme bez ortofota > > Jak rikam, mam lokalni kopii. Ani neni tak velka (1.6GB). Pak mam taky > notebooka a ADSL, coz znamena, ze se mi asi neche pustit tileserver > doma. Na druhou stranu, nekdo tu trema ma pocitac na silny lince s > 1.6GB mista? Jo, mam. Pokud bude shoda, ze to je legalni, tak velmi rad zprovoznim. -- Tomas Kasparek E-mail: kaspa...@fit.vutbr.cz CVT FIT VUT Brno, L127 Web:http://www.fit.vutbr.cz/~kasparek Bozetechova 1, 612 66Fax:+420 54114-1270 Brno, Czech Republic Phone: +420 54114-1220 jabber: tomas.kaspa...@jabber.cz GPG:2F1E 1AAF FD3B CFA3 1537 63BD DCBE 18FF A035 53BC May the command line live forever! pgpyJwUd4oRkA.pgp Description: PGP signature ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Adresy z RUIAN
Dne 11.2.2014 01:06, Petr Vejsada napsal(a): > Co se týká mazání, tak momentálně se nic nemaže. Pamatuji si, který den to > zpracuje která data a může pak porovnávat s RUIAN a mazat by se mohlo tehdy, > kdy se adresa smaže z RUIAN a zároveň bylo toto místo zpracováno. > > Zásadní otázka č.1 - co s tagy addr:country a is_in? Možnosti jsou ponechat, > mazat či nahrazovat. Jaký máte názor? Asi by bylo dobré udělat nějakou základní analýzu obsahu is_in tagu - pokud obsahuje jen část obce, obec, stát... (nebo čárkami oddelenou kombinaci), tak smazat. Pokud jsou všechna data is_in tagu obsažena ve strukturované podobě v addr:*, tak si myslím, že nemá cenu, aby nám tu nadále strašil. Zdraví, Petr Morávek aka Xificurk ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Adresy z RUIAN
Ahoj, Dne Út 11. února 2014 06:07:17, Marián Kyral napsal(a): > > těchto tabulkách je nepřímo úměrný kvalitě dat v RUIAN v dané oblasti > > ;-) > > Podle tabulek s problémy se pak dají patřičná místa pravit v JOSM před > > uploadem. > > Ty tabulky mají stejný formát jako to csv co jsi posílal? > Nebylo by lepší ty sporné body nějak označit? Třeba tagem fixme. Líp se > to > pak bude v JSOM hledat/opravovat. to mě nenapadlo, zato mě napadlo, a je tam, do těch tabulek dát odkaz na http://localhost:8111 ..., takže zkopírovat url do prohlížeče a JOSM na to msto skočí. Výhoda je, že ty FIXME se nemusí pak v JOSM mazat. Varuje třeba před adresními body příliš blízko u sebe, ale stane se, že je to 100 garáží, kde je to legitimní a pak bych musel 100 garáží editovat, kdežto takto to stačí jen zkouknout a nechat být :) > > schema. Urcite by slo predelat pro snapshot schema, které má sympatický > > HSTORE, ale v tuto chvíli to tak není hlavně proto, protože snapshot > > schema > > nemám. > > Udělej tomu nějakou konfiguraci, případně by mohlo nastavit si nějaká ta > synonyma. Koukal jsem, že postgresql by to měl umět. Myslím, že třeba > pro studijní > by se to mohlo hodit. Hm, teď ne, možná někdy -> asi určitě ne, pže čas, musel bych studovat snapshot schema atd. a bez testování to nemá smysl. Může si to udělat, kdo bude chtít ;) > > Zásadní otázka č.1 - co s tagy addr:country a is_in? Možnosti jsou > > ponechat, > > mazat či nahrazovat. Jaký máte názor? > > Určitě nechat, případně opravit, ať je to aktuální. Když to tam zůstane, > tak > se nic strašného nestane. Ta varianta ponechat má nevýhodu, že data budou vlastně pocházet z různých zdrojů. addr:country a is_is bude z původního zdroje a zbytek z RUIAN, tak já bych to viděl buď na zahodit nebo přepsat. > > > Zásadní otázka č.2 - zda do toho vůbec jít, tedy začít probírat celou > > republiku a pokud ano, co je třeba předtím udělat? O pravidlech pro > > importy > > ponětí mám a tak zahajuji diskusi s místní komunitou ;-). > > Nebylo by škoda teď skončit, když už jsi tomu věnoval tolik času a > energie? > V nejhorším bych mohl udělal nějaký plugin, který by to dokázal využít. no něco s tím určitě naadresuji, otázka byla spíš na globálnost celé akce. Například okres Vyškov byl opravdu dost bílý. Naklikal jsem tam tisíce budov tracerem, takže je dobře otestovaný (známé bugy: bug serveru - když je oblouk tvořený tak mnoha body, že změna úhlu mezi třemi po sobě jdoucími body je méně než 3 stupně, tak ty body postupně zahodí úplně všechny a oblouk zmizí a bug pluginu - křížící se budovy - napojování). Ten okres Vyškov jsem zkoušel, všude OK, jen v samotném Vyškově pracují asi nějací horliví kartoilové, protože jsou tam mraky adresních bodů 2x i 3x na stejném místě. Liší se jménem ulice nebo dokonce částí obce (Vyškov X Vyškov- předměstí např.) -- Petr ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Adresy z RUIAN
Dne Út 11. února 2014 06:07:17, Marián Kyral napsal(a): > Ty tabulky mají stejný formát jako to csv co jsi posílal? > Nebylo by lepší ty sporné body nějak označit? Třeba tagem fixme. Líp se > to > pak bude v JSOM hledat/opravovat. pro ty, co mají přístup sem do DB - jsou to view osmimport.warnings_view, osmimport.warnings_view_full a osmimport.morewarnings -- Petr ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
