Data RUIAN - výměnný formát

33 zpráv
Zpět na přehled

Data RUIAN - výměnný formát

33 zpráv JHMJJPPL 9 účastníků 29 min čtení
  1. JV j.v.2 na seznam.cz #m77c497
    Dobrý den, na adrese http://www.cuzk.cz/Dokument.aspx?AKCE=DOC:10-VFR je popis výměnného formátu RUIAN. Data k 8.6. jsou dostupná na adrese http://www.cuzk.cz/Dokument.aspx?PRARESKOD=998&MENUID=10769&AKCE=DOC:10-POSKYTOVANI_UDAJU_Z_ISUI_RUIAN Po spuštění Veřejného dálkového přístupu k RUIAN budou data dostupná přes tuto aplikaci. Přeji příjemný den Jiří Veselý
  2. hanoj ehanoj na gmail.com #mb478ea
    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
  3. JV j.v.2 na seznam.cz #mafff87
    Zdravím, EPSG:2065 je chyba v této verzi - bude opraveno na (pravděpodobně) EPSG:5514. Bohužel ale nedovedu říct kdy se to povede. Nějaké prohlížeče kolegové testují - pokud se osvědčí, tak to sem postnu. J. Veselý
  4. Martin Kokeš shr3k na typo3-hosting.com #mee0cde
    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
  5. Jan Bilak jan.bilak.osm na gmail.com #m6a325f
    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
  6. Martin Kokeš shr3k na typo3-hosting.com #m88c7e2
    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
  7. Martin Kokeš shr3k na typo3-hosting.com #m48c2d6
    Nějaké příklady... Striptýz XSL (vyhází namespacy, spoléháme 100% na ČÚZK ;-)... ): <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:template match="*"> <xsl:element name="{local-name()}" > <xsl:apply-templates select="@*|node()"/> </xsl:element> </xsl:template> <xsl:template match="@*"> <xsl:attribute name="{local-name()}"> <xsl:value-of select="." /> </xsl:attribute> </xsl:template> </xsl:stylesheet> Primitivní výcuc budov XSL: <?xml version="1.0" encoding="UTF-8" ?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:template match="/"> <ogr:FeatureCollection xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://ogr.maptools.org/" xmlns:ogr="http://ogr.maptools.org/" xmlns:gml="http://www.opengis.net/gml"> <xsl:for-each select="VymennyFormat/Data/StavebniObjekty/StavebniObjekt"> <xsl:if test="Geometrie/OriginalniHranice"> <gml:featureMember> <ogr:stavebniobjekty fid="{Kod}"> <ogr:geometryProperty> <xsl:copy-of select="Geometrie/OriginalniHranice"/> </ogr:geometryProperty> <ogr:Kod> <xsl:value-of select="Kod"/> </ogr:Kod> <ogr:CislaDomovni> <xsl:value-of select="CislaDomovni"/> </ogr:CislaDomovni> <ogr:TypStavebnihoObjektuKod> <xsl:value-of select="TypStavebnihoObjektuKod"/> </ogr:TypStavebnihoObjektuKod> <ogr:CastObce> <xsl:value-of select="CastObce/Kod"/> </ogr:CastObce> </ogr:stavebniobjekty> </gml:featureMember> </xsl:if> </xsl:for-each> </ogr:FeatureCollection> </xsl:template> </xsl:stylesheet> Atd... MK
  8. Jan Bilak jan.bilak.osm na gmail.com #m298a27
    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
  9. Martin Kokeš shr3k na typo3-hosting.com #m111edc
    Ahoj, viz http://grass.fsv.cvut.cz/gwiki/S-JTSK-Grid, cokoliv co používá GDAL/PROJ4. MK
  10. Jan Bilak jan.bilak.osm na gmail.com #m0dc1df
    Ahoj, díky, transformace souřadnic vypadá v pohodě (testovacím příkladem to prošlo). Teď je otázka, jakou celkovou strategii importu a následných aktualizací zvolit. Zveřejněná data registru neobsahují některé informace o celé ČR, ale jen o částech, ve kterých je digitalizovaný katastr. Dále nevím, do jaké míry katastr odpovídá realitě, ale tipuji, že určitě budou budovy, které v katastru nejsou a opačně (nebo jsou data nesprávná - např. jiný tvar obrys budovy). Data mohu obsahovat více upřesňujících tagů. Je tedy možné (pravděpodobné), že některá data budou lepší v OSM než v datech registru. Uliční čáry musí nějak rozumně na sebe navazovat... Na druhou stranu registr má jistě celkově velkou míru konzistence a úplnosti, bude se průběžně rozšiřovat území, kde jsou dostupné všechny informace a bude se průběžně aktualizovat, ... Které konrétní údaje z registru se budou do OSM importovat? Jak se vypořádat se starými daty? Za ideální cílový stav bych považovat navázání dat na registr kvůli aktualizacím, ale s možnost provádění všech typů změn, pokud registr někde nebude správný, úplný nebo bude k dispozici více informací, než které registr obsahuje. Celkově jde o poměrně mnoho dat (v XML to má necelých 30 GB, i přes ukecanost XML je toho opravdu hodně), takže jakékoli větší ruční zásahy do importu budou časově náročné. Máte nějakou představu, nápady, ...? Honza
  11. Jiří Veselý j.v.2 na seznam.cz #m6b7867
    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ý
  12. Jan Bilak jan.bilak.osm na gmail.com #mdd1f75
    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
  13. Jan Bilak jan.bilak.osm na gmail.com #m27cdfb
    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
  14. Jiří Veselý j.v.2 na seznam.cz #m9a852c
    Je to tak, stavové jednou za měsíc a změny denně. Vše bude dostupné ke stažení, jména souborů bude možné odvodit podle datumu. Zatím předpokládáme držení historie 3 měsíce zpětně. J. V.
  15. hanoj ehanoj na gmail.com #me69bc1
    (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
  16. Jan Bilak jan.bilak.osm na gmail.com #m84b0ef
    (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
  17. JV j.v.2 na seznam.cz #md3201a
    Zdravím, katastr zachycuje *právní* stav, nikoliv realitu. Takže je určitě hodně budouv, které jsou na mapách a ve skutečnosti neexistují (zrovna o víkendu jsme jezdili po zaniklých vesnicích v Českém lese a některé budovy stále ještě v mapách KN jsou) nebo ve skutečnosti existují, ale v mapách KN nejsou (buď černé stavby, nebo stavby, které nejsou předmětem evidence v katastru). Uliční čáry jsou (budou). Jedná se o import ze ZABAGED. J. Veselý
  18. jzvc jzvc na tpfree.net #md3837d
    (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).
  19. Jan Bilak jan.bilak.osm na gmail.com #me9b348
    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
  20. jzvc jzvc na tpfree.net #mb82254
    Ahoj, jak vypadá ideální zápis adresního bodu v OSM XML? Koukal jsem se do snapshotu OSM dat ČR a zápisy nemají jednotný formát. Např.: <node id="296674495" lat="48.9631350" lon="14.5119948" version="2" changeset="1965423" user="Radomír Černoch" uid="51295" timestamp="2009-07-28T14:56:31Z"> <tag k="addr:conscriptionnumber" v="2030" /> <tag k="addr:housenumber" v="2030/1" /> <tag k="addr:postcode" v="37006" /> <tag k="addr:street" v="U pramene" /> <tag k="addr:streetnumber" v="1" /> <tag k="source:addr" v="uir_adr" /> <tag k="uir_adr:ADRESA_KOD" v="23398671" /> </node> <node id="1496603658" lat="48.8736400" lon="14.6758775" version="1" changeset="9784174" user="Petr1868" uid="72020" timestamp="2011-11-09T19:54:47Z"> <tag k="addr:conscriptionnumber" v="13" /> <tag k="addr:country" v="CZ" /> <tag k="addr:housenumber" v="13" /> <tag k="is_in" v="Třebeč, Borovany, Jihočeský kraj, CZ" /> <tag k="source:addr" v="mvcr:adresa" /> <tag k="source:loc" v="cuzk:km" /> </node> <node id="33705330" lat="49.7021197" lon="17.0731786" version="12" changeset="5435557" user="NE2" uid="207745" timestamp="2010-08-08T17:43:41Z"> <tag k="addr:city" v="Litovel" /> <tag k="addr:conscriptionnumber" v="678" /> <tag k="addr:country" v="CZ" /> <tag k="addr:housenumber" v="678/1" /> <tag k="addr:postcode" v="78401" /> <tag k="addr:street" v="Mlýnská" /> <tag k="addr:streetnumber" v="1" /> <tag k="is_in" v="Litovel, Olomoucký kraj, CZ" /> <tag k="name" v="Penzion U starého mlýna" /> <tag k="source:addr" v="mvcr:adresa" /> <tag k="tourism" v="hotel" /> <tag k="url" v="http://ustarehomlyna.cz" /> </node> <node id="283050015" lat="50.1039117" lon="14.5115490" version="2" changeset="1984279" user="Radomír Černoch" uid="51295" timestamp="2009-07-30T12:44:24Z"> <tag k="addr:housenumber" v="?/66" /> <tag k="addr:streetnumber" v="66" /> <tag k="created_by" v="Potlatch 0.10b" /> </node> Jak se vlastně jednoznačně/algoritmicky určí, co je a co není adresní bod?
    Jednoznacne neurci, navic trebas ja(a nejen ja) davam adresy primo na budovu. Adresni bod pouzivam jen v pripade, ze na miste budova uz nestoji, pripadne tam sou po ni uz jen stopy. <way id='37346514' timestamp='2009-12-07T13:50:31Z' uid='102554' user='Jezevec' visible='true' version='3' changeset='3316020'> <nd ref='435504008' /> <nd ref='435504010' /> <nd ref='435504011' /> <nd ref='435504013' /> <nd ref='435504015' /> <nd ref='435504016' /> <nd ref='435504008' /> <tag k='addr:conscriptionnumber' v='7' /> <tag k='addr:country' v='CZ' /> <tag k='addr:housenumber' v='7/4' /> <tag k='addr:street' v='Školní Park' /> <tag k='addr:streetnumber' v='4' /> <tag k='building' v='yes' /> <tag k='is_in' v='Novosedlice, Ústecký kraj, CZ' /> <tag k='source' v='cuzk:km' /> <tag k='source:addr' v='mvcr:adresa' /> </way> Slinkovat se to da tam kde mas uir_adr:ADRESA_KOD, to je asi celkem jednoznacny, u toho zbytku leda podle adresy, coz samo nebude 100%. Ta posledni varianta, kde je v housenum ? je jeste z doby pred tim, nez padla dohoda ze tam budou obe cisla (orientacni a popisny). Hromadne se to poustelo na celou mapu, takze vsude kde tam je ? to znamena, ze od ty doby tu adresu nikdo neaktualizoval. Proto sem psal, ze v zadnym pripade nejaky hromadny mazani, to by nadelalo vic skody nez uzitku.
  21. hanoj ehanoj na gmail.com #m40ef39
    (nebo jsou data nesprávná - např. jiný tvar obrys budovy).
    *** No katastr, uznává tuším styk budovy se zemí jako reprezentující a vzhledem k tomu že to dosud od něj obkreslujem asi by to chtělo uznat za standard.
    Tak to pozor, km sice pouzivam jako jeden z primarnich zdroju, ale vzdycky minimalne kontroluju, jestli tam ta budova +- opravdu stoji.
    *** Me slo predevsim o ten tvar budovy...
    A pripadu kdy v km budova je, ale fyzicky tam neni po budove ani pamatky (= ani ruiny), pripadne naopak, budova si na miste vesele stoji, zato po ni ani pamatky neni v km (a to vcetne toho, ze budova ma i vlastni cp) nejsou zadnou vyjimkou, narazim na takove pri kazde editaci mapy. Zrovna tento tyden sem odmazaval zborene budovy, ktere v km vesele stale jsou (a to jsou zborene uz minimalne par let).
    *** Je treba pochopit jak katastr vznika. Jedna se o evidenci majetku, nikdo aktivne nehleda, zda tu budovu nekdo nezboural, ci si nepostavil kralikarnu na dvorku. Zatim jsem techto chyb (absence nebo prezence existujici budovy) videl daleko mene, nez lidovych tvorivosti s tracerem.
    1) zadny zbesily import a rozhodne ne zadne mazani v OSM.
    *** zbesilost je vetsinou v srdci, ne importech. Neni kam spechat.
    Co se aktualizaci tyce - pokud dojde ke zmene v km a neni zadna zmena na strane osm, tak asi neni co resit - aktualizace v osm. Pokud ke zmene dojde opacne, tak dost pochybuju ze nekdo zmeni neco v km. Pokud je zmena oboustrana, tak asi leda tak, ze nekdo koukne do osm a bud prohlasi, ze se to ma syncnou s km nebo prohlasi, ze data sou spravne v osm (a nejakym marknutim objektu ho vyradi ze synchronizace).
    *** Seda je teorie... Jediny zpusob je umoznit aktualizaci je aktualizovat jen primitivni body (napr. addr). U vseho ostatniho je to problem, co s tim kdyz do toho nekdo hrabne. Nebo jak zajistit spravne vazby na existujici objekty. Dosud v OSM probehly jen hromadne upravy adresnich bodu a predevsim relaci administrativnich hranic (ale samotne way hranice jsou uz problem). ha hanoj
  22. Pavel Machek pavel na ucw.cz #m7828a1
    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.
  23. Martin Kokeš shr3k na typo3-hosting.com #mabb002
    Č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
  24. Jan Bilak jan.bilak.osm na gmail.com #m060ab0
    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
  25. Martin Kokeš shr3k na typo3-hosting.com #ma38947
    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
  26. Jan Bilak jan.bilak.osm na gmail.com #mbf6fbe
    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
  27. hanoj ehanoj na gmail.com #me68dc9
    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
  28. jzvc jzvc na tpfree.net #mdb4e82
    Ahoj
    Takže v první fázi udělat program, který porovná stav v OSM a v RUIAN. Jak by měl vypadat výstup tohoto porovnání? Může nastat mnoho případů (nejde o disjunktní případy):
    *** Hodne nam muze pomoci historie editaci a puvod UIR-ADR: 1) vymazat addr body ktere prosly jen hromadnym importem/hromadnou upravou z UIR-ADR (predpokladam ze to bude vetsina)
    Velka cast z nich bude ruzne posunuta - prave kvuli tomu nesmyslu, ze snima "oznacime kde je vchod" + ani presnost importovanych dat jako takovych neni nijak uzasna, casto jsou adresy nekolik desitek metru mimo. Ale na casti uzemi to bude rucne u/opraveno. => opet se znici spousta prace spousty lidi.
    2) mixovane addr+POI vymazat info o addr a POI tagy v nodu ponechat (cca < 1000 nodu)
    => misto jedny tecky jich udelame na kazdy budove nekolik? A jak zjistim ze to vsechno patri k sobe? Jak zjistim, ze na adrese XYZ je hospoda? To si na to mam psat expertni system a analizovat vzdalenosti jednotlivych bodu? Nehlede na to, ze to opet budes delat kazdy den znova?
    3) budovy s addr prevest na body (cca 13.000 way)
    => viz vejs, editori je opet zacnou posunovat "ke vchodu" => budes den co den mazat stovky bodu a znova je importovat?
    4) addr ktere se shoduji tagem a polohou z OSM vymazat (polohova shoda do 10m) 5) uplny itinerar to neni, ale vetsinu to snad pokryva, co se zbytkem, se ukaze az pri cinu 6) to co zbyde priradit fixme
    Proto si myslim, ze je lepsi dat adresu na budovu. Navrch (kdyz uz sme u toho) vetsinou se tu kupodivu propaguje datove spravne reseni, coz v tomto pripade neni - nic jako adresa bodu neexistuje. Az si nekdo vzpomene, ze bude do OSM davat cisla parcel, tak sme opet u toho, ze zase nekam flaknu bod misto abych oznacil hranici? Je to stejny jako s KU - proc markovat hranice KU, kdyz nekam dovnitr muzu flaknout bod.
  29. "Petr Morávek [Xificurk]" xificurk na gmail.com #m7d510f
    Proto si myslim, ze je lepsi dat adresu na budovu. Navrch (kdyz uz sme u toho) vetsinou se tu kupodivu propaguje datove spravne reseni, coz v tomto pripade neni - nic jako adresa bodu neexistuje. Az si nekdo vzpomene, ze bude do OSM davat cisla parcel, tak sme opet u toho, ze zase nekam flaknu bod misto abych oznacil hranici? Je to stejny jako s KU - proc markovat hranice KU, kdyz nekam dovnitr muzu flaknout bod.
    Mně by se taky líbílo dávat adresu spíše na budovu, ale vidím tu dva "problémy": 1) Občas má jedna (reálná) budova více adres a občas je v OSM budova zakreslena pomocí více cest (např. pro možnost označení nižší/vyšší části jedné budovy), takže vztah OSM budova:adresní bod je obecně N:M a nevím, jak to elegantně vyřešit. 2) Aktualizace bodů je řádově jednodušší než cest. Jak tagování pomocí bodů, tak i cest má svá pro a proti... možná bysme to mohli začít sepisovat někde na wiki, včetně návrhů řešení. Petr Morávek aka Xificurk
  30. hanoj ehanoj na gmail.com #m43cb69
    Ahoj,
    Takže v první fázi udělat program, který porovná stav v OSM a v RUIAN. Jak by měl vypadat výstup tohoto porovnání? Může nastat mnoho případů (nejde o disjunktní případy):
    *** Hodne nam muze pomoci historie editaci a puvod UIR-ADR: 1) vymazat addr body ktere prosly jen hromadnym importem/hromadnou upravou z UIR-ADR (predpokladam ze to bude vetsina)
    Velka cast z nich bude ruzne posunuta - prave kvuli tomu nesmyslu, ze snima "oznacime kde je vchod" + ani presnost importovanych dat jako takovych neni nijak uzasna, casto jsou adresy nekolik desitek metru mimo. Ale na casti uzemi to bude rucne u/opraveno. => opet se znici spousta prace spousty lidi.
    *** V OSM mame verzovani, takze urcit co je jen import UIR-ADR bez zasahu useru nebude problem. *** Oznacovani tzv. vchodu je myslim minoritni vec. Hlavni duvod posunu je, ze adresni body jsou casto o desitky metru jinde. *** Ja jsem posunul cca 10.000 adresnich bodu, ale rad si je necham nahradit necim, co ma systematicky pristup a vizi udrzby.
    2) mixovane addr+POI vymazat info o addr a POI tagy v nodu ponechat (cca < 1000 nodu)
    => misto jedny tecky jich udelame na kazdy budove nekolik? A jak zjistim ze to vsechno patri k sobe? Jak zjistim, ze na adrese XYZ je hospoda? To si na to mam psat expertni system a analizovat vzdalenosti jednotlivych bodu? Nehlede na to, ze to opet budes delat kazdy den znova?
    *** to neni expertni system, ale trivialni prostorove dotazy (co je nejbliz). Navic to tak uz dnes v mape funguje. Jde o sjednoceni ruznych pristupu. *** Navic adresa/POI je vzdycky priblizna at uz fakticky (sidlo/provozovna) nebo lokacne (napr. prumyslovy areal o 10 hektarech ma 1 adresni bod)
    3) budovy s addr prevest na body (cca 13.000 way)
    => viz vejs, editori je opet zacnou posunovat "ke vchodu" => budes den co den mazat stovky bodu a znova je importovat?
    *** tohle myslim problem plugin "building" v JOSM, ktery automaticky predelava adresni bod do nove vytvorene budovy. *** Co bude den co den zalezi na tom, jak budeme chtit udrzet v chodu aktualizace s RUIAN
    Proto si myslim, ze je lepsi dat adresu na budovu.
    *** Budovu myslis jako way (OSM building), nebo budovu v RUIAN (bod) nebo parcelu se stavbou RUIAN (polygon z katastru na 1/2 uzemi CR)?
    Navrch (kdyz uz sme u toho) vetsinou se tu kupodivu propaguje datove spravne reseni, coz v tomto pripade neni - nic jako adresa bodu neexistuje. Az si nekdo vzpomene, ze bude do OSM davat cisla parcel, tak sme opet u toho, ze zase nekam flaknu bod misto abych oznacil hranici? Je to stejny jako s KU - proc markovat hranice KU, kdyz nekam dovnitr muzu flaknout bod.
    *** No ja nevim, doposud se to tak nazyvalo v UIR-ADR jako Adresni bod. V RUIAN AdresniMisto, reprezentovane bodem navic s vazbou na budovu (zase bod). *** Reprezentace objektu v OSM je o dohode, jakou miru generalizace prijimame. Napr silnice kreslime jako osy, ikdyz by bylo zdanlive vhodnejsi uzit plochy. Aby mapa mohla fungovat, je nutna mira zjednoduseni skutecnosti. ha hanoj
  31. Libor Pechacek lpechacek na gmx.com #m13e3f2
    Ahoj,
    Takže v první fázi udělat program, který porovná stav v OSM a v RUIAN. Jak by měl vypadat výstup tohoto porovnání? Může nastat mnoho případů (nejde o disjunktní případy):
    *** Hodne nam muze pomoci historie editaci a puvod UIR-ADR: 1) vymazat addr body ktere prosly jen hromadnym importem/hromadnou upravou z UIR-ADR (predpokladam ze to bude vetsina)
    Velka cast z nich bude ruzne posunuta - prave kvuli tomu nesmyslu, ze snima "oznacime kde je vchod" + ani presnost importovanych dat jako takovych neni nijak uzasna, casto jsou adresy nekolik desitek metru mimo. Ale na casti uzemi to bude rucne u/opraveno. => opet se znici spousta prace spousty lidi.
    *** V OSM mame verzovani, takze urcit co je jen import UIR-ADR bez zasahu useru nebude problem. *** Oznacovani tzv. vchodu je myslim minoritni vec. Hlavni duvod posunu je, ze adresni body jsou casto o desitky metru jinde. *** Ja jsem posunul cca 10.000 adresnich bodu, ale rad si je necham nahradit necim, co ma systematicky pristup a vizi udrzby.
    +1 Já osobně bych bez mazal nejen neupravené importy z UIR-ADR, ale i hromadné importy ČÚZK+MVČR. Tedy: source=uir-adr, verze 1 -> smazat hned source=uir-adr, verze >1 -> podívat se a smazat source:loc=cuzk:km, source:addr=mvcr:adresa -> podívat se a smazat ČÚZK+MVČR import také není v některých místech dostatečně polohově přesný, v KM totiž proběhlo mnoho korekcí umístění bodů i průběhu kranic KÚ. Oním "podíváním se" mám na mysli ruční revizi rozdílů. Může se ukázat, že v OSM máme v některých případech přesnější data, než jsou RÚIAN, nebo se můžou ukázat nějaké další vzorce. Libor
  32. Mirek Dlask dlask.m na gmail.com #m8172d8
    Ahoj, už jsem se dlouho na nic neptal, tak se zeptám ;-) 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
  33. hanoj ehanoj na gmail.com #m98c258
    Ahoj
    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ě?
    *** zadna, musi se rucne. tyto opravy jsou v trutnove na par minut.
    Zajímá mě, v čem jsou OSM přesnější než RUIAN, pokud jde o polohovou a tvarovou přesnost. Jestli je co zachraňovat kromě tagů.
    *** presnejsi nejsou, vyuzivaji tentyz podklad "katastralni mapu". *** Nekdy ale v OSM mohou byt objekty z ortofoto, ktere z nejsou v KM zamerne vedeny nebo neni nahlaseno jejich postaveni/zboreni do KM.
    Dají se takové objekty (oblasti) označit a vyloučit z aktualizace?
    *** myslim ze samostatne stojici budovy obkreslene z ortofoto ponechat v OSM lze. V zastavbe je to algoritmicky obtizne.
    Nedá se aktualizace z RUIAN rozdělit na etapy od nejjednoduššího ke složitějšímu? Začít třeba budovami v obcích, kde ještě žádné nejsou ...
    *** Rozdelit na etapy casto znamena odlozit rozhodnuti na pozdeji, kde se uziva jednotka "navzdy".
    Přidám jeden argument pro zachování adresních bodů. Padla tady zmínka, že RUIAN jsou data z ZABAGED a tam jsou bloky budov jako celek, bez rozdělení na jednotlivé budovy. Naopak došlo ke zpřesnění tvaru budov viz např. Turnov náměstí Českého ráje 65
    *** v RUIAN jsou ze ZABAGED pouze ulicni cary. Zbytek je KM. h ahoj hanoj
Napsat odpověď e-mailem… Odpovědět

Otevře váš e-mailový klient. Odpovědi pak sledujte zde na webu.