Re: [Talk-cz] stav UHUL ortofoto

[Jan Bilak]

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] Aplikace TerrainGIS pro Android

[Jan Bilak]

Ahoj,

můžeš, prosím, uvést praktické výhody oproti Vespucci OSM Editoru:
https://play.google.com/store/apps/details?id=de.blau.android

Honza


Dne 16. září 2013 21:43 Vojtěch Kalčík  napsal(a):

>  Ahoj,
>
> jako diplomku jsem dělal open source program TerrainGIS pro mapování v
> terénu pro Android. Dnes jsem ho zveřejnil na Google Play.
>
> http://vojta.kalcik.cz/doku.php?id=programy:terraingis
> https://play.google.com/store/apps/details?id=cz.kalcik.vojta.terraingis
>
> Styl používání programu je spíše bližší klasickým GISům. Do programu je
> možné importovat a exportovat vrstvy v formátu Shapefile. Vnitřně jsou
> geodata uložená ve SpatiaLite databázi. Jako podkladová mapa se používají
> dlaždice z OSM, které se kešují pro off-line použití. Aplikace vyžaduje
> Android 4.x
>
> V Josm je možné otevírat Shapefile pomocí pluginu opendata. Není úplně
> vhodné použít data z Shapefile přímo, protože v Shapefile se nedá uložit
> topologie objektů. Shapefile je možné v Josm převést do GPX vrstvy.
>
> Aplikace by se dala dál rozvíjet, ale ještě nevím jestli o ní bude zájem.
>
> Vojtěch Kalčík
>
> ___
> 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] MTB mapa vyhledava trasy

[Jan Bilak]

a) Jaké vlastnosti mají namáhavost a působivost? Tedy mám dva úseky cesty s
namáhavostí n_1 a n_2 a působivostí p_1 a p_2, jaká bude namáhavost n a
působivost p složené cesty z těchto dvou úseků? Součet, maximum, vážený
průměr s váhou délky úseku, ...?

b) Nějaké pojmenované profily mi dávají smysl, protože řekněme jízda na
horském kole a na silničním (pokud pominu, že jde o MTB mapu) je z principu
jiná a nelze dost dobře vyjádřit zmíněným vzorečkem.

c) Mě dává smysl mít možnost nastavit i další parametry (jako nějaké
"advanced settings"). Např. za žádných okolností nechci jezdit po silnici
vyšší třídy. Nebo naopak třeba chci jezdit pouze po kvalitních cestách
(asfalt apod.) a rozhodně nechci jezdit po nějaké lesní cestičce. Nebo
maximálně preferuji rovinatý terén a kvalita povrchu je pro mě druhořadá.
Jen bude vhodné nastavení předělat tak, aby bylo lépe pochopitelné pro
běžné uživatele. Naopak pro pokročilé uživatele podrobněji vysvětlit, jaký
to má vlastně dopad na algoritmus hledající cestu.

Honza


Dne 13. června 2013 2:24 Jan Kouba  napsal(a):

> **
>
> Ahoj,
>
>
>
> nevadí, já jsem jen tak doufal, že když už umíte počítat výškový profil
> trasy, tak třeba už máte pro každou cestu její profil spočítaný a uložený.
>
>
>
>
>
>
>
> Mám ještě připomínku k těm parametrům vyhledávání. Teď je to strašně
> komplikované. Pokud jsem dobře počítal, tak je tam kolem 50 různých
> nastavení, což musí spolehlivě odradit každého.
>
>
>
> Navíc není vůbec zřejmé, jak se ta nastavení parametrů projevují v
> ohodnocení grafu cest. Jde třeba nějak nastavit, aby highway=path s
> mtb:scale=0 byla víc vhodná než highway=path s mtb:scale=1? Nejak se mi to
> nepodařilo.
>
>
>
> Pro vyhledávání trasy pro horské kolo by mi přišlo ideální, kdyby uživatel
> měl jen jedno nastavení a to "obtížnost". Tím by říkal, o kolik obtížnější
> může trasa být v porovnání s nejméně obtížnou trasou, která vůbec nebere v
> potaz vhodnost cest.
>
>
>
> Ohodnocení cest by se pak počítalo takto: Pro každou cestu a směr by se
> braly v úvahu dvě veličiny, "namáhavost" a "působivost", a ty by se pak
> spolu s nastavenou obtížností použily k vypočítání celkové váhy cesty.
>
>
>
> Namáhavost by říkala, kolik sil stojí projet cestu v daném směru.
> Například asfaltová cesta, která vede po rovině, patří k nejméně namáhavým,
> zato pěšina s mtb:scale:uphill=5 ve směru do kopce nebo schody ve směru do
> kopce, kde se musí tlačit, patří k těm nejvíce namáhavým. Podobně cesta do
> kopce je více namáhavá, než stejná cesta po rovině a ta je více namáhavá
> než stejná cesta s kopce.
>
>
>
> Působivost by pak popisovala něco jako radost z projetí cesty. Radost může
> být buď ze samotné jízdy, nebo z okolí. Například radost z jízdy po silnici
> první třídy je většinou velmi malá, zato radost z jízdy po pěšině s
> mtb:scale=0 je většinou velmi velká. Podobně cesta která vede v rovině v
> poli s kukuřicí má asi méně působivé okolí než cesta, která vede v národním
> parku, národní přírodní rezervaci, CHKO, rezervaci UNESCO a tak podobně
> (tohle dostat z OSM dat by asi byl problém).
>
>
>
> Z namáhavosti a působivosti by se pak počítala výsledná váha cesty. To jak
> se tyto dvě veličiny zkombinují by pak záleželo na nastavení obtížnosti. Na
> nejlehčí obtížnost by algoritmus vybíral co možná nejméně namáhavé cesty s
> minimem objížděk (malá váha na působivosti). Čím těžší obtížnost, tím
> raději by algoritmus vybíral namáhavější, ale působivější cesty. Počítat by
> se to dalo asi takto:
>
>  = *( - *).
>
> Algoritmus pro hledání by pak hledal trasu s nejmenší vahou.
>
>
>
> Různých hodnot pro obtížnost by asi měl být nějaký malý počet (tak 5).
> Obdobným způsobem by se asi dala udělat i pěší navigace.
>
>
>
> Dává to smysl? Vím že tu neřeším žádné detaily, ale snad je z toho mého
> popisu zřetelny princip fungování. Co vy na to?
>
>
>
>
>
> Honza Kouba
>
>
>
>
>
>
>
>
>
> Dne Út 11. června 2013 09:25:31, Martin Tesar napsal(a):
>
> Ahoj,
>
> ze dne na den to není možné, ale dodělat by to časem určitě šlo.
>
> Výškový profil trochu (nekdy i trochu dost) přehání, musím se na to
> podívat.
>
> Diky za podněty,
>
> Martin
>
>
>
> Dne 10. června 2013 19:19 Jan Kouba  napsal(a):
>
> Ahoj,
>
>
>
> nešlo by do toho ohodnocení cest nějak zahrnout taky nastoupané metry?
> Takhle mě to pořád žene někde po kopcích, přesto že se dá jet po pěkné
> cestě (mtb:scale=0, highway=track, tracktype=grade4) i mnohem víc po
> rovině.
>
>
>
> A taky mi přijde, že ten výškový profil ukazuje více nastoupaných metrů,
> než je to ve skutečnosti.
>
>
>
> Honza Kouba
>
>
>
>
>
> Dne Po 10. června 2013 12:12:29, Martin Tesar napsal(a):
>
> Ahoj,
>
> není to nic tajného. Nahraji data do PostGISu pomocí aplikace osm2po a
> "trochu" je upravím. Přímo v databázi pak vyhledává knihovna pgRouting,
> která má jako parametr SQL dotaz, v němž specifikuju výběr cest a jejich
> ohodnocení podle veškerých parametrů a omezení. Díky tomuto dynamickému
> ohodnocování každé cesty (hrany) je to celkem pomalé,

Re: [Talk-cz] Nemehlo

[Jan Bilak]

Možná tam maluje nějaký historický stav. Nějaký Palouš v obci bydlel,
vyhořel tam i nějaký mlýn... (http://www.dbranna.cz/hiszaj.htm).

Honza


Dne 7. dubna 2013 2:18 LM_1  napsal(a):
> Mnohokrát se probíralo, že spousta uživatelů - nováčků neví, že opravdu
> upravují skutečnou mapu a bez zlých záměrů se chovají jako na pískovišti...
> LM_1
>
>
> Dne 7. dubna 2013 2:13 Michal Tauchman 
> napsal(a):
>
>> Lukas Kohout  writes:
>>
>> >
>> >
>> > Souhlasím. Také se mi tu objevil jeden
>> >   takový "aktivní blbec", který v krátkém čase vygeneroval obrovské
>> >   množství nových cest, ploch a bodů. Mlátil to do editoru, jak mu
>> >   to přišlo pod ruku, cesty a plochy náhodně přes sebe, různé
>> >   cestičky nenapojené na existující silnice, nové cesty by nejradši
>> >   v celé mapě "namaloval" jedním tahem se všemi důsledky z toho
>> >   plynoucími (např. u slepé cesty se jednoduše vrátil bez přerušení
>> >   kreslení). Keepright předtím poměrně čistý po něm hrál všemi
>> >   barvami. Při kontaktu z něj vypadlo, že OSM objevil a do editace
>> >   se pustil, aniž by si přečetl jakoukoli nápovědu. Občas to není o
>> >   tom, že to ti lidé dělají naschvál, ale jednoduše nezvládnou
>> >   nadšení z možnosti přímo editovat mapu v kombinaci s obrovskou
>> >   škálou možností a voleb, které v editoru mají k dispozici.
>> >   LuKo
>> >
>> >   On 6.4.2013 21:21, LM_1 wrote:
>> >
>> >
>> >   Předně bych ho zkusil kontaktovat. Třeba ani neví
>> > co dělá...
>> > Lukáš Matějka (LM_1)
>>
>> Já to dokážu pochopit, nejsem ras, ale proč tam kreslí nějakou vodní
>> plochu,
>> která nejspíš neexistuje? Opravdu mi to nejde do hlavy. Nepochopení
>> křížení
>> apod. dokážu pochopit, ale tohle? Jak říkám, neznám tu v okolí každý metr,
>> ale na jakýchkoli ortofoto mapách vidím, že tam žádná voda není, ani
>> nevím,
>> proč by tam někdo dělal skutečný rybník, podle mne by to ani nešlo. Ani
>> netuším, co by to mohlo být jiného. No asi ho zkusím kontaktovat, nic mi
>> jinak nezbývá, ale moc se do toho neženu. Nerad někoho kárám, samotnému
>> mi to nedělá dobře, ale když není zbytí...
>>
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] rúian bot - první výsledky testů

[Jan Bilak]

Ahoj,

jak ten bot rychlý? Aneb za jak dlouho by zpracoval (pokusně) celou ČR
- tedy vygeneroval log?

Můžeš udělat histogram vzdáleností spárovaných bodů?

Honza


Dne 6. srpna 2012 4:54 Mirek Dlask  napsal(a):
> Je otázka, zda nejsou v RÚIAN adresní body domů bez č.p. , asi tam budou
> adresní body rozestavěných domů. Ty v OSM předpokládám nejsou.
> Nebo by se asi zobrazovaly tečky bez čísel!?
>
> Buď zkusit zmenšit boxík na nějaké garáže, nebo průmysl bez č.p. ,
> nebo SELECT adresních bodů bez čísel popisných a zároveň evidenčních,
> jsou-li ...
>
>
>
> 150 je fakt nějak moc
>
> Mirek
>
> Dne 5. srpna 2012 23:30 Miroslav Šulc  napsal(a):
>>
>> tak jsem dodělal bota do stádia, že načte body z osm api a z rúian db,
>> pokusí se je spárovat a vygeneruje nějaké statistiky. pokud se někdo chce
>> podívat do kódu, tak je k dispozici na https://github.com/fordfrog/ruian2osm
>>
>> co se týče načítání bodů z api, tak jsem to omezil na nody, které mají tag
>> addr:housenumber a tag addr:country=CZ (doufám, že adresní body v čr mají
>> aspoň tyto tagy, pokud ne, tak bych to musel udělat jinak).
>>
>> pro testy jsem použil BOX(14.63 50.55,14.68 50.58).
>>
>> pro párování bodů jsem nastavil maximální povolenou vzdálenost na 0.005,
>> nicméně největší vzdálenost mezi shodnými body je 0,0009538 (RÚIAN:
>> POINT(14.6562825 50.5617608) CZ, Doksy, Hálkova 890 OSM: POINT(14.6553375
>> 50.5616313) CZ, null, Hálkova 890,
>> http://maps.fordfrog.com/?zoom=18&lat=50.56166&lon=14.65557&layers=0B0FTF).
>> u tohohle bodu je zajímavé, že údaj v kú je jiný než údaj v rúian (je to
>> vidět z kú vrstvy, u nás ale zatím neproběhla digitalizace).
>>
>> co se týče propojování, tak úspěšnost byla následující:
>> Total matched nodes: 1 136
>> Total unmatched nodes - RÚIAN: 150, OSM: 15
>>
>> z toho mj vyplývá, že pokud jsem nikde neudělal chybu, tak v dané oblasti
>> je oproti rúian navíc 15 adresních bodů a 150 jich chybí (což je opravdu
>> dost na tak malé území, aspoň podle mě).
>>
>> k párování ještě poznámka. to že se body sprárovaly ještě neznamená, že
>> osm obsahuje kompletní adresy. jak jsem psal jinde, u nás kompletně chybí
>> addr:city, součástí adresy není ani addr:postcode. párování probíhá v
>> několika cyklech, nejdříve podle celé adresy, nespárované body se pak
>> porovnávají podle ulice a čísla, a to co zbyde se nakonec porovná pouze
>> podle čísla. ve všech případech se ještě zohledňuje vzdálenost bodů. pro
>> programátory podrobnější info tady:
>> https://github.com/fordfrog/ruian2osm/blob/next_release/src/main/java/com/fordfrog/ruian2osm/AddressNodesMatcher.java
>>
>> tady je ještě údaj o průměrné vzdálenosti propojených bodů:
>> Average matched node distance: 0,046
>>
>> v příloze posílám (snad proleze zip) kompletní log z bota. uvítal bych,
>> pokud by se někdo na ten log podíval, jestli tam nenajde ještě něco
>> zajímavého (nějaké zjevné chyby, na co si dát pozor apod.). stejně tak,
>> pokud budete někdo chtít, abych pustil bota (samozřejmě pouze v testovacím
>> režimu) na nějaké vaší oblíbené oblasti, tak mi pošlete bounding box a já
>> vám pošlu log z bota.
>>
>> ff
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] import budov

[Jan Bilak]

Zdravím,

metainformace o tom, že se něco nemá importovat z RUIAN, protože je to
tam špatně, by podle mě chtělo mít přímo v OSM. A to včetně informace
o tom, odkud konkrétně ta spolehlivější informace pochází.

Honza

PS: Doplňování čp. podle čísla na popelnici nemusí být moc spolehlivé,
protože občas někdo popelnici prodá/koupí, ukradne, ... a číslo
neodpovídá.



Dne 30. července 2012 0:59 Lukas Kohout  napsal(a):
>  On 28.7.2012 23:15, Miroslav Šulc wrote:
>>
>> možná nejlepší řešení by bylo adresní body naimportovat/zaktualizovat
>> automaticky, akorát případy, kdy už adresní bod existuje a je od toho v
>> rúian vzdálený víc než x jednotek by se řešily poloautomaticky. možná by
>> nebylo špatné napsat si nějaký testovací skript, který by zjistil, jak
>> moc se aktuální data v osm liší od rúian. z toho by se pak dalo ledaco
>> vyčíst. až se mi doimportují osm data do db, tak to můžu zkusit napsat a
>> uvidíme, co tu vlastně řešíme.
>
> Zdravím, navrhuji udělat možnost vyřadit oblast z automatického
> importu/aktualizace. V naší vesnici jsou některé adresní body chybně
> umístěné, některé chybí úplně. Asi bych nebyl nadšený, kdyby mi je nějaký
> bot stále dokola automaticky přesouval/mazal (zrovna dnes jsem doplňoval
> jedno č.p. podle nálepky na popelnici, což je možné jen v neděli večer :) )
>
> LuKo
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] import budov

[Jan Bilak]

Otázka je, jak by měla vypadat ta připravená data. V případě importu
nových věcí tak, kde žádné nebyly, je to celkem primitivní. Ale mnohem
náročnější bude import do míst, kde již nějaká data jsou. Tam bude
třeba něco starého odstranit, něco modifikovat, něco přidat... Lze v
OSM formátu postihnout nějak všechny tyto typy změn (odstranění,
modifikace, přidání nových objektů)? A pokud lze, je možné to pak
nějak rozumně vizualizovat, aby to člověk mohl projít a rozhodovat
"tohle je ok, tohle zamítnu a zůstane při starém, tohle bude ještě
trochu jinak..." pomocí stávajících nástrojů? Nevím, jaké jsou
možnosti.

Pokud nic vhodné stávajícího není, tak bych to viděl spíše na
interaktivní aplikaci, která zobrazí ty rozdíly ve vhodné podobě, u
každé umožní se rozhodnout, zda ponechat stará data, nová data,
automaticky zmergovat nebo ručně upravit. Ruční úpravu by ta aplikace
přímo nepodporovala, protože by to bylo příliš náročné (vlastně by
bylo třeba vytvořit obdobu editoru jako JOSM), ale poznačilo by to
nutnost ruční editace do dat nějakými tagy, aby výsledek, který z
aplikace vypadne, bylo možné otevřít např. v JOSM a ručně provést
potřebné úpravy.

Např. u adresních bodů by bylo podle mě vhodné, aplikace provedla
nějaké "inteligentní" matchování adresních bodů v OSM a RUIAN,
zobrazovala původní a nový bod vizuálně propojený šipkou, jinak
vyznačené body, které jsou pouze v OSM a naopak jinak vyznačené body,
které jsou pouze v RUIAN. Uživatel by mohl vždy zvolit, zda ponechat
novou nebo starou polohu bodu (zde by bylo možné i volit vlastní
polohu - jde o primitivní úkon) atd. Nakonec by aplikace vytvořila OSM
patch, který by obsahoval požadované úpravy včetně vhodně zmergovaných
tagů (ty by možná bylo třeba také kontrolovat v aplikaci) atd.

U budov to bude samozřejmě výrazně složitější.

Obecně čistě ručního importu se celkem obávám. Dat je vetší než malé množství.

Honza


Dne 27. července 2012 13:41 Miroslav Šulc  napsal(a):
> Dne 27.7.2012 13:20, Jan Bilak napsal(a):
>> Ahoj,
>>
>> teď z toho nechápu, zda si aplikaci představuješ jen jako evidenční
>> nebo zda aplikace má provádět vlastní import (resp. s ním výrazně
>> pomáhat).
>
> aplikace "pouze" připraví data z rúian, samotný import provede mapper.
> tj. aplikace pro import připraví data, ale nebude import provádět, ten
> se bude dělat ručně. i kdybychom (pokud vůbec, to vyplyne z ručních
> importů) v budoucnu uvažovali o nějaké automatizaci, tak v prvním kroku
> se to stejně musí udělat ručně, abychom věděli, nakolik je rúian
> spolehlivý zdroj, jaké problémy lze očekávat apod. pro kontinuální práci
> s daty z rúian je pak potřeba ta evidenční část.
>
>> Tedy za zásadní považuji porovnání současných OSM dat s daty RUIAN a
>> následné provedení změn (posuny stávajících bodů, opravy tagů,
>> zachování stávajících tagů, doplnění chybějících tagů, ...).
>> Samozřejmě s tím, že proces bude pod manuální kontrolou člověka, který
>> bude import provádět (tedy nikoli plně automatický, ale
>> poloautomatický). O těchto funkcích se v popisu nezmiňuješ.
> vycházel jsem hlavně z importu budov tam, kde je nemáme, to je asi ta
> nejjednodušší varianta. co se týče importu budov do míst, kde už nějaké
> jsou, nebo importu adresních bodů, tak se přiznám, že nevím, jestli v
> josm existují nástroje na zobrazení rozdílů ve vrstvách, na slučování
> objektů (a tagů) z různých vrstev apod. s tím zkušenosti nemám. ale
> určitě se tu najde někdo, kdo to vědět bude nebo aspoň bude vědět, kde
> hledat.
>
> ten můj nástřel je v podstatě (podle mě) asi to nejnutnější minimum pro
> to, aby se dala data z rúian využít pro manuální importy. nad tím potom
> lze dělat další nadstavby, které práci zjednoduší a zrychlí. něco určitě
> vyplyne i ze zkušeností se samotnými importy.
>> Honza
> ff
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] import budov

[Jan Bilak]

Ahoj,

teď z toho nechápu, zda si aplikaci představuješ jen jako evidenční
nebo zda aplikace má provádět vlastní import (resp. s ním výrazně
pomáhat).

Tedy za zásadní považuji porovnání současných OSM dat s daty RUIAN a
následné provedení změn (posuny stávajících bodů, opravy tagů,
zachování stávajících tagů, doplnění chybějících tagů, ...).
Samozřejmě s tím, že proces bude pod manuální kontrolou člověka, který
bude import provádět (tedy nikoli plně automatický, ale
poloautomatický). O těchto funkcích se v popisu nezmiňuješ.

Honza


Dne 27. července 2012 13:05 Miroslav Šulc  napsal(a):
> já jsem nad tím ještě včera přemýšlel, a dospěl jsem k tomuhle:
>
> * aplikace by měla umožňovat nejen jednorázový import, ale i následné
> aktualizace podle změn v rúian
> * evidence provádění importů by měla být součástí aplikace tak, aby se na ní
> nezapomínalo, současně by měla být co nejjednodušší
> * z aplikace by mělo být zřejmé, co už je hotové a co ještě ne, případně kde
> jsou nějaké změny v rúian
> * aplikace by měla fungovat naprosto samostatně, bez nutnosti nějaké obsluhy
>
> takhle nějak by ta aplikace mohla vypadat:
>
> * byla by webová aplikace, kde by se podle katastrálních území daly stahovat
> osm soubory s obrysy budov (a případně i s adresními body)
> * aplikace by zobrazovala u každého kú, zda je naimportovaný nebo ne a
> jestli v rúian došlo k nějakým změnám + možnost filtrování (okres, stav
> importu, název kú) - v případě budov by aplikace zobrazovala jen kú, kde je
> definovaný obrys alespoň jedné budovy
> * v aplikaci by se evidovalo, kdo a kdy jaký soubor naimportoval do osm +
> poznámky k importu
> * aplikace by umožňovala sledovat změny v rúian (tj. pokud někdo stáhne a
> naimportuje nějaké budovy do osm, tak info zanese do aplikace, aplikace pak
> bude vědět, že k danému datu jsou budovy naimportované a umožní příště
> vyexportovat pouze rozdíl mezi posledním naimportovaným stavem a současným
> stavem v rúian) a exportovat pouze změny (včetně informace o odstraněných
> objektech)
> * z aplikace také bude zřejmé, kdo zrovna na čem dělá
> * aplikace by mohla také zobrazovat historii importů (tj. kdo, kdy a co),
> kdo má co rozdělané a jak dlouho, kolik toho zbývá naimportovat apod.
>
> přemýšlel jsem o tom, jak pořešit, aby nebylo nutné se do aplikace
> registrovat a současně zajistit určitou míru autorizace při zadávání
> informací o provedení importu a napadlo mě následující:
>
> 1) když si budu chtít stáhnout data z určitého kú, tak si to kú vyhledám,
> zadám svůj mail a jestli chci komplet soubor nebo rozdílový soubor a
> aplikace mi soubor pošle na mail, včetně linku pro zanesení informace o
> provedení importu do aplikace
> 2) naimportuju budovy do osm (vizuální kontrola, opravy apod.)
> 3) když mám naimportováno, kliknu na link z mailu, zobrazí se mi webový
> formulář, já tam zadám poznámky k importu a odešlu
> 4) systém si informace spáruje s předchozím exportem a bude vědět, že až po
> určité datum jsou budovy naimportované, takže bude moct jednoduše sledovat
> rozdíly
>
> máte k tomu někdo nějaké připomínky nebo podněty?
>
> pak mám ještě jeden technický dotaz. tušíte někdo, jak převést data z
> postgis geometry do osm formátu? s body předpokládám problém nebude, ale
> netuším, jak s polygony. rúian se neomezuje jen na čáry, takže tam asi bude
> nutné provést nějakou konverzi. ideální by byla nějaká knihovna, která vezme
> postgis geometry a udělá z ní osm xml. zkoušel jsem něco vygooglovat, ale
> asi jsem zadával špatná klíčová slova.
>
> ff
>
> Dne 26.7.2012 08:50, Zdeněk Pražák napsal(a):
>
> no kdyby se připravily stránky se zdrojovými údaji pro budovy pro jednotlivá
> katastrální území, pak by bylo možné vytvořit stránky na wiki s odkazy na
> stažení jednotlivých souborů. zájemce by si stáhl data pro požadované
> katastrální území, provedl kontrolu např vůči bingu (odstranil různé chyby -
> například neexistující budovy, budovy s jiným tvarem, doplnil by budovy ve
> skutečnosti existující a neobsažené v datech RUIAN) a poté opravená data
> odeslal na OSM.
> V tabulce na wiki by zaznamenal provedení exportu a případné problémy
> Pražák
>
> Dne 25. července 2012 19:34 Miroslav Šulc  napsal(a):
>>
>> no, tak to by rozhodně mělo ušetřit čas, protože jestli se nepletu, tak
>> když je budova v digitální mapě kú, tak bude i v rúian a dala by se snad
>> jednoduše naimportovat. podle mě by to ale chtělo udělat nějak
>> systematicky. samozřejmě můžu udělat nějakou webovou stránku, odkud si
>> kdokoliv bude moct stáhnout osm soubor s budovama pro daný výběr (třeba
>> ten katastr) a nechat tomu volný průběh, ale pokud bychom tomu dali
>> nějaký řád, tak by to asi bylo lepší.
>>
>> máte někdo nějaké návrhy?
>>
>> ff
>>
>> Dne 25.7.2012 19:28, Zdeněk Pražák napsal(a):
>> > no já zatím pomocí pluginu tracer kreslím v katastrálních územích s
>> > digitální mapou budovy, tak jsem si myslel jestli bych nemohl využít
>> > uvedených dat
>> >
>> >>  Původní zpráva 
>> >> Od:

Re: [Talk-cz] tagování silnic - praxe a wiki se liší

[Jan Bilak]

O konvencích tagování toho moc nevím, ale co na to jít "od jinud"?
Tedy dávat silnicím tagy, které mají jasný význam. Tedy např. tag,
který bude říkat třídu silnice, tag, který bude říkat počet pruhů
apod. Takové ty neurčité tagy, podle který ale třeba renderer kreslí
mapy, by pak bylo možné hromadně automaticky nastavovat podle toho,
jak se ukáže za vhodné. Tedy něco jako "když má x pruhů a y. třídy,
tak dostane tag ...". Tato pravidla by pak stačilo udržovat na jednom
místě (na rozdíl od hlavy každého mappera), snadno by je bylo možné
udržovat konzistentní (opravovat na základě tagů s jasnou informací),
při změně pravidel by stačilo pravidla jednou změnit a spustit
skript...

Tento systém by se mi líbil obecně všude v OSM. Zaznamenávání tagů,
které nesou zcela jasnou informaci. A následné odvozování tagů, které
nenesou zcela jasnou informaci, ale jsou nutné kvůli kompatibilitě (se
světem, se softwarem apod.).

Honza


Dne 21. července 2012 1:08 Jakub  napsal(a):
> Chtěl bych se zeptat jestli proběhla (předpokládám že ano) nějaká diskuze
> ohledně tagování silnic první třídy. Pokud ne, tak bych jí rád otevřel.
>
> Na
> http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/roads_tagging
> se píše, že to zda se silnice 1. třídy taguje jako trunk nebo primary je
> určeno tím, zda má silnice 2 nebo 4 pruhy. Začal jsem tagovat podle této
> informace, ale velmi rychle mi začalo připadat, že to není dobrý nápad.
> Neodpovídá tomu vůbec praxe, která taguje jako trunk (podle toho co jsem
> viděl) jen rychlostní komunikace - pokud by se dodrželo to co je ve wiki,
> bude potřeba udělat změny na mnoha místech, například Praha by byla plná
> trunků. IMHO to není ani pěkné v Mapniku (ale to není hlacní argument) ani
> praktické. Ztrácíme tím vizuální informaci - rozdíl mezi silnicemi 1. třídy
> a dálnicí či rychlostní komunikací. Prosím vaše názory, rád bych to když
> procházím silnice ČR měl možnost zároveň upravovat.
>
> Můj návrh: silnice první třídy mapovat jako primary nehledě na počet pruhů.
>
> Jakub
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] (skoro) funkční rúian wms vrstvy

[Jan Bilak]

Tohle je podle mě vlastnost JOSM, takto se mi to chovalo vždy u všech zdrojů.

Honza

Dne 19. července 2012 20:09 Miroslav Šulc  napsal(a):
> jinak jsem zjistil, že pokud si přiblížím mapu a až pak si načtu tu wms
> vrstvu, tak se mi načte detailnější. bohužel ale při zoomování se
> podklad neaktualizuje. netušíte někdo, kde by mohl být problém?
>
> ff

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Pěkná kupka práce

[Jan Bilak]

Obkreslovat by podle mě bylo licenčně špatně. Ale používat to pro
informaci o tom, co je třeba v mapě doplnit, podle mě licenčně špatně
není. Vlastní kreslení by pak muselo probíhat podle jiného zdroje.

Honza


Dne 18. července 2012 18:43 Jan Breuer  napsal(a):
> Taky bych to uvítal, ale nebude to licenčně špatně obkreslovat podle něčeho,
> co bylo právě kvůli licenci vyřazeno?
>
> Honza
>
> Dne 18. července 2012 18:19 Zdeněk Pražák  napsal(a):
>
>> lze uvedenou mapu dostat nějak jako podkladovou vrstvu do JOSM
>> Pražák
>>
>> Dne 18. července 2012 4:56 Jakub  napsal(a):
>>
>>> Tak koukám, že máme o zábavu postaráno. Republika je plná rozkouskovaných
>>> cest :-) ... Takže (zkušení omluví trivialitu sdělení) pokud máte pár dní
>>> čas, tak doporučuju zasednout ke strojům. K přehledu o tom, co bylo smazáno
>>> (čistě technicky spíše v historii editování skryto dobře poslouží mapa
>>>
>>>
>>> http://harrywood.dev.openstreetmap.org/license-change/botprocessing.php?zoom=8&lat=49.70961&lon=14.42081&layers=B00F
>>>
>>> 1. najděte si místo kde to znáte, nebo chcete opravovat a zazoomujte
>>> 2. klikněte na + v pravém hodním roku a zvolte BADMAP - tady je vidět co
>>> všechno bylo smazáno
>>> 3. dokreslete to jako kdybyste to malovali poprvé, tj. podle vašich
>>> znalostí, tras nebo leteckých snímků.
>>>
>>> Když už budete v tom, dopoučuju se na oblast podívat na
>>>
>>>
>>> http://keepright.ipax.at/report_map.php?lat=49.87008&lon=14.05625&zoom=8&layers=B0T&ch=0%2C30%2C40%2C50%2C60%2C70%2C90%2C100%2C110%2C120%2C130%2C150%2C160%2C170%2C180%2C191%2C192%2C193%2C194%2C195%2C196%2C197%2C198%2C201%2C202%2C203%2C204%2C205%2C206%2C207%2C208%2C210%2C220%2C231%2C232%2C270%2C281%2C282%2C283%2C284%2C291%2C292%2C293%2C311%2C312%2C313%2C350%2C370%2C380%2C411%2C412%2C413&show_ign=1&show_tmpign=1
>>>
>>> kde najdete i další chyby, které tam byly ještě před promazáváním. Pokud
>>> i tyto na konci vaší remapovací mise úspěšně vyřešíte, bude mapa lepší než
>>> dřív.
>>>
>>> Tak do toho
>>>
>>> Jakub
>>>
>>> ___
>>> Talk-cz mailing list
>>> Talk-cz@openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>>
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Praha bude brzy děravá :-(

[Jan Bilak]

Ahoj, to mě také zaráží. V takovém případě by snad mělo smysl použít
poslední licenčně použitelnou verzi, případně selektivně odstranit licenčně
problematické tagy apod.

Honza
Dne 16.7.2012 18:04 "Jakub Sykora"  napsal(a):

> Docela me zarazi, ze tam dojde ke smazani veci, ktere jsem mapoval v
> zacatcich OSM jen proto, ze to nekdo, kdo s licenci nesouhlasi lehce
> opravil nebo k tomu pridal nazev...
>
> Ach jo...
>
> Dne 16.7.2012 17:42, Jakub Těšínský napsal(a):
>
>> Tak jsem si zazoomoval na Prahu abych viděl, co nám relicencovací bot v
>> nejbližší době smázne a veselý pohled to není. Koukněte na
>> http://harrywood.dev.**openstreetmap.org/license-**
>> change/botprocessing.php?zoom=**12&lat=50.05582&lon=14.44004&**
>> layers=00BFTTFF
>>
>>
>> Pokud máte zrovna čas je nejspíš posledních pár hodin některé te věci
>> třeba z leteckých snímků opravit.
>>
>> Jakub
>>
>> __**_
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> http://lists.openstreetmap.**org/listinfo/talk-cz
>>
>
>
> __**_
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-cz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] RUIAN - veřejný dálkový přístup

[Jan Bilak]

Zdravím,

nemohu si pomoci, ale souhlasím s hanojem a jsem přesvědčen, tak
dlaždicování je správná cesta. Marushka je opravdu strašně pomalá -
generování výřezu 10 sekund není nic výjimečného - naštěstí s ní
nepracuji. Ono tedy nahlížení do katastru je také velmi pomalé (4 až 5
sekund běžně) - dokonce dříve to bývalo rychlejší.


> Každý den se aktualizuje
> grafika v cca 700 katastrálních územích, takže data jsou docela živá a
> nějaké vyrábění dlaždic (navíc průběžně - mapové služby mají zpoždění pouze
> v řádu hodin proti produkčnímu systému) by bylo vysoce problematické

Dlaždice se aktualizují pouze při změně (dané dlaždice). Tedy při
změně dat se zjistí jejich rozdíl (pokud není možné jej zjistit přímo)
a zneplatní se zasažené dlaždice, které se průběžně s menší prioritou
generují. S větší prioritou se generují dlaždice, které si někdo
vyžádal a nejsou již vygenerované. Nevěřím, že každý den změní
relativně velké množství dlaždic. Mapy jsou ve velkých zoomech a
dlaždice tak pokrývá poměrně malé území.


> Pro
> informaci - současné reálné špičky v zatížení WMS jsou kolem 5000 požadavků
> za minutu.

Čím více požadavků, tím více je to ve prospěch dlaždic. Generování
výřezu mapky z dat trvá dle pozorování hodně dlouho.


> Pokud je tím myšleno dlaždicování na straně klienta, tak o tom
> jsme se také bavili. Tam je ale problém s prvky, které řeže hrana dlaždice
> (popisy definičních bodů atd.) - na dlaždici s bodem pak je kus popisu a na
> sousední dlaždici není nic (protože tam není ten bod, ke kterému se doplňuje
> popis). Zrovna na ikatastr.cz to jde pěkně demonstrovat.

Tohle má celkem jednoduché řešení - pro každý takový prvek je třeba
zjistit ohraničující obdélník a ten zanést do prostorového indexu, ze
kterého se pak zjišťuje, které objekty zasahují do daného výřezu
(dlaždice). Ale tento problém musíte stejně řešit již nyní, kdy
generujete výřez na přání.


Honza

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Data RUIAN - výměnný formát

[Jan Bilak]

Takže v první fázi udělat program, který porovná stav v OSM a v RUIAN.

Jak by měl vypadat výstup tohoto porovnání?

Může nastat mnoho případů (nejde o disjunktní případy):
1) bod je v RUIAN, ale chybí v OSM
2) bod je v OSM, ale není v RUIAN
3) je v OSM i v RUIAN, ale nemá stejnou polohu
4) je v OSM i v RUIAN, ale má rozdílné údaje (číslo popisné, číslo
orientační, ulice, ...)
5) v RUIAN není poloha definována
6) v OSM chybí některé údaje (číslo popisné, orientační, ulice, ...)
7) v OSM je bod vícekrát
8) v OSM je místo bodu otagována budova
9) v OSM jsou některé údaje navíc oproti RUIAN
10 ...

Přičemž nastává řada otázek ... např. co třeba považovat za stejný bod
v RUIAN i OSM (co se musí shodovat, s jakou tolerancí, ...).

Honza


Dne 30. června 2012 13:36 Martin Kokeš  napsal(a):
> Ano, PROJ4 je základ všeho. Ad program, tak to je skvělá zpráva.
>
> Osobně jsem pro adresní body uvnitř budov, protože budovy (polygony) lze pak 
> bez problémů očíslovat při vytváření topologie, viz Hanoj. S ohledem na to, 
> že RUIAN je základním registrem státní správy bych přešel komplet na něj a 
> rozdíly nahlásil, případně ověřil a nadále udržoval synchronní stav. U budov 
> a jakýchkoliv jiných polygonů je to těžké, možná by byl lepší nějaký 
> "tracer", co by netracoval, ale jen tahal napozicované a transformované 
> vektory z prostorové databáze, přičemž samotné vkládání nebo rozhodnutí, zda 
> vložit, by bylo už na uživateli. To se týká i WFS s tématem INSPIRE parcely, 
> které jsou krásně vyčištěny a ze kterých by šly dělat např. zahrady, pole, 
> lesy atp. podobným způsobem.
>
> MK
>
> - Original Message -
> From: Jan Bilak
> [mailto:jan.bilak@gmail.com]
> To: OpenStreetMap Czech Republic
> [mailto:talk-cz@openstreetmap.org]
> Sent: Sat, 30 Jun 2012 13:21:16
> +0200
> Subject: Re: [Talk-cz] Data RUIAN - výměnný formát
>
>
>> Ahoj,
>>
>> transformaci souřadnic mám rozchozenou v .NETu pomocí knihovny PROJ.4
>> (http://trac.osgeo.org/proj/) s gridem
>> (http://grass.fsv.cvut.cz/gwiki/S-JTSK-Grid). Tedy alespoň v tom
>> doufám, že to počítá správně. Ověřoval jsem na příkladu, který
>> je
>> uveden na té stránce GRIDu - ten to spočítalo přesně. Bez použití
>> GRIDu byly výsledky trošku jiné.
>>
>> Spíše je otázka, co s tím dál, protože zatím ještě není dohodnuto,
>> jaký je ideální výsledný stav (zda adresní body nebo tagy na
>> budovách,
>> jaké tagy, jak nakládat se starými daty apod.) a jaký postup importu
>> tedy zvolit.
>>
>> Honza
>>
>>
>> Dne 30. června 2012 13:11 Martin Kokeš 
>> napsal(a):
>> > Čistě matematická transformace dosahuje značné nepřesnosti v
>> závislosti na lokalitě až 70 metrů.
>> > http://grass.fsv.cvut.cz/gwiki/Chyba_při_transformaci_z_WGS84_do_S-JTSK
>> >
>> > Převod GML se dělá pomocí ogr2ogr, případně lze GDAL knihovnu
>> začlenit do Céčkového programu nebo do Python skriptu bez problémů
>> pomocí API: http://gdal.org/gdal_tutorial.html
>> >
>> > MK
>> >
>> > - Original Message -
>> > From: Pavel Machek [mailto:pa...@ucw.cz]
>> > To:
>> > OpenStreetMap Czech Republic [mailto:talk-cz@openstreetmap.org]
>> > Sent: Sat,
>> > 30 Jun 2012 12:45:23 +0200
>> > Subject: Re: [Talk-cz] Data RUIAN - výměnný
>> > formát
>> >
>> >
>> >> On Sat 2012-06-23 04:45:21, Jan Bilak wrote:
>> >> Díky. Nevíte o nějakých
>> >> knihovnách (.NET, Java, JavaScript, C, C++,
>> >> ...) pro transformaci pomocí
>> >> toho S-JTSK gridu? Nebo, pokud nejsou
>> >> přímo knihovny, ve kterých
>> >> opensource programech s vhodnou licencí by
>> >> tato transformace šla
>> >> najít?
>> >
>> > Ja tu mam:
>> >
>> > gdalwarp -s_srs "+proj=krovak +a=6377397.155
>> >> +rf=299.1528128 +no_defs
>> > +towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56"
>> >> -t_srs
>> > "+proj=latlong +a=6378137 +rf=298.257223563
>> >> +no_defs
>> > +towgs84=0.000,0.000,0.000"
>> >> /data/gis/READ-ONLY/cechy.tif
>> > /tmp/delme.tiff
>> >
>> > a pak pascalovej zdrojak:
>> >
>> > {
>> >
>> >>Copyright 2005 Zdenek Hrdina, distribute under GPLv2
>> > }
>> >
>> > procedure
>> >> jtsk_wgs( X,Y,Hel:double; var B,L,H:double);
>> > {Vypocet zemepisnych souradnic
>> >> v systemu WGS-84 z rovinnych souradnic
>> > S-JTSK a elipsoidicke
>> >> vysky}
>> >
>> > proced

Re: [Talk-cz] Data RUIAN - výměnný formát

[Jan Bilak]

Ahoj,

transformaci souřadnic mám rozchozenou v .NETu pomocí knihovny PROJ.4
(http://trac.osgeo.org/proj/) s gridem
(http://grass.fsv.cvut.cz/gwiki/S-JTSK-Grid). Tedy alespoň v tom
doufám, že to počítá správně. Ověřoval jsem na příkladu, který je
uveden na té stránce GRIDu - ten to spočítalo přesně. Bez použití
GRIDu byly výsledky trošku jiné.

Spíše je otázka, co s tím dál, protože zatím ještě není dohodnuto,
jaký je ideální výsledný stav (zda adresní body nebo tagy na budovách,
jaké tagy, jak nakládat se starými daty apod.) a jaký postup importu
tedy zvolit.

Honza


Dne 30. června 2012 13:11 Martin Kokeš  napsal(a):
> Čistě matematická transformace dosahuje značné nepřesnosti v závislosti na 
> lokalitě až 70 metrů.
> http://grass.fsv.cvut.cz/gwiki/Chyba_při_transformaci_z_WGS84_do_S-JTSK
>
> Převod GML se dělá pomocí ogr2ogr, případně lze GDAL knihovnu začlenit do 
> Céčkového programu nebo do Python skriptu bez problémů pomocí API: 
> http://gdal.org/gdal_tutorial.html
>
> MK
>
> - Original Message -
> From: Pavel Machek [mailto:pa...@ucw.cz]
> To:
> OpenStreetMap Czech Republic [mailto:talk-cz@openstreetmap.org]
> Sent: Sat,
> 30 Jun 2012 12:45:23 +0200
> Subject: Re: [Talk-cz] Data RUIAN - výměnný
> formát
>
>
>> On Sat 2012-06-23 04:45:21, Jan Bilak wrote:
>> Díky. Nevíte o nějakých
>> knihovnách (.NET, Java, JavaScript, C, C++,
>> ...) pro transformaci pomocí
>> toho S-JTSK gridu? Nebo, pokud nejsou
>> přímo knihovny, ve kterých
>> opensource programech s vhodnou licencí by
>> tato transformace šla
>> najít?
>
> Ja tu mam:
>
> gdalwarp -s_srs "+proj=krovak +a=6377397.155
>> +rf=299.1528128 +no_defs
> +towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56"
>> -t_srs
> "+proj=latlong +a=6378137 +rf=298.257223563
>> +no_defs
> +towgs84=0.000,0.000,0.000"
>> /data/gis/READ-ONLY/cechy.tif
> /tmp/delme.tiff
>
> a pak pascalovej zdrojak:
>
> {
>
>>Copyright 2005 Zdenek Hrdina, distribute under GPLv2
> }
>
> procedure
>> jtsk_wgs( X,Y,Hel:double; var B,L,H:double);
> {Vypocet zemepisnych souradnic
>> v systemu WGS-84 z rovinnych souradnic
> S-JTSK a elipsoidicke
>> vysky}
>
> procedure transformace_BLH(var B,L,H: double);
> {Transformace
>> zemepisnych souradnic z JTSK do WGS}
>  var
>> lat,lon,alt,x1,y1,z1,x2,y2,z2:double;
>
>
> ... Poslu nebo by mel jit
>> vygooglit.
> --
> (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
> http://lists.openstreetmap.org/listinfo/talk-cz
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Formát zápisu adresních bodů (was Data RUIAN - výměnný formát)

[Jan Bilak]

Ahoj,

> Trochu sem se prohrab temi samply, a me by se libilo nevyrabet adresni
> body ale priradit adresy budovam, neb ta vazba v tech datech je. Bod
> bych vyrobil jen tam, kde budova neni (a je tam definovana adresa).
> Co se tyce ulic, tam to asi s jejich presnosti nebude zadna slava -
> predpokladam, ze kazdej kdo obkresloval rucne to udelal podrobnejsi. Ale
> lepsi nez dratem do oka.

Adresní bod a budova ... to mě napadlo také (a někde se to v OSM i
používá), ale vidím v tom trochu problémy.

Zaprvé budova může mít více vchodů/adres. Jak by se jmenovaly tagy?
addr:housenumber1, addr:housenumber2, addr:housenumber3 apod.? Nebo by
se dělila budova na části? Ale jak? Nikdo nebude zkoumat vnitřní
strukturu budovy - typicky ji vidíš zvenku a pár vchodů dovnitř. Občas
se je zřejmé, ale nemusí být vždy.

Zadruhé adresní bod (pokud je vhodně umístěn) říká i polohu vchodu.
Např. budova stojí mezi dvěma ulicemi a takto by nebylo zřejmé, odkud
je vlastně vchod.

Zatřetí je otázka, zda je vhodné štěpit jeden druh informace do
různých zápisů (někdy adresní bod, někde vlastnost budovy).

Nicméně informace u budovy může být také užitečná. Teoreticky lze
najít všechny adresní body, které leží uvnitř polygonu budovy. Jak je
rychlé/pracné, to záleží na tom, jak se data oindexují apod. Jak je to
pracné v existujících nástrojích, to nevím. Předpokládám, že dotaz na
objekty ležící v daném obdélníku je jeden z nejčastějších dotazů a
data jsou tedy vhodně oindexována (r-tree, quad-tree nebo tak něco).


> Tohle je pekny, ale uvital bych SVG.
> List tvoří tři vodorovné pruhy, žlutý, modrý oboustranně
> zubatý a žluto-černě polcený, v poměru 1:2:1. Modrý má nahoře i dole po
> čtyřech zubech a pěti mezerách, vysokých jednu osminu šířky listu. V
> modrém pruhu žlutý kráčející lev s červenou zbrojí držící v předních
> tlapách bílou rybu hlavou nahoru a hřbetem k žerdi. Poměr šířky k délce
> listu je 2:3.
> V modrém štítě se zlatou cimbuřovou hlavou zlatý kráčející
> lev s červenou zbrojí držící v předních tlapách stříbrnou rybu, pod ním
> zlato-černě polcený štítek.

Tohle tam není jen textově, ale i ve formě obrázků. Pravda - bitmap,
nikoli vektorů. Ono asi ani všechno vektory nejde dobře vyjádřit nebo
nejsou data ve vektorech dostupná. Přeci jen tohle vznikalo v době,
kdy se ještě malovalo štětcem na papír apod.


> > Podle me naopak nejvetsi kandidat na vyhozeni je prave is_in, protoze je
> > to nestrukturovana hromada cehosi. Navic v soucasnosti drtiva vetsina
> > aplikaci spravne najde ze adresa lezi uvnitr boundary XYZ.
>
> Souhlas, je to nestrukturovaná hromada, ovšem to cosi nese užitečnou 
> informaci.
> Jak už jsem psal, někdy jedno katastrální uzemí obsahuje více částí obce, 
> každá
> část má vlastní číslování domů.  Tedy v hranicích jednoho KÚ se čísla opakují.

Nestrukturovaná data se mě také nelíbí. Ale existuje strukturovaná
verze is_in, jak píšou na té stránce
http://wiki.openstreetmap.org/wiki/Key:is_in (is_in:city,
is_in:country, ...).


> > > Dál navrhuji seskupit adresy jedné ulice do relace, která ponese 
> > > addr:street a
> > > is_in, aby se předešlo duplikaci.  Adresní body by v tom případě měly jen
> > > addr:housenumber, addr:streetnumber a addr:conscriptionnumber.  Otázkou 
> > > je, jak
> > > by taková relace měla vypadat[2].
> >
> > Toto je neprohledatelny, zadny stavajici nastroj s necim takovym
> > nepocita, tudiz tu adresu nikdo nenajde. Jako bonus je to obtizne
> > editovatelny.
>
> Nominatim používá relaci associatedStreet.
> http://wiki.openstreetmap.org/wiki/Nominatim/Development_overview#Building_Indexing
>
> Editace jsou samozřejmě obtížnější, nicméně mě stále láká strukturovanost této
> relace.  Na druhou stranu, software na import asi psát nebudu, a kdyby ano,
> nemořil bych se s generováním relací.  Takže to tu nechme jako "dobrý nápad".

Po stránce software na import bych tom neviděl velký problém (software
na import průběžně připravuji). Větší starost mi dělá to, že vlastně
nevím, co mám přesně udělat. Tedy jak má vypadat výsledek, co udělat
se starými daty, podle čeho matchovat stará a nová data apod. Nemám
dobrý přehled o významu všech tagů a vůbec konvencích a doporučení OSM
a studovat WIKI se mi opravdu nechce (zabralo by mi to spoustu času).
Proto bych rád, kdyby z diskuse vzešly nějaké závěry a mohl jsem to
podle nich implementovat.

Honza

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Formát zápisu adresních bodů (was Data RUIAN - výměnný formát)

[Jan Bilak]

Ahoj,

koukám, že tu budou i různé rozdíly mezi adresami z registru a z OSM,
i když v OSM mají v tagu uveden kód adresy registru (tedy mělo by se
jednat o stejnou adresu a asi import z UIR-ADR):

Pár rozdílů z Prahy (pokud jsem neudělal chybu):
http://jabi.aspone.cz/osm/temp/praha-rozdily.pdf

Narážím konkrétně na rozdíly v číslech domu, nikoli v poloze.

Poznámka: levá část je z registru, pravá část z OSM, 0 = neuvedeno,
vzdálenost brát s velkou rezervou, celkově je výstup odporný...

Otázka je, co je správně. Řešit to ručně? Bude toho mnohem více (i z
Prahy). A jak to vůbec řešit?

Honza

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Formát zápisu adresních bodů (was Data RUIAN - výměnný formát)

[Jan Bilak]

Ahoj,

díky za rozbor, ale myslel jsem to tak, jaký zápis chceme v OSM
ideálně mít. Tedy v jakém formátu připravovat import z RUIAN, jaké
tagy tam dát pro nové adresní body, jaké tagy doplnit ke stávajícím,
jaké existující tagy případně smazat nebo změnit (ostatní předpokládám
zachovat). Tedy aby to všude jednotné (+ u některých bodů nějaké
specifické tagy). Jak se má složit obsah tagu is_in (pokud tam má
být), protože to je složenina různých údajů.

Honza


Dne 26. června 2012 13:58 Libor Pechacek  napsal(a):
> Ahoj,
>
> Z mojí zkušenosti se formát adresního bodu liší podle použitého nástroje.  
> Jsou
> tři (polo)automatické způsoby importu, a nakonec pak ruční zadání.
>
> On Tue 26-06-12 04:14:04, Jan Bilak wrote:
>> jak vypadá ideální zápis adresního bodu v OSM XML? Koukal jsem se do
>> snapshotu OSM dat ČR a zápisy nemají jednotný formát. Např.:
>>
>>       > changeset="1965423" user="Radomír Černoch" uid="51295"
>> timestamp="2009-07-28T14:56:31Z">
>>               
>>               
>>               
>>               
>>               
>>               
>>               
>>       
>
> Tohle je podle mě výsledek UIR-ADR importu.
> http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/freemap#Adresn.C3.AD_body_-_MPSV.28UIR-ADR.29
>
>>       > changeset="9784174" user="Petr1868" uid="72020"
>> timestamp="2011-11-09T19:54:47Z">
>>               
>>               
>>               
>>               
>>               
>>               
>>       
>
> Tento záznam vytváří nástroje napsané Lukášem Kábrtem.
> http://wiki.openstreetmap.org/wiki/Import_Adres_%C4%8CR
> Pokud jsou v obci ulice, je přítomen i tag "addr:street".
>
>>       > changeset="5435557" user="NE2" uid="207745"
>> timestamp="2010-08-08T17:43:41Z">
>>               
>>               
>>               
>>               
>>               
>>               
>>               
>>               
>>               
>>               
>>               
>>               http://ustarehomlyna.cz"; />
>>       
>
> Tohle je podle mě CzechAddress plugin pro JOSM napsaný Radomírem Černochem.
> http://wiki.openstreetmap.org/wiki/CS:JOSM/Plugins/CzechAddress
> Name a URL tagy byly zřejmě přidány ručně.
>
>>       > changeset="1984279" user="Radomír Černoch" uid="51295"
>> timestamp="2009-07-30T12:44:24Z">
>>               
>>               
>>               
>>       
>
> Tenhle byl asi vyroben ručně v Potlatchi, JOSM vytváří podobné.  Chybí v nich
> is_in.
>
>> Jak se vlastně jednoznačně/algoritmicky určí, co je a co není adresní bod?
>
> Všechny mají "addr:housenumber", čehož bych se držel.
>
>> Je vidět, že některé adresní body obsahují i doplňkové informace,
>> které bude třeba zachovat. Tedy nějaké globální mazání a import
>> adresních bodů nebude možný. Bude třeba matchovat staré a nové a podle
>> toho se nějak zachovat.
>
> Rozhodně.  A aby to nebylo jednoduché, různé zdroje mají různou přesnost.
> Polohově nejpřesnější jsou ruční editace, pak je import pomocí nástrojů Lukáše
> K., nejméně přesný je UIR-ADR.
>
> Co se týče doplňkových informací, informaci o ulici, čísle orientačním a
> hierarchii sídel obsahují body vytvořené ručně s pomocí CzechAddress a
> poloautomaticky nástroji Lukáše K.  Informace o čísle, ulici a sídle pochází z
> databáze adres MVČR, umístění adresního bodu je pak výsledkem tvůrčí práce.  V
> případech, kdy je na jednom katastrálním území více částí obcí, mohou někdy 
> být
> tyto informace nesprávně.  Záleží totiž, jak pečlivě byl import proveden.
>
> Libor
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Data RUIAN - výměnný formát

[Jan Bilak]

Ahoj,

jak vypadá ideální zápis adresního bodu v OSM XML? Koukal jsem se do
snapshotu OSM dat ČR a zápisy nemají jednotný formát. Např.:

































http://ustarehomlyna.cz"; />








Jak se vlastně jednoznačně/algoritmicky určí, co je a co není adresní bod?

Je vidět, že některé adresní body obsahují i doplňkové informace,
které bude třeba zachovat. Tedy nějaké globální mazání a import
adresních bodů nebude možný. Bude třeba matchovat staré a nové a podle
toho se nějak zachovat.

Honza



Dne 25. června 2012 12:16 jzvc  napsal(a):
> Dne 25.6.2012 0:35, hanoj napsal(a):
>>> (nebo jsou data nesprávná - např. jiný tvar obrys budovy).
>> *** No katastr, uznává tuším styk budovy se zemí jako reprezentující a
>> vzhledem k tomu že to dosud od něj obkreslujem asi by to chtělo uznat
>> za standard.
> Tak to pozor, km sice pouzivam jako jeden z primarnich zdroju, ale
> vzdycky minimalne kontroluju, jestli tam ta budova +- opravdu stoji. A
> pripadu kdy v km budova je, ale fyzicky tam neni po budove ani pamatky
> (= ani ruiny), pripadne naopak, budova si na miste vesele stoji, zato po
> ni ani pamatky neni v km (a to vcetne toho, ze budova ma i vlastni cp)
> nejsou zadnou vyjimkou, narazim na takove pri kazde editaci mapy. Zrovna
> tento tyden sem odmazaval zborene budovy, ktere v km vesele stale jsou
> (a to jsou zborene uz minimalne par let).
>
> =>
>
> 1) zadny zbesily import a rozhodne ne zadne mazani v OSM.
>
> 2) optimalne vygenerovani nejake kolizni mapy (wms/tms server) aby sla
> dat na podkres editoru.
> 3) IMo by bodnul nastroj, kterej by byl schopnej nejak slinkovat
> existujici budovy - rekneme s nejakym rozpalem hranic +- 1m? a
> ohranicene plochy +- 10%? Cisla by samo chtelo vyhodnotit na zaklade
> uspesnosti => pokud zbude nejaky nepatrny % budov, ty se daj poresit
> rucne. Pokud se budova vejde to tohodle rozpalu (IMO vsechny vyrobeny
> tracerem), tak se da prohlasit, ze to je "ona", priradit ji prislusny ID
> a posunout jeji hranice tak, aby to sedelo presne na km.
>
>
> Co se aktualizaci tyce - pokud dojde ke zmene v km a neni zadna zmena na
> strane osm, tak asi neni co resit - aktualizace v osm. Pokud ke zmene
> dojde opacne, tak dost pochybuju ze nekdo zmeni neco v km. Pokud je
> zmena oboustrana, tak asi leda tak, ze nekdo koukne do osm a bud
> prohlasi, ze se to ma syncnou s km nebo prohlasi, ze data sou spravne v
> osm (a nejakym marknutim objektu ho vyradi ze synchronizace).
>
>
>>
>>> obsahovat více upřesňujících tagů. Je tedy možné (pravděpodobné), že
>>> některá data budou lepší v OSM než v datech registru. Uliční čáry musí
>>> nějak rozumně na sebe navazovat...
>> *** Opravdu se jedná o uliční čáry, nebude to jen popisek? Já jsem v
>> ukazkach nic nenašel
>>
>>> Které konrétní údaje z registru se budou do OSM importovat?
>> *AdresniMisto (addr=*)
>> *Stavebni objekt (building=*)
>> *Ulice (name=*)
>>
>>> Jak se vypořádat se starými daty?
>> *** Mno nebal bych se smazat a nahrat novou geometrii budov (pro
>> source=cuzk:km) a ponechat pripadne tagy navic. Dost digitalizaci je
>> neduslednych co do geometrie tvaru (krizeni, nesdileni hran a nodu)
>> nebo pokryti zdanlive hotoveho uzemi. Obdobne u adresnich bodu, coz je
>> dano nedokoncenym importem a zdrojem dat.
>>
>>
>>> Za ideální cílový stav bych považovat navázání dat na registr kvůli
>>> aktualizacím.
>> *** To je zbozne prani, ktere se nam doposud nepovedlo, viz napr.:
>> 1) adresni body obcas nekdo strka do POI ci polygonu building
>> 2) admin_border se staly soucasti multipolygonu budov a ruznych preklepu...
>> 3) import rek DIBAVOD, a lesu UHUL uz je prakticky neudrzovatelny s 
>> originalem
>>
>> Takze nejvetsi otazkou je co s tim co uz v OSM je a jak nakladat s
>> daty v budoucnosti.
>>
>>
>> ha
>> hanoj
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Import budov

[Jan Bilak]

Ahoj,

s importem adresních bodů získaných z teček na mapě bych se teď moc
nezatěžoval, protože v brzké době se doufám podaří provést import z
RUIAN, což být měl být kvalitnější zdroj (viz probíhající diskuse o
RUIAN) - tedy úplný, denně aktualizovaný, přesnější, s menším rizikem
chyby, lehčeji zpracovatelný, ... Zrovna adresní body myslím budou to
nejjednodušší, co z RUIAN půjde naimportovat.

Honza


Dne 25. června 2012 13:50 Libor Pechacek  napsal(a):
> Ahoj,
>
> Postup importu adresních bodů je dobře popsán na již zmíněné wiki [1].  Až se
> Ti podaří rozchodit software, zapiš se na wiki jako importér a pusť se do
> toho.
>
> Při importu je většina práce řešení chyb při importu.  Jde o to, že v jednom
> katastrálním území je někdy více částí obcí.  V tomto případě se v souboru
> *-fixme.osm objeví duplicitní adresy a je třeba relaci popisující hranice
> karastrálního území rozdělit na části a tyto části zapojit do hierarchie adres
> editací *.map souboru.  Malá ukázka je v adresy-priklad.zip [2].
>
> Dál pak může být potřeba posunout hranice KÚ, v mapě jsou někdy nepřesně, nebo
> je třeba přiřadit části obcí katastrálním územím, když se nepodařilo Lukášovi
> vytvořit tato spojení algoritmicky.
>
> Hodně štěstí, pozor na oblasti kde už adresní body jsou a ozvi se kdybys
> potřeboval pomoc.
>
> Libor
>
> [1] http://wiki.openstreetmap.org/wiki/Import_Adres_%C4%8CR
> [2] http://osm.kabrt.cz/home/adresy-priklad.zip?attredirects=0&d=1
>
> On Thu 21-06-12 22:11:45, xkomc...@centrum.cz wrote:
>> Aha, tak to jsem nevěděl, myslel jsem, že se importují adresy i rovnou s 
>> nakreslenými budovami :-(
>>
>> V tom případě bych rád poprosil, zda-li by nebyl odkaz na návod jak 
>> importovat alespoň ty adresy a jak vytvořit obrysy budov.
>>
>> Díky,
>>
>> xkomczax
>>
>> __
>> > Od: "jzvc" 
>> > Komu: OpenStreetMap Czech Republic 
>> > Datum: 21.06.2012 19:40
>> > Předmět: Re: [Talk-cz] Import budov
>> >
>> >On nekdo nejak importuje budovy?
>> >
>> >Pokud se pamatuju, mluvilo se tu o importu adresnich bodu, coz je
>> >ponekud neco jineho - a ten odkaz odpovida prave adresam. Osobne to teda
>> >delam jinak, za pomoci czech address pluginu, neb mam overeno, ze
>> >adresni body jsou dost casto naprosto mimo, pripadne chybi uplne, takze
>> >by to stejne byla dvoji prace. Vetsinou postupuju tak, ze pouziju tracer
>> >a na nakreslenou budovu rovnou pridam i adresu.
>> >
>> >V kazdym pripade, importem do mapy asi nic nezkazis - kazdej by si mel
>> >predem overit jestli tam uz data nejsou, jen to udelej pod nejakym extra
>> >uctem, aby se vedelo, ze jde o import.
>> >
>> >Kazdopadne by to pomalu chtelo nejakej tool, kterej by umel najit
>> >budovy, ktere maji uvnitr "cervenou tecku", ale jsou bez adresy (a
>> >idealne to zobrazit jako podklad do JOSM a spol), pripadne najit adresy,
>> >ktere nejsou v mape ... protoze posledni dobou uz narazim i na "starsi"
>> >oblasti, kde je zmapovano, ale mezi tim tam jsou nove budovy ... ktere
>> >se v OSM objevi jen, pokud na to nahodou nekdo narazi.
>> >
>> >Dne 21.6.2012 19:23, xkomc...@centrum.cz napsal(a):
>> >> Zdravím,
>> >>
>> >> chtěl jsem se zeptat jak je to s importem budov z katastru nemovitostí. U 
>> >> okresu Prostějov je napsána poznámka "probíhá", ale žádný pokrok osobně 
>> >> nepozoruji. Napsal jsem proto před časem uživateli Dave, který je u 
>> >> Prostějova napsán, ale od začátku března nepřišla odpověď, z čehož 
>> >> usuzuji, že import bude muset proběhnout jinak. Mám tedy o import požádat 
>> >> někoho zkušenějšího nebo se mám do něj pustit svépomocí?
>> >>
>> >> A mimochodem, když jsem našel na serveru http://osm.kabrt.cz/ soubor 
>> >> Prostějov.zip, ve kterém jsou i zbývající vesnice v .map formátu, znamená 
>> >> to že jsou již importovány a stačí jej pouze nějak nahrát na server? 
>> >> Pokud ano, jak to mohu provést?
>> >>
>> >> Díky,
>> >>
>> >> xkomczax
>> >>
>> >> ___
>> >> Talk-cz mailing list
>> >> Talk-cz@openstreetmap.org
>> >> http://lists.openstreetmap.org/listinfo/talk-cz
>> >
>> >
>> >
>> >___
>> >Talk-cz mailing list
>> >Talk-cz@openstreetmap.org
>> >http://lists.openstreetmap.org/listinfo/talk-cz
>> >
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>
> --
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Data RUIAN - výměnný formát

[Jan Bilak]

>>(nebo jsou data nesprávná - např. jiný tvar obrys budovy).
> *** No katastr, uznává tuším styk budovy se zemí jako reprezentující a
> vzhledem k tomu že to dosud od něj obkreslujem asi by to chtělo uznat
> za standard.
Řekněme, že zde mohou např. fakticky existující budovy chybět
(postavené "načerno" apod.). V tak rozsáhlých informacích bych se
divil, kdyby to bylo opravdu bez chyb. Na druhou stranu jako základ to
určitě smysl má, protože je to (v daných oblastech) asi to nejlepší,
co máme. Ale s ručními zásahy je třeba počítat.


>> obsahovat více upřesňujících tagů. Je tedy možné (pravděpodobné), že
>> některá data budou lepší v OSM než v datech registru. Uliční čáry musí
>> nějak rozumně na sebe navazovat...
> *** Opravdu se jedná o uliční čáry, nebude to jen popisek? Já jsem v
> ukazkach nic nenašel

Asi opravdu uliční čáry, viz třeba:

454281Lešanská5547822011-07-01T00:00:738883.65 1048327.51 738848.15
1048382.19 738819.05
1048435.52


>> Které konrétní údaje z registru se budou do OSM importovat?
> *AdresniMisto (addr=*)
> *Stavebni objekt (building=*)
> *Ulice (name=*)
Já myslím, které vlastnosti těchto entit. Užitečné by bylo napojení na
registry pomocí IDček apod.


>> Jak se vypořádat se starými daty?
> *** Mno nebal bych se smazat a nahrat novou geometrii budov (pro
> source=cuzk:km) a ponechat pripadne tagy navic.
Což znamená namatchovat k nové budově tu starou, aby bylo možné
zkopírovat tagy. Otázka je, jak. Budovy nemusí být zakresleny přesně a
není jisté, že budou fungovat nějaké metody typy "X má průsečík s Y"
apod.

> Dost digitalizaci je
> neduslednych co do geometrie tvaru (krizeni, nesdileni hran a nodu)
> nebo pokryti zdanlive hotoveho uzemi.
Také bude třeba kontrolovat, že node není sdílený s něčím jiným. Rovně
může dojít k nějakým nechtěným průsečíkům, pokud budova byla
nakreslena odlišně a obdobně jsou nakresleny i okolní objekty.

S ulicemi, které mají návaznosti, bude také asi celkem problém. V
registrech je jen něco (nebo to prostě není ulice, ale něco fakticky
podobného).

> Obdobne u adresnich bodu, coz je
> dano nedokoncenym importem a zdrojem dat.
Adresní body budou asi celkem v pohodě.


>> Za ideální cílový stav bych považovat navázání dat na registr kvůli
>> aktualizacím.
> *** To je zbozne prani, ktere se nam doposud nepovedlo, viz napr.:
> 1) adresni body obcas nekdo strka do POI ci polygonu building
> 2) admin_border se staly soucasti multipolygonu budov a ruznych preklepu...
> 3) import rek DIBAVOD, a lesu UHUL uz je prakticky neudrzovatelny s originalem
Zatím ano, ale tady bych to neviděl jako nemožné. U entit bych
nechával v tagu návaznost na registr ve formě ID. Pak bude možné
automaticky detekovat, kde došlo k ruční úpravě a kde ne, stejně tak
ze změnových souborů bude možné snadno zjišťovat změny v registrech a
neupravované entity automaticky opravovat. U těch, kde byl proveden
manuální zásah, tak tam bude třeba asi ruční posouzení, ale toho bude
předpokládám málo.


> Takze nejvetsi otazkou je co s tim co uz v OSM je a jak nakladat s
> daty v budoucnosti.
Souhlas, proto považuji za nezbytné to nejprve prodiskutovat a vybrat
nějaké nejlepší řešení a pak jej implementovat. Adresy, obrysy budov


Honza

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Data RUIAN - výměnný formát

[Jan Bilak]

Tak si odpovídám sám. Snapshoty budou zveřejňovány jednou za měsíc,
změnové soubory budou generovány jednou za den. Oboje patrně bude
veřejně dostupné ke stažení (jaká bude dostupná historie změnových
souborů, to jsem nenašel). To je rozumné a mělo by to umožnit
pravidelnou aktualizaci dat v OSM.

Honza

Dne 24. června 2012 17:55 Jan Bilak  napsal(a):
> Zdravím,
>
> díky za info, ještě mám dotazy. Budou průběžně vydávané změnové soubory
> (popis formátu jsem tam viděl) nebo jen kompletní snapshoty? S jak častou
> aktualizací dat se počítá (jednou denně, ...)?
>
> Honza
>
> Dne 24.6.2012 17:26 "Jiří Veselý"  napsal(a):
>
>> Zdravím všechny,
>> s webovými službami se zatím nepočítá, výjimkou bude WS pro ověření
>> adresy. Jinak pokud jde o pokrytí území, tak katastrální data jsou ve
>> výměnném formátu na cca 2/3 katastrálních území (DKM + KMD). Definiční čáry
>> ulic a další prvky jsou v RUIAN přes celou republiku.
>>
>> J. Veselý
>>
>> Dne 22.6.2012 22:12, Martin Kokeš napsal(a):
>>>
>>> Ano, jde o RÚIAN, veřejný registr bez licence, dle 111/2009 Sb..
>>> Generovaná data jsou už teď ke stažení. Rozhraní VDP ještě není, bude až od
>>> 1.7., nevím jak to bude se SOAPem, možná podobně, jako funguje u WSDP ke KN.
>>> Více info by asi dal p. Veselý.
>>>
>>> Využitelné jsou samozřejmě uliční čáry, polygony budov, adresní body,
>>> takže je čas udělat tracerům pápá (to platí pro zastavěné území).
>>>
>>> V souvislosti s WFS službou nad tématem INSPIRE parcely je možné získávat
>>> parcely i mimo zastavěné území, buď jako předgenerované soubory, nebo přímo
>>> přes WFS dotaz (možná by se ulevilo ZP a jeho tabletu při obkreslování
>>> zemědělské půdy ;-)...).
>>>
>>> Jelikož se všude používá nativně Křovák, je nutná zpřesněná transformace
>>> pomocí S-JTSK gridu.
>>>
>>> MK
>>>
>>> - Original Message -
>>> From: Jan Bilak
>>> [mailto:jan.bilak@gmail.com]
>>> To: OpenStreetMap Czech Republic
>>> [mailto:talk-cz@openstreetmap.org]
>>> Sent: Fri, 22 Jun 2012 20:53:02
>>> +0200
>>> Subject: Re: [Talk-cz] Data RUIAN - výměnný formát
>>>
>>>
>>>> Ahoj,
>>>>
>>>> předem se omlouvám, pokud budu psát nesmysly - moc o tom nevím.
>>>>
>>>> Chápu to správně tak, že data budou licenčně použitelné pro OSM,
>>>> budou
>>>> obsahovat např. adresní body, obrysy budov, ulice apod., vše zdarma ve
>>>> formě veřejné dostupné aplikace na bázi XML/SOAP? A nyní data ještě
>>>> dostupná nejsou, ale budou od příštího měsíce. Data nejsou
>>>> kompletní,
>>>> ale zahrnutí jen ty části ČR, které mají digitalizovaný katastr
>>>> nemovitostí (cca půlka, ale výhledově bude růst). Data budou
>>>> průběžně
>>>> aktualizována a budou dostupná ve dvou formátech:
>>>> a) aktuální stav
>>>> b) změnové soubory
>>>>
>>>> Pokud je to tak je, tak by bylo vhodné celý proces importu maximálně
>>>> zautomatizovat tak, aby se dala provádět pravidelně aktualizace dat
>>>> (třeba 1x denně nebo týdně ... to je už detail). Kromě vlastního
>>>> převedení dat bude třeba řešit kolize s daty, které pochází z
>>>> jiných
>>>> zdrojů (např. ručně kreslené). Rád bych se na takové automatizaci
>>>> podílel, protože v tom vidím značný přínos.
>>>>
>>>> S pozdravem
>>>> Honza
>>>
>>> ___
>>> Talk-cz mailing list
>>> Talk-cz@openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>>
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Data RUIAN - výměnný formát

[Jan Bilak]

Zdravím,

díky za info, ještě mám dotazy. Budou průběžně vydávané změnové soubory
(popis formátu jsem tam viděl) nebo jen kompletní snapshoty? S jak častou
aktualizací dat se počítá (jednou denně, ...)?

Honza
Dne 24.6.2012 17:26 "Jiří Veselý"  napsal(a):

> Zdravím všechny,
> s webovými službami se zatím nepočítá, výjimkou bude WS pro ověření
> adresy. Jinak pokud jde o pokrytí území, tak katastrální data jsou ve
> výměnném formátu na cca 2/3 katastrálních území (DKM + KMD). Definiční čáry
> ulic a další prvky jsou v RUIAN přes celou republiku.
>
> J. Veselý
>
> Dne 22.6.2012 22:12, Martin Kokeš napsal(a):
>
>> Ano, jde o RÚIAN, veřejný registr bez licence, dle 111/2009 Sb..
>> Generovaná data jsou už teď ke stažení. Rozhraní VDP ještě není, bude až od
>> 1.7., nevím jak to bude se SOAPem, možná podobně, jako funguje u WSDP ke
>> KN. Více info by asi dal p. Veselý.
>>
>> Využitelné jsou samozřejmě uliční čáry, polygony budov, adresní body,
>> takže je čas udělat tracerům pápá (to platí pro zastavěné území).
>>
>> V souvislosti s WFS službou nad tématem INSPIRE parcely je možné získávat
>> parcely i mimo zastavěné území, buď jako předgenerované soubory, nebo přímo
>> přes WFS dotaz (možná by se ulevilo ZP a jeho tabletu při obkreslování
>> zemědělské půdy ;-)...).
>>
>> Jelikož se všude používá nativně Křovák, je nutná zpřesněná transformace
>> pomocí S-JTSK gridu.
>>
>> MK
>>
>> - Original Message -
>> From: Jan Bilak
>> [mailto:jan.bilak.osm@gmail.**com ]
>> To: OpenStreetMap Czech Republic
>> [mailto:talk-cz@openstreetmap.**org ]
>> Sent: Fri, 22 Jun 2012 20:53:02
>> +0200
>> Subject: Re: [Talk-cz] Data RUIAN - výměnný formát
>>
>>
>>  Ahoj,
>>>
>>> předem se omlouvám, pokud budu psát nesmysly - moc o tom nevím.
>>>
>>> Chápu to správně tak, že data budou licenčně použitelné pro OSM,
>>> budou
>>> obsahovat např. adresní body, obrysy budov, ulice apod., vše zdarma ve
>>> formě veřejné dostupné aplikace na bázi XML/SOAP? A nyní data ještě
>>> dostupná nejsou, ale budou od příštího měsíce. Data nejsou
>>> kompletní,
>>> ale zahrnutí jen ty části ČR, které mají digitalizovaný katastr
>>> nemovitostí (cca půlka, ale výhledově bude růst). Data budou
>>> průběžně
>>> aktualizována a budou dostupná ve dvou formátech:
>>> a) aktuální stav
>>> b) změnové soubory
>>>
>>> Pokud je to tak je, tak by bylo vhodné celý proces importu maximálně
>>> zautomatizovat tak, aby se dala provádět pravidelně aktualizace dat
>>> (třeba 1x denně nebo týdně ... to je už detail). Kromě vlastního
>>> převedení dat bude třeba řešit kolize s daty, které pochází z
>>> jiných
>>> zdrojů (např. ručně kreslené). Rád bych se na takové automatizaci
>>> podílel, protože v tom vidím značný přínos.
>>>
>>> S pozdravem
>>> Honza
>>>
>> __**_
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> http://lists.openstreetmap.**org/listinfo/talk-cz<http://lists.openstreetmap.org/listinfo/talk-cz>
>>
>
>
> __**_
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-cz<http://lists.openstreetmap.org/listinfo/talk-cz>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Data RUIAN - výměnný formát

[Jan Bilak]

Ahoj,

díky, transformace souřadnic vypadá v pohodě (testovacím příkladem to prošlo).

Teď je otázka, jakou celkovou strategii importu a následných
aktualizací zvolit. Zveřejněná data registru neobsahují některé
informace o celé ČR, ale jen o částech, ve kterých je digitalizovaný
katastr. Dále nevím, do jaké míry katastr odpovídá realitě, ale
tipuji, že určitě budou budovy, které v katastru nejsou a opačně (nebo
jsou data nesprávná - např. jiný tvar obrys budovy). Data mohu
obsahovat více upřesňujících tagů. Je tedy možné (pravděpodobné), že
některá data budou lepší v OSM než v datech registru. Uliční čáry musí
nějak rozumně na sebe navazovat...

Na druhou stranu registr má jistě celkově velkou míru konzistence a
úplnosti, bude se průběžně rozšiřovat území, kde jsou dostupné všechny
informace a bude se průběžně aktualizovat, ...

Které konrétní údaje z registru se budou do OSM importovat?
Jak se vypořádat se starými daty?

Za ideální cílový stav bych považovat navázání dat na registr kvůli
aktualizacím, ale s možnost provádění všech typů změn, pokud registr
někde nebude správný, úplný nebo bude k dispozici více informací, než
které registr obsahuje. Celkově jde o poměrně mnoho dat (v XML to má
necelých 30 GB, i přes ukecanost XML je toho opravdu hodně), takže
jakékoli větší ruční zásahy do importu budou časově náročné.

Máte nějakou představu, nápady, ...?

Honza


Dne 23. června 2012 7:39 Martin Kokeš  napsal(a):
> Ahoj,
>
> viz http://grass.fsv.cvut.cz/gwiki/S-JTSK-Grid, cokoliv co používá GDAL/PROJ4.
>
> MK
>
> - Original Message -----
> From: Jan Bilak
> [mailto:jan.bilak@gmail.com]
> To: OpenStreetMap Czech Republic
> [mailto:talk-cz@openstreetmap.org]
> Sent: Sat, 23 Jun 2012 04:45:21
> +0200
> Subject: Re: [Talk-cz] Data RUIAN - výměnný formát
>
>
>> Díky. Nevíte o nějakých knihovnách (.NET, Java, JavaScript, C, C++,
>> ...) pro transformaci pomocí toho S-JTSK gridu? Nebo, pokud nejsou
>> přímo knihovny, ve kterých opensource programech s vhodnou licencí by
>> tato transformace šla najít?
>>
>> Honza
>>
>>
>> Dne 22. června 2012 22:12 Martin Kokeš 
>> napsal(a):
>> > Jelikož se všude používá nativně Křovák, je nutná zpřesněná
>> transformace pomocí S-JTSK gridu.
>> >
>> > MK
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Data RUIAN - výměnný formát

[Jan Bilak]

Díky. Nevíte o nějakých knihovnách (.NET, Java, JavaScript, C, C++,
...) pro transformaci pomocí toho S-JTSK gridu? Nebo, pokud nejsou
přímo knihovny, ve kterých opensource programech s vhodnou licencí by
tato transformace šla najít?

Honza


Dne 22. června 2012 22:12 Martin Kokeš  napsal(a):
> Jelikož se všude používá nativně Křovák, je nutná zpřesněná transformace 
> pomocí S-JTSK gridu.
>
> MK

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Data RUIAN - výměnný formát

[Jan Bilak]

Ahoj,

předem se omlouvám, pokud budu psát nesmysly - moc o tom nevím.

Chápu to správně tak, že data budou licenčně použitelné pro OSM, budou
obsahovat např. adresní body, obrysy budov, ulice apod., vše zdarma ve
formě veřejné dostupné aplikace na bázi XML/SOAP? A nyní data ještě
dostupná nejsou, ale budou od příštího měsíce. Data nejsou kompletní,
ale zahrnutí jen ty části ČR, které mají digitalizovaný katastr
nemovitostí (cca půlka, ale výhledově bude růst). Data budou průběžně
aktualizována a budou dostupná ve dvou formátech:
a) aktuální stav
b) změnové soubory

Pokud je to tak je, tak by bylo vhodné celý proces importu maximálně
zautomatizovat tak, aby se dala provádět pravidelně aktualizace dat
(třeba 1x denně nebo týdně ... to je už detail). Kromě vlastního
převedení dat bude třeba řešit kolize s daty, které pochází z jiných
zdrojů (např. ručně kreslené). Rád bych se na takové automatizaci
podílel, protože v tom vidím značný přínos.

S pozdravem
Honza


Dne 22. června 2012 18:37 Martin Kokeš  napsal(a):
> Já jsem si udělal pár jednoduchých XSL a přechroustal to pomocí XMLStarletu 
> dvěma kroky (první odstraní ty namespacy a druhý je pak transformace do 
> daného typu vrstvy) do docela importovatelného GML, které jde poslat do QGISu 
> nebo transformovat přes ogr2ogr.
>
> Jde třeba hranice ku, hranice obce (nic moc), hranice parcel, hranice budov, 
> budovy jako body, adresni místa jako body... s většinou atributů.
>
> Chce se toho někdo ujmout a vylepšit to na nějaký udělátor pro import? Asi by 
> šlo i udělat XSL přímo do OSM formátu, ale Merkaartor zvládne GML levou zadní.
>
> MK
>
> - Original Message -
> From: hanoj [mailto:eha...@gmail.com]
> To:
> OpenStreetMap Czech Republic [mailto:talk-cz@openstreetmap.org]
> Sent: Fri,
> 22 Jun 2012 13:48:11 +0200
> Subject: Re: [Talk-cz]  Data RUIAN - výměnný
> formát
>
>
>> Ahoj,
>
>> Po spuštění Veřejného dálkového přístupu k RUIAN budou
>> data dostupná přes tuto aplikaci.
> Vyborna zprava! Par otazek...
>
> * Proc se
>> uziva EPSG:2065, kdyz na data se bezne uziva ESRI:102067?
> * Je nejaky
>> osvedceny prohlizec, ktery umi data zobrazit krome
> Snowflake s
>> registraci?
>
>
> In specie OSM
> -
> Chapu to tak ze pro OSM
>> jsou pro plne automaticky import pouzitelne
> vrstvy na uzemi ktera uz ma DKM
>> (v dubnu 2012 55% CR):
> *AdresniMisto (addr=*)
> *Stavebni objekt
>> (building=*)
> *Ulice (name=*)
>
>
> Na uzemi bez DKM je jen Adresni
>> Misto.
>
>
> ha
> hanoj
>
> ___
> Talk-cz
>> mailing
>> list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] OSM ortofoto

[Jan Bilak]

Zdravím,

rád bych se na to podíval a případně to nějak zpracoval. Nic neslibuji
- nevím, jak to vypadá. A i kdybych to viděl, tak nevím, jak mi to
půjde zpracovat. Nicméně rád bych to zkusil.

Honza


Dne 2. února 2012 14:34 Jakub Sykora  napsal(a):
> Kolik je to asi tak dat? Mame nejake servery na ktere bychom mohli neco
> umistit...
>
> K
>
> Dne 2.2.2012 14:32, Pavel Machek napsal(a):
>
>> On Tue 2011-12-20 22:35:12, Jan Bilak wrote:
>>>
>>> Zdravím.
>>>
>>> Problém vidím v bodě 3. Třeba máš lepší zdroje, spoustu kamarádů
>>> pilotů, ale nějak moc nevěřím tomu, že by se toho podařilo dostatek
>>> nashromáždit. Přitom, aby to mělo rozumnou kvalitu, tak by to muselo
>>
>>
>> Na disku mam celou CR, cernobilou a starsi ale ve slusny kvalite,
>> redistribuovatelnou. (WMS CENIA).
>>
>> Otazka je jen "kde".
>>
>> Najdou se dobrovolnici na zpracovani?
>>
>>  Pavel
>>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] OSM Inspector a stav přijetí licence

[Jan Bilak]

Také mnohokrát děkuji. I mě to konečně dává smysl. Nakonec to je to
trochu podobné tomu, když jsem vymýšlel licenci pro tracer. Tam jsem
také chtěl to, aby si s tracerem a výsledkem trasování mohl dělat
každý co chce, ale pouze v případě, kdy získaná data také uveřejní v
OSM. Tento příspěvek obrátil můj pohled na změnu licence.

Honza


Dne 26. ledna 2012 17:10 Petr Holub  napsal(a):
>> Z praktického pohledu je pak nejvýraznější změna ohledně odvozených děl,
>> kdy někdo vezme OSM data, nějakým způsobem je vylepší (třeba něco
>> přidá), vykreslí a publikuje mapu. V případě CC je povinen dát výslednou
>> mapu k dispozici pod CC, ale už nemusí publikovat provedená vylepšení;
>> ODbL nařizuje praví opak, tj. mapu si dej pod licencí jakou chceš, ale
>> publikuj vylepšenou verzi dat.
>
> Huraaa! Dekuji! Prvni pekne vysvetleni rozdilu v tehle diskusi. Mne to dava
> smysl - v podstate OSM chce, aby byla ta licence stejne infekcni jako
> GPL. Coz u projektu, ktere vznikaji ciste ve volnem case lidi, dava
> docela smysl.
>
> Pro Kavola: cast ukolu, o jehoz splneni jsem Te pozadal v minulem mailu,
> uz splnil Xificurk. Muzes tedy aspon zkusit udelat tu druhou pulku
> a vysvetlit mi, co konkretne Ti na ODBL vadi? (A samotnou vymenu licence
> za ten duvod nepovazuji, protoze to _neni_ nabozenstvi. Je to jen
> vec, kterou vymenujeme jednu za druhou.)
>
> Dekuji,
> Petr
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] OSM Inspector a stav přijetí licence

[Jan Bilak]

Zdravím,

mám několik dotazů:

1) Změna licence má nějaké klady a nějaké zápory. Mezi zápory jistě
patří ztráta dat z OSM map. To je celkem podstatný zápor. Otázka tedy
zní, jaké jsou ty konkrétní podstatné klady, které mají převážit
zápory?

2) Změnou licence nedojde ze ztrátě dat obecně, ale ke ztrátě z OSM.
Pokud to dobře chápu, tak ve FOSM (což je vzniklá odnož s původní
licencí) bude fungovat dále. Má tato odnož k dispozici prostředky, aby
mohla reálně fungovat?

3) Pokud někdo bude po rozdělení na OSM a FOSM příspívat do OSM, může
tyto změny přebírat FOSM (po stránce licence)?

4) Pokud někdo bude po rozdělení na OSM a FOSM příspívat do FORM, může
tyto změny přebírat OSM (po stránce licence)?

Chápu, že u bodu 3 a 4 bude technický problém s návaznostmi na
stávající data, která nebudou v obou projektech stejná.

5) Jaké praktické důsledky změna licence má? Co někdo dříve mohl a
nově nemůže a naopak? Myslím, že už jsem se jednou na to ptal, ale
nedostal jasnou odpověď (z čehož jsem usoudil, že to asi není moc
jasné nebo o tom spousta lidí neví).

6) V čem bude OSM lepší než FOSM? FOSM bude obsahovat více dat,
protože žádná neztratí, ne?

Honza


Dne 25. ledna 2012 19:23 "Petr Morávek [Xificurk]"
 napsal(a):
> jzvc wrote:
>> Jenze v principu ma pravdu, protoze kvuli tyhle kravine bude znicena
>> prace spousty lidi
>
> Ale houby! Práce spousty lidí nebude zničena proto, že se mění licence,
> ale proto, že pavel momentálně zaujal postoj - "chci zničit co nejvíc
> dat OSM, aby lidi přešli na FOSM".
> Ono, když se podíváte na statistiky, tak nebýt rozhodnutí pavla a jkjk,
> tak ztráta dat je prakticky nulová... Ale mají na to rozhodnutí právo, a
> zbytek komunity se holt bude muset nějak se vzniklou situací vypořádat.
>
> Petr Morávek aka Xificurk
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] OSM ortofoto

[Jan Bilak]

Zdravím.

Problém vidím v bodě 3. Třeba máš lepší zdroje, spoustu kamarádů
pilotů, ale nějak moc nevěřím tomu, že by se toho podařilo dostatek
nashromáždit. Přitom, aby to mělo rozumnou kvalitu, tak by to muselo
být focené nějak rozumně (v nějakém rozmezí úhlů, z nějakého rozmezí
výšek, přijatelnou kvalitou fotoaparátu + objektivů, při slušném
počasí a světelných podmínkách atp.). Navíc snímky by musely být nějak
otagované alespoň přibližnou polohou, protože těžko z pohledu na fotku
určit, odkud vlastně je. A také vlastnostmi objektivu (možná by stačil
EXIF), aby se to dalo nějak rozumně zpracovávat.

Pokud by byl dostatek podkladů, tak nějaké to technické zpracování
bych už viděl jako menší problém. Tedy v případě slušných podkladů. V
případě špatných podkladů naopak téměř za nemožné - tedy výsledek by
nebyl moc použitelný. Pracnost také bude zvyšovat různorodost
fotoaparátů, objektivů a podmínek, ze kterých to bylo focené
(nastavení fotoaparátu apod.).

Každopádně první krok je nashromáždění těch podkladů. Pokud nebudou
podklady, tak nemá smysl začínat s něčím dalším.

Honza



Dne 20. prosince 2011 22:25 Petr Nejedly  napsal(a):
> http://openaerialmap.org/Main_Page
>
> Sent via BlackBerry
>
> -Original Message-
> From: Petr Balíček 
> Date: Tue, 20 Dec 2011 22:12:33
> To: 
> Reply-To: OpenStreetMap Czech Republic 
> Subject: [Talk-cz] OSM ortofoto
>
> Zdravim,
>
> jeden z posledních vážných důvodů, proč používat nesvobodný mapy od Seznamu, 
> Gúglu, atd. je, že OSM chybí vrstva s leteckou mapou. Tak mě napadlo, proč si 
> ji taky nevyrobit? Hodila by se třeba i k odvozování dat do OSM (Na 
> "obkreslování" by to asi nebylo.).
>
> Bylo by k tomu potřeba:
>
> 1) Přístup k serveru, kam by se nahrávaly dlaždice.
>
> 2) Software, kterej by uměl transformovat letecký fotky do souřadnic podle 3+ 
> naklikaných bodů, jejichž polohu známe, rozřezat na dlaždice a poslat na 
> server. Napsat takovej program by byl asi největší kámen úrazu, ale možná se 
> někdo schopnej najde.
>
> 3) Spousta leteckejch fotek, ale myslim, že by se jich podařilo nashromáždit 
> překvapivě dost - stačilo by se poptat kamarádů a známejch, oni by se určitě 
> rádi vzdali autorských práv.
>
> 4) Mravenčí práce, trochu si s tim pohrát.
>
> Zkoušel sem si takhle vyrobit pár dlaždic jen tak ručně v GIMPu nástrojem 
> "perspektiva" a výsledek je docela slušnej (Samozřejmě, že je to takhle moc 
> pracný a ne zrovna přesný).
> Sám se do takovýho projektu nepustim, protože na to nemam potřebný zázemí a 
> znalosti, ale samozřejmě bych se taky rád přičinil.
> Přišlo mi to prostě jako dobrej nápad, třeba se toho někdo chytne, možná by 
> to bylo pěkný téma na bakalářku...
>
> Mělo by něco takovýho smysl nebo je to úplně zcestná myšlenka?
>
> PB
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] hlášení chybného zobrazení katastrální mapy

[Jan Bilak]

Zdravím,

omlouvám, že se nyní projektu nevěnuji (nedostatek času). VerticalSkip
tuším bylo kvůli odříznutí nějakého copyrightu, který by dělal při
rozpoznávání problémy v případě, že by někdo kliknul na místo, kde se
zrovna nacházel. Nevím, zda se tam pořád nebo už tam není. Pokud tam
je, že tak to s VerticalSkip=1 bude dělat problémy. Stejně tak větší
dlaždice nemělo příliš smysl dělat, protože pak už tam přibyl další
copyright.

S pozdravem
Honza


2011/11/28 jzvc :
> Dne 28.11.2011 15:44, Petr Schonmann napsal(a):
>> Dne 28.11.2011 10:50, Zdeněk Pražák napsal(a):
>>> Dá se někam nahlásit chybné zobrazení katastrální mapy na cuzk.cz -
>>> zobrazuje se duplicitně digitální mapa i původní rastrová mapa
>>> například v katastrálním území Trusnov
>>> Pražák
>>>
>>> ___
>>> Talk-cz mailing list
>>> Talk-cz@openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-cz
>> Mám nastaveno
>>
>> wms:http://wms.cuzk.cz/wms.asp?FORMAT=image/png&transparent=TRUE&VERSION=1.1.1&SERVICE=WMS&REQUEST=GetMap&Layers=DEF_BUDOVY,dalsi_p_mapy_i,hranice_parcel_i,obrazy_parcel_i,parcelni_cisla_i&SRS={proj}&WIDTH={width}&HEIGHT={height}&BBOX={bbox}
>>
>>
>> A abych si ještě postěžoval já :) Stejné vrstvy jsem nastavil i do
>> traceru - jsou to jen digitalizované mapy. V Josm stejnou wms url,
>> přesto dostávám výsledný polygon z traceru kousek posunutý. Je to bug ?
>
> Neni to bug, je to dany historickym nastavenim v konfiguraci.
>
> jde o toto: 
> verticalSkip bylo puvodne (od autora) nastaveno na 560, kdyz sem tam
> nastavil 0, tak to sedi temer dokonale (a lehce sem zvednul rozliseni na
> dvojnasobek zmensenim titlesize, ale to uz spis kvuli ruznym pidi domeckum)
>
>>
>> http://tinypic.com/view.php?pic=3160x0g&s=5
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Oauth strasi?

[Jan Bilak]

Řekněme, že by se opravdu někdo našel a data začal prodávat. Kdo by je
ale koupil, kdy je může získat zdarma přímo z OSM? Jistě - někdo by se
najít mohl, ale nevidím v tom žádné podstatné riziko. Obdobně
vydělávat lze např. i prodejem GPL software, ale kdo GPL software
kupoval, když jej může mít zdarma?

Také by mohl data nějak vylepšit a prodat vylepšená data. Ale to je
velmi podobný případ. Kdo by koupil takto vylepšená data za větší cenu
než je cena tohoto vylepšení? Mohl by si totiž vzít zdarma data z OSM
a vylepšit si je stejně.

Honza


Dne 21. června 2011 17:43 Jakub Sykora  napsal(a):
> "Přirozenou nevýhodou demokracie je, že těm, kdo to s ní myslí poctivě,
> nesmírně svazuje ruce, zatímco těm, kteří ji neberou vážně, umožňuje téměř
> vše." (V. Havel)
>
> Jinymi slovy - cela tahle habadura se dela vlastne jen proto, ze by v
> budoucnu (nebo soucasnosti) mohl nekdo vytezovat OSM a prodavat to jako
> svoji praci.
>
> Xfree a Xorg - celkem hezke prirovnani - akorat u Xek neni ten vyvoj tak
> strasne rychly jako u OSM... Navic ne mala skupina lidi podporila zmenu na
> ODBL (skoro 50% vsech) Bohuzel OSM pro me neni jen ta databaze ale i vsechno
> kolem - servery, sluzby - a to neni malo. Neumim si v tuhle chvili
> predstavit zivotaschopny fork.
>
> K
>
> Dne 21.6.2011 17:08, Stanislav Brabec napsal(a):
>>
>> Jakub Sykora píše v Út 21. 06. 2011 v 16:20 +0200:
>>
>>> - to znamena, ze "hodni hosi" legalne nemuzou vlastne data pouzivat a
>>> "zli hosi" je muzou beztak vyuzivat jak chteji
>>
>> Takže chápu-li to dobře, tak proto, aby "zlí hoši" nemohli kopírovat mou
>> práci, tak "hodní hoši" čtvrtinu mé práce zničí.
>>
>> S novou licencí jsem souhlasil. Souhlasil jsem s tím, aby mé příspěvky
>> byly public domain. Ale hrubě nesouhlasím s tím, aby se mé příspěvky
>> mazaly z jakéhokoliv vnitřně politického důvodu.
>>
>> Pokud to provedou, projektu OpenStreetMap předpovídám budoucnost
>> XFree86. Ten projekt také dodnes existuje a vydává své verze, ale téměř
>> všichni uživatelé utekli po vnucené změně licence k forku - k Xorg.
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Oauth strasi?

[Jan Bilak]

Díky. Ale ještě z toho shrnutí nerozumím, jak to tedy podle nové
licence bude v tom modelovém případě:

"Pokud někdo vaše data používá pro mapu s několika vrstvami v knize,
co všechno má být pod CC-BY-SA? Jen vrstva OpenStreetMap a její
úpravy? Celá mapa včetně nesouvisejících vrstev a značek? Celá kniha?"

Tohoto se patrně týká odstavec:

"Podle nové licence může mapu uvolnit pod jakoukoli licencí chce,
pokud uvolní všechny doplňky a vylepšení, které k našim datům přidal.
Hlavním důvodem pro tuto změnu je, že mapy lze nyní vytvářet pomocí
vrstev z nekompatibilních zdrojů dat."

Těmi doplňky se myslí např. software, který použil k vytvoření mapy z
dat, data jiných vrstev? Tedy nyní lze vzít OSM data, vytvořit z jich
libovolným způsobem mapu (např. pomocí nějakého software, který není
"volný"), dokreslit si na ni nějaké další informace (např. trasu
nějakého závodu), které neuvolním ... a tohle po změně licence již
nepůjde (tedy s novými daty, které nejsou licencovány i starou
licencí)?

Tedy změna licence přidává omezení na využití dat?

Honza


Dne 21. června 2011 16:39 Petr Kadlec  napsal(a):
> Ahoj
>
>>> Můžete mi prosím někdo stručně vysvětlit, v čem jsou zásadní rozdíly mezi 
>>> licencemi?
>>> Věřím, že tyto informace stručně a jasně shrnuté pomohou i dalším.
>> [...]
>> Volne prekladam z [1]:
>
> Nechci nějak moc provádět samopropagaci, ale...
> http://wiki.openstreetmap.org/wiki/Cz:ODbL/We_Are_Changing_The_License
> :-)
>
> -- Petr Kadlec / Mormegil
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Oauth strasi?

[Jan Bilak]

Zdravím,

situaci ohledně změny licence jsem nesledoval a i když nemám žádný
podstatný podíl na editacích v OSM, rád bych si udělal obrázek o tom,
o co jde, a nějak se rozhodnul. Můžete mi prosím někdo stručně
vysvětlit, v čem jsou zásadní rozdíly mezi licencemi? Jaký je hlavní
důvod změny licence? Jaké jsou naopak negativa nové licence, že
někteří nesouhlasí (podle té tabulky s licencí nesouhlasí i druhý
nejčastější přispěvovatel "pavel", který je pořád velmi aktivní).

Jakým způsobem je třeba vyjádřit souhlas/nesouhlas a do kdy?

Věřím, že tyto informace stručně a jasně shrnuté pomohou i dalším.

Díky
Honza



Dne 21. června 2011 15:36 MP  napsal(a):
> To že vznikne CC-BY-SA fork je skoro jisté, teď už jen doufat, že ten fork
> bude jen jeden, nebo že pokud jich bude víc, tak ty ostatní rychle vychcípou
> a zbyde jen jeden (plus někteří lidi chtěli i PD fork, takže je možné, že
> vznikne ještě jeden fork, kde ale bude asi jen minimum dat)
>
> Pokud v ČR zmizí 20 až 25 procent dat (což je aktuální odhad dle té
> stránky), tak bych tipoval, že lidi nejspíš utečou k cc-by-sa forku, v
> jiných zemích to může dopadnout jinak (pokud bude dopad mazání minimální,
> můžou tam lidi zůstat).
>
> Úplný rozpad asi nebude, ale tipuju, že se přispěvatelé rozdělí na tři
> skupiny, jedna co zůstane na ODBl a pokusí se napravit chaos vzniklý
> smazáním čtvrtiny dat (tipuju to na většinu lesů a vodstva plus asi celkem
> dost silnic a dalších věcí - může to být méně než čtvrtina pokud se některé
> podaří přesvědčit aby odbl akceptovali, ale i více, pokud se ukáže že
> některé importy jsou s novou licencí nekompatibilní a pak by musela data
> pryč ať už dotyčný souhlasil s odbl nebo ne) a ta se nejspíš časem bude
> spíše zmenšovat (asi je těžké dávat dohromady mapu, kde po celé republice
> různé "náhodné" kousky chybí). Druhá se přesune na cc-by-sa fork, kde budou
> data všechny (ale je to fork, ne každý o něm ví atd ...). Třetí odejde a
> přestane mapovat. Tipuju, že žádná z prvních dvou nebude větší než polovina
> současných uživatelů.
>
> Martin
>
> On Tue, 21 Jun 2011 14:21:21 +0200, Jakub Sykora wrote:
>>
>> Ja pockam, jak se to vyvine. Kazdopadne pokud to zpusobi rozpad
>> tohoto projektu, bude me to hodne mrzet - adl jsem do toho dost sveho
>> casu a energie, ktera by vysla dost nazmar.
>>
>> A vkladat znovu energii do neceho co bude zase zacinat od piky, to
>> opravdu ne...
>>
>> K
>>
>> Dne 21.6.2011 14:05, Michal Grézl napsal(a):
>>>
>>> 2011/6/21 Jakub Sykora:

 Abych pravdu rekl, tak jsem tohle moc nesledoval i kdyz jsem vedel, ze
 to
 dopadne jako pru.er, ale faze 4 me trochu desi a jeste vic po ni faze 5.
 Pokud bude clovek pro kompletni dataset muset mergovat finalccby.osm a
 novou
 odbl databazi, tak to bude pekne na "vite co"... Tech dat, ktere z DB
 vypadnou, nebude malo - vizte [1]

 K

 [1] http://odbl.de/czech_republic.html

>>>
>>> Pokud ty data opravdu smazou, coz udelaji, a nikdo je neda zpet, tak
>>> se bude muset zustat u forku, nebot zadne mergeovani pravdepodobne
>>> nebude mozne. Nehlede na to ze budeme mozna muset vymazat veskera
>>> importovana data, u kterych puvodni vlastnik nebude souhlasit s novou
>>> licenci.
>>>
>>> Pro zacatek http://fosm.org/
>>>
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Import adresních bodů - Nekonzistenc e cuzk:km a mvcr:adresa

[Jan Bilak]

> Problem je, ze toto neni adresa. Ve vetsine obci, ktere maji i sve
> casti, je urcujici adresa ulice + cp + obec + psc. Z psc se da (pokud je
> spravne) urcit cast obce. Cast obce (tu oficialni) spousta lidi ani
> nezna. Klidne muzu uvest konkretni priklad, v Teplicich je cast Trnovany
> a cast Sanov, ale existuje prostor, kteremu se "odjakziva" rika Sanov
> II, presto, ze oficielne je soucasti mestske casti Trnovany. Vetsina
> lidi ale vubec netusi ze bydli v Trnovanech, protoze za ty je oznacovana
> starsi zastavba, nikoli sidliste na kopci.

Dobře, ale co tím chceš říct? Co je to adresa? Všechny informace o
daném místě? Minimální množství údajů, které identifikuje dané místo?
Nevím a o pojmy stejně nejde. Je jasné, že pro danou adresu musí jít
lehce zjistit všechno, co je možné - část obce, obec, okres, kraj,
psč, stát, ... prostě všechno. Ale neznamená to automaticky, že ty
všechny informace musí být u daného adresního nodu.

Obdobné je to třeba v relačních (typicky SQL) databázích, které se
typicky navrhují ve 3. normální formě, která víceméně kromě jiného
volně řečeno říká, že jedna informace tam má být zanesena pouze
jednou. Ústupky z normální formy se typicky dělají pouze z
výkonostních důvodů. A i v SQL databázích jsou nástroje pro výkonostní
optimalizaci bez narušení normální formy - např. materializované
pohledy. Tedy jde vlastně u uchování duplicitních dat v nějakém tvaru,
který je výhodný pro rychlou práci, a který se automaticky aktualizuje
podle primárních údajů v tabulkách.

A obdobně bych si dovedl představit, že "automat" bude doplňovat např.
obec k adresnímu místu a to tak, že se podívá na adresní místo, do
jaké části obce patří. A pak na danou část obce, do jaké obce tato
část obce patří.

A co s případy, kde si lidé myslí něco jiného než je oficiální
rozdělení? Nevím. Buď to ignorovat - proč zanášet do OSM nepravdivé
informace? Nebo to tam zapsat jako nějaký jiný tag typu
"nezanedbatelná skupina lidí si myslí, že tohle je ..., i když to není
pravda", což pak může nějaká aplikace využít pro nějaké hledání.

Honza



2010/9/30 jzvc :
> Problem je, ze toto neni adresa. Ve vetsine obci, ktere maji i sve
> casti, je urcujici adresa ulice + cp + obec + psc. Z psc se da (pokud je
> spravne) urcit cast obce. Cast obce (tu oficialni) spousta lidi ani
> nezna. Klidne muzu uvest konkretni priklad, v Teplicich je cast Trnovany
> a cast Sanov, ale existuje prostor, kteremu se "odjakziva" rika Sanov
> II, presto, ze oficielne je soucasti mestske casti Trnovany. Vetsina
> lidi ale vubec netusi ze bydli v Trnovanech, protoze za ty je oznacovana
> starsi zastavba, nikoli sidliste na kopci.
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Import adresních bodů - Nekonzistenc e cuzk:km a mvcr:adresa

[Jan Bilak]

Ahoj,

> Jak už jsem napsal dvakrát, tak si myslím, že název obce je součástí
> adresy, a měl by bít součástí adresního bodu. Jednak kvůli problémům s
> přesností hranic obce, jednak kvůli rozdílům v úředních databázích, ale
> především kvůli tomu, že z dat není jasné, který nadřazený celek má
> vlastně na té adrese být a u částí obce v datech vůbec není.

Jak se to vezme. Pokud bychom se chtěli vyhnout duplicitám, tak v
adrese patrně stačí:
- část obce
- číslo domovní
- ulice (náměstí, ..., obecně UVP)
- číslo orientační

Každá část obce pak jednoznačně patří do nějaké obce. Obec patří do
okresy atp. Přesně podle toho schematu:
http://forms.mpsv.cz/uir/prohlizec/prohlizec.html

Obec pak lze zjistit přes část obce.

A pokud bychom duplicity považovali z nějakého důvodu užitečné, tak by
bylo dobré jasně prohlásit takové údaje za duplicity (jakési
sekundární vyjádření informací, které jsou primárně vyjádřené nějak
jinak), a které se budou aktualizovat automaticky podle primárního
vyjádření informací a tak bude zaručena konzistence dat a snadnost
aktualizací.

> Doplňovat tam celý strom mi ale přijde trochu zbytečné.

Mít v OSM informace o všech objektech, které jsou v UIR-ADR mi přijde
poměrně užitečné. Nakonec OSM chápu jako takovou DB, do které se
importují všechna užitečná geo data, která jsou licenčně dostupná. A
když tam budou ty objekty, tak by tam měly být i jejich vzájemné
vztahy. Zda ten vztah bude primárně vyjádřen hranicí nebo atributem
"patří_do", to je už je věc jiná a zde by podle mne mělo záležet na
tom, jak je daný vztah primárně definovaný (např. nějakým zákonem,
opatřením ČSÚ apod.). Sekundárně může být vyjádřen i jinak, ale
sekundární vyjádření lze již doplňovat automaticky z primárního
vyjádření. Takový postup podle mne usnadní aktualizace.

Honza


2010/9/30 Petr Dlouhý :
> Ahoj,
>
> mám pocit, že Nominatim si ten strom bez problému generuje z dat, takže
> pro většinu běžných použití to bohatě stačí. Napojení na úřední databáze
> pomocí čísel je samozřejmě víc než vhodné udělat v každém případě.
>
> Jak už jsem napsal dvakrát, tak si myslím, že název obce je součástí
> adresy, a měl by bít součástí adresního bodu. Jednak kvůli problémům s
> přesností hranic obce, jednak kvůli rozdílům v úředních databázích, ale
> především kvůli tomu, že z dat není jasné, který nadřazený celek má
> vlastně na té adrese být a u částí obce v datech vůbec není.
> Doplňovat tam celý strom mi ale přijde trochu zbytečné.
>
>
> On Thu, 30 Sep 2010 16:16:59 +0200, Jan Bilak 
> wrote:
>
>> Ahoj,
>>
>> souhlasím. Hranice mají tu výhodu, že je lze dobře vykreslovat na
>> mapě. Z stromového/svazového (dále budu psát jen o stromu, i když
>> možná by šlo obecně o svaz kvůli městským částem a částem obcí apod.)
>> by se pro vykreslení musela hranice vždy počítat - jinak si nedovedu
>> představit nějaké rozumné vykreslení na mapě (barvení budov apod. není
>> myslím dobrý nápad).
>>
>> Stromovou strukturu poskytuje v rozumné podobě UIR-ADR. Tato DB se i
>> průběžně aktualizuje a je tedy vhodné si udržovat na ni vazby. A to
>> ideálně před ty kódy, které jsou v této DB. Nevím, kdo je vymyslel
>> (asi jsou to nějaké číselníky statistického úřadu), ale hojně se
>> používají (např. katastr, ARES apod.). A tyto kódy bych tedy navrhoval
>> doplnit ke všem objektům (krajům, obcím, částem obce, budovám, ...),
>> kde to bude možné. Usnadní se tak mimo jiné i možnost automatické
>> aktualizace OSM podle UIR-ADR.
>>
>> Když budou data jak ve formě hranice, tak ve formě stromu/svazu, tak
>> to znamená duplicity v datech a spoustu problémů při změnách. Otázka
>> je, zda ty změny jsou tady tak časté, aby mělo smysl na tím uvažovat.
>> Ideální by podle mne bylo, mít jako primární jeden způsob uchování
>> vztahů mezi objekty pro každou dvojici typů objektů. Tedy např.
>> stanovit, že vztahy mezi objekty (budovami) a částmi obce bude
>> primárně ve formě stromu a hranice částí obcí se budou dopočítávat. Na
>> dopočítávání by se udělala nějaká utilitka. Dopočítávání až při
>> kreslení ... nevím, zda je reálné, ale obecně nějaké dopočítávané
>> "cache" informace v OSM obecně nepovažuji za špatné - jen je třeba s
>> nimi tak zacházet.
>>
>> Hierarchie UIR-ADR je znázorněna tady a stejná hierarchie by neškodila v
>> OSM:
>> http://forms.mpsv.cz/uir/prohlizec/prohlizec.html
>>
>>
>> S těmi SVJčky máš asi pravdu - koukal jsem namátkově na několik SVJ.
>> Získat automaticky polohu dalších vchodů (čísel popisných) si nedovedu
>> moc představit - tedy nevím, z čeho. Ale zjistit čísla popisná, která
>> tvoří jednu "budovu" v katastru, není takový problém - a to právě z
>> katastru nemovitostí. Otázka al

Re: [Talk-cz] Import adresních bodů - Nekonzistenc e cuzk:km a mvcr:adresa

[Jan Bilak]

Ahoj,

souhlasím. Hranice mají tu výhodu, že je lze dobře vykreslovat na
mapě. Z stromového/svazového (dále budu psát jen o stromu, i když
možná by šlo obecně o svaz kvůli městským částem a částem obcí apod.)
by se pro vykreslení musela hranice vždy počítat - jinak si nedovedu
představit nějaké rozumné vykreslení na mapě (barvení budov apod. není
myslím dobrý nápad).

Stromovou strukturu poskytuje v rozumné podobě UIR-ADR. Tato DB se i
průběžně aktualizuje a je tedy vhodné si udržovat na ni vazby. A to
ideálně před ty kódy, které jsou v této DB. Nevím, kdo je vymyslel
(asi jsou to nějaké číselníky statistického úřadu), ale hojně se
používají (např. katastr, ARES apod.). A tyto kódy bych tedy navrhoval
doplnit ke všem objektům (krajům, obcím, částem obce, budovám, ...),
kde to bude možné. Usnadní se tak mimo jiné i možnost automatické
aktualizace OSM podle UIR-ADR.

Když budou data jak ve formě hranice, tak ve formě stromu/svazu, tak
to znamená duplicity v datech a spoustu problémů při změnách. Otázka
je, zda ty změny jsou tady tak časté, aby mělo smysl na tím uvažovat.
Ideální by podle mne bylo, mít jako primární jeden způsob uchování
vztahů mezi objekty pro každou dvojici typů objektů. Tedy např.
stanovit, že vztahy mezi objekty (budovami) a částmi obce bude
primárně ve formě stromu a hranice částí obcí se budou dopočítávat. Na
dopočítávání by se udělala nějaká utilitka. Dopočítávání až při
kreslení ... nevím, zda je reálné, ale obecně nějaké dopočítávané
"cache" informace v OSM obecně nepovažuji za špatné - jen je třeba s
nimi tak zacházet.

Hierarchie UIR-ADR je znázorněna tady a stejná hierarchie by neškodila v OSM:
http://forms.mpsv.cz/uir/prohlizec/prohlizec.html


S těmi SVJčky máš asi pravdu - koukal jsem namátkově na několik SVJ.
Získat automaticky polohu dalších vchodů (čísel popisných) si nedovedu
moc představit - tedy nevím, z čeho. Ale zjistit čísla popisná, která
tvoří jednu "budovu" v katastru, není takový problém - a to právě z
katastru nemovitostí. Otázka ale je, jak je to licencí těchto dat.
Pokud by to šlo legálně využít, tak nějaká data mohu dodat (mám toho
tady poměrně hodně předzpracovaného).

Honza


Dne 30. září 2010 15:27 Ondrej Zajicek  napsal(a):
> On Thu, Sep 30, 2010 at 12:53:56PM +0200, jzvc wrote:
>> > A jinak jo, v is_in muze byt cela hierarchie.
>> >                                                                     Pavel
>> >
>> Jak bylo receno, je to z historickych duvodu, ale u nove vkladanych dat
>> bych to tam necpal, postrada to smysl. Ony se casem aplikace naucej
>> pouzivat hranice a pak bude mozny to odstranit.
>
> Je otazka, zda ma kvuli takovym vecem smysl pouzivat hranice, zda by
> nebylo mnohem lepsi mit nekde zvlast hierarchicka data ve forme stromu
> nebo svazu, ktere by aplikace pouzivaly pro urceni nadrazenych celku.
> Reseni vyuzivajici geometrickou hranici ma nevyhody jednak kvuli
> nekonzistenci dat (napr. zmineny problem s objekty blizko hranice,
> kde je nekonzistence mezi hranici v OSM a u uradu. Opravit tag urcujici
> nadrazeny celek je jednoduche, ale opravit hranici (bez vhodneho zdroje
> dat slouziciho jako podklad) je vyrazne komplikovanejsi.
>
> Krom toho reseni skrz hranice nemusi byt v nekterych pripadech vubec
> mozne - AFAIK casti obce (v ramci obce) nejsou vymezene hranicema, ale
> ciste formalnim rozdelenim objektu (budov), aby platila jedinecnost
> cisla popisneho/evidencniho v ramci casti obce. V nekterych obcich (co
> jsem si vsiml v KN) treba budovy s cislem popisnym jsou rozdelene na
> casti obce podle toho kde lezi, ale skoro vsechny budovy s cislem
> evidencnim jsou prirazene k 'hlavni' casti obce.
>
>
> Druhy problem je, ze jak addr:city, tak ani is_in (v soucasne podobe
> ziskane importem adres) neni v nekterych pripadech dostatecny. is_in
> (generovany importem adres z CUZK a KN) obsahuje cast obce, obec a kraj,
> jenze jmena obci jsou unikatni jen v ramci okresu a i v ramci kraju
> existuje par set kolizi. Mam napsany programek na validaci importovanych
> adres v OSM, ale na tomhle selhava. Mozna by bylo dobre zavest nejaky
> cesky specificky atribut udavajici kod casti obce unikatni v CZ (treba
> ten pouzivany v registru CUZK, nebo nektery jiny oficialni) a udavat ho
> u adresnich bodu v CZ. To by dost usnadnilo validaci a pripadne
> pozdejsi automaticke udrzovani konzistence s daty CUZK ci automaticke
> upravy osatnich tagu adres na zaklade dat z CUZK.
>
>
> Jinak jeste je tu jeden nesouvisejici problem s importama adres z CUZK a
> KN. Vypada to, ze kdyz se druzstevni domy konvertovaly na SVJ, tak v KN
> je pro ne jen jeden adresni bod (s jednim c.p.), prestoze realne jde o
> vic c.p. . Tohle generuje znacnou cast nenalezenych adres z CUZK. Je otazka,
> zda by slo tohle nejak (polo)automaticky opravit.
>
> --
> Elen sila lumenn' omentielvo
>
> Ondrej 'SanTiago' Zajicek (email: santi...@crfreenet.org)
> OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
> "To err is human -- to blame it on a computer is ev

Re: [Talk-cz] OSM tracer fix

[Jan Bilak]

Ahoj,

máš nějakou konkrétní potřebu tam začlenit nějakou GPL knihovnu, pro
kterou není alternativa pod jinou vhodnou licencí?

Honza


Dne 16. září 2010 8:01 Pavel Machek  napsal(a):
> On Wed 2010-09-08 22:54:21, Jan Bilak wrote:
>> Ahoj,
>>
>> v licencích se moc neorientuji. Představoval bych si to tak, že
>> program lze bez omezení použít pro přípravu dat do projektu
>> OpenStreetMap. Program lze bez omezení šířit a měnit s tím, že bude
>> zachována a přiložena tato licence. Program ale nelze použít pro
>> přípravu dat, které by byly komerčně využity, aniž by před tímto
>> využitím byly uploadovány do projektu OpenStreetMap pod licencí,
>> kterou OSM vyžaduje.
>
> Prosim prosim, dejte tam proste GPL. Pak pujdou pridavat do traceru
> casti jinych (BSD, GPL) svobodnych programu, a pujde to hostovat ve
> streetmapi SVNce, kam to patri...
>                                                                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
> http://lists.openstreetmap.org/listinfo/talk-cz
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] tema bakalarky

[Jan Bilak]

Ahoj,

myslím, že by se těch témat našlo o dost více, ale jde spíše o to, co
by tě bavilo dělat (nemyslím konkrétně, to bys pak téma nehledala),
ale druh práce (hromadné zpracování dat, algoritmické úlohy,
desktopové aplikace, klientskou část webové aplikace, serverové
aplikace, propojování existujících služeb, teoreticky zaměřená práce,
...).

Honza


2010/9/20 Anna Kratochvílová :
> Díky za rychlou odpověď, ještě se na to podívám podrobněji a případně 
> prodiskutuji s vyučujícím. Kdybych se pro něco takového rozhodla, určitě se 
> ozvu.
>
> Anna Kratochvílová
>
>
>>  Původní zpráva 
>> Od: Radek Bartoň 
>> Předmět: Re: [Talk-cz] tema bakalarky
>> Datum: 20.9.2010 21:58:36
>> 
>> > Ahoj,
>>
>> Ahoj.
>>
>> > v současnosti hledám téma bakalářské práce (studuji Geoinformatiku na 
>> > ČVUTu),
>> > tak mne napadlo, jestli byste mi někdo nenavrhnul něco souvisejícího s 
>> > OSM. S
>> > OSM jsem se setkala jen okrajově, ale projekt mne zaujal. Přiznám se, že
>> nejsem
>> > žádný rozený programátor, ale programování se nevyhýbám, jen preferuji 
>> > Python.
>> S
>> > databázemi mám také nějaké zkušenosti. Pokuď vás napadne něco užitečného, 
>> > co
>> > bych byla schopná napsat (v rozsahu bakalářky), napište prosím.
>> > Díky
>> > Anna Kratochvílová
>>
>> Co se týče projektu OpenTrackMap, tak zde by se našlo spousta dílčích 
>> problémů k
>> implementaci:
>>
>>  * Výpočet výškového profilu cesty, podobně jako u
>> http://tchor.fi.muni.cz:8080/
>>  * Výpočet délky/času trasy.
>>  * Integrace s routovacími službami jako je http://openrouteservice.org/ nebo
>> implementace vlastní specializované pro účely pěší turistiky.
>>  * Integrace se službami poskytujícími georeferencované data jako je např.
>> Panoramio, Flickr, 360 Cities, OpenStretView, OpenStreetPhoto, GeoRSS, atp.
>>  * Nedávno zmiňovaná podpora uploadu georeferencovaných obrázků rozcestníků.
>>  * Uživatelsky editovatelné osobní mapy (podobně jako u Google Maps).
>>  * Samotné definování Mapnik stylu s turisticky zajímavými POI, který mám v
>> plánu, ale ještě jsem se k tomu nedostal.
>>  * atd, atd, vše by se ale asi implementovalo většinou v JavaScriptu.
>>
>> Dalším možným tématem by mohla  být služba (Python+PgSQL) zobrazující
>> přehledněji změny dat OpenStreetMap v daném bounding boxu, podobně jako 
>> záložka
>> "Historie" v na http://openstreetmap.org, ale místo dotazu typu:
>>
>>   Vyber všechny seznamy změn, v nichž je element v bounding boxu XY.
>>
>> by zobrazovala dotazy typu:
>>
>>   Vyber všechny změněné elementy v bounding boxu XY.
>>
>> Snad je můj popis daných problému alespoň částečně srozumitelný. Kdyby ne,
>> vysvětlím podrobněji.
>>
>> S pozdravem,
>>
>> Radek Bartoň.
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>>
>>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] OSM tracer fix

[Jan Bilak]

Ještě jsem našel assembla, která vypadá velmi dobře. 2 GB prostoru,
spoustu nástrojů, ... jediné omezení je to, že repository je veřejně
přístupné, což mi nevadí - naopak je plus.

Takže adresa:

https://assembla.com/code/osm-tracer/subversion/nodes


Pokud chcete přidat do seznamu členů projektu, stačí říct (login na
assemla nebo e-mail pro pozvánku) - není tam žádné omezení na počet
uživatelů.

Honza


2010/9/9 Jan Bilak :
> Tak codeplex.com patrně umožnuje jen některé licence. Ale ještě jsem
> našel xp-dev.com ... nabízí 200 MB pro dva privátní projekty nebo
> neomezeně veřejných, neomezený počet uživatelů, SVN. Akorát patrně se
> zálohování to není žádná sláva, ale to se u free dá celkem pochopit a
> stejně to bude mít několik lidí (včetně mne) u sebe. Když mi vyjde
> čas, večer to tam založím.
>
> Honza
>
>
> 2010/9/9 Jan Bilak :
>> Ještě mne napadnul codeplex.com ... který poskytuje dobré zázemí a pro
>> .NET projekty je jak dělaný. Licence jsem tam tuším viděl všelijaké,
>> ale třeba se pletu.
>>
>> Honza
>>
>>
>> Dne 9. září 2010 19:37 jan.bilak@gmail.com
>>  napsal(a):
>>> Ahoj,
>>>
>>> pokud to opravdu není žádný problém, tak by to bylo fajn. Jinak jsem našel
>>> třeba unfuddle.com. Akorát jsou tam jen dva účty, takže by se muselo řešit
>>> pod společným účtem. Ale to při předpokládané četnosti změn mi nepřijde jako
>>> příliš neomezující. Stejně je otázka, jak by účty vznikaly u tebe. Asi jen
>>> ručně - tedy další práce s tím, že?
>>>
>>> Honza
>>>
>>> - Reply message -
>>> Od: "Aleš Janda"
>>> Datum: čt, 9. 9, 2010 19:25
>>> Předmět: [Talk-cz] OSM tracer fix
>>> Komu: "OpenStreetMap Czech Republic"
>>>
>>> Ahoj,
>>>
>>>> 2) hodí se to někam jinam - má někdo nějaký server kde by mohl být svn
>>>> nebo jiný (git?) repozitář? Vzhledem k tomu, že nejde o svobodný
>>>> sotware, tak github, sourceforge a podobné využít nepůjdou.
>>>
>>> Zřídit SVN nebo GIT server není problém, můžu udělat u mě (tam co teď běží
>>> izometrická mapa apod.).
>>> Kdyžtak mi napište.
>>>
>>> Aleš Janda
>>>
>>>
>>>
>>> Dne 9.9.2010 01:50, MP napsal/a:
>>>> On 2010-09-08, Jan Bilak wrote:
>>>>> Hmmm, tak pokud je jediný problém to, že k tomu nemohu napsat, že je
>>>>> to svobodný software, tak to nevidím jako problém. Šlo mne o podporu
>>>>
>>>> U svobodných licencí je jen omezení co člověk může dělat se zdrojáky a
>>>> progamem ohledně distribuce, ne už ohledně používání programu. Stímhle
>>>> omezením už to technicky nepatří mezi svobodný software (což ale pro
>>>> účely použití v OSM vůbec nevadí :).
>>>>
>>>>> projektu OSM a ne o to, aby program např. používala nějaká firma pro
>>>>> přípravu map, které pak bude prodávat.
>>>>
>>>> Vzhledem k tomu, že výstup z traceru pořád potřebuje celkem dost ruční
>>>> práce, tak mi takovéhle použití přijde nepravděpodobné. K něčemu
>>>> takovému by to museli jednak dost vylepšit, jednak tam přidat další
>>>> části, jako třeba něco co určí kde začít trasovat. A pak by měli jen
>>>> budovy - myslím si, že ty snadněji získají odjinud.
>>>>
>>>> Tak s tímhle to asi nepůjde dát do SVN openstreetmap, nevím jestli tam
>>>> jdou cpát věci co nejsou svobodný software. Vidím to asi tak na 2
>>>> alternativy -
>>>> 1) zdrojáky, binárky a případná vylepšení budou kolovat mailinglistem
>>>> jako dosud.
>>>> 2) hodí se to někam jinam - má někdo nějaký server kde by mohl být svn
>>>> nebo jiný (git?) repozitář? Vzhledem k tomu, že nejde o svobodný
>>>> sotware, tak github, sourceforge a podobné využít nepůjdou.
>>>>
>>>> Martin
>>>>
>>>
>>>
>>> ___
>>> Talk-cz mailing list
>>> Talk-cz@openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>
>>
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] OSM tracer fix

[Jan Bilak]

Tak codeplex.com patrně umožnuje jen některé licence. Ale ještě jsem
našel xp-dev.com ... nabízí 200 MB pro dva privátní projekty nebo
neomezeně veřejných, neomezený počet uživatelů, SVN. Akorát patrně se
zálohování to není žádná sláva, ale to se u free dá celkem pochopit a
stejně to bude mít několik lidí (včetně mne) u sebe. Když mi vyjde
čas, večer to tam založím.

Honza


2010/9/9 Jan Bilak :
> Ještě mne napadnul codeplex.com ... který poskytuje dobré zázemí a pro
> .NET projekty je jak dělaný. Licence jsem tam tuším viděl všelijaké,
> ale třeba se pletu.
>
> Honza
>
>
> Dne 9. září 2010 19:37 jan.bilak@gmail.com
>  napsal(a):
>> Ahoj,
>>
>> pokud to opravdu není žádný problém, tak by to bylo fajn. Jinak jsem našel
>> třeba unfuddle.com. Akorát jsou tam jen dva účty, takže by se muselo řešit
>> pod společným účtem. Ale to při předpokládané četnosti změn mi nepřijde jako
>> příliš neomezující. Stejně je otázka, jak by účty vznikaly u tebe. Asi jen
>> ručně - tedy další práce s tím, že?
>>
>> Honza
>>
>> - Reply message -
>> Od: "Aleš Janda"
>> Datum: čt, 9. 9, 2010 19:25
>> Předmět: [Talk-cz] OSM tracer fix
>> Komu: "OpenStreetMap Czech Republic"
>>
>> Ahoj,
>>
>>> 2) hodí se to někam jinam - má někdo nějaký server kde by mohl být svn
>>> nebo jiný (git?) repozitář? Vzhledem k tomu, že nejde o svobodný
>>> sotware, tak github, sourceforge a podobné využít nepůjdou.
>>
>> Zřídit SVN nebo GIT server není problém, můžu udělat u mě (tam co teď běží
>> izometrická mapa apod.).
>> Kdyžtak mi napište.
>>
>> Aleš Janda
>>
>>
>>
>> Dne 9.9.2010 01:50, MP napsal/a:
>>> On 2010-09-08, Jan Bilak wrote:
>>>> Hmmm, tak pokud je jediný problém to, že k tomu nemohu napsat, že je
>>>> to svobodný software, tak to nevidím jako problém. Šlo mne o podporu
>>>
>>> U svobodných licencí je jen omezení co člověk může dělat se zdrojáky a
>>> progamem ohledně distribuce, ne už ohledně používání programu. Stímhle
>>> omezením už to technicky nepatří mezi svobodný software (což ale pro
>>> účely použití v OSM vůbec nevadí :).
>>>
>>>> projektu OSM a ne o to, aby program např. používala nějaká firma pro
>>>> přípravu map, které pak bude prodávat.
>>>
>>> Vzhledem k tomu, že výstup z traceru pořád potřebuje celkem dost ruční
>>> práce, tak mi takovéhle použití přijde nepravděpodobné. K něčemu
>>> takovému by to museli jednak dost vylepšit, jednak tam přidat další
>>> části, jako třeba něco co určí kde začít trasovat. A pak by měli jen
>>> budovy - myslím si, že ty snadněji získají odjinud.
>>>
>>> Tak s tímhle to asi nepůjde dát do SVN openstreetmap, nevím jestli tam
>>> jdou cpát věci co nejsou svobodný software. Vidím to asi tak na 2
>>> alternativy -
>>> 1) zdrojáky, binárky a případná vylepšení budou kolovat mailinglistem
>>> jako dosud.
>>> 2) hodí se to někam jinam - má někdo nějaký server kde by mohl být svn
>>> nebo jiný (git?) repozitář? Vzhledem k tomu, že nejde o svobodný
>>> sotware, tak github, sourceforge a podobné využít nepůjdou.
>>>
>>> Martin
>>>
>>
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] OSM tracer fix

[Jan Bilak]

Ještě mne napadnul codeplex.com ... který poskytuje dobré zázemí a pro
.NET projekty je jak dělaný. Licence jsem tam tuším viděl všelijaké,
ale třeba se pletu.

Honza


Dne 9. září 2010 19:37 jan.bilak@gmail.com
 napsal(a):
> Ahoj,
>
> pokud to opravdu není žádný problém, tak by to bylo fajn. Jinak jsem našel
> třeba unfuddle.com. Akorát jsou tam jen dva účty, takže by se muselo řešit
> pod společným účtem. Ale to při předpokládané četnosti změn mi nepřijde jako
> příliš neomezující. Stejně je otázka, jak by účty vznikaly u tebe. Asi jen
> ručně - tedy další práce s tím, že?
>
> Honza
>
> - Reply message -
> Od: "Aleš Janda"
> Datum: čt, 9. 9, 2010 19:25
> Předmět: [Talk-cz] OSM tracer fix
> Komu: "OpenStreetMap Czech Republic"
>
> Ahoj,
>
>> 2) hodí se to někam jinam - má někdo nějaký server kde by mohl být svn
>> nebo jiný (git?) repozitář? Vzhledem k tomu, že nejde o svobodný
>> sotware, tak github, sourceforge a podobné využít nepůjdou.
>
> Zřídit SVN nebo GIT server není problém, můžu udělat u mě (tam co teď běží
> izometrická mapa apod.).
> Kdyžtak mi napište.
>
> Aleš Janda
>
>
>
> Dne 9.9.2010 01:50, MP napsal/a:
>> On 2010-09-08, Jan Bilak wrote:
>>> Hmmm, tak pokud je jediný problém to, že k tomu nemohu napsat, že je
>>> to svobodný software, tak to nevidím jako problém. Šlo mne o podporu
>>
>> U svobodných licencí je jen omezení co člověk může dělat se zdrojáky a
>> progamem ohledně distribuce, ne už ohledně používání programu. Stímhle
>> omezením už to technicky nepatří mezi svobodný software (což ale pro
>> účely použití v OSM vůbec nevadí :).
>>
>>> projektu OSM a ne o to, aby program např. používala nějaká firma pro
>>> přípravu map, které pak bude prodávat.
>>
>> Vzhledem k tomu, že výstup z traceru pořád potřebuje celkem dost ruční
>> práce, tak mi takovéhle použití přijde nepravděpodobné. K něčemu
>> takovému by to museli jednak dost vylepšit, jednak tam přidat další
>> části, jako třeba něco co určí kde začít trasovat. A pak by měli jen
>> budovy - myslím si, že ty snadněji získají odjinud.
>>
>> Tak s tímhle to asi nepůjde dát do SVN openstreetmap, nevím jestli tam
>> jdou cpát věci co nejsou svobodný software. Vidím to asi tak na 2
>> alternativy -
>> 1) zdrojáky, binárky a případná vylepšení budou kolovat mailinglistem
>> jako dosud.
>> 2) hodí se to někam jinam - má někdo nějaký server kde by mohl být svn
>> nebo jiný (git?) repozitář? Vzhledem k tomu, že nejde o svobodný
>> sotware, tak github, sourceforge a podobné využít nepůjdou.
>>
>> Martin
>>
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] OSM tracer fix

[Jan Bilak]

Hmmm, tak pokud je jediný problém to, že k tomu nemohu napsat, že je
to svobodný software, tak to nevidím jako problém. Šlo mne o podporu
projektu OSM a ne o to, aby program např. používala nějaká firma pro
přípravu map, které pak bude prodávat.

Honza


Dne 8. září 2010 23:09 Aleš Janda  napsal(a):
> Ahoj,
>
> tak přesně takovouhle licenci jsem chtěl taky pro svůj program, jenže pak se
> stává nesvobodným, viz
> http://www.abclinuxu.cz/poradna/programovani/show/297980
>
> Nakonec jsem to vyřešil GPLv3.
>
> Aleš Janda
>
>
> Dne 8.9.2010 22:54, Jan Bilak napsal/a:
>>
>> Ahoj,
>>
>> v licencích se moc neorientuji. Představoval bych si to tak, že
>> program lze bez omezení použít pro přípravu dat do projektu
>> OpenStreetMap. Program lze bez omezení šířit a měnit s tím, že bude
>> zachována a přiložena tato licence. Program ale nelze použít pro
>> přípravu dat, které by byly komerčně využity, aniž by před tímto
>> využitím byly uploadovány do projektu OpenStreetMap pod licencí,
>> kterou OSM vyžaduje.
>>
>> Aneb když připravíš data pro OSM, tak neaplikuj žádná omezení a klidně
>> data použij i komerčně. Pokud program použiješ, ale o výsledná data se
>> nepodělíš vprojektu OSM, tak data nesmíš komerčně použít (tím se
>> vyřeší to, že třeba data z nějakého důvodu zahodíš nebo předáš někomu
>> jinému pro dopracování, než se uploadnou do OSM).
>>
>> Pokud v tom vidíte nějaký problém, řekněte. Třeba je to blbost.
>>
>> Honza
>>
>>
>> Dne 8. září 2010 22:33 MP  napsal(a):
>>>
>>> On 2010-09-07, Jan Bilak  wrote:
>>>>
>>>> Ahoj,
>>>>
>>>>  díky za úpravy. Na SVNko OSM to samozřejmě klidně dejte - bude to
>>>>  nejlepší. Jen pak prosím sem do maillistu napište na to odkaz, kde se
>>>>  to dá najít.
>>>
>>> No tak momentálně zdrojáky neobsahují žádnou licenci, takže pro
>>> publikování někde v SVNku OSM by chtělo minimálně vymyslet pod jakou
>>> licencí to tam dát (GPL2? GPL3? BSD? Jiná? )  no a potom by se
>>> to už asi mohlo nechat aby se to nějak vyvíjelo - zatím jsem pro to
>>> napsal jeden patch, kde je možné specifikovat adresář pro cache, aby
>>> to neplnilo adresář s binárkou cachovanými daty, takže ten bych tam
>>> pak mohl přidat :)
>>>
>>> Mohl bych to tam pak hodit (musel bych k tomu dopsat min. nějakékrátké
>>>  readme a info o autorivi, licenci, k čemu ten program je a tak
>>> ...)... asi bych to tam dal do
>>> http://svn.openstreetmap.org/applications/utils/ a tam bych vytvořil
>>> adresář tracer-server
>>>
>>> Martin
>>>>
>>>>  Honza
>>>>
>>>>
>>>>  2010/9/7 hanoj:
>>>>
>>>>>> binarka
>>>>
>>>>  >>
>>>>  >>  http://openstreetmap.cz/tracer/tracer7patched.tar.gz
>>>>  >  *** supr funguje to, na CZ:wiki pluginu jsem pridal odkaz.
>>>>  >
>>>>  >  diky
>>>>  >  hanoj
>>>>  >
>>>>  >  ___
>>>>  >  Talk-cz mailing list
>>>>  >  talk...@openstreetmap.org
>>>>  >  http://lists.openstreetmap.org/listinfo/talk-cz
>>>>  >
>>>>
>>>>  ___
>>>>  Talk-cz mailing list
>>>>  talk...@openstreetmap.org
>>>>  http://lists.openstreetmap.org/listinfo/talk-cz
>>>>
>>>
>>> ___
>>> Talk-cz mailing list
>>> Talk-cz@openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] OSM tracer fix

[Jan Bilak]

Ahoj,

v licencích se moc neorientuji. Představoval bych si to tak, že
program lze bez omezení použít pro přípravu dat do projektu
OpenStreetMap. Program lze bez omezení šířit a měnit s tím, že bude
zachována a přiložena tato licence. Program ale nelze použít pro
přípravu dat, které by byly komerčně využity, aniž by před tímto
využitím byly uploadovány do projektu OpenStreetMap pod licencí,
kterou OSM vyžaduje.

Aneb když připravíš data pro OSM, tak neaplikuj žádná omezení a klidně
data použij i komerčně. Pokud program použiješ, ale o výsledná data se
nepodělíš vprojektu OSM, tak data nesmíš komerčně použít (tím se
vyřeší to, že třeba data z nějakého důvodu zahodíš nebo předáš někomu
jinému pro dopracování, než se uploadnou do OSM).

Pokud v tom vidíte nějaký problém, řekněte. Třeba je to blbost.

Honza


Dne 8. září 2010 22:33 MP  napsal(a):
> On 2010-09-07, Jan Bilak  wrote:
>> Ahoj,
>>
>>  díky za úpravy. Na SVNko OSM to samozřejmě klidně dejte - bude to
>>  nejlepší. Jen pak prosím sem do maillistu napište na to odkaz, kde se
>>  to dá najít.
>
> No tak momentálně zdrojáky neobsahují žádnou licenci, takže pro
> publikování někde v SVNku OSM by chtělo minimálně vymyslet pod jakou
> licencí to tam dát (GPL2? GPL3? BSD? Jiná? )  no a potom by se
> to už asi mohlo nechat aby se to nějak vyvíjelo - zatím jsem pro to
> napsal jeden patch, kde je možné specifikovat adresář pro cache, aby
> to neplnilo adresář s binárkou cachovanými daty, takže ten bych tam
> pak mohl přidat :)
>
> Mohl bych to tam pak hodit (musel bych k tomu dopsat min. nějakékrátké
>  readme a info o autorivi, licenci, k čemu ten program je a tak
> ...)... asi bych to tam dal do
> http://svn.openstreetmap.org/applications/utils/ a tam bych vytvořil
> adresář tracer-server
>
> Martin
>>
>>  Honza
>>
>>
>>  2010/9/7 hanoj :
>>
>> >> binarka
>>  >>
>>  >> http://openstreetmap.cz/tracer/tracer7patched.tar.gz
>>  > *** supr funguje to, na CZ:wiki pluginu jsem pridal odkaz.
>>  >
>>  > diky
>>  > hanoj
>>  >
>>  > ___
>>  > Talk-cz mailing list
>>  > Talk-cz@openstreetmap.org
>>  > http://lists.openstreetmap.org/listinfo/talk-cz
>>  >
>>
>>  ___
>>  Talk-cz mailing list
>>  talk...@openstreetmap.org
>>  http://lists.openstreetmap.org/listinfo/talk-cz
>>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Import adres okresu Benešov

[Jan Bilak]

Ahoj. Stiskni START. Zvol položku Spustit a napiš:
cmd.exe
a stiskni ENTER

napiš
CD "C:\Users\Zdeněk Pražák\osmosis"
(vcetne uvozozovek) a stiskni ENTER. Nyní se ti zobrazí:
C:\Users\Zdeněk Pražák\osmosis>

napiš
osmosis.bat
a stiskni ENTER.

Ale co to bude dělat, to nevím. Osmosis jsem nikdy nepoužil.

Honza


2010/9/7 Zdeněk Pražák :
> asi jsem nějak natvrdlý ale nejsde mi to.
> osmosis jsem rozbalil do adresáře c:\Users\Zdeněk Pražák\osmosis
>
> Spustím cmd.exe
> nastavím adresář c:\Users\Zdeněk Pražák\osmosis a napíši
> c:\Users\Zdeněk Pražák\osmosis\osmosis.bat a napíše mi že osmosis.bat není 
> názvem vnitřního ani vnějšího příkazu, spustitelného programu nebo dávkového 
> souboru
>
> totéž mi píše i když nastavím adresář c:\Users\Zdeněk 
> Pražák\osmosis\bin\osmosis.bat
>>  Původní zpráva 
>> Od: Michal Grézl 
>> Předmět: Re: [Talk-cz] Import adres okresu Benešov
>> Datum: 07.9.2010 20:35:04
>> 
>> 2010/9/7 Zdeněk Pražák :
>> > no ale jak ho mám spustit,
>> > když na něj poklepu, otevře se okno a hned zase zmizí a ani si nemohu
>> > přečíst co je v něm napsáno,
>> >
>> cudl start pak spustit
>> napsat cmd.exe odentrovat
>> napsat cd adresar_ve_kerem_je_osmosis.bat
>> osmosis.bat
>>
>> nebo pokud se to musi pustit s tim bin tak cd adrresar_kde_je_bin a
>> pak bin\osmosis.bat
>>
>> jinak receno pustit ho v prikazovem radku
>>
>>
>> --
>> Michal Grézl
>> http://openstreetmap.cz
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>>
>>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] OSM tracer fix

[Jan Bilak]

Ahoj,

díky za úpravy. Na SVNko OSM to samozřejmě klidně dejte - bude to
nejlepší. Jen pak prosím sem do maillistu napište na to odkaz, kde se
to dá najít.

Honza


2010/9/7 hanoj :
>> binarka
>>
>> http://openstreetmap.cz/tracer/tracer7patched.tar.gz
> *** supr funguje to, na CZ:wiki pluginu jsem pridal odkaz.
>
> diky
> hanoj
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] OSM tracer fix

[Jan Bilak]

Ahoj,

z důvodu nedostatku času jsem se k tomu pořádně nedostal. Tady jsou
zdrojáky, kde jsem to nahrubo připravil, ale netestoval jsem to a ani
nezjišťoval, jaká je vlastně nová adresu wms serveru či co jiného se
změnilo. Doufám, že se najde někdo, kdo to dotáhne. Kdyby tam něco
chybělo, dejte vědět ... snad jsem nevzal nějakou starou verzi ...
dělal jsem to dost na rychlo.

http://jabi.aspone.cz/osm/TraceServerBeta7-src.zip

Honza


2010/9/6 Zdeněk Pražák :
> Dne 2. 9. 2010 Jan Bilak napsal:
>
> Ahoj,
>
> urcite ... jen, co se k tomu dostanu (asi pred vikend).
>
> Honza
>
>
> Dne 1. září 2010 10:54 hanoj  napsal(a):
>>
>> Ahoj Honzo,
>> dnes doslo ke zmene nastaveni KM na WMS CUZK.
>> Bylo by mozno upravit tracer na novy stav pripadne rovnou nechat
>> moznost si nastavit zdrojovy server v konfiguraku?
>>
>> diky
>> hanoj
>>
>
> Mohu se zeptat, jaký je stav aktualizace traceru
> Děkuji, Pražák
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] OSM tracer fix

[Jan Bilak]

Ahoj,

urcite ... jen, co se k tomu dostanu (asi pred vikend).

Honza


Dne 1. září 2010 10:54 hanoj  napsal(a):
> Ahoj Honzo,
> dnes doslo ke zmene nastaveni KM na WMS CUZK.
> Bylo by mozno upravit tracer na novy stav pripadne rovnou nechat
> moznost si nastavit zdrojovy server v konfiguraku?
>
> diky
> hanoj
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] nefunkční tracer

[Jan Bilak]

Zdravím,

zkoušel jsem tracer se starým JOSM 2561 na jedné oblasti a trasoval v
pohodě - stahované mapy vypadaly obdobně jako dříve. Za jakých
podmínek to nefunguje? Záleží na oblasti nebo na něčem jiném?

Honza


2010/7/14 hanoj :
>>> IMHO Tracer ma WMS nastaveno URL natvrdo. Problem na prvni pohled je
>>> ze, mapa KN je jineho charakteru, nema spojite linie, resp. je ma
>>> tensi a jsou mezi nimi obcas diry.
>> tady bych si dovolil to trochu bránit :-) DKM momentálně vzniká z 
>> vektorových dat, takže by tam díry být neměly. Pokud ano, prosím o ukázku. 
>> Možná mohou být problémy s hranicemi parcel pro měřítko nad 1:3000 nebo s 
>> vnitřní kresbou - tam je použita 1 px linie a ta v obecném směru nemůže být 
>> spojitá.
> *** viz
> http://osm.templ.net/wms-josm.png
>  podle HTTP req:
> http://wms.cuzk.cz/wms.asp?service=WMS&VERSION=1.Zdravím,1.1&REQUEST=GetMap&SRS=EPSG:4326&LAYERS=kn-i,prehledky,def_budovy&FORMAT=image/png&transparent=TRUE&;
>
>>> Primlouval bych se za snizeni barevne hloubky smerem k puvodnim 4
>>> bitum. Mozna je JOSM spatne napsan pro operaci s tak barevnymi rastry,
>>> ale pro cernobilou mapu nejsou prave barvy(true color) potreba.
>> Já u výstupu z WMS vidím barevnou hloubku 8-bit. 32-bit hloubka byla před 
>> časem (doufám :-) opravena
> *** Ano, neco jsem prehledl, na wms-new.asp je 32, ale na wms.asp je 8.
>
>>> PS: jeste by se mi libilo mit v KM vrstvu, ktera by mi rikala jaka
>>> data vidim (DKM, KM-D, SK...), jak jsou stara vuci ISKN a jaka je
>>> obecna kvalita geodat.
>> I v současné době jsou poskytovány jednotlivé vrstvy podle původu dat (DKM, 
>> analog, KM-D, PK, geometráky). To ostatní je spíž záležitostí metadat.
> *** Vypinat a zapinat si vrstvy a zjistovat ktera ze se mi to natahuje
> je ponekud neprakticke.
> *** Pocet uzivatelu, kteri jsou schopni a maji odbornou erudici
> zkoumat metadata z ISKN se limitne blizi nule, resp poctu geodetu,
> kteri tusi, co tam zadavaji.
> Presto informacni vrstva obsahujici text: tady je platna mapa typu SK,
> tady delame digitalizaci a bude hotova za rok, tady je empiricka
> presnost radech 1 dm, tady se porad dokresluje na folie... ma svuj
> vyznam.
>
>> Obecně teď u nového způsobu aktualizace vektorů platí, že publikovaná data 
>> mají maximálně jednodenní zpoždění za stavem katastru (běžně spíš v řádu 
>> hodin).
> *** Rastry jsou v KM take a dlouho jeste budou.
>
> zdravi
> hanoj
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Bug v Traceru

[Jan Bilak]

Ahoj, můžeš zkusit:
http://jabi.aspone.cz/osm/TraceServerBeta6.zip
(mělo by stačit vyměnit jen exe soubor)

Honza


Dne 6. dubna 2010 23:50 Petr Schönmann  napsal(a):
> Zdravím, chtěl jsem po nějakém čase zase přispět trochou do OSM, ovšem hodně
> na mě vyskakuje tato hláška, která zanepříčiňuje trasování budovy
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Izometrická 3D mapa z OSM

[Jan Bilak]

Ahoj ... to je celkem vážný problém. Nejsem odborníkem na stavebnictví
a tak mi názvy moc neříkají, ale je pravda, že "seříznutí" ze všech
stran bez štítů není moc časté. Otázka je, zda jde sedlová střecha
obecně zkonstruovatelná nad libovolným polygonem. Řekl bych, že ne
(třeba nad trojúhelníkem nebo cca pravidelným pětiúhelníkem), ale
těžko to tvrdit, když vlastně nevím, jak definována sedlová střecha.
Ve wikipedii jsem našel "definici" víceméně příklady..

Jedna možnost je taková, že by se udělala kontrukce valbové střechy a
pak se nějakou heuristikou vynechávalo "seříznutí" na některých
stranách, kde tvoří v půdorysu trojúhelník. U nějakých hodně složitých
střech se asi sedlová moc nepoužívá.

Problém bude v tom, že u cca čtvercových staveb nebudeme znát
orientaci střechy - tedy kde má střecha štíty a kde je seříznutá.

Honza


2010/3/30 hanoj :
>> kdybys narazil na nějaký problém, tak dej vědět :)
> *** ten algoritmus je na valbove strechy (v kategorii sikmych strech).
>
> Ty jsou u nas z tradice v naprostem minimu. Nejcasteji se uplatnuji u
> sikmych strech strechy sedlove, pultove, stanove, mansardove,
> polovalbove...
>
> hanoj
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Izometrická 3D mapa z OSM

[Jan Bilak]

Ahoj,

kdybys narazil na nějaký problém, tak dej vědět :)

Honza


Dne 29. března 2010 22:56 Aleš Janda  napsal(a):
> Ahoj,
>
> to je skvělé, díky za ty odkazy! Snad se mi pomocí toho podaří ty střechy 
> udělat
> - to by byla paráda :-)
>
> Aleš Janda
>
>
> On 29.3.2010 00:56, Jan Bilak napsal/a:
>> A tady je ještě Java applet, který to názorně a interaktivně ukazuje:
>> http://www.sable.mcgill.ca/~dbelan2/roofs/roofs.html
>>
>> Honza
>>
>> 2010/3/28 Jan Bilak:
>>> Ahoj,
>>> dostal jsem typ na reseni renderovani strech...
>>>
>>> Knihovna:
>>> http://www.cgal.org/Manual/3.2/doc_html/cgal_manual/Straight_skeleton_2/Chapter_main.html
>>>
>>> Popis algoritmu:
>>> http://web.natur.cuni.cz/~bayertom/Adk/adk7.pdf
>>>
>>> Honza
>>>
>>>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Izometrická 3D mapa z OSM

[Jan Bilak]

A tady je ještě Java applet, který to názorně a interaktivně ukazuje:
http://www.sable.mcgill.ca/~dbelan2/roofs/roofs.html

Honza

2010/3/28 Jan Bilak :
> Ahoj,
> dostal jsem typ na reseni renderovani strech...
>
> Knihovna:
> http://www.cgal.org/Manual/3.2/doc_html/cgal_manual/Straight_skeleton_2/Chapter_main.html
>
> Popis algoritmu:
> http://web.natur.cuni.cz/~bayertom/Adk/adk7.pdf
>
> Honza
>
>
> 2010/3/28 hanoj :
>>> Podle pravidel fotbalu má hřiště nějakou danou velikost -
>>> http://en.wikipedia.org/wiki/Association_football_pitch, takže pokud
>>> je to příliš velké, tak je možné, že někdo otagoval pomocí
>>> sport=soccer i okolní tribuny, zázemí a tak  (a pokud moc malé,
>>> tak jde nejspíš o trénínkové hřiště pro dorost nebo tak něco :)
>> *** tak zrovna rozmer fotbalového hriste je hodne plovouci, (chapu ze
>> UEFA to ma fix), ale UEFA hrist je asi par v republice. Navic existuji
>> okolni odstupove zony, na ktere se podle souteze az tak nedba.
>>
>>>> A také je škoda, že při importu z UHUL se nezachovala informace o druhu
>>> lesa.
>>>
>>> Možná by to šlo nějak doplnit - brát existující polygony z UHULu jeden
>>> po druhém, zjišťovat typ lesa (coniferous/deciduous, případně mixed -
>>> a u těch mixed pak případně zvážit, jestli by se ten les nedal
>>> rozetnout na listnaté a jehličnaté části), na polygon se plácne
>>> patřičný tag a jede se dál :)
>> *** to sice asi ano, ale problem je doslo ke slouceni prostorovych a
>> druhovych(habrina, dubohabrina, smrcina, ...) polygonu jen do
>> prostorovych polygonu.
>>
>> ha
>> hanoj
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Izometrická 3D mapa z OSM

[Jan Bilak]

Ahoj,
dostal jsem typ na reseni renderovani strech...

Knihovna:
http://www.cgal.org/Manual/3.2/doc_html/cgal_manual/Straight_skeleton_2/Chapter_main.html

Popis algoritmu:
http://web.natur.cuni.cz/~bayertom/Adk/adk7.pdf

Honza


2010/3/28 hanoj :
>> Podle pravidel fotbalu má hřiště nějakou danou velikost -
>> http://en.wikipedia.org/wiki/Association_football_pitch, takže pokud
>> je to příliš velké, tak je možné, že někdo otagoval pomocí
>> sport=soccer i okolní tribuny, zázemí a tak  (a pokud moc malé,
>> tak jde nejspíš o trénínkové hřiště pro dorost nebo tak něco :)
> *** tak zrovna rozmer fotbalového hriste je hodne plovouci, (chapu ze
> UEFA to ma fix), ale UEFA hrist je asi par v republice. Navic existuji
> okolni odstupove zony, na ktere se podle souteze az tak nedba.
>
>>> A také je škoda, že při importu z UHUL se nezachovala informace o druhu
>> lesa.
>>
>> Možná by to šlo nějak doplnit - brát existující polygony z UHULu jeden
>> po druhém, zjišťovat typ lesa (coniferous/deciduous, případně mixed -
>> a u těch mixed pak případně zvážit, jestli by se ten les nedal
>> rozetnout na listnaté a jehličnaté části), na polygon se plácne
>> patřičný tag a jede se dál :)
> *** to sice asi ano, ale problem je doslo ke slouceni prostorovych a
> druhovych(habrina, dubohabrina, smrcina, ...) polygonu jen do
> prostorovych polygonu.
>
> ha
> hanoj
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Tracer - nastavení

[Jan Bilak]

Ahoj.

SmallHoleRemover je spíše ukázkový filtr, než filtr, který by to
opravdu dobře řešil. V rámci úpravy traceserveru tak, aby byl
konfigovatelný, jsem se rozhodl vytvořit dva typy filtrů. Jeden typ
umí pozměnit černobílou bitmapu (a tedy např. lze pomocí takového typu
filtru zacelovat díry). Druhý typ filtru pak slouží k redukci
(případně i přidání) bodů na obrysu trasovaného domu.

Filtrů druhého typu existuje v programu několik a tvoří to podstatnou
část traceserveru. Na vstupu je množina bodů tvořící vnější obrys
oblasti vyplnění floodfillem.   Pak tato množina projde sadou filtrů a
výsledek posledního filtru je už vlastně konečný výsledek (jen se
přepočtou souřadnice apod.). Přitom typy filtrů, jejich pořadí a
nastavení je výsledek nějakých pokusů zejména na jednom typy mapového
podkladu. Věřím, že lze zde dosáhnout i lepších výsledků - zejména v
jiných oblastech mapy, než kde jsem to zkoušel.

Filtr prvního typu ale žádný neexistoval a SmallHoleRemover je vlastně
takový ukázkový filtr (zacelí opravdu jen malé díry a tak jeho
praktický použití je dosti omezené, ale zase to názorná ukázka, jak
takový filtr vytvořit).

Konfigurací pak lze ovlivnit, které filtry se použijí, v jakém pořadí
a s jakým nastavením filtru (pokud filtr nějaké nastavení podporuje).

Nyní si tedy každý (.NET programátor) může vytvářet vlastní filtry a
konfiguraci podle oblasti, kterou trasuje nebo osobních preferencí.

Shrnuto: Tato verze si nekladla za cíl lepší rozpoznávání nebo opravu
nějakých chyb. Cílem bylo zavedení konfigurovatelnosti, kterou ocení
třeba někteří vývojáři nebo pokročilejší uživatelé.

Honza


2010/3/1 Petr Dlouhý :
> Ahoj,
>
> tím funguje lépe jsem myslel v jiných směrech - například často správně
> ignoruje nesouvisející čáry zasahující do trasovaného objektu.
>
> Myslel jsem, že SmallHoleRemover má problém tenkých čar řešit.
>
> Mimochodem: v Traceru jsou stále některé otravné chyby z dřívějška - občas
> trasovaná oblast vůbec neobsahuje bod, na který jsem kliknul; někdy
> "vystřelují" body z objektu daleko za jeho hranici; občas hlásí
> "IndexOutOfRangeException".
>
> On Mon, 01 Mar 2010 18:13:33 +0100, Jan Bilak 
> wrote:
>
>> Ahoj,
>>
>> to se divím, že funguje o dost lépe, protože tam prakticky žádné změny
>> v tomto směru nejsou. Změny se týkají možnosti nastavení a pluginů
>> (filtrů). Pravda je, že jeden ukázkový primitivní filtr
>> SmallHoleRemover, jehož zdroják jsem zde posílal, zaceluje malé díry a
>> tak může někde přinést lepší výsledky (někde zase horší, pokud jsou
>> čáry už tak dost tlusté).
>>
>> Ten plugin nemá žádné nastavení. Když se koukneš do toho zdrojáku (je
>> velmi krátký a zřejmý), tak zjistíš, že natvrdo obarvuje bílé body,
>> které na jedné ze 4 základních stran sousedí s černým pixelem. Stačí
>> tuto podmínku upravit nebo filtr udělat konfigurovatelný... a může se
>> to chovat jinak. Nebo prostě udělat jiný filtr ... tvorba filtru je
>> jednoduchá věc, stačí referencovat jednu Class Library a implementovat
>> jednoduché rozlišení. Výsledné DLL dát do adresáře plugins a přidat
>> filtr v konfiguráku na vhodné místo
>>
>> Případně "hrubou silou" lze v konfiguráku aplikovat stejný filtr třeba
>> 2x za sebou. Tím se také zacelí trochu větší díry (ale není to moc
>> pěkné řešení).
>>
>>   
>>     
>>     
>>   
>>
>> Honza
>>
>>
>> 2010/3/1 Petr Dlouhý :
>>> Ahoj,
>>>
>>> zkoušel jsem tu novou verzi, která opravdu funguje zase o dost lépe.
>>> Zdá se ale, že to na tenkých čarách stále moc nefunguje - většinou to
>>> stejně projde nějakou mezerou.
>>> Dá se někde nastavit, jak velkou mezeru to zacelí?
>>>
>>> On Mon, 01 Mar 2010 13:32:21 +0100, Jan Bilak 
>>> wrote:
>>>
>>>> Zdroják SmallHoleRemover filtru vypadá takto:
>>>>
>>>> using System;
>>>> using System.Collections.Generic;
>>>> using System.Linq;
>>>> using System.Text;
>>>> using Osm.Kn.Trace.Server.Trace.Interfaces;
>>>>
>>>> namespace SmallHoleRemover
>>>> {
>>>>     [BitmapFilter("SmallHoleRemover")]
>>>>     public class SmallHoleRemover : IBitmapFilter
>>>>     {
>>>>         const byte BACKGROUND = 0;
>>>>         const byte PEN = 1;
>>>>         const byte TEMP = 2;
>>>>
>>>>         #region IBitmapFilter Members
>>>>
>>>>         public byte[][] Filter(byte[][] bitmap)
>>>>         {
>>>>             int h = bitmap.Length;
>>>>             int w

Re: [Talk-cz] Tracer - nastavení

[Jan Bilak]

Ahoj,

to se divím, že funguje o dost lépe, protože tam prakticky žádné změny
v tomto směru nejsou. Změny se týkají možnosti nastavení a pluginů
(filtrů). Pravda je, že jeden ukázkový primitivní filtr
SmallHoleRemover, jehož zdroják jsem zde posílal, zaceluje malé díry a
tak může někde přinést lepší výsledky (někde zase horší, pokud jsou
čáry už tak dost tlusté).

Ten plugin nemá žádné nastavení. Když se koukneš do toho zdrojáku (je
velmi krátký a zřejmý), tak zjistíš, že natvrdo obarvuje bílé body,
které na jedné ze 4 základních stran sousedí s černým pixelem. Stačí
tuto podmínku upravit nebo filtr udělat konfigurovatelný... a může se
to chovat jinak. Nebo prostě udělat jiný filtr ... tvorba filtru je
jednoduchá věc, stačí referencovat jednu Class Library a implementovat
jednoduché rozlišení. Výsledné DLL dát do adresáře plugins a přidat
filtr v konfiguráku na vhodné místo

Případně "hrubou silou" lze v konfiguráku aplikovat stejný filtr třeba
2x za sebou. Tím se také zacelí trochu větší díry (ale není to moc
pěkné řešení).

  


  

Honza


2010/3/1 Petr Dlouhý :
> Ahoj,
>
> zkoušel jsem tu novou verzi, která opravdu funguje zase o dost lépe.
> Zdá se ale, že to na tenkých čarách stále moc nefunguje - většinou to
> stejně projde nějakou mezerou.
> Dá se někde nastavit, jak velkou mezeru to zacelí?
>
> On Mon, 01 Mar 2010 13:32:21 +0100, Jan Bilak 
> wrote:
>
>> Zdroják SmallHoleRemover filtru vypadá takto:
>>
>> using System;
>> using System.Collections.Generic;
>> using System.Linq;
>> using System.Text;
>> using Osm.Kn.Trace.Server.Trace.Interfaces;
>>
>> namespace SmallHoleRemover
>> {
>>     [BitmapFilter("SmallHoleRemover")]
>>     public class SmallHoleRemover : IBitmapFilter
>>     {
>>         const byte BACKGROUND = 0;
>>         const byte PEN = 1;
>>         const byte TEMP = 2;
>>
>>         #region IBitmapFilter Members
>>
>>         public byte[][] Filter(byte[][] bitmap)
>>         {
>>             int h = bitmap.Length;
>>             int w = bitmap[0].Length;
>>
>>             for (int y = 1; y < h - 1; y++)
>>             {
>>                 for (int x = 1; x < w - 1; x++)
>>                 {
>>                     if ((bitmap[y][x] == PEN) &&
>>                         (bitmap[y][x - 1] != BACKGROUND || bitmap[y][x
>> + 1] != BACKGROUND ||
>>                         bitmap[y - 1][x] != BACKGROUND || bitmap[y +
>> 1][x] != BACKGROUND))
>>                         bitmap[y][x] = TEMP;
>>                 }
>>             }
>>             for (int y = 1; y < h - 1; y++)
>>             {
>>                 for (int x = 1; x < w - 1; x++)
>>                 {
>>                     if (bitmap[y][x] == TEMP)
>>                         bitmap[y][x] = PEN;
>>                 }
>>             }
>>
>>             return bitmap;
>>         }
>>
>>         #endregion
>>
>>         #region IConfigurable Members
>>
>>         public void Init(IDictionary confValues)
>>         {
>>         }
>>
>>         #endregion
>>     }
>> }
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>
>
> --
> Petr Dlouhý
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Tracer - nastavení

[Jan Bilak]

Zdroják SmallHoleRemover filtru vypadá takto:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Osm.Kn.Trace.Server.Trace.Interfaces;

namespace SmallHoleRemover
{
[BitmapFilter("SmallHoleRemover")]
public class SmallHoleRemover : IBitmapFilter
{
const byte BACKGROUND = 0;
const byte PEN = 1;
const byte TEMP = 2;

#region IBitmapFilter Members

public byte[][] Filter(byte[][] bitmap)
{
int h = bitmap.Length;
int w = bitmap[0].Length;

for (int y = 1; y < h - 1; y++)
{
for (int x = 1; x < w - 1; x++)
{
if ((bitmap[y][x] == PEN) &&
(bitmap[y][x - 1] != BACKGROUND || bitmap[y][x
+ 1] != BACKGROUND ||
bitmap[y - 1][x] != BACKGROUND || bitmap[y +
1][x] != BACKGROUND))
bitmap[y][x] = TEMP;
}
}
for (int y = 1; y < h - 1; y++)
{
for (int x = 1; x < w - 1; x++)
{
if (bitmap[y][x] == TEMP)
bitmap[y][x] = PEN;
}
}

return bitmap;
}

#endregion

#region IConfigurable Members

public void Init(IDictionary confValues)
{
}

#endregion
}
}

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Tracer - nastavení

[Jan Bilak]

Ahoj,

omlouvám se za chyby ... opravenou verzi jsem dal na stejné místo.

Honza


2010/2/28 Jan Bilak :
> Ahoj,
>
> díky za reakci ... zítra (nebo možná ještě teď večer) se kouknu, v čem
> je problém. Mimochodem zkoušíš to na Windows nebo pod Monem?
>
> Honza
>
>
> Dne 28. února 2010 2:21 MP  napsal(a):
>> On 27/02/2010, Jan Bilak  wrote:
>>> Ahoj,
>>>
>>>  přidal jsem podporu nějakého nastavení TraceServeru:
>>>  http://jabi.aspone.cz/osm/TraceServerBeta5.zip
>>
>> Tak jsem to zkusil a nefunguje to, hází to jakousi exception kvůli
>> nenalezenému filtru:
>>
>>>     
>>
>> Pokud tuhle řádku v defaultním konfiguráku nezakomentuju, hází mi to
>> tuhle chybu:
>>
>> $ mono Osm.Kn.Trace.Server.exe
>> EXPERIMENTALNI VERZE (2)
>>
>> Plugin dir is /m/e/p/josm/tracer/plugins.
>> Plugin SmallHoleRemover.dll loaded.
>>
>> Unhandled Exception: System.Collections.Generic.KeyNotFoundException:
>> The given key was not present in the dictionary.
>>  at 
>> System.Collections.Generic.Dictionary`2[System.String,System.Type].get_Item
>> (System.String key) [0x0]
>>  at Osm.Kn.Trace.Server.Wms.BitmapFilterManager.AddFilter
>> (System.String name, IDictionary`2 parameters) [0x0]
>>  at Osm.Kn.Trace.Server.Config.LoadBitmapFilters () [0x0]
>>  at Osm.Kn.Trace.Server.Server.Start () [0x0]
>>  at Osm.Kn.Trace.Server.Program.Main (System.String[] args) [0x0]
>>
>> Bez téhle řádky to sice jde spustit, ale pak to hází tuhle chybu:
>>
>> - trace/simple/50.10415000432744;14.36878225455269
>> http://wms.cuzk.cz/wms.asp?service=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG:4326&FORMAT=image/pn
>>
>> g&LAYERS=kn&BBOX=14.3660,50.1040,14.3680,50.1067&WIDTH=1600&HEIGHT=2160
>> System.NullReferenceException: Object reference not set to an instance
>> of an object
>>  at Osm.Kn.Trace.Server.Config.get_Treshold () [0x0]
>>  at Osm.Kn.Trace.Server.Wms.TileDownloader.Download
>> (Osm.Kn.Trace.Server.Wms.Tile tile) [0x0
>>             ]
>>  at Osm.Kn.Trace.Server.Wms.TileDownloader.Get
>> (Osm.Kn.Trace.Server.Wms.Tile tile) [0x0]
>>  at Osm.Kn.Trace.Server.Server.CreateBitmap
>> (Osm.Kn.Trace.Server.Wms.Tile[,] tiles, Int32 resolution) [0x0]
>>  at Osm.Kn.Trace.Server.Server.TraceCommand (PointGeo point,
>> IExporter exporter) [0x0]
>>  at Osm.Kn.Trace.Server.Server.webServer_GetContent (System.Object
>> sender, Osm.Kn.Trace.Server.WebServer.GetDataEventArgs e) [0x0]
>>
>> ... takže ta nová verze vlastně nefunguje 
>>
>> Martin
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Tracer - nastavení

[Jan Bilak]

Ahoj,

díky za reakci ... zítra (nebo možná ještě teď večer) se kouknu, v čem
je problém. Mimochodem zkoušíš to na Windows nebo pod Monem?

Honza


Dne 28. února 2010 2:21 MP  napsal(a):
> On 27/02/2010, Jan Bilak  wrote:
>> Ahoj,
>>
>>  přidal jsem podporu nějakého nastavení TraceServeru:
>>  http://jabi.aspone.cz/osm/TraceServerBeta5.zip
>
> Tak jsem to zkusil a nefunguje to, hází to jakousi exception kvůli
> nenalezenému filtru:
>
>>     
>
> Pokud tuhle řádku v defaultním konfiguráku nezakomentuju, hází mi to
> tuhle chybu:
>
> $ mono Osm.Kn.Trace.Server.exe
> EXPERIMENTALNI VERZE (2)
>
> Plugin dir is /m/e/p/josm/tracer/plugins.
> Plugin SmallHoleRemover.dll loaded.
>
> Unhandled Exception: System.Collections.Generic.KeyNotFoundException:
> The given key was not present in the dictionary.
>  at 
> System.Collections.Generic.Dictionary`2[System.String,System.Type].get_Item
> (System.String key) [0x0]
>  at Osm.Kn.Trace.Server.Wms.BitmapFilterManager.AddFilter
> (System.String name, IDictionary`2 parameters) [0x0]
>  at Osm.Kn.Trace.Server.Config.LoadBitmapFilters () [0x0]
>  at Osm.Kn.Trace.Server.Server.Start () [0x0]
>  at Osm.Kn.Trace.Server.Program.Main (System.String[] args) [0x0]
>
> Bez téhle řádky to sice jde spustit, ale pak to hází tuhle chybu:
>
> - trace/simple/50.10415000432744;14.36878225455269
> http://wms.cuzk.cz/wms.asp?service=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG:4326&FORMAT=image/pn
>
> g&LAYERS=kn&BBOX=14.3660,50.1040,14.3680,50.1067&WIDTH=1600&HEIGHT=2160
> System.NullReferenceException: Object reference not set to an instance
> of an object
>  at Osm.Kn.Trace.Server.Config.get_Treshold () [0x0]
>  at Osm.Kn.Trace.Server.Wms.TileDownloader.Download
> (Osm.Kn.Trace.Server.Wms.Tile tile) [0x0
>             ]
>  at Osm.Kn.Trace.Server.Wms.TileDownloader.Get
> (Osm.Kn.Trace.Server.Wms.Tile tile) [0x0]
>  at Osm.Kn.Trace.Server.Server.CreateBitmap
> (Osm.Kn.Trace.Server.Wms.Tile[,] tiles, Int32 resolution) [0x0]
>  at Osm.Kn.Trace.Server.Server.TraceCommand (PointGeo point,
> IExporter exporter) [0x0]
>  at Osm.Kn.Trace.Server.Server.webServer_GetContent (System.Object
> sender, Osm.Kn.Trace.Server.WebServer.GetDataEventArgs e) [0x0]
>
> ... takže ta nová verze vlastně nefunguje 
>
> Martin
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Tracer - nastavení

[Jan Bilak]

Ahoj,

přidal jsem podporu nějakého nastavení TraceServeru:
http://jabi.aspone.cz/osm/TraceServerBeta5.zip

Zároveň podporuje pluginy pro předzpracování bitmapy i filtraci bodů
(asi nejproblematičtější část trasování).

Konfigurační soubor je ve formátu XML a definuje dvě pipelines
(bitmapFilters a pointSetFilters). Tyto lze skládat z vestavených
filtrů a pluginů. Pluginy ve formě tříd v Class Library musí
referencovat Osm.Kn.Trace.Server.Interfaces.dll a implementovat
jednoduché rozhraní IBitmapFilter nebo IPointSetFilter.

Schema: http://jabi.aspone.cz/osm/PluginInterface.png

Zároveň je třeba třídě přiřadit atribut BitmapFilterAttribut nebo
PointSetFilterAttribute a kontruktoru přiřadit jméno, které se pak
používá pro označení pluignu v konfiguračním souboru. Filtry mohou mít
parametry, které lze nastavovat v konf. souboru. Jeden filtr může být
v pipeline vícekrát (třeba i s různým nastavením). Hotové Class
Libraries (jedna knihovna může obsahovat více filtrů) je třeba umístit
do složky plugins, která leží ve složce, ve které je
Osm.Kn.Trace.Server.exe a Osm.Kn.Trace.Server.Interfaces.dll.

Pro pochopení, co který filtr dělá, doporučuji všechny následující
filtry v pipeline zakomentovat a zkusit v JOSM, co z toho bude lézt.

Při změně bitmapFilters je vhodné smazat cache soubory. Při změně
pointSetFilters to není třeba.

I bez tvorby nových pluignů je možné trasování ovlivňovat změnou
pipeline (ubírám filtrů, změnou pořadí, přidávám filtrů, změnou
parametrů, ...). Pomocí pluginů je možné část nebo celou pipeline
nahradit.

Honza


Příklad konfiguráku:




  


  

  



  
  
  
  




  
  




  
  




  
  
  
  
  
  
  




  




  








  
  




  
  


  

  


  

  








  



___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Izometrická 3D mapa z OSM

[Jan Bilak]

Ahoj,

tohle by opravdu obecně nefungovalo ... i u obdélníku by to bylo
divné. Ale mohlo by to jít jinak... nebo nějak obdobně. Rozhodně je to
relativně snadno algoritmicky řešitelné i u nekonvexních a
nepravoúhlých polygonů.

Honza


Dne 24. února 2010 22:37 Aleš Janda  napsal(a):
> Ahoj,
>
>>> To by to řešilo, ovšem tím se problém jen trochu převede - neumím z obecného
>>> polygonu udělat menší polygon :-) Aspoň mě nenapadá žádný způsob jak to 
>>> udělat.
>>
>> Celkem jednoduse vemes tu strechu, zmensis ji (je to 2D plocha, operace
>> zmenseni je celkem trivialni, kdyztak hledej 2D transformace), zmensenou
>> plochu pak posunes vejskove, rekneme +2m a vzajemne odpovidajici body
>> spojis. Jak to bude vypadat by se muselo testnout. Samozrejme by to
>> vzhledem k poctu budov sezralo asi dost vykonu.
>
> Tohle by zřejmě nefungovalo ;-) Teda fungovalo, ale jen pro nevykousnuté 
> budovy.
> Kdyby ta budova byla např. do L, tak by se vrchní část posunula do středu. 
> Nebo
> dokonce kdyby ta budova byla s dírou uvnitř, tak by ta střecha nešla nad 
> středem
> konkrétních budov po obvodu, ale byla by šouplá směrem k vnitřnímu vykousnutí.
>
>
>> Kdyz sme u toho, mozna by nebylo od veci stvorit aplikaci pro boinc, pak
>> by potize s vykonem zmizly :D.
>
> Něco takového už připravuju, minimálně to používám pro vlastní účely. Je to
> klient, který si říká o práci a nahrává na server. Používám to doma i v práci.
> Chce to ale ještě doladit - sám nedokáže aktualizovat vstupní data, neošetřuje
> to moc chybových stavů, funguje to jen pod Linuxem, no a ještě to často měním 
> :-)
> Ale až to dám do nějakého použitelnějšího stavu, určitě to nabídnu. Minimálně
> aby se to i mně lépe používalo.
>
> Aleš Janda
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
<>___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Izometrická 3D mapa z OSM

[Jan Bilak]

Nebo ty body BCDE můžeš hledat i přímo jako průsečíky třech ploch:
B = průsečík ploch přiléhajících k s1, s2, s3
C = průsečík ploch přiléhajících k s1, s3, s4
D = průsečík ploch přiléhajících k s1, s4, s5
E = průsečík ploch přiléhajících k s1, s5, s6

Celkově jde pořád prakticky jen o analytickou geometrii - tedy nějaké
průsečíky rovin, přímek apod. Nemyslím, že by vlastní výpočet (ať může
vypadat složitě) nějak zvlášť zvyšoval výpočetní náročnost. Přecijen
na budovu to budou odhadem stovky elementárních operací s floaty a
těch budov zase tak moc není.

Jak se to projeví na větším množství ploch (trojúhelníků) k
rendrování, to je otázka. Přecijen pixelů výsledného obrázku je řádově
více. Ale myslím, že to stojí zato.

A případně lze řešit pomalost distribuovaným výpočtem.

Honza


2010/2/25 Jan Bilak :
> Ahoj,
>
> tohle by opravdu obecně nefungovalo ... i u obdélníku by to bylo
> divné. Ale mohlo by to jít jinak... nebo nějak obdobně. Rozhodně je to
> relativně snadno algoritmicky řešitelné i u nekonvexních a
> nepravoúhlých polygonů.
>
> Honza
>
>
> Dne 24. února 2010 22:37 Aleš Janda  napsal(a):
>> Ahoj,
>>
>>>> To by to řešilo, ovšem tím se problém jen trochu převede - neumím z 
>>>> obecného
>>>> polygonu udělat menší polygon :-) Aspoň mě nenapadá žádný způsob jak to 
>>>> udělat.
>>>
>>> Celkem jednoduse vemes tu strechu, zmensis ji (je to 2D plocha, operace
>>> zmenseni je celkem trivialni, kdyztak hledej 2D transformace), zmensenou
>>> plochu pak posunes vejskove, rekneme +2m a vzajemne odpovidajici body
>>> spojis. Jak to bude vypadat by se muselo testnout. Samozrejme by to
>>> vzhledem k poctu budov sezralo asi dost vykonu.
>>
>> Tohle by zřejmě nefungovalo ;-) Teda fungovalo, ale jen pro nevykousnuté 
>> budovy.
>> Kdyby ta budova byla např. do L, tak by se vrchní část posunula do středu. 
>> Nebo
>> dokonce kdyby ta budova byla s dírou uvnitř, tak by ta střecha nešla nad 
>> středem
>> konkrétních budov po obvodu, ale byla by šouplá směrem k vnitřnímu 
>> vykousnutí.
>>
>>
>>> Kdyz sme u toho, mozna by nebylo od veci stvorit aplikaci pro boinc, pak
>>> by potize s vykonem zmizly :D.
>>
>> Něco takového už připravuju, minimálně to používám pro vlastní účely. Je to
>> klient, který si říká o práci a nahrává na server. Používám to doma i v 
>> práci.
>> Chce to ale ještě doladit - sám nedokáže aktualizovat vstupní data, 
>> neošetřuje
>> to moc chybových stavů, funguje to jen pod Linuxem, no a ještě to často 
>> měním :-)
>> Ale až to dám do nějakého použitelnějšího stavu, určitě to nabídnu. Minimálně
>> aby se to i mně lépe používalo.
>>
>> Aleš Janda
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Dibavod konfliktni data

[Jan Bilak]

Sice nevím, o co jde, ale podle pořadí mailů a rozsahů to vypadá na:

11 - 20 ... Jan Dudík
21 - 30 ... Zdeněk Pražák
31 - 35 ... Jiří Parkan

Honza

2010/2/24 Martin Kupec :
> On Wed, Feb 24, 2010 at 08:56:25PM +0100, Zdeněk Pražák wrote:
>> Beru tedy 11 - 20
>        Koukam ze o to 11 se popralo spousta lidi :-)
>
>        Ja pockam az se dohodnete a pak si taky vezmu kus.
>
>                Martin Kupec
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Import DIBAVOD

[Jan Bilak]

Ted jsem to asi uplne nepochopil. V JSOM lze nejak nastavit, jestli
pouzije API metodu "diff upload", aby nahral vsechno v jednom
changesetu a transakci nebo to delal nejak jinak?

Osobne bych cekal, ze ten alternativni postup je pro ten webovy editor
a JOSM bude pouzivat vzdy "diff upload". Tedy vse pekne v transakci a
jednom changesetu. Tedy, pokud se to vejde do toho limitu poctu zmen.

Honza


2010/2/23 Tomas Kolda :
> Tak jsem to asi vykoukal. Ja jsem si 0.6 jeste necetl, coz je mozna skoda.
> Naposledy jsem delal lesy a to byla verze 0.5. Ty soubory co jsem posilal se
> totiz dali udelat velmi rychle pomoci toho diff upload. Mozna JOSMu vadilo,
> ze v xml bylo 
> JOSM to dela po jednom nodu v changesetu a nakonec po jedne line. To je
> samozrejmne 1 requestu a to trva tu hodinu.
>
> Pak je tam napsano:
> To avoid stale open changesets a mechanism is implemented to automatically
> close changesets upon one of the following three conditions:
>
> More than 50.000 edits on a single changeset See more specific limits
> The changeset has been open for more than 24 hours
> There have been no changes/API calls related to a changeset in 1 hour (i.e.
> idle timeout)
>
> Coz vysvetluje proc data zustaly. Ja to pochopil, ze je changeset jen kvuli
> lepsi identifikaci pro reverty ne jako transakce. Na transakci je pouzit ten
> diff upload.
>
> No aspon vime jak se to asi ma priste delat.
>
> Tomas
>
>
> jzvc napsal(a):
>
> Dne 23.2.2010 21:55, Jan Bilak napsal(a):
>
>
> Ja vychazel z tohoto:
>
> Diff upload: POST /api/0.6/changeset/#id/upload
>
> With this API call files in the OsmChange format can be uploaded to
> the server. This is guaranteed to be running in a transaction. So
> either all the changes are applied or none.
> To upload an OSC file it has to conform to the OsmChange specification
> with the addition of a changeset and a version attribute for each
> element, except when you are creating an element where the version is
> not required as the server sets that for you.
>
> [http://wiki.openstreetmap.org/wiki/OSM_Protocol_Version_0.6]
>
> Honza
>
>
>
>
> Otazka je, jestli vam to nezbuchlo ve finalni fazi, kdyz uz transakce
> byla uzavrena => melo by to by duplicitni komplet a teoreticky by melo
> jit revertnout komplet jeden changeset (pokud ho nekdo mezi tim
> nezmenil). Dalsi varianta, ktera me napada (spekulace) ze kdyz changeset
> je otevreny dyl nez X (hodina ???) tak ho OSM uzavre automaticky.
> Nektere typy chyb by tomu nasvedcovaly.
>
> BTW: Osobne trochu nechapu co trva na uploadu 1MB dat na 8Mbit lince cca
> 20 - 30 minut. Tech +- 10k zaznamu se da nacpat do databaze behem vterin.
>
>
>
> 2010/2/23 Tomas Kolda :
>
>
>
> No asi to tak neni, protoze by pak nevznikly ty duplikaty.
>
> Jak presne jste postupovali, kdyz vam to spadlo? At vysledujeme jak se
> spravne pri uploadech chovat...
>
> Tomas
>
> Jan Bilak napsal(a):
>
> Nahravani changesetu z JOSM je transakcni, ne? Takze bude se to povede
> cele nebo vubec a je to mozne opakovat. Nebo jsem to pochopil spatne?
>
> Honza
>
>
> Dne 23. února 2010 21:44 Tomas Kolda  napsal(a):
>
>
> A jak se ma pri tomto postupovat? Ja myslel, ze pro kazdy bod co JOSM
> uploadne si priradi nove id. Takze kdyz spadne spojeni melo by stacit dat
> save a tim uz by mel byt XML updatovan o to co se uploadlo. Nebo se mylim?
>
> Tomas
>
> Jan Dudík napsal(a):
>
> Jo, to je možný část 91 mi spadla chvilku po začátku imortu, myslel
> jsem ,že se stačilo přenést jen pár kousků a zatím to vypadá na skoro
> celý díl :-(...
>
> J&D
>
> Dne 23. února 2010 20:41 MP  napsal(a):
>
>
> Aha, ja nekdy predevcirem nektere casti uz v JOSM opravoval (s
> validatorem to jde rychle a vcelku automaticky...), takze nektere
> rybniky tam jsou uz jen jednou.
>
>
> Jinak dalsi problem je v datech nahranych uzivatelem Medulove. Skript,
> kterym kontroluju cas od casu dumpy na mozne chyby mi na dumpu z
> dnesniho rana nahlasil asi 10700 duplicitnich nodu od nej
> (rozprostrenych po cele CR) a co jsem tak koukal, tak je to taky
> dibavod (byt kazdy rybnik je tam "jen" dvakrat). pavel ma 13700
> duplicitnich nodu (nez jsem vcera nektere casti opravoval, tak jich
> bylo asi 32000)
>
> Takze duplicity od Medulove by taky asi chtely vyresit...
>
> Martin
>
> On 22/02/2010, Pavel Machek  wrote:
>
>
> Hi!
>
>  It seems that I created duplicate data when importing DIBAVOD; I
>  assumed that if connection died before closing transaction, no data
>  would be uploaded, and it seems it is not so :-(.
>
>  Edits in question are:
>
>  #3938287 February 21, 2010 20:50

Re: [Talk-cz] Import DIBAVOD

[Jan Bilak]

Ja vychazel z tohoto:

Diff upload: POST /api/0.6/changeset/#id/upload

With this API call files in the OsmChange format can be uploaded to
the server. This is guaranteed to be running in a transaction. So
either all the changes are applied or none.
To upload an OSC file it has to conform to the OsmChange specification
with the addition of a changeset and a version attribute for each
element, except when you are creating an element where the version is
not required as the server sets that for you.

[http://wiki.openstreetmap.org/wiki/OSM_Protocol_Version_0.6]

Honza


2010/2/23 Tomas Kolda :
> No asi to tak neni, protoze by pak nevznikly ty duplikaty.
>
> Jak presne jste postupovali, kdyz vam to spadlo? At vysledujeme jak se
> spravne pri uploadech chovat...
>
> Tomas
>
> Jan Bilak napsal(a):
>
> Nahravani changesetu z JOSM je transakcni, ne? Takze bude se to povede
> cele nebo vubec a je to mozne opakovat. Nebo jsem to pochopil spatne?
>
> Honza
>
>
> Dne 23. února 2010 21:44 Tomas Kolda  napsal(a):
>
>
> A jak se ma pri tomto postupovat? Ja myslel, ze pro kazdy bod co JOSM
> uploadne si priradi nove id. Takze kdyz spadne spojeni melo by stacit dat
> save a tim uz by mel byt XML updatovan o to co se uploadlo. Nebo se mylim?
>
> Tomas
>
> Jan Dudík napsal(a):
>
> Jo, to je možný část 91 mi spadla chvilku po začátku imortu, myslel
> jsem ,že se stačilo přenést jen pár kousků a zatím to vypadá na skoro
> celý díl :-(...
>
> J&D
>
> Dne 23. února 2010 20:41 MP  napsal(a):
>
>
> Aha, ja nekdy predevcirem nektere casti uz v JOSM opravoval (s
> validatorem to jde rychle a vcelku automaticky...), takze nektere
> rybniky tam jsou uz jen jednou.
>
>
> Jinak dalsi problem je v datech nahranych uzivatelem Medulove. Skript,
> kterym kontroluju cas od casu dumpy na mozne chyby mi na dumpu z
> dnesniho rana nahlasil asi 10700 duplicitnich nodu od nej
> (rozprostrenych po cele CR) a co jsem tak koukal, tak je to taky
> dibavod (byt kazdy rybnik je tam "jen" dvakrat). pavel ma 13700
> duplicitnich nodu (nez jsem vcera nektere casti opravoval, tak jich
> bylo asi 32000)
>
> Takze duplicity od Medulove by taky asi chtely vyresit...
>
> Martin
>
> On 22/02/2010, Pavel Machek  wrote:
>
>
> Hi!
>
>  It seems that I created duplicate data when importing DIBAVOD; I
>  assumed that if connection died before closing transaction, no data
>  would be uploaded, and it seems it is not so :-(.
>
>  Edits in question are:
>
>  #3938287         February 21, 2010 20:50         dibavod, cast 41
>  11.985,48.587,17.993,50.959   (big)
>  #3938219        February 21, 2010 21:37         import dibavod, cast
>  41      11.985,48.587,17.993,50.959 (big)
>  #3938181        February 21, 2010 21:30         import dibavod, cast
>  41      11.985,48.587,17.993,50.959 (big)
>  #3938082        February 21, 2010 21:23         import dibavod, cast
>  41      11.985,48.587,17.993,50.959 (big)
>
>  ...they should be duplicates (if not, the biggest one should be left).
>
>  Now, there are big fat warnings about revert scripts and I'd prefer
>  not to mess up the database even more. What is the best way to
>  proceed?
>
>  Sorry for the mess,
>
>                                                                 Pavel
>
>
>  > Pokud jsem se díval na několik rybníků, tak všechny byly nahrány 4x.
>  >
>  > Například Trubární rybník - cesta č. 50937312 je nahrán ještě jako cesta
> č. 50932852, 50935613 a 50934642
>  >
>  > Praák
>  > >  Původní zpráva 
>  > > Od: Pavel Machek 
>  > > Předmět: Re: [Talk-cz] Import DIBAVOD
>  > > Datum: 22.2.2010 08:03:14
>  > > 
>  > > Ahoj!
>  > >
>  > > > Namátkou jsem zjistil, že Pavel nahrál omylem část č. 41 celkem
> čtyřikrát.
>  > >
>  > > Padlo spojeni ve fazi uploading, ale pred uzavrenim transakce. Takze
>  > > jsem letmo skontroloval ze tam data nejsou (a nebyla?!) a zkusil to
>  > > znovu.
>  > >
>  > > Opravdu je duplicita v datech?
>  > >
>  > > --
>  > > (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
>  > > http://lists.openstreetmap.org/listinfo/talk-cz
>  > >
>  > >
>  > >
>  >
>  > ___
>  >

Re: [Talk-cz] Import DIBAVOD

[Jan Bilak]

Nahravani changesetu z JOSM je transakcni, ne? Takze bude se to povede
cele nebo vubec a je to mozne opakovat. Nebo jsem to pochopil spatne?

Honza


Dne 23. února 2010 21:44 Tomas Kolda  napsal(a):
> A jak se ma pri tomto postupovat? Ja myslel, ze pro kazdy bod co JOSM
> uploadne si priradi nove id. Takze kdyz spadne spojeni melo by stacit dat
> save a tim uz by mel byt XML updatovan o to co se uploadlo. Nebo se mylim?
>
> Tomas
>
> Jan Dudík napsal(a):
>
> Jo, to je možný část 91 mi spadla chvilku po začátku imortu, myslel
> jsem ,že se stačilo přenést jen pár kousků a zatím to vypadá na skoro
> celý díl :-(...
>
> J&D
>
> Dne 23. února 2010 20:41 MP  napsal(a):
>
>
> Aha, ja nekdy predevcirem nektere casti uz v JOSM opravoval (s
> validatorem to jde rychle a vcelku automaticky...), takze nektere
> rybniky tam jsou uz jen jednou.
>
>
> Jinak dalsi problem je v datech nahranych uzivatelem Medulove. Skript,
> kterym kontroluju cas od casu dumpy na mozne chyby mi na dumpu z
> dnesniho rana nahlasil asi 10700 duplicitnich nodu od nej
> (rozprostrenych po cele CR) a co jsem tak koukal, tak je to taky
> dibavod (byt kazdy rybnik je tam "jen" dvakrat). pavel ma 13700
> duplicitnich nodu (nez jsem vcera nektere casti opravoval, tak jich
> bylo asi 32000)
>
> Takze duplicity od Medulove by taky asi chtely vyresit...
>
> Martin
>
> On 22/02/2010, Pavel Machek  wrote:
>
>
> Hi!
>
>  It seems that I created duplicate data when importing DIBAVOD; I
>  assumed that if connection died before closing transaction, no data
>  would be uploaded, and it seems it is not so :-(.
>
>  Edits in question are:
>
>  #3938287         February 21, 2010 20:50         dibavod, cast 41
>  11.985,48.587,17.993,50.959   (big)
>  #3938219        February 21, 2010 21:37         import dibavod, cast
>  41      11.985,48.587,17.993,50.959 (big)
>  #3938181        February 21, 2010 21:30         import dibavod, cast
>  41      11.985,48.587,17.993,50.959 (big)
>  #3938082        February 21, 2010 21:23         import dibavod, cast
>  41      11.985,48.587,17.993,50.959 (big)
>
>  ...they should be duplicates (if not, the biggest one should be left).
>
>  Now, there are big fat warnings about revert scripts and I'd prefer
>  not to mess up the database even more. What is the best way to
>  proceed?
>
>  Sorry for the mess,
>
>                                                                 Pavel
>
>
>  > Pokud jsem se díval na několik rybníků, tak všechny byly nahrány 4x.
>  >
>  > Například Trubární rybník - cesta č. 50937312 je nahrán ještě jako cesta
> č. 50932852, 50935613 a 50934642
>  >
>  > Praák
>  > >  Původní zpráva 
>  > > Od: Pavel Machek 
>  > > Předmět: Re: [Talk-cz] Import DIBAVOD
>  > > Datum: 22.2.2010 08:03:14
>  > > 
>  > > Ahoj!
>  > >
>  > > > Namátkou jsem zjistil, že Pavel nahrál omylem část č. 41 celkem
> čtyřikrát.
>  > >
>  > > Padlo spojeni ve fazi uploading, ale pred uzavrenim transakce. Takze
>  > > jsem letmo skontroloval ze tam data nejsou (a nebyla?!) a zkusil to
>  > > znovu.
>  > >
>  > > Opravdu je duplicita v datech?
>  > >
>  > > --
>  > > (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
>  > > http://lists.openstreetmap.org/listinfo/talk-cz
>  > >
>  > >
>  > >
>  >
>  > ___
>  > Talk-cz mailing list
>  > Talk-cz@openstreetmap.org
>  > http://lists.openstreetmap.org/listinfo/talk-cz
>
>  --
>  (english) http://www.livejournal.com/~pavelmachek
>  (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>
>  ___
>  Talk-cz mailing list
>  talk...@openstreetmap.org
>  http://lists.openstreetmap.org/listinfo/talk-cz
>
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
>
>
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Izometrická 3D mapa z OSM

[Jan Bilak]

Ahoj,

jak píšeš o stylovém souboru ... tak ten asi bude obsahovat prakticky
všechno. Jaká data se vezmou a jakým způsobem se vykreslí. Takže to je
ideální forma parametrizace vykreslování.

Co se týká výšky budov, tak samozřejmě vhodně otagované budovy jsou
ideální. Ale nedělám si iluze, že někdo bude hromadně přeměřovat
budovy (možná na několika málo zajímavých místech). Žádný zdroj dat,
který by obsahoval výšku budov v ČR, nejspíše neexistuje. Takže
podstatná bude nějaká defaultní výška. A defautní výšku bude vhodné
zvolit jinou na vesnici a jinou třeba na sídlišti plného paneláků.

Tlouštky čar možná nemá velký smysl měnit, to byl jen příklad. Ukáže
čas, co bude třeba.

Pokud budeš dělat nějaké zohlednění výšky terénu, tak bych to dělal
vypínatelné. V některých případech (orientační mapka) to bude spíše na
obtíž.

Je jasné, že je zatím brzy.

Honza


Dne 17. února 2010 21:11 Aleš Janda  napsal(a):
> Ahoj,
>
> díky za názor.
>
> Jak to myslíš s tím způsobem vykreslení? Resp. co by se mělo všechno měnit?
> Počítám s tím, že výška budov se bude brát z tagů
>
> http://wiki.openstreetmap.org/wiki/Proposed_features/Building_attributes
>
> minimálně typ střechy a výška, popř. počet pater. Pak je jen otázka, jestli 
> to v
> těch datech bude...
>
> Tloušťky čar... no, možná, ale v defaultu by to mělo být alespoň přijatelně 
> pěkné.
>
> Mimochodem, ten převodní program asi později uvolním (pod nějakou volnou
> licencí) a stylový soubor bude patrně jeho externí částí. Takže každý si bude
> moci vyrenderovat co chce.
> Ale zatím je to příliš v raném stádiu.
>
> Aleš Janda
>
>
> On 17.2.2010 20:52, Jan Bilak napsal/a:
>> Zdravím,
>>
>> je to moc pěkné. Dovedu si živě představit, že třeba orientační mapka
>> typu "jak se dostat do ..." by byla tímto způsobem provedená a
>> vypadala velmi efektně.
>>
>> Měřítko ... v izometrickém pohledu prostě bude mapka zkreslená, s tím
>> nic nenaděláš. Když to nějak roztáhneš, tak už to není izometrické
>> zobrazení, ale něco nereálného, divného, ...
>>
>> Kombinovat 2D pohled shora a izometrický pohled (jako různé vrstvy)
>> nedává smysl. Různé vrstvy použít lze, ale všechny musí být zobrazené
>> stejně - tedy např. v izometrii.
>>
>> Vylepšení ... napadá mne vyrendrování nějaké oblasti mapy na přání
>> (tedy se zvoleným úhlem pohledu). A také nějaká konfigurace způsobu
>> vykreslení (výška budov, barvy, tlouštky čar apod.). Když si bude moci
>> každý nastavit vlastní zobrazení, tak se myslím brzy najde nějaké
>> obecně hezčí než toto.
>>
>> Honza
>>
>>
>> Dne 17. února 2010 19:48 Aleš Janda  napsal(a):
>>> Zdravím,
>>>
>>> trošku jsem si hrál a udělal jsem izometrickou 3D mapu z OSM dat. Něco jsem 
>>> dal
>>> na web, je to na
>>> http://osm.kyblsoft.cz/3dmapa/
>>>
>>> Napřed jak to pracuje a potom na co se chci zeptat :-)
>>> Udělal jsem si program v C++, který načte .osm soubor a ty objekty, které 
>>> zná,
>>> převede do nějaké 3D podoby. Výstup programu je ve formátu POV, čili formát 
>>> pro
>>> POV-Ray, což je renderer 3D modelů. Takže ten výsek mapky, co vidíte na 
>>> uvedeném
>>> odkaze, je proveden několika cykly osmosis =>  můj osm2pov =>  povray =>  
>>> rozsekat
>>> na dlaždice =>  web :-)
>>>
>>> A teď co se chci zeptat:
>>>
>>> 1) co tomu říkáte? :-)
>>>
>>> 2) narazil jsem na problém s měřítkem. Jak je totiž mapa v izometrickém 
>>> pohledu,
>>> tak je trochu nakloněná. Tím dojde ke "smrštění" osy Y - to co vede od 
>>> severu k
>>> jihu se zdá menší než od východu k západu. Zatím moc nevím, jak to vyřešit,
>>> napadají mě dva způsoby, na tom odkazu jsou použity oba:
>>>   - roztažení obrázku na výšku tak, aby to bylo správně vysoké. To ale 
>>> vypadá
>>> divně (většina mapy)
>>>   - v ose Y bude mít mapa poloviční velikost (to jsem použil v pásu od 
>>> Kralup do
>>> Neratovic) - vypadá to mnohem lépe, ale je to nekompatibilní se zbytkem OSM 
>>> - je
>>> problém s přepínáním vrstev, permalinkem, různé navazování s jinými mapami 
>>> atd.
>>>
>>> Chci se zeptat, jestli nevíte o nějakém standardním způsobu, jak řešit 
>>> netypické
>>> měřítko.
>>>
>>> Jinak ta mapa je jen v oblasti od Kralup do Prahy, ladil jsem ji za pochodu,
>>> některé dlaždice jsou chybné (nenavazují, špatná šířka silnicí...), hromadu 
>>> toho
>>> ještě nevykresluje nebo chybně (atribut layer). V pruhu Kralupy-Neratovice 
>

Re: [Talk-cz] Izometrická 3D mapa z OSM

[Jan Bilak]

Zdravím,

je to moc pěkné. Dovedu si živě představit, že třeba orientační mapka
typu "jak se dostat do ..." by byla tímto způsobem provedená a
vypadala velmi efektně.

Měřítko ... v izometrickém pohledu prostě bude mapka zkreslená, s tím
nic nenaděláš. Když to nějak roztáhneš, tak už to není izometrické
zobrazení, ale něco nereálného, divného, ...

Kombinovat 2D pohled shora a izometrický pohled (jako různé vrstvy)
nedává smysl. Různé vrstvy použít lze, ale všechny musí být zobrazené
stejně - tedy např. v izometrii.

Vylepšení ... napadá mne vyrendrování nějaké oblasti mapy na přání
(tedy se zvoleným úhlem pohledu). A také nějaká konfigurace způsobu
vykreslení (výška budov, barvy, tlouštky čar apod.). Když si bude moci
každý nastavit vlastní zobrazení, tak se myslím brzy najde nějaké
obecně hezčí než toto.

Honza


Dne 17. února 2010 19:48 Aleš Janda  napsal(a):
> Zdravím,
>
> trošku jsem si hrál a udělal jsem izometrickou 3D mapu z OSM dat. Něco jsem 
> dal
> na web, je to na
> http://osm.kyblsoft.cz/3dmapa/
>
> Napřed jak to pracuje a potom na co se chci zeptat :-)
> Udělal jsem si program v C++, který načte .osm soubor a ty objekty, které zná,
> převede do nějaké 3D podoby. Výstup programu je ve formátu POV, čili formát 
> pro
> POV-Ray, což je renderer 3D modelů. Takže ten výsek mapky, co vidíte na 
> uvedeném
> odkaze, je proveden několika cykly osmosis => můj osm2pov => povray => 
> rozsekat
> na dlaždice => web :-)
>
> A teď co se chci zeptat:
>
> 1) co tomu říkáte? :-)
>
> 2) narazil jsem na problém s měřítkem. Jak je totiž mapa v izometrickém 
> pohledu,
> tak je trochu nakloněná. Tím dojde ke "smrštění" osy Y - to co vede od severu 
> k
> jihu se zdá menší než od východu k západu. Zatím moc nevím, jak to vyřešit,
> napadají mě dva způsoby, na tom odkazu jsou použity oba:
>  - roztažení obrázku na výšku tak, aby to bylo správně vysoké. To ale vypadá
> divně (většina mapy)
>  - v ose Y bude mít mapa poloviční velikost (to jsem použil v pásu od Kralup 
> do
> Neratovic) - vypadá to mnohem lépe, ale je to nekompatibilní se zbytkem OSM - 
> je
> problém s přepínáním vrstev, permalinkem, různé navazování s jinými mapami 
> atd.
>
> Chci se zeptat, jestli nevíte o nějakém standardním způsobu, jak řešit 
> netypické
> měřítko.
>
> Jinak ta mapa je jen v oblasti od Kralup do Prahy, ladil jsem ji za pochodu,
> některé dlaždice jsou chybné (nenavazují, špatná šířka silnicí...), hromadu 
> toho
> ještě nevykresluje nebo chybně (atribut layer). V pruhu Kralupy-Neratovice 
> jsem
> dal záměrně to smrštění v ose Y (vypadá to líp, pochopitelně nenavazuje se
> zbytkem mapy).
>
> 3) máte nějaké nápady na vylepšení?
>
> Díky.
>
> Aleš Janda
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Import adres z katastralni mapy

[Jan Bilak]

Než to nějak upravím ... tak zatím ještě přikládám beta4 zdrojáky pro zájemce:
http://jabi.aspone.cz/osm/FindAddressPoints-beta4-src.zip

Honza


2010/2/17 Jan Bilak :
> A mimochodem nejde o můj program ... je to upravený ten tvůj.
>
> Honza
>
>
> 2010/2/17 Jan Bilak :
>> Ahoj,
>>
>> odkaz na zdrojáky jsem do této konference už zasílal (na betu 3) - o
>> pár příspěvků výše jej najdeš. Beta 4 upravovala jen drobnosti. Ještě
>> zdrojáky trochu upravím (po formální stránce - refaktoring, komentáře,
>> ...) ... a pak, když vymyslíte vhodné místo na SVN, tak tam nahraju.
>>
>> Obecně si ale myslím, že je vhodné dělat tyto utility jako class
>> library (v případě .NETu) s nějakým rozumným interfacem, aby je bylo
>> možné začlěňovat do celku. Tedy místo dlouhého postupu, co spouštět v
>> jakém pořadí, tak pak mít utilitku s příjemným rozhraním (ať již
>> konzolovým nebo GUI), která tohle všechno zařídí. A přitom jednotlivé
>> části řešené jako vyměnitelné a nahraditelné jinou implementací.
>>
>> Jinak mám velké pochybnosti o tom, že se budou dostatečně často data
>> aktualizovat. Už to nebude mít takový ten "wow" efekt, kdy na mapách
>> přibude mnoho dat a tak se do toho nikomu nebude moc chtít, když to
>> bude složité.
>>
>> Honza
>>
>>
>> 2010/2/17 Petr Dlouhý :
>>> Princip práce Honzova programu se dá jednoduše poznat z logových souborů.
>>>
>>> Zdrojáky by asi bylo nejlepší nahrát na 
>>> <http://svn.openstreetmap.org/applications/utils/>, abychom se s nimi při 
>>> příštím importu zase setkali, a aby se jimi mohli inspirovat i ostatní.
>>>
>>>
>>>>  Původní zpráva 
>>>> Od: Lukas Kabrt 
>>>> Předmět: Re: [Talk-cz] Import adres z katastralni mapy
>>>> Datum: 17.2.2010 15:38:57
>>>> 
>>>
>>>> BTW, muzes nekam dat zdrojaky, docela by me zajimalo, jak tvuj program 
>>>> pracuje.
>>>>
>>>> --
>>>> Lukas
>>>>
>>>> ___
>>>> Talk-cz mailing list
>>>> Talk-cz@openstreetmap.org
>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>
>>>>
>>>>
>>>
>>> Petr Dlouhý
>>> petr.dlo...@email.cz
>>>
>>> ___
>>> Talk-cz mailing list
>>> Talk-cz@openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>
>>
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Import adres z katastralni mapy

[Jan Bilak]

A mimochodem nejde o můj program ... je to upravený ten tvůj.

Honza


2010/2/17 Jan Bilak :
> Ahoj,
>
> odkaz na zdrojáky jsem do této konference už zasílal (na betu 3) - o
> pár příspěvků výše jej najdeš. Beta 4 upravovala jen drobnosti. Ještě
> zdrojáky trochu upravím (po formální stránce - refaktoring, komentáře,
> ...) ... a pak, když vymyslíte vhodné místo na SVN, tak tam nahraju.
>
> Obecně si ale myslím, že je vhodné dělat tyto utility jako class
> library (v případě .NETu) s nějakým rozumným interfacem, aby je bylo
> možné začlěňovat do celku. Tedy místo dlouhého postupu, co spouštět v
> jakém pořadí, tak pak mít utilitku s příjemným rozhraním (ať již
> konzolovým nebo GUI), která tohle všechno zařídí. A přitom jednotlivé
> části řešené jako vyměnitelné a nahraditelné jinou implementací.
>
> Jinak mám velké pochybnosti o tom, že se budou dostatečně často data
> aktualizovat. Už to nebude mít takový ten "wow" efekt, kdy na mapách
> přibude mnoho dat a tak se do toho nikomu nebude moc chtít, když to
> bude složité.
>
> Honza
>
>
> 2010/2/17 Petr Dlouhý :
>> Princip práce Honzova programu se dá jednoduše poznat z logových souborů.
>>
>> Zdrojáky by asi bylo nejlepší nahrát na 
>> <http://svn.openstreetmap.org/applications/utils/>, abychom se s nimi při 
>> příštím importu zase setkali, a aby se jimi mohli inspirovat i ostatní.
>>
>>
>>>  Původní zpráva 
>>> Od: Lukas Kabrt 
>>> Předmět: Re: [Talk-cz] Import adres z katastralni mapy
>>> Datum: 17.2.2010 15:38:57
>>> 
>>
>>> BTW, muzes nekam dat zdrojaky, docela by me zajimalo, jak tvuj program 
>>> pracuje.
>>>
>>> --
>>> Lukas
>>>
>>> ___
>>> Talk-cz mailing list
>>> Talk-cz@openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>
>>>
>>>
>>
>> Petr Dlouhý
>> petr.dlo...@email.cz
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Import adres z katastralni mapy

[Jan Bilak]

Ahoj,

odkaz na zdrojáky jsem do této konference už zasílal (na betu 3) - o
pár příspěvků výše jej najdeš. Beta 4 upravovala jen drobnosti. Ještě
zdrojáky trochu upravím (po formální stránce - refaktoring, komentáře,
...) ... a pak, když vymyslíte vhodné místo na SVN, tak tam nahraju.

Obecně si ale myslím, že je vhodné dělat tyto utility jako class
library (v případě .NETu) s nějakým rozumným interfacem, aby je bylo
možné začlěňovat do celku. Tedy místo dlouhého postupu, co spouštět v
jakém pořadí, tak pak mít utilitku s příjemným rozhraním (ať již
konzolovým nebo GUI), která tohle všechno zařídí. A přitom jednotlivé
části řešené jako vyměnitelné a nahraditelné jinou implementací.

Jinak mám velké pochybnosti o tom, že se budou dostatečně často data
aktualizovat. Už to nebude mít takový ten "wow" efekt, kdy na mapách
přibude mnoho dat a tak se do toho nikomu nebude moc chtít, když to
bude složité.

Honza


2010/2/17 Petr Dlouhý :
> Princip práce Honzova programu se dá jednoduše poznat z logových souborů.
>
> Zdrojáky by asi bylo nejlepší nahrát na 
> , abychom se s nimi při 
> příštím importu zase setkali, a aby se jimi mohli inspirovat i ostatní.
>
>
>>  Původní zpráva 
>> Od: Lukas Kabrt 
>> Předmět: Re: [Talk-cz] Import adres z katastralni mapy
>> Datum: 17.2.2010 15:38:57
>> 
>
>> BTW, muzes nekam dat zdrojaky, docela by me zajimalo, jak tvuj program 
>> pracuje.
>>
>> --
>> Lukas
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>>
>>
>
> Petr Dlouhý
> petr.dlo...@email.cz
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Tracer na rozpoznání budov z katastr ální mapy

[Jan Bilak]

Ahoj,

server dostane souřadnici kliknutí myší a vrací obrys souvislé bílé
plochy zvětšené o polovinu tlouštky čáry v podobě souřadnic polygonu.
Tedy s vlastním napojováním nemá nic společného. Ovlivňuje pouze
kvalitu trasování - jak přesná hranice budovy bude. Samozřejmě pokud
se zlepšením přesnosti se mohou body různých budov dostat blíže a tedy
tím nepřímo zafunguje napojování.

V případě problémů prosím uvádějte příklad ve formě souřadnic kliknutí
myší (vypisuje se do konzole trace serveru), při kterém došlo k něčemu
nečekanému.

Honza


Dne 16. února 2010 13:42 MP  napsal(a):
> Zkoušl jsem to a když jsem zkusmo přetrasoval blok asi 5 budov, tak mi
> je to spojovalo.
> Plugin mám ve verzi 19985 a používám k tomu experimentální verzi traceru 
> (beta3)
>
> Co jsem koukal do logu, tak v r19927 bylo opraveno občas nefungující
> undo (způsobovalo někdy nekonzistanci dat) a v r19985 zase chyba, kdy
> se budovy na sebe napojí křížem, takže bych zkusil upgradnout na 19985
> (i když to asi tenhle problém nevyřeší, ale opraví to jiné nepříjemné
> chyby)
>
> Používám beta verzi tracer serveru, takže bych zkusil případně
> upgradnout i tracer. Vyhrabal jsem odkaz na Beta3 z historie
> mailinglistu:
> http://jabi.aspone.cz/osm/TraceServerBeta3.zip
>
> Martin
>
> On 16/02/2010, Zdeněk Pražák  wrote:
>>
>>  Včera jsem si stáhl z JOSM aktuální verzi traceru č. 19892 a trasoval jsem 
>> budovy v Novém Bydžově.
>>  Po nahrání výsledku jsem si všiml, že pokud trasuji jednotlivé budovy v 
>> bloku domů, tak se na sebe nenapojují a je mezi nimi vidět malá mezírka.
>>  Je to správné chování traceru nebo se dá nějak přinutit aby spojoval 
>> přiléhající budovy k sobě.
>>  Pražák
>>
>>  ___
>>  Talk-cz mailing list
>>  talk...@openstreetmap.org
>>  http://lists.openstreetmap.org/listinfo/talk-cz
>>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Import adres z katastralni mapy

[Jan Bilak]

Ahoj,

nezkousel jsem porovnavat vysledky z tesseractu a meho rozpoznavani
vzoru, ale myslim, ze by to slo snadno. Staci nejaka data, ktera byla
zpracovana tesseractem, zpracovat take timto. Oba csv soubory seradit
a pouzit nejaky klasicky diff.

Obecne mam obavu, ze tesseract se muze splest a rozpoznat cislo
spatne, i kdyz vysledek rozpoznani odpovida vzoru. Zato muj OCR na
miru detektuje pripady, kdy si neni jisty, a loguje je, aby je bylo
mozne rucne zkontrolovat. Pritom je jich dostatecne maly pocet na to,
aby rucni kontrola byla proveditelna. Pokud v programu neni chyba (coz
nevylucuji), tak by program nemel popisek rozpoznat spatne, aniz by
jej oznacil, ze si neni jisty.

To byl hlavni cil, proc jsem OCR delal - zajisteni spolehlivosti.
Zvyseni rychlosti bylo druhorade, i kdyz je to prijemne.

Honza


2010/2/15 Petr Dlouhý :
> Ahoj,
>
> algoritmus po Honzových úpravách pracuje výrazně rychleji a dokáže
> detekovat překrývající se čísla s téměř 100% úspěšností (na rozsáhlém
> území jsou to jednotky chyb). Vzhledem k tomu, že je to možné zpracovat za
> několik dnů na jednom PC, tak bych řekl, že se to předělat vyplatí.
>
> On Mon, 15 Feb 2010 09:44:58 +0100, Lukas Kabrt  wrote:
>
>> Ahoj,
>>
>> ja byl ted tyden pryc, proto jsem se do diskuze a reseni problemu
>> nezapojil.
>>
>> Pokud spravne chapu situaci, tak problem je u c.e., ve kterych je
>> cislice 2 se obcas stava a obcas se stava, ze se rozpozna jako 7. Jak
>> jsem z diskuze pochopil, tak Honza Bilak napsal programek, ktery vezme
>> celou dlazdici a provede OCR jinym zpusobem.
>>
>> Ja mam pripravene skripty na docisteni vysledku (slouceni dat z
>> dlazdic, vymazani duplicit zpusobenych prekryvem dlazdic, vyfiltorvani
>> bodu ktere neodpovidaji vzoru c.p., c.e., bez cp./c.e a jejich stazeni
>> ve vyssim rozliseni a znovuprovedeni OCR - vyreseni prokryvajicich se
>> napisu)
>>
>> Vysledky po stazeni detailu a znovuprovedeni OCR jsou celkem dobre. Na
>> datech, co byla  spocitana minuly tyden (cca 2/3 republiky) je po
>> znovuprovedeni OCR jen 1050 adresnich bodu, ktere neodpovidaji
>> zadanemu vzoru.
>>
>> Myslim, ze by bylo zbytecne zpracovavat celou CR znovu. Z dat si muzu
>> vytahnout c.e., ktera obsahuji cislici 7, stahnout si detail ve vyssim
>> rozliceni a ten misto terreractem zpracovat algoritmem od Honzy.
>> --
>> Lukas
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>
>
> --
> Petr Dlouhý
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Tracer na rozpoznání budov z katastr . map

[Jan Bilak]

Ahoj,

něco zkusím, až se k tomu dostanu. Ta stránka o dilataci vypadá na
první pohled zajímavě (zatím na ni tedy koukal jen pár sekund) ... už
jsem si od doby studia na matfyzu trochu odvykl tohle číst.

Ale myslím, že by mohla pomoci běžná operace typy pixel je černý právě
tehdy, pokud byl černý nebo jeho soused byl černý. To ztlustí všechny
čáry a zacelí díry do velikosti cca 2 px. Ale tlustší čáry nám nevadí,
protože se stejně zajímáme o střed čáry. Ale bude to chtít nejspíš
vypínatelné. A také to bude chtít provádět jen někde ... aby to nebylo
moc pomalé. Nebo to provádět hned po stažení a s tím to tak ukládat
cachovat na disk...

Uvažuji tedy nad nějakou konfigurací. Jedna možnost je konfigurační
soubor. Druhá možnost je konfigurace přes HTTP pomocí jednoduchých
příkazů. To jde vylepšit zaintegrováním konfigurační stránky přímo do
programu. A celé to lze zkombinovat, že úpravy ve webové konfiguraci
se budou ukládat do konfiguračního souboru.

Alternativa je frontend v JOSM - nějaký dialog, který by posílal
konfiguraci na server klasicky po HTTP jako posílá příkaz pro
trasování.

Každopádně to nebude hned.

Honza


Dne 15. února 2010 3:52 MP  napsal(a):
> On 13/02/2010, Petr Dlouhý  wrote:
>> Ahoj,
>>
>>  v Praze, například, už začínají docházet nezmapovaná KÚ, která jsou
>>  kreslená tlustými čarami. Zbylá území jsou kreslená čárami tenkými a na
>>  těch se Tracer moc nechytá, takže to dá výrazně víc práce.
>
> Jiná města jsou třeba skoro celá kreslena tlustými čarami - např.
> Hradec Králové, takže by šlo do vyřešení problému trasovat tam. Co
> jsem koukal i jinde, tak i menší města (odhadem tak od 3 obyvatel
> výše, ale je ti různé...) jsou často trasována tlustými čarami.
>
>>  Nešlo by upravit Tracer server pro tenké čáry? Hlavní problémy jsou dva -
>>  slučky a díry v čarách.
>>  Slučky asi budou tvrdší oříšek, a asi jsou zatím důležitější věci na práci
>>  (například import adresních bodů).
>>  Díry by ale možná šly vyřešit jednodušeji. Nešlo by udělat, aby šlo
>>  nastavit, jak moc velkou dírou ten flood-fill proleze? V tlustých čarách
>>  je naopak problém s tím, že u některých garáží to občas neproleze kolem
>>  nápisu vedle kterého je úzká díra.
>
> Zkusit na to pustit dilataci?
> http://en.wikipedia.org/wiki/Dilation_(morphology)
>
> Sice to nepomůže s garážemi, ale mohlo by to vyřešit tenké polygony s dírami.
>
> Martin
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Import adres z katastralni mapy

[Jan Bilak]

Ahoj.

Jedná se o špatně detekované body. Tedy ona detekovaná tečka daného
rozměru vznikla slitím popisků nebo se tečka zvětšila, protože se
slila s popiskem. Tedy takovéto body nejsou ve skutečnosti adresní
body.

Nová verze beta 4 s drobnými úpravami:

a) takovéto body označuje [CHECK][OVERLAP][NOT POINT] (kvůli možnosti
kontroly, pokud se potvrdí správná funkce programu, tak je může
program klidně zcela vynechávat)

b) spouští vlákna s menší prioritou, aby program mohl běžet na pozadí,
aniž by to výrazně zpomalovalo ostatní programy

c) vynechává prázdné dlaždice 4000x4000 ještě před rozbalením bitmapy
v paměti (kontroluje velikost a CRC32 souboru)

d) odděluje možnosti v případě nejednoznačnosti svislítkem, tedy místo
?[č.p.bez č.p./č.e.]
je
?[č.p.|bez č.p./č.e.]

e) v logu formátuje souřadnice (lon, lat) stejně jako v csv kvůli
snadném dohledávání

http://jabi.aspone.cz/osm/OcrBeta4.zip

Honza


2010/2/14 Jan Bilak :
> Máš pravdu, hledal jsem to nějak špatně - mám to v logách... Omlouvám se.
>
> Honza
>
>
> 2010/2/14 Petr Dlouhý :
>> Ahoj,
>>
>> právě že to nastává u těch dat z Prahy-západ (generoval jsem to ale sám),
>> například:
>>
>> 50.1673801,14.3893938,[OVERLAP]
>> 50.1025125,14.4268763,[OVERLAP]
>> 50.1025113,14.4268763,[OVERLAP]
>> 50.0950088,14.3479638,[OVERLAP]
>> 50.0950088,14.3479650,[OVERLAP]
>>
>> S tím GC není problém, že by vůbec nefungoval - problém je s tím, že
>> najednou přestane fungovat (po delší době bezproblémového výpočtu).
>> Souhlasím ale, že zapnutí GC asi nemá velký vliv na výkon, takže to
>> nemusíš řešit.
>>
>> On Sun, 14 Feb 2010 23:30:56 +0100, Jan Bilak 
>> wrote:
>>
>>> Ahoj,
>>> pokud máš někde po ruce csv výpis (kde jsou souřadnice těch chyb s
>>> mezerami), tam mi jej prosím pošli. Kouknul bych se, proč to nastává a
>>> co se s tím dá dělat. Může to způsobovat i nějaké méně viditelné
>>> chyby. U těch dat Prahy, které jsi mne poslal, se toto nestalo.
>>> S tím GC to volat třeba po 100 mapkách asi nemá smysl, protože každá
>>> bitmapa v paměti zabere asi 50 MB (4000x4000 px a v RGB 3 byte na
>>> pixel) a k tomu ještě další pomocné struktury ... celé se to musí
>>> násobit počtem vláken ... tedy alokuje se tam velké množství paměti.
>>> Ale ten rozdíl časů nemusí být velký, protože i při standardním
>>> chování se musí GC volat celkem často.
>>
>>
>> --
>> Petr Dlouhý
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Import adres z katastralni mapy

[Jan Bilak]

Máš pravdu, hledal jsem to nějak špatně - mám to v logách... Omlouvám se.

Honza


2010/2/14 Petr Dlouhý :
> Ahoj,
>
> právě že to nastává u těch dat z Prahy-západ (generoval jsem to ale sám),
> například:
>
> 50.1673801,14.3893938,[OVERLAP]
> 50.1025125,14.4268763,[OVERLAP]
> 50.1025113,14.4268763,[OVERLAP]
> 50.0950088,14.3479638,[OVERLAP]
> 50.0950088,14.3479650,[OVERLAP]
>
> S tím GC není problém, že by vůbec nefungoval - problém je s tím, že
> najednou přestane fungovat (po delší době bezproblémového výpočtu).
> Souhlasím ale, že zapnutí GC asi nemá velký vliv na výkon, takže to
> nemusíš řešit.
>
> On Sun, 14 Feb 2010 23:30:56 +0100, Jan Bilak 
> wrote:
>
>> Ahoj,
>> pokud máš někde po ruce csv výpis (kde jsou souřadnice těch chyb s
>> mezerami), tam mi jej prosím pošli. Kouknul bych se, proč to nastává a
>> co se s tím dá dělat. Může to způsobovat i nějaké méně viditelné
>> chyby. U těch dat Prahy, které jsi mne poslal, se toto nestalo.
>> S tím GC to volat třeba po 100 mapkách asi nemá smysl, protože každá
>> bitmapa v paměti zabere asi 50 MB (4000x4000 px a v RGB 3 byte na
>> pixel) a k tomu ještě další pomocné struktury ... celé se to musí
>> násobit počtem vláken ... tedy alokuje se tam velké množství paměti.
>> Ale ten rozdíl časů nemusí být velký, protože i při standardním
>> chování se musí GC volat celkem často.
>
>
> --
> Petr Dlouhý
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Import adres z katastralni mapy

[Jan Bilak]

Ahoj,

pokud máš někde po ruce csv výpis (kde jsou souřadnice těch chyb s
mezerami), tam mi jej prosím pošli. Kouknul bych se, proč to nastává a
co se s tím dá dělat. Může to způsobovat i nějaké méně viditelné
chyby. U těch dat Prahy, které jsi mne poslal, se toto nestalo.

S tím GC to volat třeba po 100 mapkách asi nemá smysl, protože každá
bitmapa v paměti zabere asi 50 MB (4000x4000 px a v RGB 3 byte na
pixel) a k tomu ještě další pomocné struktury ... celé se to musí
násobit počtem vláken ... tedy alokuje se tam velké množství paměti.
Ale ten rozdíl časů nemusí být velký, protože i při standardním
chování se musí GC volat celkem často.

Honza


2010/2/14 Petr Dlouhý :
> Ahoj,
>
> zatím jsem se na to zběžně podíval. Jediná chyba, kterou jsem našel je, že
> se několikrát detekovalo [OVERLAP] a řada mezer bez jakéhokoliv textu.
> Uzlů s [CHECK][OVERLAP] jsem našel na třetině okresu 8, a to ještě ve
> všech případech  kromě jednoho byl řetězec správně (kromě mezer na konci).
>
> Jinak s tím garbage collectorem to funguje, nezkoušel jsem kolik to
> zpomaluje, ale jestli myslíš že se to projeví, tak by ho možná šlo volat
> jen jednou za 100 dlaždic (nebo něco takového). Asi je v Monu nějaká chyba
> a GC najednou přestane automaticky fungovat.
>
> On Sun, 14 Feb 2010 18:40:26 +0100, Jan Bilak 
> wrote:
>
>> Ahoj,
>> mas k tomu jeste nejake zasadni postrehy (co je treba upravit)? Tedy
>> krome toho, ze ti to zacne plnit pamet, protoze to se mi nepodarilo
>> nasimulovat a ani nemam zadny napad, cim by to mohlo byt.
>> Honza
>
>
> --
> Petr Dlouhý
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Import adres z katastralni mapy

[Jan Bilak]

Ahoj,

mas k tomu jeste nejake zasadni postrehy (co je treba upravit)? Tedy
krome toho, ze ti to zacne plnit pamet, protoze to se mi nepodarilo
nasimulovat a ani nemam zadny napad, cim by to mohlo byt.

Honza



2010/2/13 Jan Bilak :
> Tady jsou výsledná *.csv a logy z tvých dat Prahy:
> http://www.flyshare.cz/stahni/46207/praha.zip
>
> Zpracovával jsem to po 5 částech - jsou očíslovány stejně *.csv a logy
> (stejná čísla patří k sobě).
>
> Honza
>
>
>
> 2010/2/13 Jan Bilak :
>> Projel jsem všechny dlaždice, které jsi mi poslal. Na problém jsem
>> nenarazil. Možné je to specifické chování Mona - já to dělám pod
>> .NETem (třeba vím, že pod Monem mi aplikace vždycky padala, když jsem
>> přistupoval ke konzoli z více vláken, zato .NET to automaticky
>> synchronizoval apod.). Nevím - těžko se ladí něco, co se mi
>> neprojevuje.
>>
>> Zdrojáky jsou tady:
>> http://jabi.aspone.cz/osm/FindAddressPoints-beta3-src.zip
>>
>> Pokud by se problém nepodařilo odstranit, tak je možné to dělat pod
>> Windows. Zase tak dlouho to myslím netrvá, aby byla třeba dělat akce
>> na způsob s...@home.
>>
>> Honza
>>
>>
>> 2010/2/13 Jan Bilak :
>>> Dal jsem tam novou verzi beta3 (na stejné místo). Má navíc parametr
>>> -gc, kterým lze zařídit zavolání Garbace Collectoru po zpracování
>>> každé dlaždice. Tím se výrazně sníží paměťové nároky, ale za cenu
>>> nějakého snížení rychlosti.
>>>
>>> Zkus to prosím.
>>>
>>> Mne to ve Windows žere bez -gc spičkově tak 650 MB, s -gc tak 250 MB.
>>> To při použití dvou vláken. Jinak jsem zatím po zpracování dalších
>>> dlaždic z Prahy problém nenarazil.
>>>
>>> Honza
>>>
>>>
>>>
>>> 2010/2/13 Petr Dlouhý :
>>>> Ahoj,
>>>>
>>>> je tam stále ten problém s pamětí. Když jsem zkoušel adresář pz1, tak to
>>>> po nějaké době začne náhle konzumovat velké množství paměti (zabere mi to
>>>> cca 1,7 GB paměti +  0,5 GB swapu). Není to způsobené programem samotným
>>>> (dlouhou dobu se paměť téměř nezabírá), ale ani jednotlivou dlaždicí
>>>> (během finále se stále ještě dlaždice mění).
>>>>
>>>> On Sat, 13 Feb 2010 18:10:37 +0100, Jan Bilak 
>>>> wrote:
>>>>
>>>>> Ještě jsem tam hodil malinko opravenou betu3 (na stejné místo) -
>>>>> oprava "padání".
>>>>> Honza
>>>>
>>>>
>>>> --
>>>> Petr Dlouhý
>>>>
>>>> ___
>>>> Talk-cz mailing list
>>>> Talk-cz@openstreetmap.org
>>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>>
>>>
>>
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Tracer na rozpoznání budov z katastr . map

[Jan Bilak]

Ahoj,

kdyz nepouzivam zadnou fotomapu, tak pouzivam kn neinvertovanou a s
citelnosti nemam problem. Invertovana je citelna take, ale tohle mi
vyhovuje vice (asi otazka zvyku). To vse s defaultnim barevnych
schematem. S jinym barevnych schematek bude citelnost uplne jina.

Idealni by bylo z WMS ziskavat seznam dostupnych vrstev a jinych
nastaveni a toto poskytnout formou dialogu. Ale nemuzu rict, ze by to
nejak chybelo.

Honza


2010/2/14 hanoj :
>> ten seznam předvoleb pro WMS plugin je na [1], ale taky si nejsem jist, že
>> dobrý nápad tam dávat tu inverzní barvu. Sice jsem to nezkoušel, ale řekl
>> bych, že to bude špatně vidět nad Yahoo/UHUL ortofotomapou. Na druhou
>> stranu opravdu není dobře, že to v defaultu není vidět.
>> Možná by bylo lepší změnit defaultní pozadí, já používám šedivou.
>
> Kdyz si udelam tabulky citelnosti kombinovanych vrstev:
>
> vrstva; samotna; s uhul; s cenia;
> kn;      ne; horsi; ano;
> kn-i;    ano; ano; ano;
>
> mate jine prakticke zkusenosti?
>
>
> hanoj
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Tracer na rozpoznání budov z katastr . map

[Jan Bilak]

Ahoj,

díky za vypracování stručného návodu. Ale ten odkaz bych nenahrazoval.
Možná přidal jako alternativu. Ne vždy je inverzní provedení vhodné.

Honza


2010/2/14 hanoj :
>> Dal jsem tam odkaz na server a zdrojové soubory bety 2. Bylo by dobré tam
>> dát nějaké stálé odkazy - nejlepší by asi bylo nahrát Tracer server někam
>> na svn.openstreetmap.org (například Francouzi by si ho mohli upravit pro
>> svoji katastrální mapu).
>>
>> [1] http://wiki.openstreetmap.org/wiki/Cz:JOSM/Plugins/Tracer
>
> *** dopisuji neco do tohoto navodu. Neumel by nekdo v JOSM zdrojacich
> upravit vlastnosti CUZK:KM vrstvy, kterou lze primo pridavat do
> WMSplugin menu tak aby namisto:
>
> LAYERS=kn,prehledky,def_budovy&
>
> bylo:
> LAYERS=kn-i,prehledky,def_budovy&
>
>
>
> zacinajiciho uzivatele musi prekvapit, ze na cernem pozadi JOSM je
> cerna kresba KN...
>
> diky
>
> hanoj
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Import adres z katastralni mapy

[Jan Bilak]

Tady jsou výsledná *.csv a logy z tvých dat Prahy:
http://www.flyshare.cz/stahni/46207/praha.zip

Zpracovával jsem to po 5 částech - jsou očíslovány stejně *.csv a logy
(stejná čísla patří k sobě).

Honza



2010/2/13 Jan Bilak :
> Projel jsem všechny dlaždice, které jsi mi poslal. Na problém jsem
> nenarazil. Možné je to specifické chování Mona - já to dělám pod
> .NETem (třeba vím, že pod Monem mi aplikace vždycky padala, když jsem
> přistupoval ke konzoli z více vláken, zato .NET to automaticky
> synchronizoval apod.). Nevím - těžko se ladí něco, co se mi
> neprojevuje.
>
> Zdrojáky jsou tady:
> http://jabi.aspone.cz/osm/FindAddressPoints-beta3-src.zip
>
> Pokud by se problém nepodařilo odstranit, tak je možné to dělat pod
> Windows. Zase tak dlouho to myslím netrvá, aby byla třeba dělat akce
> na způsob s...@home.
>
> Honza
>
>
> 2010/2/13 Jan Bilak :
>> Dal jsem tam novou verzi beta3 (na stejné místo). Má navíc parametr
>> -gc, kterým lze zařídit zavolání Garbace Collectoru po zpracování
>> každé dlaždice. Tím se výrazně sníží paměťové nároky, ale za cenu
>> nějakého snížení rychlosti.
>>
>> Zkus to prosím.
>>
>> Mne to ve Windows žere bez -gc spičkově tak 650 MB, s -gc tak 250 MB.
>> To při použití dvou vláken. Jinak jsem zatím po zpracování dalších
>> dlaždic z Prahy problém nenarazil.
>>
>> Honza
>>
>>
>>
>> 2010/2/13 Petr Dlouhý :
>>> Ahoj,
>>>
>>> je tam stále ten problém s pamětí. Když jsem zkoušel adresář pz1, tak to
>>> po nějaké době začne náhle konzumovat velké množství paměti (zabere mi to
>>> cca 1,7 GB paměti +  0,5 GB swapu). Není to způsobené programem samotným
>>> (dlouhou dobu se paměť téměř nezabírá), ale ani jednotlivou dlaždicí
>>> (během finále se stále ještě dlaždice mění).
>>>
>>> On Sat, 13 Feb 2010 18:10:37 +0100, Jan Bilak 
>>> wrote:
>>>
>>>> Ještě jsem tam hodil malinko opravenou betu3 (na stejné místo) -
>>>> oprava "padání".
>>>> Honza
>>>
>>>
>>> --
>>> Petr Dlouhý
>>>
>>> ___
>>> Talk-cz mailing list
>>> Talk-cz@openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>
>>
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Import adres z katastralni mapy

[Jan Bilak]

Projel jsem všechny dlaždice, které jsi mi poslal. Na problém jsem
nenarazil. Možné je to specifické chování Mona - já to dělám pod
.NETem (třeba vím, že pod Monem mi aplikace vždycky padala, když jsem
přistupoval ke konzoli z více vláken, zato .NET to automaticky
synchronizoval apod.). Nevím - těžko se ladí něco, co se mi
neprojevuje.

Zdrojáky jsou tady:
http://jabi.aspone.cz/osm/FindAddressPoints-beta3-src.zip

Pokud by se problém nepodařilo odstranit, tak je možné to dělat pod
Windows. Zase tak dlouho to myslím netrvá, aby byla třeba dělat akce
na způsob s...@home.

Honza


2010/2/13 Jan Bilak :
> Dal jsem tam novou verzi beta3 (na stejné místo). Má navíc parametr
> -gc, kterým lze zařídit zavolání Garbace Collectoru po zpracování
> každé dlaždice. Tím se výrazně sníží paměťové nároky, ale za cenu
> nějakého snížení rychlosti.
>
> Zkus to prosím.
>
> Mne to ve Windows žere bez -gc spičkově tak 650 MB, s -gc tak 250 MB.
> To při použití dvou vláken. Jinak jsem zatím po zpracování dalších
> dlaždic z Prahy problém nenarazil.
>
> Honza
>
>
>
> 2010/2/13 Petr Dlouhý :
>> Ahoj,
>>
>> je tam stále ten problém s pamětí. Když jsem zkoušel adresář pz1, tak to
>> po nějaké době začne náhle konzumovat velké množství paměti (zabere mi to
>> cca 1,7 GB paměti +  0,5 GB swapu). Není to způsobené programem samotným
>> (dlouhou dobu se paměť téměř nezabírá), ale ani jednotlivou dlaždicí
>> (během finále se stále ještě dlaždice mění).
>>
>> On Sat, 13 Feb 2010 18:10:37 +0100, Jan Bilak 
>> wrote:
>>
>>> Ještě jsem tam hodil malinko opravenou betu3 (na stejné místo) -
>>> oprava "padání".
>>> Honza
>>
>>
>> --
>> Petr Dlouhý
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Import adres z katastralni mapy

[Jan Bilak]

Dal jsem tam novou verzi beta3 (na stejné místo). Má navíc parametr
-gc, kterým lze zařídit zavolání Garbace Collectoru po zpracování
každé dlaždice. Tím se výrazně sníží paměťové nároky, ale za cenu
nějakého snížení rychlosti.

Zkus to prosím.

Mne to ve Windows žere bez -gc spičkově tak 650 MB, s -gc tak 250 MB.
To při použití dvou vláken. Jinak jsem zatím po zpracování dalších
dlaždic z Prahy problém nenarazil.

Honza



2010/2/13 Petr Dlouhý :
> Ahoj,
>
> je tam stále ten problém s pamětí. Když jsem zkoušel adresář pz1, tak to
> po nějaké době začne náhle konzumovat velké množství paměti (zabere mi to
> cca 1,7 GB paměti +  0,5 GB swapu). Není to způsobené programem samotným
> (dlouhou dobu se paměť téměř nezabírá), ale ani jednotlivou dlaždicí
> (během finále se stále ještě dlaždice mění).
>
> On Sat, 13 Feb 2010 18:10:37 +0100, Jan Bilak 
> wrote:
>
>> Ještě jsem tam hodil malinko opravenou betu3 (na stejné místo) -
>> oprava "padání".
>> Honza
>
>
> --
> Petr Dlouhý
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Import adres z katastralni mapy

[Jan Bilak]

Ahoj,
mne se stalo něco podobného, když jsem tam nechal v adresáři PNGčko,
které jsem generoval z původních PNG tak, že jsem tam doplňoval modré
tečky (kvůli hledání toho chybějícího bodu, který nakonec nechyběl).
Ale to mi spíše začalo strašně rychle plnit log.

Právě to zkouším na těch tvých datech Prahy ... ještě nejsem u konce.
Pravda je, že mám 4 GB RAM, takže 2,3 GB by mi systém možná přežil,
kdyby odswapoval všechno ostatní zkusím sledovat paměť. Lukáš tam
volal explicitně Garbage Collector tuším po zpracování každé dlaždice,
zkusím to tam případně vrátit - třeba pro to měl dobrý důvod (já to
odstranil jako zbytečně zdržující).

Jinak výsledky jsou podle mne velmi pěkné ... asi 9 bodů k ruční
kontrole z cca 3000 dlaždic a nějakých 5 bodů. A to je v Praze,
kde jsou překryvy častější než na venkově.

Honza


2010/2/13 Petr Dlouhý :
> Ahoj,
>
> je tam stále ten problém s pamětí. Když jsem zkoušel adresář pz1, tak to
> po nějaké době začne náhle konzumovat velké množství paměti (zabere mi to
> cca 1,7 GB paměti +  0,5 GB swapu). Není to způsobené programem samotným
> (dlouhou dobu se paměť téměř nezabírá), ale ani jednotlivou dlaždicí
> (během finále se stále ještě dlaždice mění).
>
> On Sat, 13 Feb 2010 18:10:37 +0100, Jan Bilak 
> wrote:
>
>> Ještě jsem tam hodil malinko opravenou betu3 (na stejné místo) -
>> oprava "padání".
>> Honza
>
>
> --
> Petr Dlouhý
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Import adres z katastralni mapy

[Jan Bilak]

Ještě jsem tam hodil malinko opravenou betu3 (na stejné místo) -
oprava "padání".

Honza


2010/2/13 Jan Bilak :
> Ahoj.
>
> Dal jsem tam betu 3 ... http://jabi.aspone.cz/osm/OcrBeta3.zip
>
> Pridava drive zminovanou podminku, ktera umoznuje detekovat, zda jde o
> jednoznacne rozpoznani nebo je treba rucni kontrola.
> Dale meni stavy rozpoznani:
> [CHECK] ... je treba rucni kontrola
> [OVERLAP] ... byl tam prekryv, ale melo by to byt jednoznacne (spise
> pro debug ucely a overeni programu)
>
> Doslo i ke zmene parametru programu:
>
> Command line options are:
>  -tiles [..]     (*) Path to downloaded tiles
>  -output [..]    (*) Output filename
>  -log [..]       Log filename
>  -all            Log all
>  -overlap        Log overlap
>  -threads [..]   Thread count
> (*) Required.
>
> Defaultni logovani pri uvedeni souboru logu je takove, ze se loguji
> jen CHECK body. Lze zapnout i overlap body nebo vsechny.
> Na Monu je asi problem s vicevlaknovym provozem (asi je treba jeste
> navic neco zamykat nebo tak neco), tak pribyl argument pro urceni
> poctu vlaken. Pri problemech nastavte na hodnotu 1.
>
> A dale cernou barvu povazuji za cervenou. Pokud s tim budou problemy,
> lze zvolit variantu s orezem a vetsim prekryvem nebo dynamicke
> stahovani zazoomovane oblasti (pracnejsi).
>
> Honza
>
>
>
> 2010/2/13 Petr Dlouhý :
>> Jedno upozornění - ta data jsem stahoval na třikrát, a potom to sesypal do
>> jednoho adresáře (v domnění, že se překrývající dlaždice požerou, což se
>> ale nestalo protože nejsou zaokrouhlovány stejně). V adresáři jsou tedy v
>> překrývajících oblastech shodné dlaždice akorát s posunem.
>>
>> Pokud bys chtěl jednotlivé dlaždice rozdělit do původních adresářů, tak na
>> [1] jsou seznamy souborů z jednotlivých původních adresářů.
>>
>> [1] http://www.flyshare.cz/stahni/46192/pz.tar.gz
>>
>> On Sat, 13 Feb 2010 02:07:28 +0100, Petr Dlouhý 
>> wrote:
>>
>>> Posílám testovací data (měl by to být celý okres Praha-západ) na [2].
>>
>>
>> --
>> Petr Dlouhý
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Tracer na rozpoznání budov z katastr . map

[Jan Bilak]

Tam jsou čáry souvislé (tedy až na výjimku, kde jsou křivě slepené dvě
mapy, které vůbec nepasují k sobě a to je tak ošklivá věc, že si
nedovedu představit její automatické řešení - je to častý případ?).

Honza


2010/2/13 Petr Dlouhý :
> Například tady:
> http://www.openstreetmap.org/?lat=50.03166&lon=14.49917&zoom=17
> ale jestli jinak v Praze stačí stáhnout nějakou oblast, ve které domy
> chybí, a většinou se trefíš.
>
> On Sat, 13 Feb 2010 16:31:49 +0100, Jan Bilak 
> wrote:
>
>> Můžeš poslat nějakou souřadnici, kde je typická ukázka těchto tenkých
>> čar?
>
>
> --
> Petr Dlouhý
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Import adres z katastralni mapy

[Jan Bilak]

Ahoj.

Dal jsem tam betu 3 ... http://jabi.aspone.cz/osm/OcrBeta3.zip

Pridava drive zminovanou podminku, ktera umoznuje detekovat, zda jde o
jednoznacne rozpoznani nebo je treba rucni kontrola.
Dale meni stavy rozpoznani:
[CHECK] ... je treba rucni kontrola
[OVERLAP] ... byl tam prekryv, ale melo by to byt jednoznacne (spise
pro debug ucely a overeni programu)

Doslo i ke zmene parametru programu:

Command line options are:
  -tiles [..] (*) Path to downloaded tiles
  -output [..](*) Output filename
  -log [..]   Log filename
  -allLog all
  -overlapLog overlap
  -threads [..]   Thread count
(*) Required.

Defaultni logovani pri uvedeni souboru logu je takove, ze se loguji
jen CHECK body. Lze zapnout i overlap body nebo vsechny.
Na Monu je asi problem s vicevlaknovym provozem (asi je treba jeste
navic neco zamykat nebo tak neco), tak pribyl argument pro urceni
poctu vlaken. Pri problemech nastavte na hodnotu 1.

A dale cernou barvu povazuji za cervenou. Pokud s tim budou problemy,
lze zvolit variantu s orezem a vetsim prekryvem nebo dynamicke
stahovani zazoomovane oblasti (pracnejsi).

Honza



2010/2/13 Petr Dlouhý :
> Jedno upozornění - ta data jsem stahoval na třikrát, a potom to sesypal do
> jednoho adresáře (v domnění, že se překrývající dlaždice požerou, což se
> ale nestalo protože nejsou zaokrouhlovány stejně). V adresáři jsou tedy v
> překrývajících oblastech shodné dlaždice akorát s posunem.
>
> Pokud bys chtěl jednotlivé dlaždice rozdělit do původních adresářů, tak na
> [1] jsou seznamy souborů z jednotlivých původních adresářů.
>
> [1] http://www.flyshare.cz/stahni/46192/pz.tar.gz
>
> On Sat, 13 Feb 2010 02:07:28 +0100, Petr Dlouhý 
> wrote:
>
>> Posílám testovací data (měl by to být celý okres Praha-západ) na [2].
>
>
> --
> Petr Dlouhý
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Tracer na rozpoznání budov z katastr . map

[Jan Bilak]

Ahoj,

popravdě mne zatím nenapadá nějaký vhodný algoritmus, který by na to
šel aplikovat. Ani jsem moc neprocházel katastrální mapu, takže nevím,
jak na jiných místech vypadá.

Pro slučky bych si dovedl představit něco, co bude detekovat dvě čáry,
které se skoro dotýkají, jsou téměř rovnoběžné a mezi nimi je řada
jiných divných úseků (obkroužující služku). Celé toto by se pak
nahradilo jednou čarou.

U floodfillu by sice šlo nějak detekovat, že jsem v díře ... na dvou
různých stranách je nějaký černý pixel, ale aby to bylo trochu
rozumné, tak by to chtělo domyslet konkrétní řešení.

Můžeš poslat nějakou souřadnici, kde je typická ukázka těchto tenkých čar?

Ještě dodělávám ten OCRovač, pak bych na to kouknul. Ale jak říkám,
zatím nemám konkrétní nápad...

Honza


2010/2/13 Petr Dlouhý :
> Ahoj,
>
> v Praze, například, už začínají docházet nezmapovaná KÚ, která jsou
> kreslená tlustými čarami. Zbylá území jsou kreslená čárami tenkými a na
> těch se Tracer moc nechytá, takže to dá výrazně víc práce.
>
> Nešlo by upravit Tracer server pro tenké čáry? Hlavní problémy jsou dva -
> slučky a díry v čarách.
> Slučky asi budou tvrdší oříšek, a asi jsou zatím důležitější věci na práci
> (například import adresních bodů).
> Díry by ale možná šly vyřešit jednodušeji. Nešlo by udělat, aby šlo
> nastavit, jak moc velkou dírou ten flood-fill proleze? V tlustých čarách
> je naopak problém s tím, že u některých garáží to občas neproleze kolem
> nápisu vedle kterého je úzká díra.
>
> On Sun, 07 Feb 2010 20:33:57 +0100, Petr Dlouhý 
> wrote:
>
>> Ono to funguje na tlustých čarách bez problému. Na některých místech je
>> ale KM kreslená tenkými čarami, a v nich jsou občas i díry - proto to
>> natrasuje ten pozemek okolo. Možná by stálo za to udělat nějakou
>> speciální
>> verzi pro tenké čáry (ale nevím jestli je to otázka úpravy konstant nebo
>> by to dalo spoustu práce).
>> To s tím, že to občas skončí tak, že místo kliknutí není v té budově je
>> ale určitě chyba.
>
>
> --
> Petr Dlouhý
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Import adres z katastralni mapy

[Jan Bilak]

OK, nic se nestalo. Hlavně, že se to vyjasnilo.

Honza

2010/2/13 Petr Dlouhý :
> Omlouvám se. To není chyba - Merge nevygeneruje pro "bez č.p./č.e." žádný 
> bod, takže je všechno v pořádku.
>
>
>>  Původní zpráva 
>> Od: Petr Dlouhý 
>> Předmět: Re: [Talk-cz] Import adres z katastralni mapy
>> Datum: 13.2.2010 03:02:22
>> 
>> Ahoj,
>>
>> 186 souhlasí, ty chybějící body jsou vždy "bez č.p./č.e.". Chybí například
>> bod pod č.p. 1 a 121 na souřadnicích 50,13254; 14,33821.
>>
>> On Sat, 13 Feb 2010 01:58:07 +0100, Jan Bilak 
>> wrote:
>>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Import adres z katastralni mapy

[Jan Bilak]

Ahoj,
díky, kouknu se na to, kde je problém.

Honza

2010/2/13 Petr Dlouhý :
> Ahoj,
>
> 186 souhlasí, ty chybějící body jsou vždy "bez č.p./č.e.". Chybí například
> bod pod č.p. 1 a 121 na souřadnicích 50,13254; 14,33821.
>
> On Sat, 13 Feb 2010 01:58:07 +0100, Jan Bilak 
> wrote:
>
>> Zkoušel jsem tu dlaždici
>> http://www.flyshare.cz/stahni/46186/14.3362_50.1291_14.3412_50.1341-budovy.png
>> a nenašel jsem žádný bod, který by to nedetekovalo. Nechal jsem si
>> udělat modrou tečku do původní bitmapy na každý detekovaný bod ... a
>> ruční kontrolou byly všechny omodřené a žádný červený nezbyl.
>> Prosím o jeden případ bodu (číslo popisné, souřadnici v pixelech nebo
>> tak něco), který se ti nedetekoval.
>> Do csv mi to napsalo 186 řádek. Tedy to našlo 186 bodů. Tobě také?
>> Honza
>
>
> --
> Petr Dlouhý
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Import adres z katastralni mapy

[Jan Bilak]

Zkoušel jsem tu dlaždici
http://www.flyshare.cz/stahni/46186/14.3362_50.1291_14.3412_50.1341-budovy.png
a nenašel jsem žádný bod, který by to nedetekovalo. Nechal jsem si
udělat modrou tečku do původní bitmapy na každý detekovaný bod ... a
ruční kontrolou byly všechny omodřené a žádný červený nezbyl.

Prosím o jeden případ bodu (číslo popisné, souřadnici v pixelech nebo
tak něco), který se ti nedetekoval.

Do csv mi to napsalo 186 řádek. Tedy to našlo 186 bodů. Tobě také?

Honza


2010/2/13 Petr Dlouhý :
> Aha, tak to jsem předtím nepochopil. V tom případě se ale u některých "bez
> č.p./č.e." detekují nějaké mezery nebo jiný bordel za nimi a možná jsem
> viděl i případ, kdy se nějaké číslo prodloužilo o číslice, které tam
> neměly být (pokusím se to najít).
>
> Dlaždice je na [1], je tam víc takových bodů, co se nedetekovali.
> Testovací data se pokusím nahrát, je toho kolem 200MB.
>
> [1]
> http://www.flyshare.cz/stahni/46186/14.3362_50.1291_14.3412_50.1341-budovy.png
>
> On Sat, 13 Feb 2010 01:10:29 +0100, Jan Bilak 
> wrote:
>
>> Ořez by mohl být nižší, ale já to každý sloupec reprezentuji
>> 16-bitovým číslem (16 řádek) a pak s tím dělám různé bitové operace.
>> Takže 15 by se mi nehodilo...
>> Tyhle nápady jsou dobré, ale nejsou třeba. Algoritmus totiž funguje
>> tak, že se snaží najít napřed přesnou shodu. A pokud přesná shoda
>> není, tak najít všechny možnosti, které tam mohou být. Pokud je více
>> možností, co by tam mohlo být, tak to do textu přidá ?. Pokud jedna
>> možnost, tak ji to bere jako správnou. A pokud žádá možnost, tak to
>> končí. Check je jen indikace toho, že tam nebyla přesná shoda. Otazník
>> je indikace toho, že to bylo mnohoznačné. Zatím tam tedy chybí jedna
>> kontrola, která teoreticky může způsobit chybu bez otázníku (jen s
>> checkem). Ale to opravím a pravděpodobnost takové chyby je velmi malá.
>> Testovací data by se mi hodila, pokud máš kam dát nějaký archiv
>> (klidně na nějaký free one-file hosting typu rapidshare - ale účet tam
>> nikde nemám, tak aby to bylo reálné stáhnout zdarma).
>> Honza
>
>
> --
> Petr Dlouhý
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Import adres z katastralni mapy

[Jan Bilak]

Ano, to prodloužení o něco bude řešit ta kontrola (už je celkem jedno,
zda prodloužení čísla nebo popisu "bez č.p./č.e.". Tedy alespoň jsem o
tom přesvědčen. Do vypořádání se s copyrightem a přidání té kontroly
to není zcela spolehlivé. Může to jak zkrátit číslo, tak prodloužit -
teoreticky i možná změnit.

Díky za příklad i data.

Honza


2010/2/13 Petr Dlouhý :
> Aha, tak to jsem předtím nepochopil. V tom případě se ale u některých "bez
> č.p./č.e." detekují nějaké mezery nebo jiný bordel za nimi a možná jsem
> viděl i případ, kdy se nějaké číslo prodloužilo o číslice, které tam
> neměly být (pokusím se to najít).
>
> Dlaždice je na [1], je tam víc takových bodů, co se nedetekovali.
> Testovací data se pokusím nahrát, je toho kolem 200MB.
>
> [1]
> http://www.flyshare.cz/stahni/46186/14.3362_50.1291_14.3412_50.1341-budovy.png
>
> On Sat, 13 Feb 2010 01:10:29 +0100, Jan Bilak 
> wrote:
>
>> Ořez by mohl být nižší, ale já to každý sloupec reprezentuji
>> 16-bitovým číslem (16 řádek) a pak s tím dělám různé bitové operace.
>> Takže 15 by se mi nehodilo...
>> Tyhle nápady jsou dobré, ale nejsou třeba. Algoritmus totiž funguje
>> tak, že se snaží najít napřed přesnou shodu. A pokud přesná shoda
>> není, tak najít všechny možnosti, které tam mohou být. Pokud je více
>> možností, co by tam mohlo být, tak to do textu přidá ?. Pokud jedna
>> možnost, tak ji to bere jako správnou. A pokud žádá možnost, tak to
>> končí. Check je jen indikace toho, že tam nebyla přesná shoda. Otazník
>> je indikace toho, že to bylo mnohoznačné. Zatím tam tedy chybí jedna
>> kontrola, která teoreticky může způsobit chybu bez otázníku (jen s
>> checkem). Ale to opravím a pravděpodobnost takové chyby je velmi malá.
>> Testovací data by se mi hodila, pokud máš kam dát nějaký archiv
>> (klidně na nějaký free one-file hosting typu rapidshare - ale účet tam
>> nikde nemám, tak aby to bylo reálné stáhnout zdarma).
>> Honza
>
>
> --
> Petr Dlouhý
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Import adres z katastralni mapy

[Jan Bilak]

Dal jsem tam betu 2 ... http://jabi.aspone.cz/osm/OcrBeta2.zip

Je vícevláknová, trochu přepracovaný výpis do konzole (časový odhad do
konce apod.).
+ zapisuje do csv souboru info o tom, že bod je moc blízko kraje dlaždice.

Honza

2010/2/13 Jan Bilak :
> Ořez by mohl být nižší, ale já to každý sloupec reprezentuji
> 16-bitovým číslem (16 řádek) a pak s tím dělám různé bitové operace.
> Takže 15 by se mi nehodilo...
>
> Tyhle nápady jsou dobré, ale nejsou třeba. Algoritmus totiž funguje
> tak, že se snaží najít napřed přesnou shodu. A pokud přesná shoda
> není, tak najít všechny možnosti, které tam mohou být. Pokud je více
> možností, co by tam mohlo být, tak to do textu přidá ?. Pokud jedna
> možnost, tak ji to bere jako správnou. A pokud žádá možnost, tak to
> končí. Check je jen indikace toho, že tam nebyla přesná shoda. Otazník
> je indikace toho, že to bylo mnohoznačné. Zatím tam tedy chybí jedna
> kontrola, která teoreticky může způsobit chybu bez otázníku (jen s
> checkem). Ale to opravím a pravděpodobnost takové chyby je velmi malá.
>
> Testovací data by se mi hodila, pokud máš kam dát nějaký archiv
> (klidně na nějaký free one-file hosting typu rapidshare - ale účet tam
> nikde nemám, tak aby to bylo reálné stáhnout zdarma).
>
> Honza
>
>
> 2010/2/13 Petr Dlouhý :
>> Ahoj,
>>
>> teprv teď jsem si všiml toho krásného logu. Ořez by mohl být o 1 pixel
>> nižší a o něco užší (nevím ale kolikaciferná je nejdelší adresa).
>> Další nápady na snížení množství [CHECK] jsou:
>>        Pokud adresa začíná na "bez č.p./č.e." tak není nutné dávat [CHECK], 
>> ale
>> stačí oříznout zbytek řetězce (tím se vyřadí tak polovina případů).
>>        Pokud je tam navíc pouze pár bodů nižších než číslice/písmeno, 
>> nemohou ji
>> tvořit, a tudíž není nutné dávat [CHECK], protože se tam nemohl připlést
>> nějaký další adresný bod, který by musel začínat na č nebo b.
>>
>> Pro vypořádání s copyrightem existuje ještě možnost d) - pokud si skript 
>> není jist výsledkem, tak si stáhne zazoomované číslo, takže mu muže být 
>> copyright jedno.
>> Spolehlivé to není hlavně v místech, kde je několik adres v jednom shluku 
>> (poměrně blízko sebe).
>>
>> Kontroluju to tak, že si vygeneruju adresní body pomocí Merge skriptu a
>> otevřu to v JOSM.
>>
>> PS. Jestli pořád sháníš testovací data, můžu ti poslat celou prahu-západ, 
>> myslel jsem, že už jsem jí smazal, ale není tomu tak.
>>
>>>  Původní zpráva 
>>> Od: Petr Dlouhý 
>>> Předmět: Re: [Talk-cz] Import adres z katastralni mapy
>>> Datum: 13.2.2010 00:29:16
>>> 
>>> Ahoj,
>>>
>>> ten copyright je jen úplně nahoře na každé dlaždici, nebo se pletu? Pokud
>>> tomu tak je, tak bych volil možnost a), protože je to minimum z velikosti
>>> dlaždice, a ty se už stejně stahují s přesahem (kvůli tomu, že se čísla
>>> kreslí jen na dlaždici s tečkou).
>>>
>>> Jinak jsem se koukal na ten skript, a zdá se to velice dobré. Myslím, že
>>> by stálo za to to přepočítat, vzhledem k tomu, že je to tak 20x rychlejší,
>>> tak to asi nebude problém udělat na jednou počítači.
>>>
>>> Chyby vidím následující:
>>>
>>> -Některé adresní body nejsou vůbec detekovány, a u některých je prázdný
>>> text (přestože jsou daleko od všeho).
>>> -Často se objevuje [CHECK] i u bodů, které byly detekovány správně. Pokud
>>> je to v případech, kdy se čísla už skutečně překrývají, tak OK. Jenom se
>>> ptám, jestli není možné zvolit agresivnější ořez před detekcí (pozor na
>>> jiné posunutí č.e. vs č.p.).
>>> -V případech, kdy se objeví [CHECK], tak by asi skript měl stáhnout číslo
>>> ve vyšším rozlišení a detekovat to.
>>>
>>>
>>> On Fri, 12 Feb 2010 22:05:40 +0100, Jan Bilak 
>>> wrote:
>>>
>>> > Zkousel jsem to na jednom kousku (cca 300 dlazdic) z centra Prahy.
>>> > Prehryvy tomu prakticky vubec nevadi a detekuje rozpozna to spravne.
>>> > Ale co tomu vadi, to je ten copyright. Zatím totiž beru v úvahu pouze
>>> > červenou barvu. Jsou 3 možnosti jak to řešit:
>>> >
>>> > a) stahovat dlaždice s překryvem tak, že se bude rozpoznávat pouze z
>>> > těch částí mapy, které copyright není. Výhody: Nejlepší výsledky.
>>> > Nevýhody: Nutnost stahovat více dat z WMS.
>>> >
>>> > b) považovat černou barvu za červenou. Výhody: Nejsou nutné úpravy
>>> > downloaderu, u rozpoznávače jen triviální změna 3 konstant. Nevýhody:
>>

Re: [Talk-cz] Import adres z katastralni mapy

[Jan Bilak]

Ořez by mohl být nižší, ale já to každý sloupec reprezentuji
16-bitovým číslem (16 řádek) a pak s tím dělám různé bitové operace.
Takže 15 by se mi nehodilo...

Tyhle nápady jsou dobré, ale nejsou třeba. Algoritmus totiž funguje
tak, že se snaží najít napřed přesnou shodu. A pokud přesná shoda
není, tak najít všechny možnosti, které tam mohou být. Pokud je více
možností, co by tam mohlo být, tak to do textu přidá ?. Pokud jedna
možnost, tak ji to bere jako správnou. A pokud žádá možnost, tak to
končí. Check je jen indikace toho, že tam nebyla přesná shoda. Otazník
je indikace toho, že to bylo mnohoznačné. Zatím tam tedy chybí jedna
kontrola, která teoreticky může způsobit chybu bez otázníku (jen s
checkem). Ale to opravím a pravděpodobnost takové chyby je velmi malá.

Testovací data by se mi hodila, pokud máš kam dát nějaký archiv
(klidně na nějaký free one-file hosting typu rapidshare - ale účet tam
nikde nemám, tak aby to bylo reálné stáhnout zdarma).

Honza


2010/2/13 Petr Dlouhý :
> Ahoj,
>
> teprv teď jsem si všiml toho krásného logu. Ořez by mohl být o 1 pixel
> nižší a o něco užší (nevím ale kolikaciferná je nejdelší adresa).
> Další nápady na snížení množství [CHECK] jsou:
>        Pokud adresa začíná na "bez č.p./č.e." tak není nutné dávat [CHECK], 
> ale
> stačí oříznout zbytek řetězce (tím se vyřadí tak polovina případů).
>        Pokud je tam navíc pouze pár bodů nižších než číslice/písmeno, nemohou 
> ji
> tvořit, a tudíž není nutné dávat [CHECK], protože se tam nemohl připlést
> nějaký další adresný bod, který by musel začínat na č nebo b.
>
> Pro vypořádání s copyrightem existuje ještě možnost d) - pokud si skript není 
> jist výsledkem, tak si stáhne zazoomované číslo, takže mu muže být copyright 
> jedno.
> Spolehlivé to není hlavně v místech, kde je několik adres v jednom shluku 
> (poměrně blízko sebe).
>
> Kontroluju to tak, že si vygeneruju adresní body pomocí Merge skriptu a
> otevřu to v JOSM.
>
> PS. Jestli pořád sháníš testovací data, můžu ti poslat celou prahu-západ, 
> myslel jsem, že už jsem jí smazal, ale není tomu tak.
>
>>  Původní zpráva 
>> Od: Petr Dlouhý 
>> Předmět: Re: [Talk-cz] Import adres z katastralni mapy
>> Datum: 13.2.2010 00:29:16
>> 
>> Ahoj,
>>
>> ten copyright je jen úplně nahoře na každé dlaždici, nebo se pletu? Pokud
>> tomu tak je, tak bych volil možnost a), protože je to minimum z velikosti
>> dlaždice, a ty se už stejně stahují s přesahem (kvůli tomu, že se čísla
>> kreslí jen na dlaždici s tečkou).
>>
>> Jinak jsem se koukal na ten skript, a zdá se to velice dobré. Myslím, že
>> by stálo za to to přepočítat, vzhledem k tomu, že je to tak 20x rychlejší,
>> tak to asi nebude problém udělat na jednou počítači.
>>
>> Chyby vidím následující:
>>
>> -Některé adresní body nejsou vůbec detekovány, a u některých je prázdný
>> text (přestože jsou daleko od všeho).
>> -Často se objevuje [CHECK] i u bodů, které byly detekovány správně. Pokud
>> je to v případech, kdy se čísla už skutečně překrývají, tak OK. Jenom se
>> ptám, jestli není možné zvolit agresivnější ořez před detekcí (pozor na
>> jiné posunutí č.e. vs č.p.).
>> -V případech, kdy se objeví [CHECK], tak by asi skript měl stáhnout číslo
>> ve vyšším rozlišení a detekovat to.
>>
>>
>> On Fri, 12 Feb 2010 22:05:40 +0100, Jan Bilak 
>> wrote:
>>
>> > Zkousel jsem to na jednom kousku (cca 300 dlazdic) z centra Prahy.
>> > Prehryvy tomu prakticky vubec nevadi a detekuje rozpozna to spravne.
>> > Ale co tomu vadi, to je ten copyright. Zatím totiž beru v úvahu pouze
>> > červenou barvu. Jsou 3 možnosti jak to řešit:
>> >
>> > a) stahovat dlaždice s překryvem tak, že se bude rozpoznávat pouze z
>> > těch částí mapy, které copyright není. Výhody: Nejlepší výsledky.
>> > Nevýhody: Nutnost stahovat více dat z WMS.
>> >
>> > b) považovat černou barvu za červenou. Výhody: Nejsou nutné úpravy
>> > downloaderu, u rozpoznávače jen triviální změna 3 konstant. Nevýhody:
>> > Drobné zhoršení rozpoznávání v případě překryvu copyrightu s popiskem
>> > - pokud se to nešikovně trefí, tak bude třeba ruční rozpoznání, ale
>> > nemusí to znamenat nic, i když se to trefí.
>> >
>> > c) Provádět ruční kontrolu všech popisků s překryvem (těch může být
>> > hodně).
>> >
>> > Osobně považuji c) za špatné řešení. A mezi a) a b) nemám vyhrazený
>> > názor. Možnost a) je sice teoreticky nejlepší, ale b) nemusí mít
>> > postřehnutelně horší výsledky.
>> >
>> > Honza
>> >
>> >
>> &

Re: [Talk-cz] Import adres z katastralni mapy

[Jan Bilak]

Ty body, které nemají rozpoznané popisky, jsou myslím příliš u kraje.
Tedy nyní tam mám nějaký tvrdý limit podle vzdálenosti bodu od kraje
(tuším 120px od pravého okraje, a cca 20 od horního). Na ploše, kde to
má rozpoznávat, je třeba se dohodnout. Pokud máš nějaký případ, který
není takto blízko kraje, tak mi prosím pošli dlaždici. Přidám tamk
takovým bodům zatím popisek [out-of-box] do csv souboru.

A ocením i zaslání dlaždice, kde bod nebyl nalezen vůbec.


Honza


2010/2/13 Jan Bilak :
> Jinak ... když si povolíš logování, tak se loguje i grafická
> reprezentace toho textu, takže tam uvidíš, co a jak to rozpoznává.
>
> Honza
>
>
> 2010/2/13 Jan Bilak :
>> Ahoj,
>> ten copyright je vlevo nahoře, ale pak i na souřadnici cca [530,510] px.
>>
>> Ta detekce bodů ... toho jsem si nevšiml. Jak to kontroluješ?
>>
>> Check ... to značí opravdu i nepatrný překryv. Pokud si to není jisté,
>> tak je tam znak otazník a v hranatých závorkách seznam možností. Ještě
>> tam dám jednu kontrolu a mělo byt o být myslím 100% spolehlivé, když
>> tam nebude žádný červený bod chybět (tedy je třeba použít možnost a)
>> nebo b) vypořádání se s copyrightem).
>>
>> Ořez před detekcí nedělám ... detekce si sama řídí, kdy skončit.
>>
>> Check by nemělo být nic, co by bylo třeba ručně kontrolovat - až se
>> vyřeší ten copyright a přidám tam tu jednu drobnou kontrolu. Těch
>> možností, kdy se tam objeví otazník (není si to jisté) je myslím
>> minimum. Zatím se mi to nestalo.
>>
>> Honza
>>
>>
>> 2010/2/13 Petr Dlouhý :
>>> Ahoj,
>>>
>>> ten copyright je jen úplně nahoře na každé dlaždici, nebo se pletu? Pokud
>>> tomu tak je, tak bych volil možnost a), protože je to minimum z velikosti
>>> dlaždice, a ty se už stejně stahují s přesahem (kvůli tomu, že se čísla
>>> kreslí jen na dlaždici s tečkou).
>>>
>>> Jinak jsem se koukal na ten skript, a zdá se to velice dobré. Myslím, že
>>> by stálo za to to přepočítat, vzhledem k tomu, že je to tak 20x rychlejší,
>>> tak to asi nebude problém udělat na jednou počítači.
>>>
>>> Chyby vidím následující:
>>>
>>> -Některé adresní body nejsou vůbec detekovány, a u některých je prázdný
>>> text (přestože jsou daleko od všeho).
>>> -Často se objevuje [CHECK] i u bodů, které byly detekovány správně. Pokud
>>> je to v případech, kdy se čísla už skutečně překrývají, tak OK. Jenom se
>>> ptám, jestli není možné zvolit agresivnější ořez před detekcí (pozor na
>>> jiné posunutí č.e. vs č.p.).
>>> -V případech, kdy se objeví [CHECK], tak by asi skript měl stáhnout číslo
>>> ve vyšším rozlišení a detekovat to.
>>>
>>>
>>> On Fri, 12 Feb 2010 22:05:40 +0100, Jan Bilak 
>>> wrote:
>>>
>>>> Zkousel jsem to na jednom kousku (cca 300 dlazdic) z centra Prahy.
>>>> Prehryvy tomu prakticky vubec nevadi a detekuje rozpozna to spravne.
>>>> Ale co tomu vadi, to je ten copyright. Zatím totiž beru v úvahu pouze
>>>> červenou barvu. Jsou 3 možnosti jak to řešit:
>>>>
>>>> a) stahovat dlaždice s překryvem tak, že se bude rozpoznávat pouze z
>>>> těch částí mapy, které copyright není. Výhody: Nejlepší výsledky.
>>>> Nevýhody: Nutnost stahovat více dat z WMS.
>>>>
>>>> b) považovat černou barvu za červenou. Výhody: Nejsou nutné úpravy
>>>> downloaderu, u rozpoznávače jen triviální změna 3 konstant. Nevýhody:
>>>> Drobné zhoršení rozpoznávání v případě překryvu copyrightu s popiskem
>>>> - pokud se to nešikovně trefí, tak bude třeba ruční rozpoznání, ale
>>>> nemusí to znamenat nic, i když se to trefí.
>>>>
>>>> c) Provádět ruční kontrolu všech popisků s překryvem (těch může být
>>>> hodně).
>>>>
>>>> Osobně považuji c) za špatné řešení. A mezi a) a b) nemám vyhrazený
>>>> názor. Možnost a) je sice teoreticky nejlepší, ale b) nemusí mít
>>>> postřehnutelně horší výsledky.
>>>>
>>>> Honza
>>>>
>>>>
>>>>
>>>> 2010/2/12 Jan Bilak :
>>>>> Doplnil jsem tam chybějící číslici 4.
>>>>>
>>>>> Honza
>>>>>
>>>>> 2010/2/12 Jan Bilak :
>>>>>> K vyzkoušení:
>>>>>> http://jabi.aspone.cz/osm/OcrBeta1.zip
>>>>>>
>>>>>> Má to stejné ovládání jako původní tile-processor, ale navíc možnost
>>>>>> logování:
>>>>>>
>>>>>> FindAddressPoints.exe 

Re: [Talk-cz] Import adres z katastralni mapy

[Jan Bilak]

Jinak ... když si povolíš logování, tak se loguje i grafická
reprezentace toho textu, takže tam uvidíš, co a jak to rozpoznává.

Honza


2010/2/13 Jan Bilak :
> Ahoj,
> ten copyright je vlevo nahoře, ale pak i na souřadnici cca [530,510] px.
>
> Ta detekce bodů ... toho jsem si nevšiml. Jak to kontroluješ?
>
> Check ... to značí opravdu i nepatrný překryv. Pokud si to není jisté,
> tak je tam znak otazník a v hranatých závorkách seznam možností. Ještě
> tam dám jednu kontrolu a mělo byt o být myslím 100% spolehlivé, když
> tam nebude žádný červený bod chybět (tedy je třeba použít možnost a)
> nebo b) vypořádání se s copyrightem).
>
> Ořez před detekcí nedělám ... detekce si sama řídí, kdy skončit.
>
> Check by nemělo být nic, co by bylo třeba ručně kontrolovat - až se
> vyřeší ten copyright a přidám tam tu jednu drobnou kontrolu. Těch
> možností, kdy se tam objeví otazník (není si to jisté) je myslím
> minimum. Zatím se mi to nestalo.
>
> Honza
>
>
> 2010/2/13 Petr Dlouhý :
>> Ahoj,
>>
>> ten copyright je jen úplně nahoře na každé dlaždici, nebo se pletu? Pokud
>> tomu tak je, tak bych volil možnost a), protože je to minimum z velikosti
>> dlaždice, a ty se už stejně stahují s přesahem (kvůli tomu, že se čísla
>> kreslí jen na dlaždici s tečkou).
>>
>> Jinak jsem se koukal na ten skript, a zdá se to velice dobré. Myslím, že
>> by stálo za to to přepočítat, vzhledem k tomu, že je to tak 20x rychlejší,
>> tak to asi nebude problém udělat na jednou počítači.
>>
>> Chyby vidím následující:
>>
>> -Některé adresní body nejsou vůbec detekovány, a u některých je prázdný
>> text (přestože jsou daleko od všeho).
>> -Často se objevuje [CHECK] i u bodů, které byly detekovány správně. Pokud
>> je to v případech, kdy se čísla už skutečně překrývají, tak OK. Jenom se
>> ptám, jestli není možné zvolit agresivnější ořez před detekcí (pozor na
>> jiné posunutí č.e. vs č.p.).
>> -V případech, kdy se objeví [CHECK], tak by asi skript měl stáhnout číslo
>> ve vyšším rozlišení a detekovat to.
>>
>>
>> On Fri, 12 Feb 2010 22:05:40 +0100, Jan Bilak 
>> wrote:
>>
>>> Zkousel jsem to na jednom kousku (cca 300 dlazdic) z centra Prahy.
>>> Prehryvy tomu prakticky vubec nevadi a detekuje rozpozna to spravne.
>>> Ale co tomu vadi, to je ten copyright. Zatím totiž beru v úvahu pouze
>>> červenou barvu. Jsou 3 možnosti jak to řešit:
>>>
>>> a) stahovat dlaždice s překryvem tak, že se bude rozpoznávat pouze z
>>> těch částí mapy, které copyright není. Výhody: Nejlepší výsledky.
>>> Nevýhody: Nutnost stahovat více dat z WMS.
>>>
>>> b) považovat černou barvu za červenou. Výhody: Nejsou nutné úpravy
>>> downloaderu, u rozpoznávače jen triviální změna 3 konstant. Nevýhody:
>>> Drobné zhoršení rozpoznávání v případě překryvu copyrightu s popiskem
>>> - pokud se to nešikovně trefí, tak bude třeba ruční rozpoznání, ale
>>> nemusí to znamenat nic, i když se to trefí.
>>>
>>> c) Provádět ruční kontrolu všech popisků s překryvem (těch může být
>>> hodně).
>>>
>>> Osobně považuji c) za špatné řešení. A mezi a) a b) nemám vyhrazený
>>> názor. Možnost a) je sice teoreticky nejlepší, ale b) nemusí mít
>>> postřehnutelně horší výsledky.
>>>
>>> Honza
>>>
>>>
>>>
>>> 2010/2/12 Jan Bilak :
>>>> Doplnil jsem tam chybějící číslici 4.
>>>>
>>>> Honza
>>>>
>>>> 2010/2/12 Jan Bilak :
>>>>> K vyzkoušení:
>>>>> http://jabi.aspone.cz/osm/OcrBeta1.zip
>>>>>
>>>>> Má to stejné ovládání jako původní tile-processor, ale navíc možnost
>>>>> logování:
>>>>>
>>>>> FindAddressPoints.exe -tiles test-dir-with-png-images -output test.csv
>>>>> -log log.txt -all
>>>>>
>>>>> -log log.txt ... pokud se toto uvede, tak program bude logovat
>>>>> nerozpoznané body nebo ty, které byly narušené překryvem.
>>>>>
>>>>> Pokud se uvede navíc -all, tak se budou logovat všechny body.
>>>>>
>>>>> Soubor charDef.txt obsahuje definici znaků nebo posloupnosti znaků. Je
>>>>> to také textový soubor, který když zobrazíte fontem s pevnou šířkou,
>>>>> tak je myslím význam jasný. Chybí tam číslice 4 posunutá dolů (tedy za
>>>>> č.o.), protože jsem na nic při pokusech nenarazil. Soubor musí být při
>>>>> spuštění v aktuálním adresáři.
>>>>>
>>>>> Honza
>>>>&g

Re: [Talk-cz] Import adres z katastralni mapy

[Jan Bilak]

Ahoj,
ten copyright je vlevo nahoře, ale pak i na souřadnici cca [530,510] px.

Ta detekce bodů ... toho jsem si nevšiml. Jak to kontroluješ?

Check ... to značí opravdu i nepatrný překryv. Pokud si to není jisté,
tak je tam znak otazník a v hranatých závorkách seznam možností. Ještě
tam dám jednu kontrolu a mělo byt o být myslím 100% spolehlivé, když
tam nebude žádný červený bod chybět (tedy je třeba použít možnost a)
nebo b) vypořádání se s copyrightem).

Ořez před detekcí nedělám ... detekce si sama řídí, kdy skončit.

Check by nemělo být nic, co by bylo třeba ručně kontrolovat - až se
vyřeší ten copyright a přidám tam tu jednu drobnou kontrolu. Těch
možností, kdy se tam objeví otazník (není si to jisté) je myslím
minimum. Zatím se mi to nestalo.

Honza


2010/2/13 Petr Dlouhý :
> Ahoj,
>
> ten copyright je jen úplně nahoře na každé dlaždici, nebo se pletu? Pokud
> tomu tak je, tak bych volil možnost a), protože je to minimum z velikosti
> dlaždice, a ty se už stejně stahují s přesahem (kvůli tomu, že se čísla
> kreslí jen na dlaždici s tečkou).
>
> Jinak jsem se koukal na ten skript, a zdá se to velice dobré. Myslím, že
> by stálo za to to přepočítat, vzhledem k tomu, že je to tak 20x rychlejší,
> tak to asi nebude problém udělat na jednou počítači.
>
> Chyby vidím následující:
>
> -Některé adresní body nejsou vůbec detekovány, a u některých je prázdný
> text (přestože jsou daleko od všeho).
> -Často se objevuje [CHECK] i u bodů, které byly detekovány správně. Pokud
> je to v případech, kdy se čísla už skutečně překrývají, tak OK. Jenom se
> ptám, jestli není možné zvolit agresivnější ořez před detekcí (pozor na
> jiné posunutí č.e. vs č.p.).
> -V případech, kdy se objeví [CHECK], tak by asi skript měl stáhnout číslo
> ve vyšším rozlišení a detekovat to.
>
>
> On Fri, 12 Feb 2010 22:05:40 +0100, Jan Bilak 
> wrote:
>
>> Zkousel jsem to na jednom kousku (cca 300 dlazdic) z centra Prahy.
>> Prehryvy tomu prakticky vubec nevadi a detekuje rozpozna to spravne.
>> Ale co tomu vadi, to je ten copyright. Zatím totiž beru v úvahu pouze
>> červenou barvu. Jsou 3 možnosti jak to řešit:
>>
>> a) stahovat dlaždice s překryvem tak, že se bude rozpoznávat pouze z
>> těch částí mapy, které copyright není. Výhody: Nejlepší výsledky.
>> Nevýhody: Nutnost stahovat více dat z WMS.
>>
>> b) považovat černou barvu za červenou. Výhody: Nejsou nutné úpravy
>> downloaderu, u rozpoznávače jen triviální změna 3 konstant. Nevýhody:
>> Drobné zhoršení rozpoznávání v případě překryvu copyrightu s popiskem
>> - pokud se to nešikovně trefí, tak bude třeba ruční rozpoznání, ale
>> nemusí to znamenat nic, i když se to trefí.
>>
>> c) Provádět ruční kontrolu všech popisků s překryvem (těch může být
>> hodně).
>>
>> Osobně považuji c) za špatné řešení. A mezi a) a b) nemám vyhrazený
>> názor. Možnost a) je sice teoreticky nejlepší, ale b) nemusí mít
>> postřehnutelně horší výsledky.
>>
>> Honza
>>
>>
>>
>> 2010/2/12 Jan Bilak :
>>> Doplnil jsem tam chybějící číslici 4.
>>>
>>> Honza
>>>
>>> 2010/2/12 Jan Bilak :
>>>> K vyzkoušení:
>>>> http://jabi.aspone.cz/osm/OcrBeta1.zip
>>>>
>>>> Má to stejné ovládání jako původní tile-processor, ale navíc možnost
>>>> logování:
>>>>
>>>> FindAddressPoints.exe -tiles test-dir-with-png-images -output test.csv
>>>> -log log.txt -all
>>>>
>>>> -log log.txt ... pokud se toto uvede, tak program bude logovat
>>>> nerozpoznané body nebo ty, které byly narušené překryvem.
>>>>
>>>> Pokud se uvede navíc -all, tak se budou logovat všechny body.
>>>>
>>>> Soubor charDef.txt obsahuje definici znaků nebo posloupnosti znaků. Je
>>>> to také textový soubor, který když zobrazíte fontem s pevnou šířkou,
>>>> tak je myslím význam jasný. Chybí tam číslice 4 posunutá dolů (tedy za
>>>> č.o.), protože jsem na nic při pokusech nenarazil. Soubor musí být při
>>>> spuštění v aktuálním adresáři.
>>>>
>>>> Honza
>>>>
>>>>
>>>> 2010/2/12 Jan Bilak :
>>>>> Na slušné detekci překryvů právě pracuji a myslím, že rozhodně bude
>>>>> výrazně lepší než byla (to už je myslím teď). Ale stoprocentní
>>>>> samozřejmě ne - když překryv bude velký, tak to určitě nepůjde.
>>>>>
>>>>> Ale jinak si myslím, že generování dlaždic na serveru KN bude nějakou
>>>>> dobu trvat - a to, ať je na té dlaždici 5 bodů nebo třeba jen jeden. A
>>>>> také jim to bude zatěžovat servery,

Re: [Talk-cz] Import adres z katastralni mapy

[Jan Bilak]

Zkousel jsem to na jednom kousku (cca 300 dlazdic) z centra Prahy.
Prehryvy tomu prakticky vubec nevadi a detekuje rozpozna to spravne.
Ale co tomu vadi, to je ten copyright. Zatím totiž beru v úvahu pouze
červenou barvu. Jsou 3 možnosti jak to řešit:

a) stahovat dlaždice s překryvem tak, že se bude rozpoznávat pouze z
těch částí mapy, které copyright není. Výhody: Nejlepší výsledky.
Nevýhody: Nutnost stahovat více dat z WMS.

b) považovat černou barvu za červenou. Výhody: Nejsou nutné úpravy
downloaderu, u rozpoznávače jen triviální změna 3 konstant. Nevýhody:
Drobné zhoršení rozpoznávání v případě překryvu copyrightu s popiskem
- pokud se to nešikovně trefí, tak bude třeba ruční rozpoznání, ale
nemusí to znamenat nic, i když se to trefí.

c) Provádět ruční kontrolu všech popisků s překryvem (těch může být hodně).

Osobně považuji c) za špatné řešení. A mezi a) a b) nemám vyhrazený
názor. Možnost a) je sice teoreticky nejlepší, ale b) nemusí mít
postřehnutelně horší výsledky.

Honza



2010/2/12 Jan Bilak :
> Doplnil jsem tam chybějící číslici 4.
>
> Honza
>
> 2010/2/12 Jan Bilak :
>> K vyzkoušení:
>> http://jabi.aspone.cz/osm/OcrBeta1.zip
>>
>> Má to stejné ovládání jako původní tile-processor, ale navíc možnost 
>> logování:
>>
>> FindAddressPoints.exe -tiles test-dir-with-png-images -output test.csv
>> -log log.txt -all
>>
>> -log log.txt ... pokud se toto uvede, tak program bude logovat
>> nerozpoznané body nebo ty, které byly narušené překryvem.
>>
>> Pokud se uvede navíc -all, tak se budou logovat všechny body.
>>
>> Soubor charDef.txt obsahuje definici znaků nebo posloupnosti znaků. Je
>> to také textový soubor, který když zobrazíte fontem s pevnou šířkou,
>> tak je myslím význam jasný. Chybí tam číslice 4 posunutá dolů (tedy za
>> č.o.), protože jsem na nic při pokusech nenarazil. Soubor musí být při
>> spuštění v aktuálním adresáři.
>>
>> Honza
>>
>>
>> 2010/2/12 Jan Bilak :
>>> Na slušné detekci překryvů právě pracuji a myslím, že rozhodně bude
>>> výrazně lepší než byla (to už je myslím teď). Ale stoprocentní
>>> samozřejmě ne - když překryv bude velký, tak to určitě nepůjde.
>>>
>>> Ale jinak si myslím, že generování dlaždic na serveru KN bude nějakou
>>> dobu trvat - a to, ať je na té dlaždici 5 bodů nebo třeba jen jeden. A
>>> také jim to bude zatěžovat servery, když se to přežene s rychlostí
>>> stahování (mnoho vláken apod.).
>>>
>>> Honza
>>>
>>>
>>> 2010/2/12 Petr Dlouhý :
>>>> Kvůli překryvům - čísla se s rozlišením zmenšují.
>>>> Nevím, jak moc je tvůj algoritmus dokonalý v detekci překrývajících se
>>>> číslic, ale nevěřím, že dokážeš spolehlivě poznat, kde číslo skončí.
>>>> Samozřejmě je to otázka nějakého kompromisu, ale většinu času předtím
>>>> zabralo počítání.
>>>>
>>>> Myslím, že ale to dynamické rozlišení, které navrhuješ, nemá moc cenu,
>>>> protože ty dlaždice jsou v PNG, takže by bílé plochy neměly zabírat příliš
>>>> mnoho datového objemu. To samé platí pro vyšší rozlišení - zpomalení může
>>>> nastat spíš tím, že je nutné zpracovat větší množství obrazové informace.
>>>>
>>>> On Fri, 12 Feb 2010 15:39:54 +0100, Jan Bilak 
>>>> wrote:
>>>>
>>>>> Ahoj,
>>>>> k čemu větší rozlišení? Spíše jsem uvažoval nad dynamickým rozlišením
>>>>> ... tedy stahovat výřezy nejprve v malém rozlišení a podle toho
>>>>> detekovat oblasti, které obsahují adresní body. A jen tyto úseky
>>>>> stahovat ve vyšším (třeba stávajícím) rozlišení. To by mohlo ušetřit
>>>>> množství stahovaných dat. Přijde mi, že nejpomalejší bude právě
>>>>> stahování dlaždic z WMS, takže obecným zvýšením rozlišení by se čas
>>>>> prodloužil.
>>>>>
>>>>> Mimochodem - nemáte někdo stažené dlaždice z nějaké větší oblasti,
>>>>> které byste mohli někam hodit zazipované, abych to nemusel stahovat z
>>>>> WMS pro testování?
>>>>>
>>>>> Honza
>>>>>
>>>>>
>>>>> 2010/2/12 Petr Dlouhý :
>>>>>> Ahoj,
>>>>>>
>>>>>> zní to dobře, jestli by to opravdu neznamenalo příliš mnoho času, tak by
>>>>>> možná stálo za to data kvůli té chybě předělat (pokud navíc zlepší
>>>>>> detekci
>>>>>> u překryvů, nebo díky rychlosti umožní stahovat dlaždice s větším
>>>>>> zoomem,
>>>>>> tak to bude další plus).
>&

Re: [Talk-cz] Import adres z katastralni mapy

[Jan Bilak]

Doplnil jsem tam chybějící číslici 4.

Honza

2010/2/12 Jan Bilak :
> K vyzkoušení:
> http://jabi.aspone.cz/osm/OcrBeta1.zip
>
> Má to stejné ovládání jako původní tile-processor, ale navíc možnost logování:
>
> FindAddressPoints.exe -tiles test-dir-with-png-images -output test.csv
> -log log.txt -all
>
> -log log.txt ... pokud se toto uvede, tak program bude logovat
> nerozpoznané body nebo ty, které byly narušené překryvem.
>
> Pokud se uvede navíc -all, tak se budou logovat všechny body.
>
> Soubor charDef.txt obsahuje definici znaků nebo posloupnosti znaků. Je
> to také textový soubor, který když zobrazíte fontem s pevnou šířkou,
> tak je myslím význam jasný. Chybí tam číslice 4 posunutá dolů (tedy za
> č.o.), protože jsem na nic při pokusech nenarazil. Soubor musí být při
> spuštění v aktuálním adresáři.
>
> Honza
>
>
> 2010/2/12 Jan Bilak :
>> Na slušné detekci překryvů právě pracuji a myslím, že rozhodně bude
>> výrazně lepší než byla (to už je myslím teď). Ale stoprocentní
>> samozřejmě ne - když překryv bude velký, tak to určitě nepůjde.
>>
>> Ale jinak si myslím, že generování dlaždic na serveru KN bude nějakou
>> dobu trvat - a to, ať je na té dlaždici 5 bodů nebo třeba jen jeden. A
>> také jim to bude zatěžovat servery, když se to přežene s rychlostí
>> stahování (mnoho vláken apod.).
>>
>> Honza
>>
>>
>> 2010/2/12 Petr Dlouhý :
>>> Kvůli překryvům - čísla se s rozlišením zmenšují.
>>> Nevím, jak moc je tvůj algoritmus dokonalý v detekci překrývajících se
>>> číslic, ale nevěřím, že dokážeš spolehlivě poznat, kde číslo skončí.
>>> Samozřejmě je to otázka nějakého kompromisu, ale většinu času předtím
>>> zabralo počítání.
>>>
>>> Myslím, že ale to dynamické rozlišení, které navrhuješ, nemá moc cenu,
>>> protože ty dlaždice jsou v PNG, takže by bílé plochy neměly zabírat příliš
>>> mnoho datového objemu. To samé platí pro vyšší rozlišení - zpomalení může
>>> nastat spíš tím, že je nutné zpracovat větší množství obrazové informace.
>>>
>>> On Fri, 12 Feb 2010 15:39:54 +0100, Jan Bilak 
>>> wrote:
>>>
>>>> Ahoj,
>>>> k čemu větší rozlišení? Spíše jsem uvažoval nad dynamickým rozlišením
>>>> ... tedy stahovat výřezy nejprve v malém rozlišení a podle toho
>>>> detekovat oblasti, které obsahují adresní body. A jen tyto úseky
>>>> stahovat ve vyšším (třeba stávajícím) rozlišení. To by mohlo ušetřit
>>>> množství stahovaných dat. Přijde mi, že nejpomalejší bude právě
>>>> stahování dlaždic z WMS, takže obecným zvýšením rozlišení by se čas
>>>> prodloužil.
>>>>
>>>> Mimochodem - nemáte někdo stažené dlaždice z nějaké větší oblasti,
>>>> které byste mohli někam hodit zazipované, abych to nemusel stahovat z
>>>> WMS pro testování?
>>>>
>>>> Honza
>>>>
>>>>
>>>> 2010/2/12 Petr Dlouhý :
>>>>> Ahoj,
>>>>>
>>>>> zní to dobře, jestli by to opravdu neznamenalo příliš mnoho času, tak by
>>>>> možná stálo za to data kvůli té chybě předělat (pokud navíc zlepší
>>>>> detekci
>>>>> u překryvů, nebo díky rychlosti umožní stahovat dlaždice s větším
>>>>> zoomem,
>>>>> tak to bude další plus).
>>>>>
>>>>> On Fri, 12 Feb 2010 04:25:19 +0100, Jan Bilak 
>>>>> wrote:
>>>>>
>>>>>> Ahoj,
>>>>>>
>>>>>> pokusná implementace je velmi rychlá a měla by být i spolehlivá.
>>>>>>
>>>>>> Zkoušel jsem to na 18 výřezech 4000x4000 px. Celkový čas 7.2 s.
>>>>>> Průměrný čas zpracování jednoho souboru je 405 ms, průměrný čas
>>>>>> zpracování jednoho adresního bodu je 17 ms. To vše v jednom vlákně a
>>>>>> tedy to zatěžuje jen jedno jádro procesoru.
>>>>>>
>>>>>> Zítra to snad dodělám do použitelného stavu.
>>>>>>
>>>>>> Honza
>>>>>>
>>>>>>
>>>>>> 2010/2/11 Petr Dlouhý :
>>>>>>> Ne, o to nejde. Ty čísla jsou už rozpoznaná, takže stačí předělat
>>>>>>> pouze
>>>>>>> ta
>>>>>>> evidenční čísla (ty jsou posunutá trochu níž od tečky, takže je tam ta
>>>>>>> dvojka uřízlá), ve kterých je sedmička. Není problém v tom, že by to
>>>>>>> nešlo
>>>>>>> uříznout o trochu níž. Problém je, že už

Re: [Talk-cz] Tracer na rozpoznání budov z katastr ální mapy

[Jan Bilak]

Pokud vím, tak v současné době nikoli. Ani nevím, jak by to vlastně
mělo dělat. Zda vytvořit jeden obrys přes všechny části nebo více
obrysů a přes to relaci? A jak to pak tagovat?

Honza


2010/2/12 Zdeněk Pražák :
>
> Nainstaloval jsem si tracer a chtěl bych se zeptat, zda se v případě, kdy má 
> budova například několik přístavků v katastrální mapě oddělených od 
> budovyslabší čarou, ale nalézajících se na jednom pozemku, dá tracer přinutit 
> k tomu, aby tyto přístavky otagoval spolu s budovou jako jeden objekt.
> Pražák
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz