Re: [Talk-cz] Data RUIAN - výměnný formát
Ahoj Jaká je šance hromadně opravit třeba toto http://keepright.ipax.at/report_map.php?lat=50.592556919313lon=15.140419006315zoom=14 nebo to opravovat už teď a ručně? *** zadna, musi se rucne. tyto opravy jsou v trutnove na par minut. Zajímá mě, v čem jsou OSM přesnější než RUIAN, pokud jde o polohovou a tvarovou přesnost. Jestli je co zachraňovat kromě tagů. *** presnejsi nejsou, vyuzivaji tentyz podklad katastralni mapu. *** Nekdy ale v OSM mohou byt objekty z ortofoto, ktere z nejsou v KM zamerne vedeny nebo neni nahlaseno jejich postaveni/zboreni do KM. Dají se takové objekty (oblasti) označit a vyloučit z aktualizace? *** myslim ze samostatne stojici budovy obkreslene z ortofoto ponechat v OSM lze. V zastavbe je to algoritmicky obtizne. Nedá se aktualizace z RUIAN rozdělit na etapy od nejjednoduššího ke složitějšímu? Začít třeba budovami v obcích, kde ještě žádné nejsou ... *** Rozdelit na etapy casto znamena odlozit rozhodnuti na pozdeji, kde se uziva jednotka navzdy. Přidám jeden argument pro zachování adresních bodů. Padla tady zmínka, že RUIAN jsou data z ZABAGED a tam jsou bloky budov jako celek, bez rozdělení na jednotlivé budovy. Naopak došlo ke zpřesnění tvaru budov viz např. Turnov náměstí Českého ráje 65 *** v RUIAN jsou ze ZABAGED pouze ulicni cary. Zbytek je KM. h ahoj hanoj ___ 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
Ahoj, On Sun 01-07-12 12:25:22, hanoj wrote: 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): *** Hodne nam muze pomoci historie editaci a puvod UIR-ADR: 1) vymazat addr body ktere prosly jen hromadnym importem/hromadnou upravou z UIR-ADR (predpokladam ze to bude vetsina) Velka cast z nich bude ruzne posunuta - prave kvuli tomu nesmyslu, ze snima oznacime kde je vchod + ani presnost importovanych dat jako takovych neni nijak uzasna, casto jsou adresy nekolik desitek metru mimo. Ale na casti uzemi to bude rucne u/opraveno. = opet se znici spousta prace spousty lidi. *** V OSM mame verzovani, takze urcit co je jen import UIR-ADR bez zasahu useru nebude problem. *** Oznacovani tzv. vchodu je myslim minoritni vec. Hlavni duvod posunu je, ze adresni body jsou casto o desitky metru jinde. *** Ja jsem posunul cca 10.000 adresnich bodu, ale rad si je necham nahradit necim, co ma systematicky pristup a vizi udrzby. +1 Já osobně bych bez mazal nejen neupravené importy z UIR-ADR, ale i hromadné importy ČÚZK+MVČR. Tedy: source=uir-adr, verze 1 - smazat hned source=uir-adr, verze 1 - podívat se a smazat source:loc=cuzk:km, source:addr=mvcr:adresa - podívat se a smazat ČÚZK+MVČR import také není v některých místech dostatečně polohově přesný, v KM totiž proběhlo mnoho korekcí umístění bodů i průběhu kranic KÚ. Oním podíváním se mám na mysli ruční revizi rozdílů. Může se ukázat, že v OSM máme v některých případech přesnější data, než jsou RÚIAN, nebo se můžou ukázat nějaké další vzorce. Libor ___ 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
Dne 30.6.2012 22:55, hanoj napsal(a): Ahoj 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): *** Hodne nam muze pomoci historie editaci a puvod UIR-ADR: 1) vymazat addr body ktere prosly jen hromadnym importem/hromadnou upravou z UIR-ADR (predpokladam ze to bude vetsina) Velka cast z nich bude ruzne posunuta - prave kvuli tomu nesmyslu, ze snima oznacime kde je vchod + ani presnost importovanych dat jako takovych neni nijak uzasna, casto jsou adresy nekolik desitek metru mimo. Ale na casti uzemi to bude rucne u/opraveno. = opet se znici spousta prace spousty lidi. 2) mixovane addr+POI vymazat info o addr a POI tagy v nodu ponechat (cca 1000 nodu) = misto jedny tecky jich udelame na kazdy budove nekolik? A jak zjistim ze to vsechno patri k sobe? Jak zjistim, ze na adrese XYZ je hospoda? To si na to mam psat expertni system a analizovat vzdalenosti jednotlivych bodu? Nehlede na to, ze to opet budes delat kazdy den znova? 3) budovy s addr prevest na body (cca 13.000 way) = viz vejs, editori je opet zacnou posunovat ke vchodu = budes den co den mazat stovky bodu a znova je importovat? 4) addr ktere se shoduji tagem a polohou z OSM vymazat (polohova shoda do 10m) 5) uplny itinerar to neni, ale vetsinu to snad pokryva, co se zbytkem, se ukaze az pri cinu 6) to co zbyde priradit fixme Proto si myslim, ze je lepsi dat adresu na budovu. Navrch (kdyz uz sme u toho) vetsinou se tu kupodivu propaguje datove spravne reseni, coz v tomto pripade neni - nic jako adresa bodu neexistuje. Az si nekdo vzpomene, ze bude do OSM davat cisla parcel, tak sme opet u toho, ze zase nekam flaknu bod misto abych oznacil hranici? Je to stejny jako s KU - proc markovat hranice KU, kdyz nekam dovnitr muzu flaknout bod. 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 nas potom ceka CR navzdy bez budov..., vzdyt stavajici tracer mame uz tretim rokem. 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. *** je treba nezapomenout, typ parcely na les/pole/louky vychazeji z nominalni predstavy o urceni hodnoty parcely, nikoliv co na parcele skutecne je/roste/stoji. PS: transformace skrze proj/gdal: * bez parametru towgs presnost 100m * s parametrem towgs presnost 1m (tedy nikoliv 70m) * s parametrem +nadgrids=czech 0,1m 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] Data RUIAN - výměnný formát
jzvc wrote: Proto si myslim, ze je lepsi dat adresu na budovu. Navrch (kdyz uz sme u toho) vetsinou se tu kupodivu propaguje datove spravne reseni, coz v tomto pripade neni - nic jako adresa bodu neexistuje. Az si nekdo vzpomene, ze bude do OSM davat cisla parcel, tak sme opet u toho, ze zase nekam flaknu bod misto abych oznacil hranici? Je to stejny jako s KU - proc markovat hranice KU, kdyz nekam dovnitr muzu flaknout bod. Mně by se taky líbílo dávat adresu spíše na budovu, ale vidím tu dva problémy: 1) Občas má jedna (reálná) budova více adres a občas je v OSM budova zakreslena pomocí více cest (např. pro možnost označení nižší/vyšší části jedné budovy), takže vztah OSM budova:adresní bod je obecně N:M a nevím, jak to elegantně vyřešit. 2) Aktualizace bodů je řádově jednodušší než cest. Jak tagování pomocí bodů, tak i cest má svá pro a proti... možná bysme to mohli začít sepisovat někde na wiki, včetně návrhů řešení. Petr Morávek aka Xificurk signature.asc Description: OpenPGP digital signature ___ 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
Ahoj, 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): *** Hodne nam muze pomoci historie editaci a puvod UIR-ADR: 1) vymazat addr body ktere prosly jen hromadnym importem/hromadnou upravou z UIR-ADR (predpokladam ze to bude vetsina) Velka cast z nich bude ruzne posunuta - prave kvuli tomu nesmyslu, ze snima oznacime kde je vchod + ani presnost importovanych dat jako takovych neni nijak uzasna, casto jsou adresy nekolik desitek metru mimo. Ale na casti uzemi to bude rucne u/opraveno. = opet se znici spousta prace spousty lidi. *** V OSM mame verzovani, takze urcit co je jen import UIR-ADR bez zasahu useru nebude problem. *** Oznacovani tzv. vchodu je myslim minoritni vec. Hlavni duvod posunu je, ze adresni body jsou casto o desitky metru jinde. *** Ja jsem posunul cca 10.000 adresnich bodu, ale rad si je necham nahradit necim, co ma systematicky pristup a vizi udrzby. 2) mixovane addr+POI vymazat info o addr a POI tagy v nodu ponechat (cca 1000 nodu) = misto jedny tecky jich udelame na kazdy budove nekolik? A jak zjistim ze to vsechno patri k sobe? Jak zjistim, ze na adrese XYZ je hospoda? To si na to mam psat expertni system a analizovat vzdalenosti jednotlivych bodu? Nehlede na to, ze to opet budes delat kazdy den znova? *** to neni expertni system, ale trivialni prostorove dotazy (co je nejbliz). Navic to tak uz dnes v mape funguje. Jde o sjednoceni ruznych pristupu. *** Navic adresa/POI je vzdycky priblizna at uz fakticky (sidlo/provozovna) nebo lokacne (napr. prumyslovy areal o 10 hektarech ma 1 adresni bod) 3) budovy s addr prevest na body (cca 13.000 way) = viz vejs, editori je opet zacnou posunovat ke vchodu = budes den co den mazat stovky bodu a znova je importovat? *** tohle myslim problem plugin building v JOSM, ktery automaticky predelava adresni bod do nove vytvorene budovy. *** Co bude den co den zalezi na tom, jak budeme chtit udrzet v chodu aktualizace s RUIAN Proto si myslim, ze je lepsi dat adresu na budovu. *** Budovu myslis jako way (OSM building), nebo budovu v RUIAN (bod) nebo parcelu se stavbou RUIAN (polygon z katastru na 1/2 uzemi CR)? Navrch (kdyz uz sme u toho) vetsinou se tu kupodivu propaguje datove spravne reseni, coz v tomto pripade neni - nic jako adresa bodu neexistuje. Az si nekdo vzpomene, ze bude do OSM davat cisla parcel, tak sme opet u toho, ze zase nekam flaknu bod misto abych oznacil hranici? Je to stejny jako s KU - proc markovat hranice KU, kdyz nekam dovnitr muzu flaknout bod. *** No ja nevim, doposud se to tak nazyvalo v UIR-ADR jako Adresni bod. V RUIAN AdresniMisto, reprezentovane bodem navic s vazbou na budovu (zase bod). *** Reprezentace objektu v OSM je o dohode, jakou miru generalizace prijimame. Napr silnice kreslime jako osy, ikdyz by bylo zdanlive vhodnejsi uzit plochy. Aby mapa mohla fungovat, je nutna mira zjednoduseni skutecnosti. ha hanoj ___ 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
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
Re: [Talk-cz] Data RUIAN - výměnný formát
Č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
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š sh...@typo3-hosting.com 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] Data RUIAN - výměnný formát
Ahoj 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): *** Hodne nam muze pomoci historie editaci a puvod UIR-ADR: 1) vymazat addr body ktere prosly jen hromadnym importem/hromadnou upravou z UIR-ADR (predpokladam ze to bude vetsina) 2) mixovane addr+POI vymazat info o addr a POI tagy v nodu ponechat (cca 1000 nodu) 3) budovy s addr prevest na body (cca 13.000 way) 4) addr ktere se shoduji tagem a polohou z OSM vymazat (polohova shoda do 10m) 5) uplny itinerar to neni, ale vetsinu to snad pokryva, co se zbytkem, se ukaze az pri cinu 6) to co zbyde priradit fixme 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 nas potom ceka CR navzdy bez budov..., vzdyt stavajici tracer mame uz tretim rokem. 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. *** je treba nezapomenout, typ parcely na les/pole/louky vychazeji z nominalni predstavy o urceni hodnoty parcely, nikoliv co na parcele skutecne je/roste/stoji. PS: transformace skrze proj/gdal: * bez parametru towgs presnost 100m * s parametrem towgs presnost 1m (tedy nikoliv 70m) * s parametrem +nadgrids=czech 0,1m ha hanoj ___ 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
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. *** Me slo predevsim o ten tvar budovy... 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). *** Je treba pochopit jak katastr vznika. Jedna se o evidenci majetku, nikdo aktivne nehleda, zda tu budovu nekdo nezboural, ci si nepostavil kralikarnu na dvorku. Zatim jsem techto chyb (absence nebo prezence existujici budovy) videl daleko mene, nez lidovych tvorivosti s tracerem. 1) zadny zbesily import a rozhodne ne zadne mazani v OSM. *** zbesilost je vetsinou v srdci, ne importech. Neni kam spechat. 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). *** Seda je teorie... Jediny zpusob je umoznit aktualizaci je aktualizovat jen primitivni body (napr. addr). U vseho ostatniho je to problem, co s tim kdyz do toho nekdo hrabne. Nebo jak zajistit spravne vazby na existujici objekty. Dosud v OSM probehly jen hromadne upravy adresnich bodu a predevsim relaci administrativnich hranic (ale samotne way hranice jsou uz problem). ha hanoj ___ 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
Dne 26.6.2012 4:14, Jan Bilak napsal(a): 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ř.: node id=296674495 lat=48.9631350 lon=14.5119948 version=2 changeset=1965423 user=Radomír Černoch uid=51295 timestamp=2009-07-28T14:56:31Z tag k=addr:conscriptionnumber v=2030 / tag k=addr:housenumber v=2030/1 / tag k=addr:postcode v=37006 / tag k=addr:street v=U pramene / tag k=addr:streetnumber v=1 / tag k=source:addr v=uir_adr / tag k=uir_adr:ADRESA_KOD v=23398671 / /node node id=1496603658 lat=48.8736400 lon=14.6758775 version=1 changeset=9784174 user=Petr1868 uid=72020 timestamp=2011-11-09T19:54:47Z tag k=addr:conscriptionnumber v=13 / tag k=addr:country v=CZ / tag k=addr:housenumber v=13 / tag k=is_in v=Třebeč, Borovany, Jihočeský kraj, CZ / tag k=source:addr v=mvcr:adresa / tag k=source:loc v=cuzk:km / /node node id=33705330 lat=49.7021197 lon=17.0731786 version=12 changeset=5435557 user=NE2 uid=207745 timestamp=2010-08-08T17:43:41Z tag k=addr:city v=Litovel / tag k=addr:conscriptionnumber v=678 / tag k=addr:country v=CZ / tag k=addr:housenumber v=678/1 / tag k=addr:postcode v=78401 / tag k=addr:street v=Mlýnská / tag k=addr:streetnumber v=1 / tag k=is_in v=Litovel, Olomoucký kraj, CZ / tag k=name v=Penzion U starého mlýna / tag k=source:addr v=mvcr:adresa / tag k=tourism v=hotel / tag k=url v=http://ustarehomlyna.cz; / /node node id=283050015 lat=50.1039117 lon=14.5115490 version=2 changeset=1984279 user=Radomír Černoch uid=51295 timestamp=2009-07-30T12:44:24Z tag k=addr:housenumber v=?/66 / tag k=addr:streetnumber v=66 / tag k=created_by v=Potlatch 0.10b / /node Jak se vlastně jednoznačně/algoritmicky určí, co je a co není adresní bod? Jednoznacne neurci, navic trebas ja(a nejen ja) davam adresy primo na budovu. Adresni bod pouzivam jen v pripade, ze na miste budova uz nestoji, pripadne tam sou po ni uz jen stopy. way id='37346514' timestamp='2009-12-07T13:50:31Z' uid='102554' user='Jezevec' visible='true' version='3' changeset='3316020' nd ref='435504008' / nd ref='435504010' / nd ref='435504011' / nd ref='435504013' / nd ref='435504015' / nd ref='435504016' / nd ref='435504008' / tag k='addr:conscriptionnumber' v='7' / tag k='addr:country' v='CZ' / tag k='addr:housenumber' v='7/4' / tag k='addr:street' v='Školní Park' / tag k='addr:streetnumber' v='4' / tag k='building' v='yes' / tag k='is_in' v='Novosedlice, Ústecký kraj, CZ' / tag k='source' v='cuzk:km' / tag k='source:addr' v='mvcr:adresa' / /way Slinkovat se to da tam kde mas uir_adr:ADRESA_KOD, to je asi celkem jednoznacny, u toho zbytku leda podle adresy, coz samo nebude 100%. Ta posledni varianta, kde je v housenum ? je jeste z doby pred tim, nez padla dohoda ze tam budou obe cisla (orientacni a popisny). Hromadne se to poustelo na celou mapu, takze vsude kde tam je ? to znamena, ze od ty doby tu adresu nikdo neaktualizoval. Proto sem psal, ze v zadnym pripade nejaky hromadny mazani, to by nadelalo vic skody nez uzitku. 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 j...@tpfree.net 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 +-
Re: [Talk-cz] Data RUIAN - výměnný formát
Zdravím, katastr zachycuje *právní* stav, nikoliv realitu. Takže je určitě hodně budouv, které jsou na mapách a ve skutečnosti neexistují (zrovna o víkendu jsme jezdili po zaniklých vesnicích v Českém lese a některé budovy stále ještě v mapách KN jsou) nebo ve skutečnosti existují, ale v mapách KN nejsou (buď černé stavby, nebo stavby, které nejsou předmětem evidence v katastru). Uliční čáry jsou (budou). Jedná se o import ze ZABAGED. J. Veselý Původní zpráva Od: Jan Bilak jan.bilak@gmail.com Předmět: Re: [Talk-cz] Data RUIAN - výměnný formát Datum: 25.6.2012 01:36:52 (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: vf:Ulicevf:Ulice gml:id=UL.454281uli:Kod454281/uli:Koduli:NazevLešanská/uli:Nazevuli:Obecobi:Kod554782/obi:Kod/uli:Obeculi:PlatiOd2011-07-01T00:00:00/uli:PlatiOduli:IdTransakce0/uli:IdTransakceuli:GlobalniIdNavrhuZmeny0/uli:GlobalniIdNavrhuZmenyuli:Geometrieuli:DefinicniCaragml:MultiCurve gml:id=DUL.454281.X srsName=urn:ogc:def:crs:EPSG::2065 srsDimension=2gml:curveMembergml:LineString gml:id=DUL.454281gml:posList738883.65 1048327.51 738848.15 1048382.19 738819.05 1048435.52/gml:posList/gml:LineString/gml:curveMember/gml:MultiCurve/uli:DefinicniCara/uli:Geometrie/vf:Ulice 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 ___ 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
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
Re: [Talk-cz] Data RUIAN - výměnný formát
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ř.: node id=296674495 lat=48.9631350 lon=14.5119948 version=2 changeset=1965423 user=Radomír Černoch uid=51295 timestamp=2009-07-28T14:56:31Z tag k=addr:conscriptionnumber v=2030 / tag k=addr:housenumber v=2030/1 / tag k=addr:postcode v=37006 / tag k=addr:street v=U pramene / tag k=addr:streetnumber v=1 / tag k=source:addr v=uir_adr / tag k=uir_adr:ADRESA_KOD v=23398671 / /node node id=1496603658 lat=48.8736400 lon=14.6758775 version=1 changeset=9784174 user=Petr1868 uid=72020 timestamp=2011-11-09T19:54:47Z tag k=addr:conscriptionnumber v=13 / tag k=addr:country v=CZ / tag k=addr:housenumber v=13 / tag k=is_in v=Třebeč, Borovany, Jihočeský kraj, CZ / tag k=source:addr v=mvcr:adresa / tag k=source:loc v=cuzk:km / /node node id=33705330 lat=49.7021197 lon=17.0731786 version=12 changeset=5435557 user=NE2 uid=207745 timestamp=2010-08-08T17:43:41Z tag k=addr:city v=Litovel / tag k=addr:conscriptionnumber v=678 / tag k=addr:country v=CZ / tag k=addr:housenumber v=678/1 / tag k=addr:postcode v=78401 / tag k=addr:street v=Mlýnská / tag k=addr:streetnumber v=1 / tag k=is_in v=Litovel, Olomoucký kraj, CZ / tag k=name v=Penzion U starého mlýna / tag k=source:addr v=mvcr:adresa / tag k=tourism v=hotel / tag k=url v=http://ustarehomlyna.cz; / /node node id=283050015 lat=50.1039117 lon=14.5115490 version=2 changeset=1984279 user=Radomír Černoch uid=51295 timestamp=2009-07-30T12:44:24Z tag k=addr:housenumber v=?/66 / tag k=addr:streetnumber v=66 / tag k=created_by v=Potlatch 0.10b / /node 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 j...@tpfree.net 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,
Re: [Talk-cz] Data RUIAN - výměnný formát
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š sh...@typo3-hosting.com 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š sh...@typo3-hosting.com 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
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ý j@seznam.cz 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 jan.bilak@gmail.com] To: OpenStreetMap Czech Republic [mailto:talk-cz@openstreetmap.**org 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-czhttp://lists.openstreetmap.org/listinfo/talk-cz __**_ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-czhttp://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
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 jan.bilak@gmail.com 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ý j@seznam.cz 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
Je to tak, stavové jednou za měsíc a změny denně. Vše bude dostupné ke stažení, jména souborů bude možné odvodit podle datumu. Zatím předpokládáme držení historie 3 měsíce zpětně. J. V. Dne 24.6.2012 18:49, Jan Bilak napsal(a): 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 Bilakjan.bilak@gmail.com 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ýj@seznam.cz 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 ___ 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
Zdravím, EPSG:2065 je chyba v této verzi - bude opraveno na (pravděpodobně) EPSG:5514. Bohužel ale nedovedu říct kdy se to povede. Nějaké prohlížeče kolegové testují - pokud se osvědčí, tak to sem postnu. J. Veselý Původní zpráva Od: hanoj eha...@gmail.com Předmět: Re: [Talk-cz] Data RUIAN - výměnný formát Datum: 22.6.2012 13:48:40 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
Re: [Talk-cz] Data RUIAN - výměnný formát
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
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 Dne 22. června 2012 18:37 Martin Kokeš sh...@typo3-hosting.com 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] Data RUIAN - výměnný formát
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
Re: [Talk-cz] Data RUIAN - výměnný formát
Nějaké příklady...
Striptýz XSL (vyhází namespacy, spoléháme 100% na ČÚZK ;-)... ):
xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xsl:template match=*
xsl:element name={local-name()}
xsl:apply-templates select=@*|node()/
/xsl:element
/xsl:template
xsl:template match=@*
xsl:attribute name={local-name()}
xsl:value-of select=. /
/xsl:attribute
/xsl:template
/xsl:stylesheet
Primitivní výcuc budov XSL:
?xml version=1.0 encoding=UTF-8 ?
xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xsl:template match=/
ogr:FeatureCollection
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://ogr.maptools.org/;
xmlns:ogr=http://ogr.maptools.org/; xmlns:gml=http://www.opengis.net/gml;
xsl:for-each
select=VymennyFormat/Data/StavebniObjekty/StavebniObjekt
xsl:if test=Geometrie/OriginalniHranice
gml:featureMember
ogr:stavebniobjekty fid={Kod}
ogr:geometryProperty
xsl:copy-of
select=Geometrie/OriginalniHranice/
/ogr:geometryProperty
ogr:Kod
xsl:value-of
select=Kod/
/ogr:Kod
ogr:CislaDomovni
xsl:value-of
select=CislaDomovni/
/ogr:CislaDomovni
ogr:TypStavebnihoObjektuKod
xsl:value-of
select=TypStavebnihoObjektuKod/
/ogr:TypStavebnihoObjektuKod
ogr:CastObce
xsl:value-of
select=CastObce/Kod/
/ogr:CastObce
/ogr:stavebniobjekty
/gml:featureMember
/xsl:if
/xsl:for-each
/ogr:FeatureCollection
/xsl:template
/xsl:stylesheet
Atd...
MK
- Original Message -
From: Martin Kokeš
[mailto:sh...@typo3-hosting.com]
To: OpenStreetMap Czech Republic
[mailto:talk-cz@openstreetmap.org]
Sent: Fri, 22 Jun 2012 18:37:33
+0200
Subject: Re: [Talk-cz] Data RUIAN - výměnný formát
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] 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š sh...@typo3-hosting.com 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
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š sh...@typo3-hosting.com 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
