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

25.6.2012 12:35:53 (#15)
gravatar

hanoj

<ehanoj at gmail.com>
713
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 at 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 at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > >

25.6.2012 12:16:11 (#18)
gravatar

jzvc

<jzvc at tpfree.net>
534
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 at 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 at 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 at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at 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 at 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 at 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 at 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 at openstreetmap.org > > http://lists.openstreetmap.org/listinfo/talk-cz > > _______________________________________________ > Talk-cz mailing list > Talk-cz at 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 at gmx.com] To: OpenStreetMap Czech Republic [mailto:talk-cz at 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 at 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 at openstreetmap.org > > > http://lists.openstreetmap.org/listinfo/talk-cz > > > _______________________________________________ > Talk-cz mailing list > > Talk-cz at openstreetmap.org > > http://lists.openstreetmap.org/listinfo/talk-cz
-- zobrazit citaci
>
_______________________________________________ Talk-cz mailing zobrazit citaci
> list
Talk-cz at 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>
534
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 at 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 at openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

27.6.2012 09:22:24 (#26)
gravatar

jzvc

<jzvc at tpfree.net>
534
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 at 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 at openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz

27.6.2012 09:29:47 (#27)
gravatar

jzvc

<jzvc at tpfree.net>
534
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 at 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 at 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 at openstreetmap.org > >>> http://lists.openstreetmap.org/listinfo/talk-cz > >> _______________________________________________ > >> Talk-cz mailing list > >> Talk-cz at openstreetmap.org > >> http://lists.openstreetmap.org/listinfo/talk-cz > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz
--

27.6.2012 04:26:35 (#29)
gravatar

jzvc

<jzvc at tpfree.net>
534
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 at 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 at openstreetmap.org >>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz at openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at 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>
534
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 at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

28.6.2012 09:00:17 (#32)
gravatar

hanoj

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

30.6.2012 10:55:08 (#39)
gravatar

hanoj

<ehanoj at gmail.com>
713
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>
534
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 at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120701/7537bcd1/attachment.pgp>

1.7.2012 12:25:22 (#42)
gravatar

hanoj

<ehanoj at gmail.com>
713
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>
75
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 at 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 at 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 at gmail.com] > > To: OpenStreetMap Czech Republic > > [mailto:talk-cz at 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 at 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 at ucw.cz] > >> > To: > >> > OpenStreetMap Czech Republic [mailto:talk-cz at 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 at openstreetmap.org > >> > http://lists.openstreetmap.org/listinfo/talk-cz > >> > > >> > _______________________________________________ > >> > Talk-cz mailing list > >> > Talk-cz at openstreetmap.org > >> > http://lists.openstreetmap.org/listinfo/talk-cz > >> > >> _______________________________________________ > >> Talk-cz mailing list > >> Talk-cz at openstreetmap.org > >> http://lists.openstreetmap.org/listinfo/talk-cz > >> > > > > _______________________________________________ > > Talk-cz mailing list > > Talk-cz at openstreetmap.org > > http://lists.openstreetmap.org/listinfo/talk-cz > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >
-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120706/a61ade27/attachment.html>

6.7.2012 05:54:02 (#45)
gravatar

hanoj

<ehanoj at gmail.com>
713
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