« zpět na výpis měsíce |

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

Vlákno 22.6. - 6.7.2012, počet zpráv: 45


22.6.2012 11:20:40 (#1)
gravatar

JV

<j.v.2 at seznam.cz>
57
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ý

22.6.2012 01:48:11 (#2)
gravatar

hanoj

<ehanoj at gmail.com>
718
Ahoj, zobrazit citaci
> 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

22.6.2012 02:04:36 (#3)
gravatar

JV

<j.v.2 at seznam.cz>
57
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ý zobrazit citaci
> ------------ 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 > > >

22.6.2012 06:37:33 (#4)
gravatar

Martin Kokeš

<shr3k at typo3-hosting.com>
135
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 zobrazit citaci
> Ahoj,
zobrazit citaci
> 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 zobrazit citaci
> uziva EPSG:2065, kdyz na data se bezne uziva ESRI:102067?
* Je nejaky zobrazit citaci
> osvedceny prohlizec, ktery umi data zobrazit krome
Snowflake s zobrazit citaci
> registraci?
In specie OSM --------------------- Chapu to tak ze pro OSM zobrazit citaci
> jsou pro plne automaticky import pouzitelne
vrstvy na uzemi ktera uz ma DKM zobrazit citaci
> (v dubnu 2012 55% CR):
*AdresniMisto (addr=*) *Stavebni objekt zobrazit citaci
> (building=*)
*Ulice (name=*) Na uzemi bez DKM je jen Adresni zobrazit citaci
> Misto.
ha hanoj _______________________________________________ Talk-cz zobrazit citaci
> mailing > list
Talk-cz na openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz

22.6.2012 08:53:02 (#5)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
Ahoj, předem se omlouvám, pokud budu psát nesmysly - moc o tom nevím. Chápu to správně tak, že data budou licenčně použitelné pro OSM, budou obsahovat např. adresní body, obrysy budov, ulice apod., vše zdarma ve formě veřejné dostupné aplikace na bázi XML/SOAP? A nyní data ještě dostupná nejsou, ale budou od příštího měsíce. Data nejsou kompletní, ale zahrnutí jen ty části ČR, které mají digitalizovaný katastr nemovitostí (cca půlka, ale výhledově bude růst). Data budou průběžně aktualizována a budou dostupná ve dvou formátech: a) aktuální stav b) změnové soubory Pokud je to tak je, tak by bylo vhodné celý proces importu maximálně zautomatizovat tak, aby se dala provádět pravidelně aktualizace dat (třeba 1x denně nebo týdně ... to je už detail). Kromě vlastního převedení dat bude třeba řešit kolize s daty, které pochází z jiných zdrojů (např. ručně kreslené). Rád bych se na takové automatizaci podílel, protože v tom vidím značný přínos. S pozdravem Honza Dne 22. června 2012 18:37 Martin Kokeš <shr3k na typo3-hosting.com> napsal(a): zobrazit citaci
> 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

22.6.2012 10:12:24 (#6)
gravatar

Martin Kokeš

<shr3k at typo3-hosting.com>
135
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 zobrazit citaci
> 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

22.6.2012 10:22:19 (#7)
gravatar

Martin Kokeš

<shr3k at typo3-hosting.com>
135
Nějaké příklady... Striptýz XSL (vyhází namespacy, spoléháme 100% na ČÚZK ;-)... ): <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:template match="*"> <xsl:element name="{local-name()}" > <xsl:apply-templates select="@*|node()"/> </xsl:element> </xsl:template> <xsl:template match="@*"> <xsl:attribute name="{local-name()}"> <xsl:value-of select="." /> </xsl:attribute> </xsl:template> </xsl:stylesheet> Primitivní výcuc budov XSL: <?xml version="1.0" encoding="UTF-8" ?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:template match="/"> <ogr:FeatureCollection xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://ogr.maptools.org/" xmlns:ogr="http://ogr.maptools.org/" xmlns:gml="http://www.opengis.net/gml"> <xsl:for-each select="VymennyFormat/Data/StavebniObjekty/StavebniObjekt"> <xsl:if test="Geometrie/OriginalniHranice"> <gml:featureMember> <ogr:stavebniobjekty fid="{Kod}"> <ogr:geometryProperty> <xsl:copy-of select="Geometrie/OriginalniHranice"/> </ogr:geometryProperty> <ogr:Kod> <xsl:value-of select="Kod"/> </ogr:Kod> <ogr:CislaDomovni> <xsl:value-of select="CislaDomovni"/> </ogr:CislaDomovni> <ogr:TypStavebnihoObjektuKod> <xsl:value-of select="TypStavebnihoObjektuKod"/> </ogr:TypStavebnihoObjektuKod> <ogr:CastObce> <xsl:value-of select="CastObce/Kod"/> </ogr:CastObce> </ogr:stavebniobjekty> </gml:featureMember> </xsl:if> </xsl:for-each> </ogr:FeatureCollection> </xsl:template> </xsl:stylesheet> Atd... MK ----- Original Message ----- From: Martin Kokeš [mailto:shr3k na typo3-hosting.com] To: OpenStreetMap Czech Republic [mailto:talk-cz na openstreetmap.org] Sent: Fri, 22 Jun 2012 18:37:33 +0200 Subject: Re: [Talk-cz] Data RUIAN - výměnný formát zobrazit citaci
> 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 zobrazit citaci
> 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 zobrazit citaci
> 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 zobrazit citaci
> [mailto:ehanoj na gmail.com]
To: OpenStreetMap Czech Republic zobrazit citaci
> [mailto:talk-cz na openstreetmap.org]
Sent: Fri, 22 Jun 2012 13:48:11 zobrazit citaci
> +0200
Subject: Re: [Talk-cz] Data RUIAN - výměnný formát zobrazit citaci
> Ahoj,
zobrazit citaci
> 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 zobrazit citaci
> > uziva EPSG:2065, kdyz na data se bezne uziva ESRI:102067?
* Je nejaky zobrazit citaci
> > osvedceny prohlizec, ktery umi data zobrazit krome
Snowflake s zobrazit citaci
> > registraci?
In specie OSM --------------------- Chapu to tak ze pro OSM zobrazit citaci
> > jsou pro plne automaticky import pouzitelne
vrstvy na uzemi ktera uz ma zobrazit citaci
> DKM > (v dubnu 2012 55% CR):
*AdresniMisto (addr=*) *Stavebni objekt zobrazit citaci
> > (building=*)
*Ulice (name=*) Na uzemi bez DKM je jen Adresni zobrazit citaci
> > Misto.
ha hanoj _______________________________________________ Talk-cz zobrazit citaci
> > mailing > > list
Talk-cz na openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz _______________________________________________ Talk-cz zobrazit citaci
> mailing > list
Talk-cz na openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz

23.6.2012 04:45:21 (#8)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
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): zobrazit citaci
> Jelikož se všude používá nativně Křovák, je nutná zpřesněná transformace pomocí S-JTSK gridu. > > MK

23.6.2012 07:39:48 (#9)
gravatar

Martin Kokeš

<shr3k at typo3-hosting.com>
135
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 zobrazit citaci
> 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 >

24.6.2012 01:45:34 (#10)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
Ahoj, díky, transformace souřadnic vypadá v pohodě (testovacím příkladem to prošlo). Teď je otázka, jakou celkovou strategii importu a následných aktualizací zvolit. Zveřejněná data registru neobsahují některé informace o celé ČR, ale jen o částech, ve kterých je digitalizovaný katastr. Dále nevím, do jaké míry katastr odpovídá realitě, ale tipuji, že určitě budou budovy, které v katastru nejsou a opačně (nebo jsou data nesprávná - např. jiný tvar obrys budovy). Data mohu obsahovat více upřesňujících tagů. Je tedy možné (pravděpodobné), že některá data budou lepší v OSM než v datech registru. Uliční čáry musí nějak rozumně na sebe navazovat... Na druhou stranu registr má jistě celkově velkou míru konzistence a úplnosti, bude se průběžně rozšiřovat území, kde jsou dostupné všechny informace a bude se průběžně aktualizovat, ... Které konrétní údaje z registru se budou do OSM importovat? Jak se vypořádat se starými daty? Za ideální cílový stav bych považovat navázání dat na registr kvůli aktualizacím, ale s možnost provádění všech typů změn, pokud registr někde nebude správný, úplný nebo bude k dispozici více informací, než které registr obsahuje. Celkově jde o poměrně mnoho dat (v XML to má necelých 30 GB, i přes ukecanost XML je toho opravdu hodně), takže jakékoli větší ruční zásahy do importu budou časově náročné. Máte nějakou představu, nápady, ...? Honza Dne 23. června 2012 7:39 Martin Kokeš <shr3k na typo3-hosting.com> napsal(a): zobrazit citaci
> 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

24.6.2012 05:26:23 (#11)
gravatar

Jiří Veselý

<j.v.2 at seznam.cz>
57
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): zobrazit citaci
> 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

24.6.2012 05:55:26 (#12)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
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): zobrazit citaci
> 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> >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120624/09e5ab30/attachment.html>

24.6.2012 06:49:33 (#13)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
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): zobrazit citaci
> 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

24.6.2012 07:34:01 (#14)
gravatar

Jiří Veselý

<j.v.2 at seznam.cz>
57
Je to tak, stavové jednou za měsíc a změny denně. Vše bude dostupné ke stažení, jména souborů bude možné odvodit podle datumu. Zatím předpokládáme držení historie 3 měsíce zpětně. J. V. Dne 24.6.2012 18:49, Jan Bilak napsal(a): zobrazit citaci
> 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 >

25.6.2012 12:35:53 (#15)
gravatar

hanoj

<ehanoj at gmail.com>
718
zobrazit citaci
>(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. zobrazit citaci
> 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 zobrazit citaci
> Které konrétní údaje z registru se budou do OSM importovat?
*AdresniMisto (addr=*) *Stavebni objekt (building=*) *Ulice (name=*) zobrazit citaci
> 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. zobrazit citaci
> 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

25.6.2012 01:36:28 (#16)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
zobrazit citaci
>>(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. zobrazit citaci
>> 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> zobrazit citaci
>> 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. zobrazit citaci
>> 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. zobrazit citaci
> 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). zobrazit citaci
> Obdobne u adresnich bodu, coz je > dano nedokoncenym importem a zdrojem dat.
Adresní body budou asi celkem v pohodě. zobrazit citaci
>> 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. zobrazit citaci
> 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

25.6.2012 08:19:51 (#17)
gravatar

JV

<j.v.2 at seznam.cz>
57
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ý zobrazit citaci
> ------------ 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 > > >

25.6.2012 12:16:11 (#18)
gravatar

jzvc

<jzvc at tpfree.net>
556
Dne 25.6.2012 0:35, hanoj napsal(a): zobrazit citaci
>> (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). zobrazit citaci
> >> 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

26.6.2012 04:14:04 (#19)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
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): zobrazit citaci
> 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

26.6.2012 01:58:48 (#20)
gravatar

Libor Pechacek

<lpechacek at gmx.com>
68
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: zobrazit citaci
> 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 zobrazit citaci
> <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". zobrazit citaci
> <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ě. zobrazit citaci
> <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. zobrazit citaci
> Jak se vlastně jednoznačně/algoritmicky určí, co je a co není adresní bod?
Všechny mají "addr:housenumber", čehož bych se držel. zobrazit citaci
> 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

26.6.2012 04:12:11 (#21)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
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): zobrazit citaci
> 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

26.6.2012 07:21:52 (#22)
gravatar

Libor Pechacek

<lpechacek at gmx.com>
68
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: zobrazit citaci
> 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
--

26.6.2012 07:37:36 (#23)
gravatar

Martin Kokeš

<shr3k at typo3-hosting.com>
135
Některé atributy jsou důležité pro službu Nominatim http://wiki.openstreetmap.org/wiki/Nominatim/Development_overview MK ----- Original Message ----- From: Libor Pechacek [mailto:lpechacek na gmx.com] To: OpenStreetMap Czech Republic [mailto:talk-cz na openstreetmap.org] Sent: Tue, 26 Jun 2012 19:21:52 +0200 Subject: Re: [Talk-cz] Formát zápisu adresních bodů (was Data RUIAN - výměnný formát) zobrazit citaci
> Ahoj Honzo,
Zabral jsem se do detailů a nějak zapomněl uzavřít zobrazit citaci
> návrhem.
Jsem pro požití tagů addr:housenumber, zobrazit citaci
> addr:streetnumber,
addr:conscriptionnumber, addr:street a is_in. Is_in zobrazit citaci
> proto, že často obsahuje
informaci o městských částech, kterou z mapy zobrazit citaci
> nelze odvodit. Pokud někdo najde
nějakou hypoalergenní[1] variantu k zobrazit citaci
> is_in, jsem pro.
Dál navrhuji seskupit adresy jedné ulice do relace, zobrazit citaci
> která ponese addr:street a
is_in, aby se předešlo duplikaci. Adresní zobrazit citaci
> body by v tom případě měly jen
addr:housenumber, addr:streetnumber a zobrazit citaci
> addr:conscriptionnumber. Otázkou je, jak
by taková relace měla zobrazit citaci
> vypadat[2].
Addr:postcode, addr:city a addr:country bych klidně zahodil, zobrazit citaci
> pokud neposlouží
jako náhrada is_in. Libor [1] zobrazit citaci [2] v úvahu zobrazit citaci
> zřejmě připadá
zobrazit citaci zobrazit citaci zobrazit citaci On Tue zobrazit citaci
> 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
-- zobrazit citaci
>
_______________________________________________ Talk-cz mailing zobrazit citaci
> list
Talk-cz na openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz

27.6.2012 05:05:44 (#24)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
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

27.6.2012 09:06:33 (#25)
gravatar

jzvc

<jzvc at tpfree.net>
556
Dne 26.6.2012 4:14, Jan Bilak napsal(a): zobrazit citaci
> 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. zobrazit citaci
> > 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

27.6.2012 09:22:24 (#26)
gravatar

jzvc

<jzvc at tpfree.net>
556
Dne 26.6.2012 19:21, Libor Pechacek napsal(a): zobrazit citaci
> 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. zobrazit citaci
> > 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

27.6.2012 09:29:47 (#27)
gravatar

jzvc

<jzvc at tpfree.net>
556
Dne 27.6.2012 5:05, Jan Bilak napsal(a): zobrazit citaci
> 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
To tam budes muset vyrazit a podivat se ... ;D Ne, vazne, chyby jsou ve vsech zdrojich, a pokud "preadresujes" neco trebas tak, ze tam nekdo importoval a ty pres to pustis josm plugin, tak zjistis, ze ti kazdej zdroj bude tvrdit neco trochu jinyho. Ohledne reseni - pokud je tam nejaky zasadni rozdil, tak by asi nebylo od veci stavajici marknout jako fixme a prifarit tam trebas novy bod s adresou ze zdroje a k tomu pridat trebas note. Nasledne je to na rucni upravy/opravy. Ale nerad bych opet videl dalsi vodni toky ... ;D Protoze spravovat neco je 100x vetsi vopruz nez to nakreslit rucne. zobrazit citaci
> _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

27.6.2012 03:33:03 (#28)
gravatar

Libor Pechacek

<lpechacek at gmx.com>
68
On Wed 27-06-12 09:22:24, jzvc wrote: zobrazit citaci
> 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". zobrazit citaci
> 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í. zobrazit citaci 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. zobrazit citaci
> 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. zobrazit citaci
> 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 zobrazit citaci
> > > > 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
--

27.6.2012 04:26:35 (#29)
gravatar

jzvc

<jzvc at tpfree.net>
556
Ono, co si budem rikat, mazat se da vzdycky, takze lepsi je tam mit duplicitni a nadbytecna data, nez tam neco nemit. 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. Co se tyce dalsich dat, pokud sem dobre zahlid, je tam nejaky typ/zpusob vyuziti budovy - predpokladam neco jako obytna/prumyslova/... to by se dalo vyuzit jako parametr pro building= , ale nikde sem nenasel nejakej popis co za hodnoty tam muze byt a co znamenaji - hedal sem tuhle http://www.cuzk.cz/docvfr/vfr-schema-doc/. 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> Pocet podlazi se urcite vyuzije, pokud se najde zbusob jak zjistit, kolik jich je nad zemi ... , mapka bude pekne 3D Dne 27.6.2012 15:33, Libor Pechacek napsal(a): zobrazit citaci
> 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

27.6.2012 10:12:23 (#30)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
Ahoj, zobrazit citaci
> 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). zobrazit citaci
> 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. zobrazit citaci
> > 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, ...). zobrazit citaci
> > > 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

27.6.2012 11:10:38 (#31)
gravatar

jzvc

<jzvc at tpfree.net>
556
Dne 27.6.2012 22:12, Jan Bilak napsal(a): zobrazit citaci
> 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.
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. zobrazit citaci
> > 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.
Nerika, rozhodne ne pokud ho nebudes (kazdy jeden) rucne posunovat, adresni bod je unisten v centru budovy. Nehlede na to, ze na oznaceni vhodu jsou uplne jiny tagy (entrance). zobrazit citaci
> > 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).
Tak technicky je (IMO) spravnejsi, aby adresu mela budova (protoze ty patri CP/Cev/...). Ale pokud tam ta budova uz z nejakyho duvodu neni, tak to neznamena, ze nemuzeme nechat tu adresu najit (z duvodu navigace ... - to je jedinej duvod proc pripadne vyrabim ty body). Navic by bylo hned zrejmy, ze na dany adrese nestoji zadna budova => jde o proluku nebo jiny prazdny pozemek => hned se to lip hleda (specilene v nasem bordelstanu, kde je casto problem zjistit nazev ulice ve ktery clovek stoji). zobrazit citaci
> > 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).
Daleko rychlejsi ale je, vyrobit adresni body z budov, predpokladam, ze v ty databazi kde je to ulozeno to delaji prave takhle, protoze si nedovedu moc dobre predstavit, jak lezou na strechu kazdyho baraku a zamerujou jeho stred ... ;D, navic sem uz u par navigaci videl, ze pokud je hledana adresa primo budova, tak navigace tu budovu zvyrazni, coz je v hustci zastavbe fajn. + jako bonus, pokud by ta budova mela skutecne otagovany vchody, tak te to muze navigovat k tomu bliz a nemusis kvuli tomu trebas obchazet blok, protoze adresne to patri to ulice na druhy strane. zobrazit citaci
> > >> 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

28.6.2012 09:00:17 (#32)
gravatar

hanoj

<ehanoj at gmail.com>
718
pokusim se vmisit... zobrazit citaci
>>> 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.
*** Me se vlozeni adresniho bodu do budovy nelibi (pokud to dobre chapu). Adresni bod je bod uz z nazvu. To ze se zvyrazni budova pod nim je veci sw a trivialni prostorove analyzy. Budova se casto sklada z pristavku a privesku a co bude mit adresni bod, nejvetsi cast budovy? V Brne je skoro kazdy druhy rohovy dum s dvema adresnimi body. Vazba budova a adresni bod bude tedy velmi volna, M:N. Ale urcite at je jeden element (adresni bod) jedna normalni forma, primarni sekundarni to je spatne... hanoj

28.6.2012 09:13:41 (#33)
gravatar

hanoj

<ehanoj at gmail.com>
718
zobrazit citaci
> Dne 25.6.2012 0:35, hanoj napsal(a): >>> (nebo jsou data nesprávná - např. jiný tvar obrys budovy). >> *** No katastr, uznává tuším styk budovy se zemí jako reprezentující a >> vzhledem k tomu že to dosud od něj obkreslujem asi by to chtělo uznat >> za standard. > Tak to pozor, km sice pouzivam jako jeden z primarnich zdroju, ale > vzdycky minimalne kontroluju, jestli tam ta budova +- opravdu stoji.
*** Me slo predevsim o ten tvar budovy... zobrazit citaci
> 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. zobrazit citaci
> 1) zadny zbesily import a rozhodne ne zadne mazani v OSM.
*** zbesilost je vetsinou v srdci, ne importech. Neni kam spechat. zobrazit citaci
> 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

30.6.2012 12:45:23 (#34)
gravatar

Pavel Machek

<pavel at ucw.cz>
1056 1226
On Sat 2012-06-23 04:45:21, Jan Bilak wrote: zobrazit citaci
> 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

30.6.2012 01:11:53 (#35)
gravatar

Martin Kokeš

<shr3k at typo3-hosting.com>
135
Č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 zobrazit citaci
> 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 zobrazit citaci
> +rf=299.1528128 +no_defs
+towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56" zobrazit citaci
> -t_srs
"+proj=latlong +a=6378137 +rf=298.257223563 zobrazit citaci
> +no_defs
+towgs84=0.000,0.000,0.000" zobrazit citaci
> /data/gis/READ-ONLY/cechy.tif
/tmp/delme.tiff a pak pascalovej zdrojak: { zobrazit citaci
> Copyright 2005 Zdenek Hrdina, distribute under GPLv2
} procedure zobrazit citaci
> jtsk_wgs( X,Y,Hel:double; var B,L,H:double);
{Vypocet zemepisnych souradnic zobrazit citaci
> v systemu WGS-84 z rovinnych souradnic
S-JTSK a elipsoidicke zobrazit citaci
> vysky}
procedure transformace_BLH(var B,L,H: double); {Transformace zobrazit citaci
> zemepisnych souradnic z JTSK do WGS}
var zobrazit citaci
> lat,lon,alt,x1,y1,z1,x2,y2,z2:double;
... Poslu nebo by mel jit zobrazit citaci
> vygooglit.
-- (english) http://www.livejournal.com/~pavelmachek (cesky, zobrazit citaci _______________________________________________ Talk-cz zobrazit citaci
> mailing > list
Talk-cz na openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz

30.6.2012 01:21:16 (#36)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
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): zobrazit citaci
> Č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

30.6.2012 01:36:33 (#37)
gravatar

Martin Kokeš

<shr3k at typo3-hosting.com>
135
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 zobrazit citaci
> 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 >

30.6.2012 01:55:07 (#38)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
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): zobrazit citaci
> 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

30.6.2012 10:55:08 (#39)
gravatar

hanoj

<ehanoj at gmail.com>
718
Ahoj zobrazit citaci
> 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 zobrazit citaci
> 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. zobrazit citaci
> 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

1.7.2012 11:14:44 (#40)
gravatar

jzvc

<jzvc at tpfree.net>
556
Dne 30.6.2012 22:55, hanoj napsal(a): zobrazit citaci
> 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. zobrazit citaci
> 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? zobrazit citaci
> 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? zobrazit citaci
> 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. zobrazit citaci
> > >> 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

1.7.2012 11:37:06 (#41)
gravatar

"Petr Morávek [Xificurk]"

<xificurk at gmail.com>
169
jzvc wrote: zobrazit citaci
> 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 ------------- další část --------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120701/7537bcd1/attachment.sig>

1.7.2012 12:25:22 (#42)
gravatar

hanoj

<ehanoj at gmail.com>
718
Ahoj, zobrazit citaci
>>> 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. zobrazit citaci
>> 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) zobrazit citaci
>> 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 zobrazit citaci
> 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)? zobrazit citaci
> 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

2.7.2012 09:24:10 (#43)
gravatar

Libor Pechacek

<lpechacek at gmx.com>
68
Ahoj, On Sun 01-07-12 12:25:22, hanoj wrote: zobrazit citaci
> >>> 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

6.7.2012 02:13:39 (#44)
gravatar

Mirek Dlask

<dlask.m at gmail.com>
107
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 Dne 30. června 2012 13:55 Jan Bilak <jan.bilak.osm na gmail.com> napsal(a): zobrazit citaci
> 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 >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120706/a61ade27/attachment.html>

6.7.2012 05:54:02 (#45)
gravatar

hanoj

<ehanoj at gmail.com>
718
Ahoj zobrazit citaci
> 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. zobrazit citaci
> 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. zobrazit citaci
> 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. zobrazit citaci
> 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". zobrazit citaci
> 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

« zpět na výpis měsíce