Zdravím,
máte nějaký tip, na službu, která by poskytovala vyextrahované hranice
administrativních celků?
Momentálně potřebuju data pro ČR na úrovni státu (admin-level=3), krajů
(admin-level=6) a okresů (admin-level=7), ale do budoucna by se mi hodilo i
jiné státy v Evropě a tím pádem i jiné
roste tráva nebo křoví. A to pole rozhodně
není.
Marián
-- Původní zpráva --
Od: Lukas Kabrt lu...@kabrt.cz
Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org
Datum: 30. 6. 2015 9:04:24
Předmět: [Talk-cz] Pole a sloupy VN - import LPIS
Při toulkách po mapě jsem
na tom, kdo to zakresluje. Díry zakreslené jeden rok
můžou další zmizet (viděl jsem) a naopak.
Marián
-- Původní zpráva --
Od: Lukas Kabrt lu...@kabrt.cz
Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org
Datum: 30. 6. 2015 10:59:49
Předmět: Re: [Talk-cz] Pole
Při toulkách po mapě jsem si všimnul, že pravděpodobně po importu
LPIS, se okolo sloupů VN často objevují maličké díry v polích. Např.
http://www.openstreetmap.org/#map=19/50.50930/16.23577
Zajimálo by mě jaký je pohled ostatních na to, jestli se mají při
editaci takové díry zachovávat. V
2) Sdílené hranice - souvisí s předchozím. Nemělo by vést více hranic
přes stejné body. Lepší je rozsekat jeden megapolygon do více cest a
přidat je do příslušných relací hranic - viz poměrně dlouhá zdvojená
hranice mezi CHKO Železné hory a Žďárské vrchy.
(Námět pro ty, co se nudí: sloučení s
Na adrese
https://sites.google.com/a/kabrt.cz/osm/home/adresy.zip?attredirects=0d=1
je nova verze programu pro import adresnich bodu.
Opravy a upravy programu jsou opet z dilny Libora Pechacka.
--
Lukas
2011/8/20 Lukas Kabrt lu...@kabrt.cz:
Na adresu
https://sites.google.com/a/kabrt.cz/osm
Na adresu
https://sites.google.com/a/kabrt.cz/osm/home/adresy.zip?attredirects=0d=1
jsem umistil novou verzi programu pro import adresnich bodu
merge-cuzk-db. Nova verze opravuje chybu, diky ktere obcas program
vytvoril adresni bod mimo prislusne katastralni uzemi. Autorem opravy
je Libor
Na Windows se daji bez problemu pouzit programy Kosmos [1] nebo jeho nastupce
Maperitive [2]. Taky to ale obnasi vytoreni/upraveni stylu pro
renderovani mapy.
[1] http://wiki.openstreetmap.org/wiki/Kosmos
[2] http://wiki.openstreetmap.org/wiki/Maperitive
--
Lukas
2011/2/24 Zdeněk Pražák
2011/2/20 Michal Grézl michal.gr...@openstreetmap.cz:
Vsechny ditch co najdu mazu.
Zase tak radikalni bych nebyl. Ale smazal bych ty waterway=ditch z
importu, které nikdo od importu neupravil (Kdyz je nekdo upravil a
nesmazal, tak predpokladam, ze tam neco takoveho skutecne bude).
--
Lukas
V bat souborech jsem nasel chybu ... chybi mezera pred -mappings,
staci ji do bat souboru dopsat a uz to funguje. Neumim si to
vysvetlit, jak to ze pro benesov tam ty mezery chybi a u ostatnich
okresu je to spravne.
--
Lukas Kabrt
2011/2/20 Zdeněk Pražák zpra...@seznam.cz:
děkuji za radu, po
Zkoušel jsem data pro Pardubice vygenerovat a mě funguje vše bez
problémů. Zkuste se přesvědčit, jestli je jsou všechna data rozbalená
ve správném adresáři.
Složka s programem by měla vypadat následovně:
- CUZK.Common.dll
- GeoUtils.dll
- merge-cuzk-db.exe
- OSMUtils.dll
- data
-
Tak ja jsem si chvilku hral a neco jsem si napsal. Zatim jsem to
zkousel na malem kousku a vypada to dobre.
Postup:
nactu toky (waterway:stream) a nadrze (landuse: reservoir)
najdu duplicitni body mezi toky a nadrzemi
duplicitni body v tocich nahradim odpovidajicimi body z nadrzi
puvodni
S tou verzi programu to muze byt ono ... ja pouzivam verzi z 27.2. a
funguje mi to bez problemu. Protoze program nemam v SVN, tak uz
nedohledam co se zmenilo.
Kazdopadne aktualizoval jsem program na webu [1], nejakymi zmatky tam
byla verze z 23. 2.
[1]
Jeden z dalších nápadů, který jsem zde kdysi nadhodil:
Analýza záznamů z GPS s použitím OpenStreetMap ...
Nechci si tady delat nejakou reklamu :-), ale na necem podobnem [1]
jsem pracoval letos v ramci programu Google Summer of Code. Muj
projekt byl zameren spise na analyzu casu potrebneho k
označím jednotlivé hranice
stávajících katastrálních území a dám kopírovat tak po vložení do nové vrstvy
neobsahují hranice kú informace o relacích
Původní zpráva
Od: Lukas Kabrt lu...@kabrt.cz
Předmět: Re: [Talk-cz] Import adres okresu Benešov
Datum: 06.9.2010 13:45:35
Neprirazene casti obci (zakomentovane na konci souboru) je potreba
priradit ke katastralnim uzemim. Muze se stat (a casto se tak stane),
ze domy v jednotlivych castech obce na jednom katastalnim uzemi maji
stejna c.p., pak si ze souboru s hranicemi vykopiruju prisusnou obec a
katastalni uzemi
Na http://opentrackmap.no-ip.org jsem přidal vrstvu Hiking Tracks Debug,
která oranžově podkresluje turistické trasy s tagem complete=no.
Super, to se mi libi, takhle je to mnohem prehlednejsi nez v tabulce na wiki.
K tagovani turistickych tras bych mel jeden navrh - v datech bych
explicitne
Na něčem podobném se pracovalo a stále ještě pracuje. Viz wiki.
[1] a několik nechutně dlouhých vláken tady na talk-cz [2], [3].
V současné době je stav takový, že jsou vygenerována podkladová data
pro jednotlivé okresy a postupně je zpracovávám. Pokud se chceš
zapojit, tak pomoc je určitě
V tom případě bych se chtěl zeptat, v jakém stavu jsou okresy Prachatice,
Žďár nad Sázavou nebo Brno-Venkov. Jednoho z nich bych se rád a ochotně ujal
Data pro tyto okresy jsou pripravena ke zpracovani. Odkazy na potrebne
soubory a postup je na wiki [1].
Pokud by byl nějaký problém, tak se
Mozna by slo to prekryt/zkombinovat s mapou ukazujici hustotu poctu
nodu v OSM a tak zjistit mista, kde sice je zastavba, ale moc dat v
tech mistech neni - a tedy by to tam pak chtelo v tech mistech
domapovat.
Zajímavý nápad - zkusil jsem něco takového spáchat, posuďte sami,
jestli to je
Následuje:
nahrání relací (potřebuju dodělat NUTS2 relace)
NUTS 2 (regiony) v datech jsou. Tak jak je to na wiki s admin_level=4.
Nahrana data jsem si prohlizel a narazil jsem na jeden problem.
Vsechny ways, na ktere jsou koukal existuji ve dvou duplikatech. Way
je vzdy tvorena stejnymi uzly,
Což to očekávám, ale jestli to bude jen na tu jednu cestu nebo to skončí
úplně, dnes večer se uvidí
Citace z wiki:
Processing stops at the first error, so if there are multiple
conflicts in one diff upload, only the first problem is reported.
--
Lukas
to uploadování najednou bude mít možná jedno úskalí, jelikož to trvá
dlouho, budou se tam nějaký čas povalovat neotagované body. Na některé
jsem teď narazil při kontrole rybníků, zajímalo by mě co se stane,
když je někdo nezasvěcený smaže než se začnou uploadovat waye.
Zalezi na tom, jak se
To jo, ale v jednom req lze tusim maximalne 50k bodu, takze toto tak
poslat nelze, josm umoznuje posilat po definovanem poctu - napr po 10k a
ve vysledku to bude ???jeden??? changeset. Changeset se neuzavre
automaticky pokud klient komunikuje a pokud to spravne chapu, dokud neni
uzavren, tak
Tak mam odzkouseno - 50 tis. je limit changesetu, vic ani tuk,
A jak se to chova? Pokud se to uploduje v jednom requestu, tak to je
to skutecne atomicka operace? Nebo to vezme prvnich 5 zmen a ty
ulozi?
takze uz nahravam po castech, ale jde to pomalu.
Koukal jsem a drzim palce :-)
--
Mám jen bobky z toho, co to udělá při uploadu cest, pokud bude nějaký
node chybět.
Obavam se, ze neco ve smyslu HTTP status code 409 (Conflict) nebo HTTP
status code 412 (Precondition Failed) viz. wiki [1].
[1] http://wiki.openstreetmap.org/wiki/API_v0.6
--
Lukas
jeste resim subarea - ma cenu delat ke vsemu subarea? udelal bych
navaznost CR-kraje-okresy, ale ma cenu pokracovat dale -obce-KU ?
Tech udaju tam bude moc a bude to vubec k necemu?
Ja bych byl pro pridat i obce a KU, at jsou vsechny hranice v
hierarchickem usporadani. Vyuzit se to da - napr.
relace:
type=multipolygon, ovsem vsechny soucasne hranicni relace (a nejen nase)
pouzivaji type=boundary
To neni tak uplne pravda - vpostate vsechny hranice v Nemecku,
Rakousku a Nizozemi jsou delane pomoci multipolygon. Proc jsem zvolil
multipolygon jsem psal tady [1]. Pokud ale prevlada
Viděl bych to tak, že to rozdělím po okresech a napíšu si prográmek,
který dokáže oddělit duplicity.
Při uploadu musím mít druhý prográmek, který dokáže vzít ID bodů a cest
z OSM exportu a změnit je v jiném souboru - asi detekce shodnosti polohy
bodů. Takhle to postupně naimportovat.
Jak o
To mají ale kvůli tomu, že mají často v hranicích díry, takže to dělají
jako multipolygon. To my nemáme (nebo jo?), takže bych to radši předělal
na boundary. Ale jinak z procesního hlediska je to jedno.
Pár k.ú. s dírami je. Pak jsou desítky obcí kde je území nesouvislé.
--
Lukas
A ten soubor [1] je stále aktuální nebo existuje něco novějšího?
Nejnovjější verze je na adrese [1]. Co v mapě je a není, co je
zkontrolováno a kde ještě jsou nějaké nejasnosti jsem psal do
prispevku [2] tady na foru.
Já bych to nějak rozsekal, třeba podle okresů, protože stejně to bude
chtít
Melo by to jit, JOSM umi pri uploadu rict, ze bude changeset nahravat po
castech a po jak velkych. Bude to ale trvat. Druha vec je, zda ze z toho
JOSM neopupinkuje :D. Zkusim se na to mrknout.
Mam vyzkouseno, ze JOSM ten soubor nacte. Pracovat se s tim sice moc
neda, ale otevrit jde, tak by ho
Chtěl jsem se na to podívat, ale chce to po mě .NET Framework 4.0.3...
Nějak si nejsem jistý, kterou z těch mnoha verzí co MS nabízí mám
nainstalovat a po předchoízch zkušenostech, kdy mi instalace .NET 3.5
rozhasila některé věci se mi do toho ani moc nechce.
Můžeš dát podrobnější návod,
Ve staženém souboru (Beroun) už jsou všechny výstupy udělané, proč je
tedy třeba zprovozňovat program?
Výstupy jsou udělané pro města, kde se podařil automaticky vytvořit
*.map soubor. U dalších (název souboru začíná podtržítkem) je nějaká
nejasnost v *.map souboru. Je potřeba map soubor
Ahoj,
par informací, co je nového ohledně importu adres.
Znovu jsem provedl OCR s vylepšeným programem. Výsledek je na [1]
Vylepšil jsem program merge-cuzk-db [2]
- lepší detekce problémů (duplicity)
- možnost zpracování více *.map souborů najednou
- rychlejší zpracování osm a xml souborů (bez
Uploduji soubory 006, 007, 008.
--
Lukas
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
Ahoj,
koukal na xml soubory z http://www.web2net.cz/osm/dibavod/ a nevim
jestli je to chyba nebo umysl, ale nepozdavaji se mi tagy source
tag k=source v=source=vuv:dibavod:a05 /
neni v hodnote tagu 'source=' navic?
--
Lukas
___
Talk-cz mailing list
Prave toho jsem se bal, protoze zminenym hillshadingem to asi dost
dobre nepujde a 90 metru je pro neco jinyho nez himalaje dost
nepresny.
Pokud si spravne pamatuju, tak tech 90 metru neni presnost nadmorske
vysky, ale rozliseni v horizontalnim smeru. (Data jsou ulozena v
rastru po 3 uhlovych
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
Konečně se mi podařilo dodělat mapu s hranicemi katastrálních území,
obcí, okresů, krajů, regionů a ČR. Mapa je ke stažení na [1].
Na mapě je:
13027 katastrálních uzemí
6249 obcí
77 okresů
14 krajů
8 regionů (NUTS 2)
1 hranice ČR
Informace o přiřazení k.ú. - obec - okres - kraj jsem čerpal z
Taky se přidám s dotazem. Jaký je stav importů KÚ a hranic obcí? Má cenu
je dělat ručně nebo se to bude v dohledné době importovat pro celou
republiku?
Mapa s k.u. je hotova, ted jsem do ni pridal i hranice obci [1]. Jeste
to ma ale par musek.
A jak se budou řešit ty hranice, které tam už
uz jsem skoro dopracoval svoje davky, ale nastal maly problem.
v tech cca 80 tile je cca 850 erroru v logach. Mam to nejak
resit, nebo uz si je zkusis udelat znova sam?
Vypada to ze tesseract sem tam nejak spadl nebo neco takoveho
provedl.
Resit to nijak
Zkusím nastínit zjednodušeně algoritmus, jak to
funguje (tedy jak jsem zamýšlel, třeba je tam chyba):
a) napřed se floodfillem vyplní souvislá plocha, na kterou uživatel kliknul
b) najde se vnější hranice - množina bodů
c) najdou se tam významné/zlomové body
d) zjednoduší se a naopak doplní
přemýšlel jsem o tom, jestli by nešel vyrobit i skript, co projde všechny
adresní body, které nevyhovují vzoru č.e./č.p./bez č.e./č.p a zpracoval je
znovu s vyšším rozlišením.
Koukal jsem kolika pripadu by se to tykalo a pokud za spravne
rozpoznane budeme povazovat i ruzne varianty (ce, c.e,
2010/1/27 Petr Dlouhý petr.dlo...@email.cz:
Má někdo nápad, jak by to šlo jednoduše obejít?
Vyzkousel jsem pouziti tiffcp jak navrhoval Jan Bilak. Na WIN mi to
funguje bez problemu. Stahovat muzete opet z mych stranek [1]. Je to o
neco pomalejsi, nez kdyz mutli-page tiff vytvarim primo v
Je to tak? Pokud ano, tak by to chtělo uživatele důrazně varovat, protože
by se mohlo stát, že výsledek bude pomíchaný a nikdo si toho nevšimne.
Nešlo by s tím něco udělat?
Ne, uz to tak neni, jen jsem to zapomnel zapsat do provedenych zmen.
Program si uklada pomocne soubory stale do
Proč ne ref? Dá se snad využít nějak jinak?
To bude asi ten spravny atribut.
Řekl bych, že všechna území, která v mapě jsou (možná s výjimkou hranic s
Německem) jsou méně přesná, a je tedy je možné smazat (pokud tedy nejsou
nějak vázána na další objekty). Možná by ale bylo dobré zkopírovat
Provedl jsem par zmen v programu tile-processor, binarky [1] i
zdrojove kody [2] muzete stahovat z mych stranek.
Hlavni zmeny:
rychlost - OCR utitlita se ted spousti pouze jednou pro kazdou
dlazdici - prineslo to cca dvojnasobnou rychlost zpracovani
drobne zvyseni presnosti - presnejsi orez
Tomu moc nerozumím, můj postup byl takový, že jsem vyříznul z dlaždice
číslo (což by měla být bezestrátová konverze) a potom jsem to zvětšil (což
by měla být stejná konverze jako předtím. Postup by mohl být nepatrně
náročnější na výpočetní výkon, ale výsledek by snad měl být stejný, ne?
Leda
nebylo by lepší ukládat a přibalit potom k výsledku i kousky mapy s
těmi čísly? Zrychlila by se ruční kontrola, zda to OCR rozpoznal
správně. Aneb bylo by možné pak jednoduše třeba zobrazit číslo v
textové podobě a vedle číslo v obrázkové podobě. A stejně už se to
stahuje, ořezává, ... jen to
2010/1/26 Jiri Parkan jpar...@gmail.com:
Při zkusmém zpracování oblasti 4 se zdá že mi nějak nefunguje
rozpoznávání. Výsledný csv je prázdný a v logu errory podobné tomuto:
[ERROR] Tile: 4\14.8270_50.8700_14.8320_50.8750-budovy.png Could not
find file
Nazvy jsem zakomponoval do mapy k.u. [1]
Na mape je celkem 13036 relaci, nazvy ma prirazeno 13027 relaci.
Zbylych 9 relaci predstavuje oblasti, ktere budou prisluset k
nekteremu ze sousednich k.u., na mape jsou ale hranice tak blizko
sebe, ze tvori jednu caru a nejde poznat, kam oblast patri
vygeneroval jsem soubor cr.map [2] obsahující mapování pro program
merge-cuzk-db. Soubor je jednoduše vygenerován z ulic MVČR [1], takže trpí
některými zásadními nedostatky:
Diky, urcite to hodne pomuze.
1) V MVČR se bohužel vykašlali na velikost písmen a napsali všechno
velkýma. V souboru
Asi ano, ale kdyz jsem osmosis zkousel, tak vzdycky spadnul na nejakou
podovnou vyjimku. Pak jsem v rychlosti dospel k zaveru, ze asi ke sve
cinnosti potrebuje nejakou DB (PostreSQL apod.) ... a to se mi
nechtelo instalovat ... ale treba je to spatny zaver. Moc jsem to
nezkoumal.
Urcite
Co se týče skriptů, tak myslím, že je třeba se vydat jinou cestou.
Pokud to jde alespoň trochu jednoduše udělat, tak by ten skript měl
dokázat pracovat s celou mapou katastrálních území.
Problem to neni. Kdyz jsem program vytvarel, tak jsem nevedel o tom,
ze existuje vektorizovana mapa k.u. a
Pardon, myslel jsem dní.
On Sun, 24 Jan 2010 08:46:16 +0100, Petr Dlouhý petr.dlo...@email.cz
wrote:
(mé velmi hrubé odhady se pohybují od 50 do 100 hodin jenom pro 2. fázi).
Jestli myslis cisteho vypocetniho casu, tak bych rekl, ze je to
pesimisticky odhad. Podle toho, jak rychle probiha
V kroku 3 (vytvoreni XML souboru, ktery definuje prirazeni mezi
katastralnim uzemim a obci / casti obce z databaze adresnich bodu)
jsem převzal XML z dokumentace. A k tomu se váže první dotaz. Kde
berete tyto informace? A k čemu je to dobré? Upozorňuji, že nejsem
zaměměřič, ale programátor,
Ahoj,
povedlo se mi zprovoznit kompilaci pod Monodevelop, takže si už můžu
program upravit sám (chtěl bych tam přidat podporu pro nativní Linuxový
Tesseract, což bude ten hlavní problém proč to nechodí jinak, než pod
Wine).
Pošli mi prosím tedy aspoň zdrojáky, ve kterých nepoužíváš
měl bych k tomu ryze praktický dotaz. Jakým způsobem z téhle mapy
nejsnáze vyříznout oblast která mě zajímá? Při načtení do JOSM se s
takhle velou mapou nedá rozumně pracovat, každou akci provází
minimálně několikaminutové čekání.
Jedna moznost je v JOSM si cast zkopirovat do nove vrstvy a
1) Pokud ma tile-downloader prohozeny nort south nebo east west, skonci
aniz by cokoli sdelil, je treba kontrolovat
Ano vim o tom, ze tam jsou podobne neosetrene vstupy. Pokud nekde ma
byt cislo, tak program prdpoklada ze tam to cislo je, pozor si je
potreba davat treba pri tovrbe *.map
Tak jsem trochu zapracoval na mape katastralnich uzemi, aby se k.u.
nemuseli kreslit rucne.
Vektorizovanou mapu k.u. od hanoje [1] jsem zacistil (slouceni
duplicitnich bodu, odtraneni fragmentu po vektorizaci, pospojovani
prerusenych linii) a vytvoril na ni relace pro jednotliva k.u.
Mapu jsem
Což ani nevypadá, že by byl problém s Monem. Co má být v souboru
label.txt? Když ten soubor vytvořím a vložím tam nějaké znaky, tak to
začne vypisovat:
Program pracuje tak, ze vezme dlaždici, najde na ní definicni body
budov (cervene tecky) a k nim prislusejici text. Text ulozi do obrazku
tmp.bmp
Muzu se zeptat, zda pouzivate nejak upraveny/nauceny tesseract
na ceske znaky, nebo to cestinu uspesne neumi?
Pro verzi 3.0 uz existuje i cestina. Verze 3.0 je v stadiu prerelease,
nejsou pro ni binarky a tak je potreba si stahnou zdrojove kody [1] a
zkompilovat.
Soubor pro
:13:35 +0100, Lukas Kabrt lu...@kabrt.cz wrote:
Tak jsem na wiki [1] vytvoril stranku s informacemi o importu. Zaroven
jsem jsem updatoval program [2], tak aby generoval tagy FIXME pro ty
adresni body, kde prirazeni mezi databazi a mapou neni jednoznacne.
Martin Kupec
Dalsi faze bude sehnat si
Podle me je moznost 1 spravne.
Pokud neoznacime vsechna katastralni uzemi jako admin_level=10 tak
nepujde do mapy zanest nazev k. u. a jeho identifikator. Mozna pro ne
neni momentalne vyuziti, ale v budoucnu na ne mohou byt navazana
nejaka dalsi data, nebo pujdou vyuzit pri nejakem dalsim
Tak jsem na wiki [1] vytvoril stranku s informacemi o importu. Zaroven
jsem jsem updatoval program [2], tak aby generoval tagy FIXME pro ty
adresni body, kde prirazeni mezi databazi a mapou neni jednoznacne.
Martin Kupec
Dalsi faze bude sehnat si od hanoje vektorizovane obrysy
katastralnich
Zdravim,
kdysi v lete jsem tady psal [1], jak zkousim importovat adresy a obrysy budov z
katastralni mapy CUZK. Protoze jsem nemel prilis casu, tak jsem
program pro import
nedotahnul do konce. Ted jsem se k tomu vratil a do celkem pouzitelne
podoby odelal aspon
import adresnich bodu.
pres JOSM, tak vsechno fungovalo.
--
Lukas Kabrt
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
a podarilo se mo to
rozbehat.
--
Lukas Kabrt
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
...
O tom, jak se generuje stinovani a vrstevnice nic moc nevim, ale
myslim si, ze pokud by chyba byla v datech, tak by to ovlivnilo i
vrstevnice. I ty jsou genegovany s SRTM dat, ne?
--
Lukas Kabrt
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http
Že by se svítalo na lepší časy? http://www.ct24.cz/veda-a-technika/59617-
nejucelenejsi-mapa-sveta-bude-ke-stazeni-na-internetu/
Viz. taky diskuze na t...@openstreetmap.org
http://lists.openstreetmap.org/pipermail/talk/2009-June/038101.html
--
Lukas Kabrt
na vektorizaci je prý relativně rychlý algoritmus bleskově vektorizovat
na mnoho krátkých úseček a následně zkoušet 2 sousední úsečky spojovat
do delších. Je však otázkou, jak si takový algoritmus poradí s ostrými
rohy budov -- znám jej jen z aplikace, ve které zkosené rohy nevadí.
Podobny
2009/6/29 Tomas Kolda ko...@web2net.cz:
Potrace byl pouzit na vektorizaci UHUL lesu... Pouziva se velmi hezky a
celou CR (100 000 * 70 000 pixelu nebo tak nejak) vypocital za par
minut. Pouzival jsem ho jako knihovnu.
Aha, tak to vypada, ze bych si mel rozsirit obzory a dat mu jeste sanci :-)
http://www.openstreetmap.org/?lat=50.5387lon=16.0523zoom=14layers=B000FTF
--
Lukas Kabrt
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
, docela podrobne a mapa hned vypada o tridu lip
(http://www.openstreetmap.org/?lat=50.49736lon=16.10043zoom=16layers=B000FTF).
Koukal jsem, ze treba v Praze jsou budovy take kresleny docela
podrobne, takze ja bych byl pro.
Rad si prectu vsechny napady, rady a pripominky.
--
Lukas Kabrt
v JOSM.
Ulozeny tam jsou pouze definicni body budov, ne jejich obrysy jejich
rozpoznani je jeste pomalejsi, tak jsem to tam zatim nedaval.
--
Lukas Kabrt
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
hlas pro 1)
--
Lukas Kabrt
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
Ale podmínky povinné byly v nových pravidlech zakázány. Tudíž by to
mohlo být pouze jako nepovinná podmínka a na tu se jak známo vykašle
99% lidí.
Pokud vim, tak povinne podminky byly zakazany jen u tradicnich kesi. U
mysterek je mozne i ted.
___
Rad bych navazal na predchozi dotazy, protoze jsem v OpenStreetMap
taky zacatenik.
Jedna se mi predevsim o to, jak konkretne nektere veci kreslit do mapy
a jak je znacit.
Spolecna hranice ploch, plocha linie
Na mape jsem vypozoroval, ze pokud vede cesta napr. po kraji lesa, tak
nekde je to
79 matches
Mail list logo
