> Po spuštění Veřejného dálkového přístupu k RUIAN budou data dostupná přes tuto aplikaci.

> ------------ Původní zpráva ------------ > Od: hanoj <ehanoj na 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > >

> Ahoj,

> Po spuštění Veřejného dálkového přístupu k RUIAN budou > data dostupná přes tuto aplikaci.

> uziva EPSG:2065, kdyz na data se bezne uziva ESRI:102067?

> osvedceny prohlizec, ktery umi data zobrazit krome

> registraci?

> jsou pro plne automaticky import pouzitelne

> (v dubnu 2012 55% CR):

> (building=*)

> Misto.

> mailing > list

> 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:ehanoj na gmail.com] > To: > OpenStreetMap Czech Republic [mailto:talk-cz na 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> 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

> 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.

> ku, hranice obce (nic moc), hranice parcel, hranice budov, budovy jako body, > adresni místa jako body... s většinou atributů.

> 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í.

> [mailto:ehanoj na gmail.com]

> [mailto:talk-cz na openstreetmap.org]

> +0200

> Ahoj,

> Po > spuštění Veřejného dálkového přístupu k RUIAN budou > data > dostupná přes tuto aplikaci.

> > uziva EPSG:2065, kdyz na data se bezne uziva ESRI:102067?

> > osvedceny prohlizec, ktery umi data zobrazit krome

> > registraci?

> > jsou pro plne automaticky import pouzitelne

> DKM > (v dubnu 2012 55% CR):

> > (building=*)

> > Misto.

> > mailing > > list

> mailing > list

> Jelikož se všude používá nativně Křovák, je nutná zpřesněná transformace pomocí S-JTSK gridu. > > MK

> 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š <shr3k na 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> 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.osm na gmail.com] > To: OpenStreetMap Czech Republic > [mailto:talk-cz na 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š <shr3k na 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 na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> 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 na gmail.com] > To: OpenStreetMap Czech Republic > [mailto:talk-cz na 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> 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 na gmail.**com <jan.bilak.osm na gmail.com>] >> To: OpenStreetMap Czech Republic >> [mailto:talk-cz na openstreetmap.**org <talk-cz na 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 na openstreetmap.org >> http://lists.openstreetmap.**org/listinfo/talk-cz<http://lists.openstreetmap.org/listinfo/talk-cz> >> > > > ______________________________**_________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.**org/listinfo/talk-cz<http://lists.openstreetmap.org/listinfo/talk-cz> >

> 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.v.2 na 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 na gmail.com] >>> To: OpenStreetMap Czech Republic >>> [mailto:talk-cz na 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 na openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz

> 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.osm na 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.v.2 na 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 na gmail.com] >>>> To: OpenStreetMap Czech Republic >>>> [mailto:talk-cz na 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 na openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

>(nebo jsou data nesprávná - např. jiný tvar obrys budovy).

> 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...

> 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.

>>(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.

>> 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.

> ------------ Původní zpráva ------------ > Od: Jan Bilak <jan.bilak.osm na 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:Ulice><vf:Ulice > gml:id="UL.454281"><uli:Kod>454281</uli:Kod><uli:Nazev>Lešanská</uli:Nazev><uli:Obec><obi:Kod>554782</obi:Kod></uli:Obec><uli:PlatiOd>2011-07-01T00:00:00</uli:PlatiOd><uli:IdTransakce>0</uli:IdTransakce><uli:GlobalniIdNavrhuZmeny>0</uli:GlobalniIdNavrhuZmeny><uli:Geometrie><uli:DefinicniCara><gml:MultiCurve > gml:id="DUL.454281.X" srsName="urn:ogc:def:crs:EPSG::2065" > srsDimension="2"><gml:curveMember><gml:LineString > gml:id="DUL.454281"><gml:posList>738883.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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > >

>> (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.

> >> 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> 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 na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> 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.

> 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ř.: >> >>       <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> > > 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 > >>       <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> > > 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". > >>       <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> > > 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ě. > >>       <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> > > 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> 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 <lpechacek na gmx.com> 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ř.: > >> > >>       <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> > > > > 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 > > > >>       <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> > > > > 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". > > > >>       <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> > > > > 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ě. > > > >>       <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> > > > > 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 na openstreetmap.org > > http://lists.openstreetmap.org/listinfo/talk-cz > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> Ahoj Honzo,

> návrhem.

> addr:streetnumber,

> proto, že často obsahuje

> nelze odvodit. Pokud někdo najde

> is_in, jsem pro.

> která ponese addr:street a

> body by v tom případě měly jen

> addr:conscriptionnumber. Otázkou je, jak

> vypadat[2].

> pokud neposlouží

> http://wiki.openstreetmap.org/wiki/Key:is_in#Controversy

> zřejmě připadá

> http://wiki.openstreetmap.org/wiki/Relations/Proposed/Collected_Ways,

> http://wiki.openstreetmap.org/wiki/Relations/Proposed/Street nebo

> http://wiki.openstreetmap.org/wiki/Relation:associatedStreet

> 26-06-12 16:12:11, Jan Bilak wrote: > 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 <lpechacek na gmx.com> 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ř.: > > >> > >>       <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> > > > > 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 > > > > >>       <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> > > > > 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". > > > >>       <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> > > > > 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ě. > > > >>       <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> > > > > 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 na openstreetmap.org > > > http://lists.openstreetmap.org/listinfo/talk-cz > > > _______________________________________________ > Talk-cz mailing list > > Talk-cz na openstreetmap.org > > http://lists.openstreetmap.org/listinfo/talk-cz

>

> list

> 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 <jzvc na 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, 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 na openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> Ahoj Honzo, > > Zabral jsem se do detailů a nějak zapomněl uzavřít návrhem. > > Jsem pro požití tagů addr:housenumber, addr:streetnumber, > addr:conscriptionnumber, addr:street a is_in. Is_in proto, že často obsahuje > informaci o městských částech, kterou z mapy nelze odvodit. Pokud někdo najde > nějakou hypoalergenní[1] variantu k is_in, jsem pro. > > 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].

> > Addr:postcode, addr:city a addr:country bych klidně zahodil, pokud neposlouží > jako náhrada is_in. > > Libor > > [1] http://wiki.openstreetmap.org/wiki/Key:is_in#Controversy > [2] v úvahu zřejmě připadá > http://wiki.openstreetmap.org/wiki/Relations/Proposed/Collected_Ways, > http://wiki.openstreetmap.org/wiki/Relations/Proposed/Street nebo > http://wiki.openstreetmap.org/wiki/Relation:associatedStreet > > On Tue 26-06-12 16:12:11, Jan Bilak wrote: >> 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 <lpechacek na gmx.com> 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ř.: >>>> >>>> <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> >>> 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 >>> >>>> <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> >>> 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". >>> >>>> <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> >>> 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ě. >>> >>>> <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> >>> 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 na openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz

> 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> Dne 26.6.2012 19:21, Libor Pechacek napsal(a): > > Ahoj Honzo, > > > > Zabral jsem se do detailů a nějak zapomněl uzavřít návrhem. > > > > Jsem pro požití tagů addr:housenumber, addr:streetnumber, > > addr:conscriptionnumber, addr:street a is_in. Is_in proto, že často obsahuje > > informaci o městských částech, kterou z mapy nelze odvodit. Pokud někdo najde > > nějakou hypoalergenní[1] variantu k is_in, jsem pro. > > > > 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.

> 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.

> Priklad http://nominatim.openstreetmap.org/details.php?place_id=43709385

> PSC je naopak identifikator, ktery muze byt v ramci stejneho > katastralniho uzemi ruzny, tudiz rozhodne ponechat. Uvedom si, ze > nektere podniky maji vlastni psc. Nehlede na to, ze pokud si pamatuju, > vedla se tu na to tema uz nejaka diskuse, a prakticky nikdo neni schopen > rict, odkud kam je nejake konkretni psc.

> country a city ... country je asi na vyhozeni, u city .... tam je to > takove trochu sporne, neb by IMO adresa mela byt "komplet" - zkratka > kdyz si sosnu vyrez mapy, tak bych z toho tagovani mel byt schopen tu > adresu dohledat kdekoli a nemuset si kvuli tomu stahovat cely mesto. Ale > technicky to samozrejme nadbytecny je.

> > > > Addr:postcode, addr:city a addr:country bych klidně zahodil, pokud neposlouží > > jako náhrada is_in. > > > > Libor > > > > [1] http://wiki.openstreetmap.org/wiki/Key:is_in#Controversy > > [2] v úvahu zřejmě připadá > > http://wiki.openstreetmap.org/wiki/Relations/Proposed/Collected_Ways, > > http://wiki.openstreetmap.org/wiki/Relations/Proposed/Street nebo > > http://wiki.openstreetmap.org/wiki/Relation:associatedStreet > > > > On Tue 26-06-12 16:12:11, Jan Bilak wrote: > >> 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 <lpechacek na gmx.com> 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ř.: > >>>> > >>>> <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> > >>> 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 > >>> > >>>> <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> > >>> 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". > >>> > >>>> <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> > >>> 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ě. > >>> > >>>> <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> > >>> 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 na openstreetmap.org > >>> http://lists.openstreetmap.org/listinfo/talk-cz > >> _______________________________________________ > >> Talk-cz mailing list > >> Talk-cz na openstreetmap.org > >> http://lists.openstreetmap.org/listinfo/talk-cz > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> On Wed 27-06-12 09:22:24, jzvc wrote: >> Dne 26.6.2012 19:21, Libor Pechacek napsal(a): >>> Ahoj Honzo, >>> >>> Zabral jsem se do detailů a nějak zapomněl uzavřít návrhem. >>> >>> Jsem pro požití tagů addr:housenumber, addr:streetnumber, >>> addr:conscriptionnumber, addr:street a is_in. Is_in proto, že často obsahuje >>> informaci o městských částech, kterou z mapy nelze odvodit. Pokud někdo najde >>> nějakou hypoalergenní[1] variantu k is_in, jsem pro. >>> >>> 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". > >> 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í. > >> Priklad http://nominatim.openstreetmap.org/details.php?place_id=43709385 > Protipříklad http://nominatim.openstreetmap.org/details.php?place_id=14212965 > > Nominatim podle administrativní hranice odvodil příslušnost k Pískové Lhotě, > ale tento dům je v Pískové Lhotě - Zámostí. Písková Lhota 8 je tady: > http://www.openstreetmap.org/browse/node/1238981111 > > Zřejmě bych dovedl najít i příklad kde je v jednom KÚ více obcí s různými > jmény. > >> PSC je naopak identifikator, ktery muze byt v ramci stejneho >> katastralniho uzemi ruzny, tudiz rozhodne ponechat. Uvedom si, ze >> nektere podniky maji vlastni psc. Nehlede na to, ze pokud si pamatuju, >> vedla se tu na to tema uz nejaka diskuse, a prakticky nikdo neni schopen >> rict, odkud kam je nejake konkretni psc. > Já osobně PSČ k vyhledání adres nepoužívám, ale nejsem proti přidání tohoto > údaje. > >> country a city ... country je asi na vyhozeni, u city .... tam je to >> takove trochu sporne, neb by IMO adresa mela byt "komplet" - zkratka >> kdyz si sosnu vyrez mapy, tak bych z toho tagovani mel byt schopen tu >> adresu dohledat kdekoli a nemuset si kvuli tomu stahovat cely mesto. Ale >> technicky to samozrejme nadbytecny je. > Jak vidno výše, Nominatim nášemu formátu is_in asi nerozumí. Jestli porozumí > addr:city, použijme ten. > > Libor > >>> Addr:postcode, addr:city a addr:country bych klidně zahodil, pokud neposlouží >>> jako náhrada is_in. >>> >>> Libor >>> >>> [1] http://wiki.openstreetmap.org/wiki/Key:is_in#Controversy >>> [2] v úvahu zřejmě připadá >>> http://wiki.openstreetmap.org/wiki/Relations/Proposed/Collected_Ways, >>> http://wiki.openstreetmap.org/wiki/Relations/Proposed/Street nebo >>> http://wiki.openstreetmap.org/wiki/Relation:associatedStreet >>> >>> On Tue 26-06-12 16:12:11, Jan Bilak wrote: >>>> 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 <lpechacek na gmx.com> 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ř.: >>>>>> >>>>>> <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> >>>>> 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 >>>>> >>>>>> <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> >>>>> 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". >>>>> >>>>>> <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> >>>>> 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ě. >>>>> >>>>>> <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> >>>>> 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 na openstreetmap.org >>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz na openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz

> 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.

> Tohle je pekny, ale uvital bych SVG. > <obi:VlajkaText>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.</obi:VlajkaText> > <obi:ZnakText>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.</obi:ZnakText>

> > 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í.

> > > 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".

> 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. >> <obi:VlajkaText>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.</obi:VlajkaText> >> <obi:ZnakText>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.</obi:ZnakText> > 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

>>> 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. > > S tim se pocita, data v tech samplech jsou reseny jak sem si vsim tak, > ze jedna adresa, je zvolena jako "primarni" a dalsi jsou k ni pripojeny > jako sekundarni => na budovu se da ta primarni, ostatni se muzou hodit > jako body. > > Samo, technicky spravne by bylo to na tu budovu nahazet podobne, jako je > to ve zdroji, ale to se obavam v OSM netusim jak udelat, aby to zaroven > fungovalo - idealni by bylo neco jako hodit tu budovu do relace a adresu > urcit az v ty relaci, cimz by slo budove dat neomezeny mnozstvi > relaci/adres, ale obavam se, ze tohle zadnej stavajici nastroj > nepobere.  Ostatne, podobne bych si doved predstavit i prilinkovani veci > jako "hospoda" (+samo nazev, otviracka, ...), posilovna ... , cimz by se > eliminoval vsemoznej tagovaci chaos (pokud na necem je 20+ tagu, tak uz > je to peknej bordelak) a navrch by souvisejici data byly pekne > pohromade. Du testnout, co neco takovyho udela ;D. > > Jinak, pokud predpokladam, ze vetsina km vypada vsude +- stejne, tak > zaroven predpokladam, ze v drtivy vetsine pripadu budou klasicky > panelaky zaneseny co vhod to samostatna budova (i kdyz to konstrukcne > neni pravda). > Budov s vice adresami nebude (IMO) nijak zavratny mnoztvi.

> 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.

> 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).

> 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?

> 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?

> +rf=299.1528128 +no_defs

> -t_srs

> +no_defs

> /data/gis/READ-ONLY/cechy.tif

> Copyright 2005 Zdenek Hrdina, distribute under GPLv2

> jtsk_wgs( X,Y,Hel:double; var B,L,H:double);

> v systemu WGS-84 z rovinnych souradnic

> vysky}

> zemepisnych souradnic z JTSK do WGS}

> lat,lon,alt,x1,y1,z1,x2,y2,z2:double;

> vygooglit.

> pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

> mailing > list

> Č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:pavel na ucw.cz] > To: > OpenStreetMap Czech Republic [mailto:talk-cz na 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> 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š <shr3k na 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:pavel na ucw.cz] > > To: > > OpenStreetMap Czech Republic [mailto:talk-cz na 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 na openstreetmap.org > > http://lists.openstreetmap.org/listinfo/talk-cz > > > > _______________________________________________ > > Talk-cz mailing list > > Talk-cz na openstreetmap.org > > http://lists.openstreetmap.org/listinfo/talk-cz > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> 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.osm na gmail.com] > To: OpenStreetMap Czech Republic > [mailto:talk-cz na 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š <shr3k na 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:pavel na ucw.cz] >> > To: >> > OpenStreetMap Czech Republic [mailto:talk-cz na 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 na openstreetmap.org >> > http://lists.openstreetmap.org/listinfo/talk-cz >> > >> > _______________________________________________ >> > Talk-cz mailing list >> > Talk-cz na openstreetmap.org >> > http://lists.openstreetmap.org/listinfo/talk-cz >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> 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):

> 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.

> 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> 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.

>>> 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?

> 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.

> >>> 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.

> 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š <shr3k na typo3-hosting.com> > 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.osm na gmail.com] > > To: OpenStreetMap Czech Republic > > [mailto:talk-cz na 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š <shr3k na 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:pavel na ucw.cz] > >> > To: > >> > OpenStreetMap Czech Republic [mailto:talk-cz na 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 na openstreetmap.org > >> > http://lists.openstreetmap.org/listinfo/talk-cz > >> > > >> > _______________________________________________ > >> > Talk-cz mailing list > >> > Talk-cz na openstreetmap.org > >> > http://lists.openstreetmap.org/listinfo/talk-cz > >> > >> _______________________________________________ > >> Talk-cz mailing list > >> Talk-cz na openstreetmap.org > >> http://lists.openstreetmap.org/listinfo/talk-cz > >> > > > > _______________________________________________ > > Talk-cz mailing list > > Talk-cz na openstreetmap.org > > http://lists.openstreetmap.org/listinfo/talk-cz > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> Jaká je šance hromadně opravit třeba toto > > http://keepright.ipax.at/report_map.php?lat=50.592556919313&lon=15.140419006315&zoom=14 > > nebo to opravovat už teď a ručně?

> 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ů.

> Dají se takové objekty (oblasti) označit a vyloučit z aktualizace?

> 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 ...

> 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