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

[Talk-cz] Adresy z RUIAN

Vlákno 11.2. - 18.2.2014, počet zpráv: 63


11.2.2014 01:06:30 (#1)
gravatar

Petr Vejsada

<osm at propsychology.cz>
507
Ahoj, tak? jsem piln? a zd? se, ?e n?stroj na nahr?v?n? adres z RUIAN je hotov. Funguje tak, ?e se vybere oblast, pust? se SQL skript a za p?r (des?tek) minut je p?ipraven? changeset pro JOSM. K tomu z toho vypadnou varovac? tabulky se seznamem m?st, kde si to neporadilo a chce to lidsk? pr?zkum. Po?et v?t v t?chto tabulk?ch je nep??mo ?m?rn? kvalit? dat v RUIAN v dan? oblasti ;-) Podle tabulek s probl?my se pak daj? pat?i?n? m?sta pravit v JOSM p?ed uploadem. Pot?ebuji se domluvit na podob? dat. Tyto tagy se zpracov?vaj?: addr:city - obec addr:conscriptionnumber - ??slo popisn? addr:housenumber - slo?enina, jak je popsan? na Wiki, tedy ev.<eviden?n?> ?i <popisn?>/<orienta?n?> atd, addr:provisionalnumber - eviden?n? ??slo addr:streetnumber - ??slo orienta?n? addr:place - ??st obce addr:street - ulice addr:postcode - PS? source:addr=cuzk:ruian ref:ruian=<rn_adresni_misto.kod> Na ostatn? tagy nesah?m, tedy nesah?m ani na is_in, source, addr:country ?i dal?? addr: ?i ne-addr:. Nesah?m ani na sou?adnice. Algoritmus je osmipr?chodov?, z toho 6 pr?chod? je na vlastn? p?i?azen? a zbyl? 2 jsou na generov?n? varovn?ch tabulek. Zdroj?ky tajn? nejsou, je to 100% plpgsql/postgis, nicm?n? netvo?il jsem to pro u?ivatele, ale pro sebe a tak k?d odr??? moji m?stn? situaci - vy?aduje schema RUIAN, OSM APIDB (nikoli samotn? API, jen datab?zov? schema) a Mapnik schema. Urcite by slo predelat pro snapshot schema, kter? m? sympatick? HSTORE, ale v tuto chv?li to tak nen? hlavn? proto, proto?e snapshot schema nem?m. Pracuje to se v?emi typy entit - s body, cestami/polygony i relacemi. Nalezne- li entitu s adresou (co? nalezne skoro v?dy), uprav? ji tak, ?e nahrad? v??e zm?n?n? tagy a ostatn?ch si nev??m?. Nenalezne-li, vytvo?? nov? adresn? bod se sou?adnicemi z RUIAN, a to bu? deini?n? bod adresn?ho m?sta, nen?-li, pak deini?n? bod stavebn?ho objektu, nen?-li tak st_centroid stavebn?ho objektu. Nen?-li, tak nic; na parcelu u? jsem ne?el, mohlo by to b?t geometricky dost mimo. Co se t?k? maz?n?, tak moment?ln? se nic nema?e. Pamatuji si, kter? den to zpracuje kter? data a m??e pak porovn?vat s RUIAN a mazat by se mohlo tehdy, kdy se adresa sma?e z RUIAN a z?rove? bylo toto m?sto zpracov?no. Z?sadn? ot?zka ?.1 - co s tagy addr:country a is_in? Mo?nosti jsou ponechat, mazat ?i nahrazovat. Jak? m?te n?zor? Z?sadn? ot?zka ?.2 - zda do toho v?bec j?t, tedy za??t prob?rat celou republiku a pokud ano, co je t?eba p?edt?m ud?lat? O pravidlech pro importy pon?t? m?m a tak zahajuji diskusi s m?stn? komunitou ;-). Moj? motivac? bylo a je hlavn? to, ?e Nominatim ve st?vaj?c?ch datech moc hledat neum?, proto?e is_in ho v?bec nezaj?m?, tak?e hlavn? p?idat addr:place, sjednotit v?e a snad tedy zlep?it. -- Petr, pv at propsychology.cz zobrazit citaci
>p<

11.2.2014 06:07:17 (#2)
gravatar

Marián Kyral

<mkyral at email.cz>
2234 2403
Dne 11.2.2014 01:06, Petr Vejsada napsal: zobrazit citaci
> Ahoj, > > tak? jsem piln? a zd? se, ?e n?stroj na nahr?v?n? adres z RUIAN je > hotov. > Funguje tak, ?e se vybere oblast, pust? se SQL skript a za p?r > (des?tek) minut > je p?ipraven? changeset pro JOSM. K tomu z toho vypadnou varovac? > tabulky se > seznamem m?st, kde si to neporadilo a chce to lidsk? pr?zkum. Po?et v?t > v > t?chto tabulk?ch je nep??mo ?m?rn? kvalit? dat v RUIAN v dan? oblasti > ;-) > Podle tabulek s probl?my se pak daj? pat?i?n? m?sta pravit v JOSM p?ed > uploadem. >
Ty tabulky maj? stejn? form?t jako to csv co jsi pos?lal? Nebylo by lep?? ty sporn? body n?jak ozna?it? T?eba tagem fixme. L?p se to pak bude v JSOM hledat/opravovat. zobrazit citaci
> Pot?ebuji se domluvit na podob? dat. > > Tyto tagy se zpracov?vaj?: > > addr:city - obec > addr:conscriptionnumber - ??slo popisn? > addr:housenumber - slo?enina, jak je popsan? na Wiki, tedy > ev.<eviden?n?> ?i > <popisn?>/<orienta?n?> atd, > addr:provisionalnumber - eviden?n? ??slo > addr:streetnumber - ??slo orienta?n? > addr:place - ??st obce > addr:street - ulice > addr:postcode - PS? > > source:addr=cuzk:ruian > ref:ruian=<rn_adresni_misto.kod> > > Na ostatn? tagy nesah?m, tedy nesah?m ani na is_in, source, > addr:country ?i > dal?? addr: ?i ne-addr:. Nesah?m ani na sou?adnice. > > Algoritmus je osmipr?chodov?, z toho 6 pr?chod? je na vlastn? p?i?azen? > a > zbyl? 2 jsou na generov?n? varovn?ch tabulek. > > Zdroj?ky tajn? nejsou, je to 100% plpgsql/postgis, nicm?n? netvo?il > jsem to > pro u?ivatele, ale pro sebe a tak k?d odr??? moji m?stn? situaci - > vy?aduje > schema RUIAN, OSM APIDB (nikoli samotn? API, jen datab?zov? schema) a > Mapnik > schema. Urcite by slo predelat pro snapshot schema, kter? m? sympatick? > HSTORE, ale v tuto chv?li to tak nen? hlavn? proto, proto?e snapshot > schema > nem?m. >
Ud?lej tomu n?jakou konfiguraci, p??padn? by mohlo nastavit si n?jak? ta synonyma. Koukal jsem, ?e postgresql by to m?l um?t. Mysl?m, ?e t?eba pro studijn? by se to mohlo hodit. zobrazit citaci
> Pracuje to se v?emi typy entit - s body, cestami/polygony i relacemi. > Nalezne- > li entitu s adresou (co? nalezne skoro v?dy), uprav? ji tak, ?e nahrad? > v??e > zm?n?n? tagy a ostatn?ch si nev??m?. Nenalezne-li, vytvo?? nov? adresn? > bod se > sou?adnicemi z RUIAN, a to bu? deini?n? bod adresn?ho m?sta, nen?-li, > pak > deini?n? bod stavebn?ho objektu, nen?-li tak st_centroid stavebn?ho > objektu. > Nen?-li, tak nic; na parcelu u? jsem ne?el, mohlo by to b?t geometricky > dost > mimo. > > Co se t?k? maz?n?, tak moment?ln? se nic nema?e. Pamatuji si, kter? den > to > zpracuje kter? data a m??e pak porovn?vat s RUIAN a mazat by se mohlo > tehdy, > kdy se adresa sma?e z RUIAN a z?rove? bylo toto m?sto zpracov?no. > > Z?sadn? ot?zka ?.1 - co s tagy addr:country a is_in? Mo?nosti jsou > ponechat, > mazat ?i nahrazovat. Jak? m?te n?zor? >
Ur?it? nechat, p??padn? opravit, a? je to aktu?ln?. Kdy? to tam z?stane, tak se nic stra?n?ho nestane. zobrazit citaci
> Z?sadn? ot?zka ?.2 - zda do toho v?bec j?t, tedy za??t prob?rat celou > republiku a pokud ano, co je t?eba p?edt?m ud?lat? O pravidlech pro > importy > pon?t? m?m a tak zahajuji diskusi s m?stn? komunitou ;-). >
Nebylo by ?koda te? skon?it, kdy? u? jsi tomu v?noval tolik ?asu a energie? V nejhor??m bych mohl ud?lal n?jak? plugin, kter? by to dok?zal vyu??t. BTW: czechaddress plugin by asi cht?l taky opravit. P?idat mo?nost doplnit chyb?j?c? ?daje z RUIAN (pokud jsou k dispozici). BTW 2: na Slovensk?m mailing listu je te? taky zaj?mav? debata o odres?ch: https://groups.google.com/forum/#!topic/osm_sk/YJr78HvG2TA Mari?n zobrazit citaci
> Moj? motivac? bylo a je hlavn? to, ?e Nominatim ve st?vaj?c?ch datech > moc > hledat neum?, proto?e is_in ho v?bec nezaj?m?, tak?e hlavn? p?idat > addr:place, > sjednotit v?e a snad tedy zlep?it. > > -- > Petr, pv at propsychology.cz >> p< > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz

11.2.2014 07:31:47 (#3)
gravatar

Marián Kyral

<mkyral at email.cz>
2234 2403
Dne 11.2.2014 06:07, Mari?n Kyral napsal: zobrazit citaci
> Dne 11.2.2014 01:06, Petr Vejsada napsal: >> Z?sadn? ot?zka ?.2 - zda do toho v?bec j?t, tedy za??t prob?rat celou >> republiku a pokud ano, co je t?eba p?edt?m ud?lat? O pravidlech pro >> importy >> pon?t? m?m a tak zahajuji diskusi s m?stn? komunitou ;-). >> > Nebylo by ?koda te? skon?it, kdy? u? jsi tomu v?noval tolik ?asu a > energie? > V nejhor??m bych mohl ud?lal n?jak? plugin, kter? by to dok?zal vyu??t. >
Tak mn? tak napad?, nedalo by se to br?t jako sou??st/roz???en? projektu Import Adres ?R? ( http://wiki.openstreetmap.org/wiki/Import_Adres_%C4%8CR ). Pak by cel? ta procedura mohla b?t jednodu???. Mari?n

11.2.2014 08:39:22 (#4)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
138
Dne 11.2.2014 01:06, Petr Vejsada napsal(a): zobrazit citaci
> Co se t?k? maz?n?, tak moment?ln? se nic nema?e. Pamatuji si, kter? den to > zpracuje kter? data a m??e pak porovn?vat s RUIAN a mazat by se mohlo tehdy, > kdy se adresa sma?e z RUIAN a z?rove? bylo toto m?sto zpracov?no. > > Z?sadn? ot?zka ?.1 - co s tagy addr:country a is_in? Mo?nosti jsou ponechat, > mazat ?i nahrazovat. Jak? m?te n?zor?
Asi by bylo dobr? ud?lat n?jakou z?kladn? anal?zu obsahu is_in tagu - pokud obsahuje jen ??st obce, obec, st?t... (nebo ??rkami oddelenou kombinaci), tak smazat. Pokud jsou v?echna data is_in tagu obsa?ena ve strukturovan? podob? v addr:*, tak si mysl?m, ?e nem? cenu, aby n?m tu nad?le stra?il. Zdrav?, Petr Mor?vek aka Xificurk

11.2.2014 08:52:16 (#5)
gravatar

Petr Vejsada

<osm at propsychology.cz>
507
Ahoj, Dne ?t 11. ?nora 2014 06:07:17, Mari?n Kyral napsal(a): zobrazit citaci
> > t?chto tabulk?ch je nep??mo ?m?rn? kvalit? dat v RUIAN v dan? oblasti > > ;-) > > Podle tabulek s probl?my se pak daj? pat?i?n? m?sta pravit v JOSM p?ed > > uploadem. > > Ty tabulky maj? stejn? form?t jako to csv co jsi pos?lal? > Nebylo by lep?? ty sporn? body n?jak ozna?it? T?eba tagem fixme. L?p se > to > pak bude v JSOM hledat/opravovat.
to m? nenapadlo, zato m? napadlo, a je tam, do t?ch tabulek d?t odkaz na http://localhost:8111 ..., tak?e zkop?rovat url do prohl??e?e a JOSM na to msto sko??. V?hoda je, ?e ty FIXME se nemus? pak v JOSM mazat. Varuje t?eba p?ed adresn?mi body p??li? bl?zko u sebe, ale stane se, ?e je to 100 gar???, kde je to legitimn? a pak bych musel 100 gar??? editovat, kde?to takto to sta?? jen zkouknout a nechat b?t :) zobrazit citaci
> > schema. Urcite by slo predelat pro snapshot schema, kter? m? sympatick? > > HSTORE, ale v tuto chv?li to tak nen? hlavn? proto, proto?e snapshot > > schema > > nem?m. > > Ud?lej tomu n?jakou konfiguraci, p??padn? by mohlo nastavit si n?jak? ta > synonyma. Koukal jsem, ?e postgresql by to m?l um?t. Mysl?m, ?e t?eba > pro studijn? > by se to mohlo hodit.
Hm, te? ne, mo?n? n?kdy -> asi ur?it? ne, p?e ?as, musel bych studovat snapshot schema atd. a bez testov?n? to nem? smysl. M??e si to ud?lat, kdo bude cht?t ;) zobrazit citaci
> > Z?sadn? ot?zka ?.1 - co s tagy addr:country a is_in? Mo?nosti jsou > > ponechat, > > mazat ?i nahrazovat. Jak? m?te n?zor? > > Ur?it? nechat, p??padn? opravit, a? je to aktu?ln?. Kdy? to tam z?stane, > tak > se nic stra?n?ho nestane.
Ta varianta ponechat m? nev?hodu, ?e data budou vlastn? poch?zet z r?zn?ch zdroj?. addr:country a is_is bude z p?vodn?ho zdroje a zbytek z RUIAN, tak j? bych to vid?l bu? na zahodit nebo p?epsat. zobrazit citaci
> > > Z?sadn? ot?zka ?.2 - zda do toho v?bec j?t, tedy za??t prob?rat celou > > republiku a pokud ano, co je t?eba p?edt?m ud?lat? O pravidlech pro > > importy > > pon?t? m?m a tak zahajuji diskusi s m?stn? komunitou ;-). > > Nebylo by ?koda te? skon?it, kdy? u? jsi tomu v?noval tolik ?asu a > energie? > V nejhor??m bych mohl ud?lal n?jak? plugin, kter? by to dok?zal vyu??t.
no n?co s t?m ur?it? naadresuji, ot?zka byla sp?? na glob?lnost cel? akce. Nap??klad okres Vy?kov byl opravdu dost b?l?. Naklikal jsem tam tis?ce budov tracerem, tak?e je dob?e otestovan? (zn?m? bugy: bug serveru - kdy? je oblouk tvo?en? tak mnoha body, ?e zm?na ?hlu mezi t?emi po sob? jdouc?mi body je m?n? ne? 3 stupn?, tak ty body postupn? zahod? ?pln? v?echny a oblouk zmiz? a bug pluginu - k????c? se budovy - napojov?n?). Ten okres Vy?kov jsem zkou?el, v?ude OK, jen v samotn?m Vy?kov? pracuj? asi n?jac? horliv? kartoilov?, proto?e jsou tam mraky adresn?ch bod? 2x i 3x na stejn?m m?st?. Li?? se jm?nem ulice nebo dokonce ??st? obce (Vy?kov X Vy?kov- p?edm?st? nap?.) -- Petr

11.2.2014 08:54:57 (#6)
gravatar

Petr Vejsada

<osm at propsychology.cz>
507
Dne ?t 11. ?nora 2014 06:07:17, Mari?n Kyral napsal(a): zobrazit citaci
> Ty tabulky maj? stejn? form?t jako to csv co jsi pos?lal? > Nebylo by lep?? ty sporn? body n?jak ozna?it? T?eba tagem fixme. L?p se > to > pak bude v JSOM hledat/opravovat.
pro ty, co maj? p??stup sem do DB - jsou to view osmimport.warnings_view, osmimport.warnings_view_full a osmimport.morewarnings -- Petr

11.2.2014 09:01:07 (#7)
gravatar

Dalibor Jelínek

<dalibor at dalibor.cz>
408 1253
Ahoj, ja teda is_in tag rad nemam, protoze nevim, jak se ma spravne vyplnovat. Na druhou stranu se mi nezda hezke mazat neco, co nekdo do mapy s nejakym usilim pridal. Pokud opravdu dokazeme nahradit vse, co ted ten tag obsahuje, pak ano. Ale uz ted vim, ze zatim ten navrh PV neobsahuje vse, co je v is_in. V is_in jsou mestske casti (nekde) a stat, to tam zatim PV nema. Ja bych navrhoval, do tech adres pridavat : addr:country=CZ (czechaddress to tam dava a proc to vynechavat?) addr:suburb=Praha 14 (z m?stsk? ??st/obvod) A jeste, to povazuji za dost dulezite, ale uz je asi pozde, bych zmenil ref:ruian=<rn_adresni_misto.kod> na treba ref:ruian:am=<rn_adresni_misto.kod> Protoze, az budeme chtit pridavat jine veci z RUIAN, treba stavebni objekty, pak casem nevyhnutelne dojde k tomu, ze se dostane adresa z bodu na objekt a bude konflikt ref:ruian. Ale jestli je to uz pouzito na hodne mistech, pak asi nezbyde, nez ref:ruian brat jako ID pro adresni misto a jina ID znacit jinak. Co se tyce importu, pak bych radsi prosel tu proceduru znova pro RUIAN, nez rozsirovat jiz stavajici import. Klidne to vykomunikuju. Zdravi, Dalibor

11.2.2014 09:11:04 (#8)
gravatar

Dalibor Jelínek

<dalibor at dalibor.cz>
408 1253
zobrazit citaci
> Na ostatn? tagy nesah?m, tedy nesah?m ani na is_in, source, addr:country
?i zobrazit citaci
> dal?? addr: ?i ne-addr:. Nesah?m ani na sou?adnice.
V mem okoli jsou bezne adresy treba v tomhle formatu. addr:conscriptionnumber=1068 addr:housenumber=1068/3 addr:postcode=19800 addr:street=Vl?kova addr:streetnumber=3 source:addr=uir_adr uir_adr:ADRESA_KOD=22412948 addr:conscriptionnumber=643 addr:country=CZ addr:housenumber=643/3 addr:street=?edova addr:streetnumber=3 is_in=?ern? Most, Praha, CZ source:addr=mvcr:adresa source:position=cuzk:km Zda se mi, ze treba v tom prvnim pripade bys mel smazat uir_adr: ADRESA_KOD, pokud v tom tagu neco zmenis. Nebo ne? Nebudeme mit pak zmatek v tom, z ceho ty udaje pochazi? Co tedy znamena, ze je adresa oznacena ref:ruian a source:addr= cuzk:ruian? Znamena to, ze jen ten text je z ruian a poloha ne? A kdyz budeme chtit naimportovat/zmenit i polohu podle RUIAN, pak to budeme znacit ref:ruian, source:addr= cuzk:ruian a source:position=cuzk:ruian? Jen bych to chtel mit ujasneno dopredu. Zdravi, Dalibor

11.2.2014 09:21:34 (#9)
gravatar

Petr Vejsada

<osm at propsychology.cz>
507
Dne ?t 11. ?nora 2014 09:11:04, Dalibor Jel?nek napsal(a): Super post?ehy, p?esn? o tom ta diskuse m? b?t. Pokra?uj/te ;) zobrazit citaci
> Zda se mi, ze treba v tom prvnim pripade bys mel smazat uir_adr: ADRESA_KOD, > pokud v tom tagu neco zmenis. Nebo ne? > > Nebudeme mit pak zmatek v tom, z ceho ty udaje pochazi? > > Co tedy znamena, ze je adresa oznacena ref:ruian a source:addr= cuzk:ruian? > Znamena to, ze jen ten text je z ruian a poloha ne? > A kdyz budeme chtit naimportovat/zmenit i polohu podle RUIAN, pak to > budeme znacit ref:ruian, source:addr= cuzk:ruian a > source:position=cuzk:ruian? > Jen bych to chtel mit ujasneno dopredu.

11.2.2014 11:49:11 (#10)
gravatar

Petr Vejsada

<osm at propsychology.cz>
507
Ahoj, Dne ?t 11. ?nora 2014 09:01:07, Dalibor Jel?nek napsal(a): zobrazit citaci
> Ahoj, > ja teda is_in tag rad nemam, protoze nevim, jak se ma spravne vyplnovat. > Na druhou stranu se mi nezda hezke mazat neco, co nekdo do mapy > s nejakym usilim pridal. > Pokud opravdu dokazeme nahradit vse, co ted ten tag obsahuje, pak ano. > Ale uz ted vim, ze zatim ten navrh PV neobsahuje vse, co je v is_in. > V is_in jsou mestske casti (nekde) a stat, to tam zatim PV nema. > > Ja bych navrhoval, do tech adres pridavat : > addr:country=CZ (czechaddress to tam dava a proc to vynechavat?) > addr:suburb=Praha 14 (z m?stsk? ??st/obvod)
p?idat st?t nen? probl?m, ot?zka sp?? je, zda to m? smysl.? suburb - tabulka rn_spravni_obvod, ale tam je jen ta Praha zobrazit citaci
> > A jeste, to povazuji za dost dulezite, ale uz je asi pozde, bych zmenil > ref:ruian=<rn_adresni_misto.kod> > na treba > ref:ruian:am=<rn_adresni_misto.kod> > Protoze, az budeme chtit pridavat jine veci z RUIAN, treba stavebni objekty, > pak casem nevyhnutelne dojde k tomu, ze se dostane adresa z bodu > na objekt a bude konflikt ref:ruian.
V OSM u? jsou tis?ce stavebn?ch objekt? s ref_ruian=nnnnnn; n?kte?? jsme byli piln?. Adresn? m?sto jsem je?t? nep?idal ani jedno, tak?e by to zm?nit ?lo. zobrazit citaci
> Ale jestli je to uz pouzito na hodne mistech, pak asi nezbyde, nez ref:ruian > brat jako ID pro adresni misto a jina ID znacit jinak.
Sp?? ref_ruian br?t jako budovu, i kdy? nev?m, jak? je aktu?ln? stav. zobrazit citaci
> > Co se tyce importu, pak bych radsi prosel tu proceduru znova pro RUIAN, > nez rozsirovat jiz stavajici import. Klidne to vykomunikuju.
Za tuto nab?dku moc d?ky! Pokud se to spust?, tak budu r?d. -- Petr

12.2.2014 12:05:58 (#11)
gravatar

Petr Vejsada

<osm at propsychology.cz>
507
Dne ?t 11. ?nora 2014 09:11:04, Dalibor Jel?nek napsal(a): zobrazit citaci
> source:addr=uir_adr > uir_adr:ADRESA_KOD=22412948 > > is_in=?ern? Most, Praha, CZ > source:addr=mvcr:adresa > source:position=cuzk:km > > Zda se mi, ze treba v tom prvnim pripade bys mel smazat uir_adr: ADRESA_KOD, > pokud v tom tagu neco zmenis. Nebo ne?
Ur?it? ano, d?ky zobrazit citaci
> > Nebudeme mit pak zmatek v tom, z ceho ty udaje pochazi? >
Asi trochu ano. Co se t?k? polohy, tak tu bych necht?l (zbyte?n?) automaticky m?nit. Bod mohl n?kdo ?oupnout nad vchod podle vlastn? znalosti. Data v RUIAN nejsou p???ern?, ale n?kdy jsou ty body um?st?n? nevhodn?. Co? v OSM n?kdy taky, t??ko ??ci, kde je v?ce nevhodn?ch um?st?n?. J? si to zkou?el nane?isto, t.j. bez uploadu na OSM, a kdy? jsem editoval polohy bod? v JOSM, tak mi subjektivn? p?i?lo, ?e v OSM le?? ?asto na vhodn?j??ch m?stech, ne? v RUIAN. B?h su?. Neh?bal bych s t?m. Z toho by tedy m?lo vypl?vat, ?e pokud ru?n? ?oupnu bod nad vchod, m?l bych smazat source:position? Asi ano. zobrazit citaci
> Co tedy znamena, ze je adresa oznacena ref:ruian a source:addr= cuzk:ruian? > Znamena to, ze jen ten text je z ruian a poloha ne?
J? to ch?pu tak, ?e ?daje o adrese poch?z? prim?rn? z RUIAN. Na bodu mohou b?t dal?? tagy, typicky hospody a obchody; ty pochopiteln? z RUIAN nepoch?z?. zobrazit citaci
> A kdyz budeme chtit naimportovat/zmenit i polohu podle RUIAN, pak to > budeme znacit ref:ruian, source:addr= cuzk:ruian a > source:position=cuzk:ruian? > Jen bych to chtel mit ujasneno dopredu.
P?ijde mi to jako p??li? tag? typu source, nav?c jsou platn? jen do chv?le, ne? to n?kdo zedituje ru?n? a v tom p??pad? nen? z?ruka, zda ty source: taky sma?e. Ale nem?m nic proti t?to variant?, Tak?e source:addr=cuzk:ruian source:position=[ponechat st?vaj?c?|cuzk:ruian ref:ruian:am=nnnn nebo ref:ruian:addr=nnnnn (asi mezin?rodn? srozumiteln?j??) -- Petr

12.2.2014 02:05:10 (#12)
gravatar

Petr Vejsada

<osm at propsychology.cz>
507
Dne ?t 11. ?nora 2014 08:39:22, Petr Mor?vek [Xificurk] napsal(a): zobrazit citaci
> > Z?sadn? ot?zka ?.1 - co s tagy addr:country a is_in? Mo?nosti jsou > > ponechat, mazat ?i nahrazovat. Jak? m?te n?zor? > > Asi by bylo dobr? ud?lat n?jakou z?kladn? anal?zu obsahu is_in tagu - > pokud obsahuje jen ??st obce, obec, st?t... (nebo ??rkami oddelenou > kombinaci), tak smazat. Pokud jsou v?echna data is_in tagu obsa?ena ve > strukturovan? podob? v addr:*, tak si mysl?m, ?e nem? cenu, aby n?m tu > nad?le stra?il.
Zb??n? anal?za provedena, - is_in obsahuje nav?c kraj - is_in je u cca 90 procent v?ech entit, kde se vyskytuj? adresn? tagy. Tak co s t?m krajem? -- Petr

12.2.2014 09:15:24 (#13)
gravatar

hanoj

<ehanoj at gmail.com>
713
zobrazit citaci
> > A kdyz budeme chtit naimportovat/zmenit i polohu podle RUIAN, pak to > > budeme znacit ref:ruian, source:addr= cuzk:ruian a > > source:position=cuzk:ruian? > > Jen bych to chtel mit ujasneno dopredu. > > P?ijde mi to jako p??li? tag? typu source, nav?c jsou platn? jen do
chv?le,> ne? to n?kdo zedituje ru?n? a v tom p??pad? nen? z?ruka, zda ty source: taky zobrazit citaci
> > sma?e. Ale nem?m nic proti t?to variant?, > > > > Tak?e > > source:addr=cuzk:ruian > > source:position=[ponechat st?vaj?c?|cuzk:ruian > > ref:ruian:am=nnnn nebo ref:ruian:addr=nnnnn (asi mezin?rodn?
srozumiteln?j??) *** sp??e "source:loc" ne? position http://taginfo.openstreetmap.org/keys/source:position#combinations http://taginfo.openstreetmap.org/keys/source:loc#combinations ha hanoj -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20140212/3a715a1b/attachment.html>

12.2.2014 10:32:16 (#14)
gravatar

Dalibor Jelínek

<dalibor at dalibor.cz>
408 1253
Ahoj, jeste k tem referencim. Nevim, jak to vidi ostatni, ale ja bych hodne moc zadal o to, abychom ty reference na RUIAN opravdu oddelili. Mame v RUIAN mimimalne (zatim) ctyri ID cisla, ktera kazde znamena neco jineho: AM - adresni misto http://vdp.cuzk.cz/vdp/ruian/adresnimista/26147394 SO - stavebni objekt http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/25647661 P - parcelu http://vdp.cuzk.cz/vdp/ruian/parcely/2110216101 TEA vchodu tady neznam primy link na vyhledavani Prijde mi naprosto nevhodne, abychom to nerozsilovali a znacili stejnym tagem. Jednak pak neni mozne se atuomaticky odkazat na web RUIAN a zobrazit si detaily o te veci z RUIAN, protoze se proste nevi, jaky link vytvorit. Za druhe nektere veci proste nejdou udelat. Pokud nekdo prida adresu dle AM na nejaky maly domek (tedy nepouzije adresni bod, ale da to na jeho cestu, coz hodne lidi dela, pac jim to prijde lepsi), pak uz neni kam pridat RUIAN ID te budovy. Nebo, kdyz narazite na takovy objekt, tak se nevi, jestli to ref:ruian odkazuje na AM nebo SO. zobrazit citaci
> V OSM u? jsou tis?ce stavebn?ch objekt? s ref_ruian=nnnnnn; n?kte?? jsme
byli piln?. zobrazit citaci
> Sp?? ref_ruian br?t jako budovu, i kdy? nev?m, jak? je aktu?ln? stav.
Chapu, nenavrhuju to ted zpetne menit, ale byl bych rad, kdybychom od ted zacali pripadavat tu referenci do jine znacky, nez se usnest, ze ref_ruian bez rozliseni je SO. zobrazit citaci
> ref:ruian:am=nnnn nebo ref:ruian:addr=nnnnn (asi mezin?rodn?
srozumiteln?j??) Jo, to je urcite lepsi. RUIAN sice je taky cesky, ale to addr aspon dava smysl. zobrazit citaci
> To nech?m na ostatn?ch, jak se k tomu vyj?d??. Ono z?le??, jak?m stylem se
mapuje, p??padn? bude mapovat. zobrazit citaci
> Ono je n?co jin?ho ref:ruian na budov? a n?co jin?ho je ref:ruian na
pozemku nebo adresn?m m?st?. No, prave proto, ze je to neco jineho. A rozlisovat to jen podle toho, na jakem prvku je to pridane mi prijde velmi nevhodne, protoze se to bude v praxi michat mezi sebou (nekdo treba prekopiruje znacky z adresniho bodu na cestu domu). Muj navrh by tedy byl zacit pouzivat treba toto: AM - adresni misto ref:ruian:addr=nnnnn SO - stavebni objekt ref:ruian:building=nnnnn P - parcelu ref:ruian:parcel=nnnnn (nebo mozna ref:ruian:land ci ref:ruian:estate) TEA vchodu ref:ruian:entrance=nnnnn Co myslite? Zdravi, Dalibor PS: Za pokus o prohlaseni kraju za neexistujici se omlouvam. To byla blbost. Jen jsem mel zafixovano, ze kraje byly zruseny, pak zavedeny jinak a nekde se pouzivala porad stara struktura, pac byla v necem lepsi. Moc rychle jsem psal a malo myslel.

12.2.2014 06:06:45 (#15)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
138
Dne 12.2.2014 02:05, Petr Vejsada napsal(a): zobrazit citaci
> Dne ?t 11. ?nora 2014 08:39:22, Petr Mor?vek [Xificurk] napsal(a): > >>> Z?sadn? ot?zka ?.1 - co s tagy addr:country a is_in? Mo?nosti jsou >>> ponechat, mazat ?i nahrazovat. Jak? m?te n?zor? >> >> Asi by bylo dobr? ud?lat n?jakou z?kladn? anal?zu obsahu is_in tagu - >> pokud obsahuje jen ??st obce, obec, st?t... (nebo ??rkami oddelenou >> kombinaci), tak smazat. Pokud jsou v?echna data is_in tagu obsa?ena ve >> strukturovan? podob? v addr:*, tak si mysl?m, ?e nem? cenu, aby n?m tu >> nad?le stra?il. > > Zb??n? anal?za provedena, > - is_in obsahuje nav?c kraj > - is_in je u cca 90 procent v?ech entit, kde se vyskytuj? adresn? tagy. > > Tak co s t?m krajem? > > -- > Petr
Obecn? si mysl?m, ?e d?vat na adresn? informaci o jak?mkoliv administrativn?m celku od obce v??e je nesmysl (a do toho zahrnuji i st?t) - na adresu se to typicky nep??e a pokud to n?kdo pot?ebuje z jin?ch d?vod?, tak od toho m?me udr?ovan? administrativn? hranice a overpass API a i ten Nominatim tyto hranice um? pou??vat. Zdrav?, Petr Mor?vek aka Xificurk

12.2.2014 09:00:50 (#16)
gravatar

Marián Kyral

<mkyral at email.cz>
2234 2403
Dne 12.2.2014 18:06, Petr Mor?vek [Xificurk] napsal: zobrazit citaci
> Dne 12.2.2014 02:05, Petr Vejsada napsal(a): >> Dne ?t 11. ?nora 2014 08:39:22, Petr Mor?vek [Xificurk] napsal(a): >> >>>> Z?sadn? ot?zka ?.1 - co s tagy addr:country a is_in? Mo?nosti jsou >>>> ponechat, mazat ?i nahrazovat. Jak? m?te n?zor? >>> >>> Asi by bylo dobr? ud?lat n?jakou z?kladn? anal?zu obsahu is_in tagu - >>> pokud obsahuje jen ??st obce, obec, st?t... (nebo ??rkami oddelenou >>> kombinaci), tak smazat. Pokud jsou v?echna data is_in tagu obsa?ena >>> ve >>> strukturovan? podob? v addr:*, tak si mysl?m, ?e nem? cenu, aby n?m >>> tu >>> nad?le stra?il. >> >> Zb??n? anal?za provedena, >> - is_in obsahuje nav?c kraj >> - is_in je u cca 90 procent v?ech entit, kde se vyskytuj? adresn? >> tagy. >> >> Tak co s t?m krajem? >> >> -- >> Petr > > Obecn? si mysl?m, ?e d?vat na adresn? informaci o jak?mkoliv > administrativn?m celku od obce v??e je nesmysl (a do toho zahrnuji i > st?t) - na adresu se to typicky nep??e a pokud to n?kdo pot?ebuje z > jin?ch d?vod?, tak od toho m?me udr?ovan? administrativn? hranice a > overpass API a i ten Nominatim tyto hranice um? pou??vat. >
A m?me jistotu, ?e to n?kdo t?eba nepou??v?? Mari?n zobrazit citaci
> Zdrav?, > Petr Mor?vek aka Xificurk > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz

13.2.2014 12:51:48 (#17)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
138
Dne 12.2.2014 21:00, Mari?n Kyral napsal(a): zobrazit citaci
> Dne 12.2.2014 18:06, Petr Mor?vek [Xificurk] napsal: >> Dne 12.2.2014 02:05, Petr Vejsada napsal(a): >>> Dne ?t 11. ?nora 2014 08:39:22, Petr Mor?vek [Xificurk] napsal(a): >>> >>>>> Z?sadn? ot?zka ?.1 - co s tagy addr:country a is_in? Mo?nosti jsou >>>>> ponechat, mazat ?i nahrazovat. Jak? m?te n?zor? >>>> >>>> Asi by bylo dobr? ud?lat n?jakou z?kladn? anal?zu obsahu is_in tagu - >>>> pokud obsahuje jen ??st obce, obec, st?t... (nebo ??rkami oddelenou >>>> kombinaci), tak smazat. Pokud jsou v?echna data is_in tagu obsa?ena ve >>>> strukturovan? podob? v addr:*, tak si mysl?m, ?e nem? cenu, aby n?m tu >>>> nad?le stra?il. >>> >>> Zb??n? anal?za provedena, >>> - is_in obsahuje nav?c kraj >>> - is_in je u cca 90 procent v?ech entit, kde se vyskytuj? adresn? tagy. >>> >>> Tak co s t?m krajem? >>> >>> -- >>> Petr >> >> Obecn? si mysl?m, ?e d?vat na adresn? informaci o jak?mkoliv >> administrativn?m celku od obce v??e je nesmysl (a do toho zahrnuji i >> st?t) - na adresu se to typicky nep??e a pokud to n?kdo pot?ebuje z >> jin?ch d?vod?, tak od toho m?me udr?ovan? administrativn? hranice a >> overpass API a i ten Nominatim tyto hranice um? pou??vat. >> > > A m?me jistotu, ?e to n?kdo t?eba nepou??v?? > Mari?n
Naprost? jistota samoz?ejm? nikdy nebude, ale vzhledem k rozmanitosti form?tu i obsahu tagu is_in (a z?rove? dostupnosti t? sam? informace na "lep??ch" m?stech), bych se docela divil, kdyby to n?kde bylo ve v?t?? m??e bylo pou??v?no. Petr

13.2.2014 03:31:34 (#18)
gravatar

Pavel Machek

<pavel at ucw.cz>
1036 1226
On Tue 2014-02-11 23:49:11, Petr Vejsada wrote: zobrazit citaci
> Ahoj, > > Dne ?t 11. ?nora 2014 09:01:07, Dalibor Jel?nek napsal(a): > > > Ahoj, > > ja teda is_in tag rad nemam, protoze nevim, jak se ma spravne vyplnovat. > > Na druhou stranu se mi nezda hezke mazat neco, co nekdo do mapy > > s nejakym usilim pridal. > > Pokud opravdu dokazeme nahradit vse, co ted ten tag obsahuje, pak ano. > > Ale uz ted vim, ze zatim ten navrh PV neobsahuje vse, co je v is_in. > > V is_in jsou mestske casti (nekde) a stat, to tam zatim PV nema. > > > > Ja bych navrhoval, do tech adres pridavat : > > addr:country=CZ (czechaddress to tam dava a proc to vynechavat?) > > addr:suburb=Praha 14 (z m?stsk? ??st/obvod) > > p?idat st?t nen? probl?m, ot?zka sp?? je, zda to m? smysl.?
Jo, ma. Wiki rika, ze to tam ma byt, a ne kazdy si chce stahovat hranice zemi aby mohl pracovat s adresama. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

13.2.2014 05:57:07 (#19)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
138
Dne 13.2.2014 15:31, Pavel Machek napsal(a): zobrazit citaci
> On Tue 2014-02-11 23:49:11, Petr Vejsada wrote: >> Ahoj, >> >> Dne ?t 11. ?nora 2014 09:01:07, Dalibor Jel?nek napsal(a): >> >>> Ahoj, >>> ja teda is_in tag rad nemam, protoze nevim, jak se ma spravne vyplnovat. >>> Na druhou stranu se mi nezda hezke mazat neco, co nekdo do mapy >>> s nejakym usilim pridal. >>> Pokud opravdu dokazeme nahradit vse, co ted ten tag obsahuje, pak ano. >>> Ale uz ted vim, ze zatim ten navrh PV neobsahuje vse, co je v is_in. >>> V is_in jsou mestske casti (nekde) a stat, to tam zatim PV nema. >>> >>> Ja bych navrhoval, do tech adres pridavat : >>> addr:country=CZ (czechaddress to tam dava a proc to vynechavat?) >>> addr:suburb=Praha 14 (z m?stsk? ??st/obvod) >> >> p?idat st?t nen? probl?m, ot?zka sp?? je, zda to m? smysl.? > > Jo, ma. Wiki rika, ze to tam ma byt, a ne kazdy si chce stahovat > hranice zemi aby mohl pracovat s adresama. > Pavel >
Ahoj, Wiki nen? ??dn? norma... a nikdy nebyla. Taginfo ??k?, ?e addr:country existuje na necel? polovin? adresn?ch bod? - konkr?tn? jej m?: - 44% objekt?, kter? maj? addr:housenumber - 46% objekt?, kter? maj? addr:street Tak?e ono to a? tak d?sledn?, jak nazna?uje?, pou??van? nen?. Nev?m, co si m?m p?edstavit pod "mohl pracovat s adresama", ale... Pokud chci dostat skute?n? v?echny adresn? body v ?R je to ot?zka jedin?ho jednoduch?ho dotazu na overpass API. Pokud m?m bod a chci z?skat v?echny administrativn? celky (K? a? st?t), ve kter?ch le??, tak op?t polo??m jeden jednoduch? dotaz na overpass API. Ani pro jedno si j? nepot?ebuju stahovat hranice k sob? a z?rove? to d?v? spolehliv?j?? v?sledky, ne? hled?n? podle addr:country. Zdrav?, Petr Mor?vek aka Xificurk

13.2.2014 06:20:26 (#20)
gravatar

Pavel Machek

<pavel at ucw.cz>
1036 1226
AhoJ! zobrazit citaci
> > Jo, ma. Wiki rika, ze to tam ma byt, a ne kazdy si chce stahovat > > hranice zemi aby mohl pracovat s adresama. > > Wiki nen? ??dn? norma... a nikdy nebyla.
Ne? A co je tedy norma? talk-cz@ mailing list? zobrazit citaci
> Taginfo ??k?, ?e addr:country existuje na necel? polovin? adresn?ch bod? > - konkr?tn? jej m?: > - 44% objekt?, kter? maj? addr:housenumber > - 46% objekt?, kter? maj? addr:street > Tak?e ono to a? tak d?sledn?, jak nazna?uje?, pou??van? nen?.
Coz porad neni duvod to kazit jeste vic. Dela se hromadna uprava, hromadna uprava by mela byt spravne. Pokud nesouhlasis s wiki, fajn, oprav wiki. Ale import by se mel ridit tim co je na wiki. (A ne, nemyslim ze by pro import bylo vic prace pridat addr:country, a nemyslim ze tech par bajtu navic neco zmeni.) zobrazit citaci
> Nev?m, co si m?m p?edstavit pod "mohl pracovat s adresama", ale... Pokud > chci dostat skute?n? v?echny adresn? body v ?R je to ot?zka jedin?ho > jednoduch?ho dotazu na overpass API. Pokud m?m bod a chci z?skat > v?echny
Mam tady offline navigaci na n900. Fakt chci aby zustala offline, a ne, nebudu si instalovat posgresql pro to, a by mi fungovalo vyhledavani podle adresy. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

13.2.2014 08:28:44 (#21)
gravatar

Martin Mares

<mj at ucw.cz>
18
Hello, world!\n zobrazit citaci
> Mam tady offline navigaci na n900. Fakt chci aby zustala offline, a > ne, nebudu si instalovat posgresql pro to, a by mi fungovalo > vyhledavani podle adresy.
Uprimne receno, na to vubec postgresql nepotrebujes. Lokalizace bodu v rozkladu roviny na mnohouhelniky je vcelku trivialni problem, na ktery staci napriklad uplne jednoducha konstrukce persistentniho stromu. Kdysi jsem o tom neco malo napsal, muzes se inspirovat treba zde: http://mj.ucw.cz/vyuka/ads/43-geom.pdf Have a nice fortnight -- Martin `MJ' Mares <mj at ucw.cz> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "Object orientation is in the mind, not in the compiler." -- Alan Cox

13.2.2014 10:12:38 (#22)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
138
Ahoj, j? to rad?i zas slou??m do jednoho vl?kna. A rovnou se omlouv?m, ?e ty tvoje dva maily a odpov?di na n? prom?ch?m, ale je to jedno t?ma, tak a? je to pohromad?. Dne 13.2.2014 18:20, Pavel Machek napsal(a): zobrazit citaci
>> Wiki nen? ??dn? norma... a nikdy nebyla. > > Ne? A co je tedy norma? talk-cz@ mailing list?
Ne, talk-cz@ skute?n? taky ??dn? norma nen?. Norma pro OSM tagov?n? toti? jednodu?e neexistuje. Jak? tagy jsou nebo nejsou po??v?no ur?uje jen a pouze to, jestli skute?n? jsou nebo nejsou v datab?zi pou??v?ny. Wiki slou?? jako dokumentace "best-practice". Rozhodn? nen? pravda, ?e co je na wiki, tak se mus? pou??vat a ??dn? jin? varianta nen? p??pustn?, nebo ?e co nen? na wiki, to neexistuje a se nesm? se pou??vat. A tohle nen? m?j osobn? v?mysl, takto je to prezentov?no, jak na wiki samotn?, tak i jednotliv?ch mezin?rodn?ch mailing listech. (A p???t? mi pros?m nepodsouvej v?ci, kter? jsem ani v nejmen??m nenazna?oval.) zobrazit citaci
>> Taginfo ??k?, ?e addr:country existuje na necel? polovin? adresn?ch bod? >> - konkr?tn? jej m?: >> - 44% objekt?, kter? maj? addr:housenumber >> - 46% objekt?, kter? maj? addr:street >> Tak?e ono to a? tak d?sledn?, jak nazna?uje?, pou??van? nen?. > > Coz porad neni duvod to kazit jeste vic. Dela se hromadna uprava, > hromadna uprava by mela byt spravne. Pokud nesouhlasis s wiki, fajn, > oprav wiki. Ale import by se mel ridit tim co je na wiki.
Import by se v prv? ?ad? m?l ??dit zdrav?m rozumem, a? n?sledn? n?jak?m ?l?nkem na wiki. Zn?n? t?ch ?l?nk? se koneckonc? m?n? pr?v? na z?klad? diskuze a p?edlo?en? racion?ln?ch argument?. zobrazit citaci
>> U? jsem psal koment?? vedle, pro? tento tag pova?uji za >> "po?ekonan?". > > Wiki si to nemysli. Jestli s tebou zbytek sveta souhlasi, tak nebude > problem problem problem opravit na wiki, ze?
Wiki nen? pot?eba opravovat, ono to tam u? toti? je. Jen jsi to asi p?ehl?dl: zobrazit citaci
> The keys addr:housenumber=* und addr:street=* in principle are the only necessary ones if there are valid border polygons.
(http://wiki.openstreetmap.org/wiki/Addr) zobrazit citaci
> (A ne, nemyslim ze by pro import bylo vic prace pridat addr:country, a > nemyslim ze tech par bajtu navic neco zmeni.)
T?mi p?r bajty se tu oh?n? lidi n?jak ?asto... Cel? st?tn? hranice ?R (relace, v?echny cesty a body a jejich tagy) m? 11 MB v nekomprimovan?m form?tu. '<tag k="addr:country" v="CZ"/>\n' 31 B * 2917732 adresn?ch m?st = 86 MB T?ch "par bajtu navic" je ve skute?nosti mnohon?sobn? v?c ne? m? kompletn? hranice ?R (jej?mu? stahov?n? se t?mi par bajty navic sna??? vyhnout). zobrazit citaci
>> Nev?m, co si m?m p?edstavit pod "mohl pracovat s adresama", ale... Pokud >> chci dostat skute?n? v?echny adresn? body v ?R je to ot?zka jedin?ho >> jednoduch?ho dotazu na overpass API. Pokud m?m bod a chci z?skat >> v?echny > > Mam tady offline navigaci na n900. Fakt chci aby zustala offline, a > ne, nebudu si instalovat posgresql pro to, a by mi fungovalo > vyhledavani podle adresy.
Nenapsal jsi, v ?em konkr?tn? by nastal probl?m, tak?e neum?m d?t konkr?tn? odpov??. Ale p?edpokl?d?m, ?e n?jak ty data aktualizuje?. A z toho, co jsi psal h?d?m, ?e tam necpe? p??mo cel? dump OSM dat, ale d?l?? n?jak? pre-processing, nev?m ??m a jak ale divil bych se, kdyby to neum?lo spolupracovat z relacemi hranic a spol?halo se jen a pouze na addr:country, nebo is_in tag. A i kdyby neum?lo, tak existuje zm?n?n? overpass API. zobrazit citaci
>> Ale je pravda, ?e narozd?l od is_in v tomto p??pad? hroz? v?t?? riziko, >> ?e to st?le je?t? n?kdo pou??v?. > > Is_in se pouzival treba tady: > > http://code.google.com/p/osmand/issues/detail?id=391
Irelevantn? po p?e?ten? prvn? v?ty: zobrazit citaci
> Convert using OsmAndMapCreator-0.5.1beta-b2, an osm map without borders to delimit cities, so street ownership is determined by is_in tag in the corresponding "way".
My ty hranice (nejen) m?st m?me... a je?t? k tomu m?me (a nikdo se nesna?? to zm?nit) i addr:place. J? netvrd?m, ?e se to "nikde a v?bec" nepou??v?... pr?v? naopak z historick?ch d?vod? to jako ?pln? posledn? fallback pou??v? cel? ?ada softwaru, ale je to skute?n? a? ten nejposledn?j?? fallback. Jednodu?e tenhle tag je deprecated a nem? smysl ho d?le udr?ovat, proto?e existuj? spolehliv?j?? cesty, jak se k dan?m informac?m dostat. zobrazit citaci
> Opravdu si chces projit vsechen existujici software, a overit, ze uz > to nikdo nepouziva?
Nechci, cht?l jsem po tob? alespo? jeden konkr?tn? p??klad, k ?emu/kde je to u?ite?n? - myslel jsem, ?e jsem to napsal dost jasn?, ne? A mysl?m opravdu u?ite?n?, tzn. "S is_in/addr:country tagem 'tohle' funguje, bez n?j ne." zobrazit citaci
>> Osobn? jsem tedy pro: nep?id?vat, ale nemazat (krom p??pad?, kdy tam je >> n?jak? nesmysl). > > Na wiki ten tag stale jeste je, tak by to tam byt melo.
Na wiki je naps?no, ?e tam b?t nemus?, tak tam taky b?t nemus? :P zobrazit citaci
>>> (A viz anglicka wiki, ktera vysvetluje, ze mesto v is_in muze byt jine >>> nez v addr:city.) >> >> M?? konkr?tn? p??klad pro ?R? > > Proc bych mel mit priklad pro CR?
Eh, to jako v??n?? Nu, dobr?... T?matem t?to diskuze je "Adresy z RUIAN", to jsou adresy v ?R. Tvoji v??e uvedenou pozn?mku jsem si vylo?il tak, ?e is_in tag by se v r?mci tohoto importu nem?l mazat, proto?e je u?ite?n?, proto?e m??e obsahovat jin? m?sto ne? addr:city. Jeliko? m? osobn? nenapad? ??dn? p??klad adresn?ho m?sta (importovan?ho z RUIAN), kde by se tato vlastnost hodila, tak jsem se zeptal, jestli ty n?jak? takov? m??. Je to stejn? jako s t?m softwarem - p?edlo? n?jak? rozumn? p??klad. J? jsem p?ipraven kdykoliv zm?nit sv?j n?zor, ale pot?ebuji k tomu n?jak? racion?ln? argument. Zdrav?, Petr Mor?vek aka Xificurk

13.2.2014 10:24:34 (#23)
gravatar

Marián Kyral

<mkyral at email.cz>
2234 2403
Dne 13.2.2014 20:28, Martin Mares napsal: zobrazit citaci
> Hello, world!\n > >> Mam tady offline navigaci na n900. Fakt chci aby zustala offline, a >> ne, nebudu si instalovat posgresql pro to, a by mi fungovalo >> vyhledavani podle adresy. > > Uprimne receno, na to vubec postgresql nepotrebujes. Lokalizace bodu > v rozkladu roviny na mnohouhelniky je vcelku trivialni problem, na > ktery > staci napriklad uplne jednoducha konstrukce persistentniho stromu. > > Kdysi jsem o tom neco malo napsal, muzes se inspirovat treba zde: > http://mj.ucw.cz/vyuka/ads/43-geom.pdf > > Have a nice fortnight

14.2.2014 08:29:49 (#24)
gravatar

Dalibor Jelínek

<dalibor at dalibor.cz>
408 1253
Ahoj, se nam ta debata nejak rozvasnuje. ;-) zobrazit citaci
> Pokud m?m bod a chci z?skat v?echny administrativn? celky (K? a? st?t), ve kter?ch le??, tak op?t polo??m jeden jednoduch? dotaz na overpass API
Tak ho sem napis. Ja ho neumim, vymyslet ho nechci, ale chtel bych se podivat, jak se to dela. Ja bych to addr:country=CZ daval vsude, protoze to treba zjednodusi vyhledavani bodu zajmu v prihranici. A do te adresy to proste tak nejak patri, i kdyz se zda, ze je to z naseho pohledu implicitni. Tady je dokonce nejaky naznak, ze to nekde dela problemy, kdyz to chybi http://wiki.openstreetmap.org/wiki/OSM_Inspector/Views/Addresses Ano, o neco to zvetsi databazi, ale to je fakt zanedbatelne. Kdyz uz chceme setrit misto, tak bych zmenil nazor a hlasoval pro mazani is_in tagu. Skutecne si myslim, ze je prezity, ale hlavne neni jasne nikde napsano v jakem tvaru se ma vytvaret, takze dost pochybuju, ze by ho nekdo mohl rozumne vyuzit. Jeho hlavni prinos jsem videl v dobe, kdy se nepouzivalo addr:place. Ted uz nevidim zadny.Puvodne jsem ho tam chtel nechavat, protoze mi prislo nevhodne neco mazat, ale stejne bychom ho pak museli opravovat, tedy poradne nadefinovat a obavam se, ze v tom procesu bychom zjistili, ze ho vlastne nepotrebujeme vubec. Zdravi, Dalibor

14.2.2014 08:54:05 (#25)
gravatar

Marián Kyral

<mkyral at email.cz>
2234 2403
Dne 14.2.2014 08:29, Dalibor Jel?nek napsal: zobrazit citaci
> Ahoj, > > Kdyz uz chceme setrit misto, tak bych zmenil nazor a hlasoval pro > mazani > is_in tagu. Skutecne si myslim, ze je prezity, ale hlavne neni jasne > nikde > napsano v jakem tvaru se ma vytvaret,
http://wiki.openstreetmap.org/wiki/Cs:JOSM/Plugins/CzechAddress#Adresy_v_OpenStreetMap zobrazit citaci
> takze dost pochybuju, ze by ho > nekdo mohl rozumne vyuzit. Jeho hlavni prinos jsem videl v dobe, kdy > se nepouzivalo addr:place. Ted uz nevidim zadny.Puvodne jsem ho tam > chtel nechavat, protoze mi prislo nevhodne neco mazat, ale stejne > bychom > ho pak museli opravovat, tedy poradne nadefinovat a obavam se, ze v tom > procesu bychom zjistili, ze ho vlastne nepotrebujeme vubec.
Pokud jej zachov?me, tak jsem pro to, aby se to ud?lalo po??dn?: [m?stn? ??st], [m?stsk? ??st], [m?sto], [okres], [kraj], CZ S t?m, ?e minim?ln? z?pis bude: [m?sto], [okres], [kraj], CZ Mari?n

14.2.2014 10:02:19 (#26)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
138
Dne 14.2.2014 08:29, Dalibor Jel?nek napsal(a): zobrazit citaci
> Ahoj, > se nam ta debata nejak rozvasnuje. ;-) > >> Pokud m?m bod a chci z?skat v?echny administrativn? celky (K? a? st?t), ve kter?ch le??, tak op?t polo??m jeden jednoduch? dotaz na overpass API > Tak ho sem napis. Ja ho neumim, vymyslet ho nechci, ale chtel bych se podivat, jak se to dela. > > Ja bych to addr:country=CZ daval vsude, protoze to treba zjednodusi > vyhledavani bodu zajmu v prihranici. A do te adresy to proste tak nejak patri, > i kdyz se zda, ze je to z naseho pohledu implicitni.
Jak konkr?tn? to zjednodu??? Kdy? hled?m "Ulice 42, Obec", "Ulice, Obec", nebo "POI, Obec", tak tam ani CZ nem?m a typicky to nepot?ebuji (ta obec sta??). A znovu mus?m opakovat, ?e pro tyhle ?daje existuj? spolehliv?j?? zdroje, schv?ln? si dejte hledat v nominatimu "praha hlavn? n?dra??" a zobraz? se v?m: ?elezni?n? stanice Prague Main Railway Station, Legerova, Vinohrady, Praha, Hlavn? m?sto Praha, Praha, 12000, ?esko (hm, asi bych se m?l pod?vat, pro? to tam je anglicky :D) A p?itom ten uzel neobsahuje jedin? addr:* nebo is_in tag. A pokud jde o reverzn? ?kol, nap?. z?skat v?echny adresn? body t?eba v Mikulov?, tak tady jsou: http://overpass-turbo.eu/s/2w1 Op?t, na to nen? pot?eba ??dn? addr:* nebo is_in tag. zobrazit citaci
> Tady je dokonce nejaky naznak, ze to nekde dela problemy, kdyz to chybi > http://wiki.openstreetmap.org/wiki/OSM_Inspector/Views/Addresses
Uv?domuje? si, ?e d?v?? odkaz na n?co, co u? v?c jak p?t let nefunguje? :-) Nav?c ten hlavn? probl?m nen? v chyb?j?c?m addr:country, ale jednodu?e ?patn? navr?en?m algoritmu. Zdrav?, Petr Mor?vek aka Xificurk

14.2.2014 01:35:36 (#27)
gravatar

Dalibor Jelínek

<dalibor at dalibor.cz>
408 1253
Ahoj, http://wiki.openstreetmap.org/wiki/Cs:JOSM/Plugins/CzechAddress#Adresy_v_OpenStreetMap tak to jsem nenasel. Cekal bych, ze to najdu na ceskych Map Features nebo Editing Standards. Neva, prilezitostne to tam dopisu. zobrazit citaci
> Pokud jej zachov?me, tak jsem pro to, aby se to ud?lalo po??dn?: > [m?stn? ??st], [m?stsk? ??st], [m?sto], [okres], [kraj], CZ > S t?m, ?e minim?ln? z?pis bude: > [m?sto], [okres], [kraj], CZ
Hmm. A nevadi nam, ze tam mame carky, kdyz tady http://wiki.openstreetmap.org/wiki/Key:is_in se zcela zjevne doporucujou stredniky? M? to teda vad? hodn?. St?edn?k by byl lep??, proto?e to je standardn? odd?lov?tko. Nav?c ta str?nka p??e, ?e vlastn? na po?ad? t?ch ??st? zas tak moc nez?le?? (i kdy? je lep?? je m?t se?azen?), ale my vlastn? ??dn? ??sti nem?me, tak?e zahrani?n? programy na to asi koukaj dost divn?. zobrazit citaci
> Uv?domuje? si, ?e d?v?? odkaz na n?co, co u? v?c jak p?t let nefunguje?
Ee, nee, proste jsem to jen nasel. Mozna blbej algoritmus, ale chybelo jim to. ;-) zobrazit citaci
> Pokud m?m bod a chci z?skat v?echny administrativn? celky (K? a? > st?t), ve kter?ch le??, tak op?t polo??m jeden jednoduch? dotaz na > overpass API
Kdy? j? jsem cht?l v?d?t, jak se d?l? tohle. Naj?t adresy v n?jak?ch hranic?ch u? jste m? nau?ili. Zdrav?, Dalibor

14.2.2014 03:26:36 (#28)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
138
Dne 14.2.2014 13:35, Dalibor Jel?nek napsal(a): zobrazit citaci
> Ahoj, > http://wiki.openstreetmap.org/wiki/Cs:JOSM/Plugins/CzechAddress#Adresy_v_OpenStreetMap > tak to jsem nenasel. Cekal bych, ze to najdu na ceskych Map Features nebo Editing Standards. > Neva, prilezitostne to tam dopisu. > >> Pokud jej zachov?me, tak jsem pro to, aby se to ud?lalo po??dn?: >> [m?stn? ??st], [m?stsk? ??st], [m?sto], [okres], [kraj], CZ >> S t?m, ?e minim?ln? z?pis bude: >> [m?sto], [okres], [kraj], CZ > > Hmm. A nevadi nam, ze tam mame carky, kdyz tady > http://wiki.openstreetmap.org/wiki/Key:is_in > se zcela zjevne doporucujou stredniky? > M? to teda vad? hodn?. St?edn?k by byl lep??, proto?e to je standardn? odd?lov?tko. > Nav?c ta str?nka p??e, ?e vlastn? na po?ad? t?ch ??st? zas tak moc nez?le?? (i kdy? je lep?? > je m?t se?azen?), ale my vlastn? ??dn? ??sti nem?me, tak?e zahrani?n? programy na > to asi koukaj dost divn?.
A je?t? by se tam mohl p?idat NUTS2 region, katastr?ln? ?zem?, ZSJ, PS?, jm?no ulice, ... t?ch p?r bajt? nav?c nikoho nezabije :P A te? v??n? - dok??e n?kdo ??ct k ?emu by to m?lo b?t u?ite?n?? O tom, ?e je tento tag p?ekonan? koneckonc? sv?d?? i ??sla z taginfo: addr:housenumber celkem 29 mil. objekt?, 2 mil. m? is_in tag addr:street celkem 26 mil. objekt?, 1 mil. z nich m? is_in tag is_in celkem 4 mil. objekt? zobrazit citaci
>> Uv?domuje? si, ?e d?v?? odkaz na n?co, co u? v?c jak p?t let nefunguje? > Ee, nee, proste jsem to jen nasel. Mozna blbej algoritmus, ale chybelo jim to. ;-)
Chyb?lo jim to "tenkr?t" - bylo pot?eba bu? addr:country, rozumn?j?? hranice st?t?, nebo chyt?ej?? algoritmus. Rozhodn? tuhle p?t let mrtvou v?c nelze pova?ovat za smyslupln? argument pro plo?n? pou??v?n? addr:country ;-) zobrazit citaci
>> Pokud m?m bod a chci z?skat v?echny administrativn? celky (K? a? >> st?t), ve kter?ch le??, tak op?t polo??m jeden jednoduch? dotaz na >> overpass API > Kdy? j? jsem cht?l v?d?t, jak se d?l? tohle.
Nap?. takto: http://overpass-turbo.eu/s/2wb zobrazit citaci
> Naj?t adresy v n?jak?ch hranic?ch u? jste m? nau?ili.
Overpass API toho um? opravdu spoustu, na wiki je rozs?hl? dokumentace. Hlavn? v?hodou je, ?e nen? pot?eba vlastn?ma silama n?co instalovat a nastavovat. Zdrav?, Petr Mor?vek

15.2.2014 10:59:21 (#29)
gravatar

Pavel Machek

<pavel at ucw.cz>
1036 1226
Ahoj! zobrazit citaci
> > Mam tady offline navigaci na n900. Fakt chci aby zustala offline, a > > ne, nebudu si instalovat posgresql pro to, a by mi fungovalo > > vyhledavani podle adresy. > > Uprimne receno, na to vubec postgresql nepotrebujes. Lokalizace bodu > v rozkladu roviny na mnohouhelniky je vcelku trivialni problem, na ktery > staci napriklad uplne jednoducha konstrukce persistentniho stromu.
Je zajimave, cemu se jeste da rict "vcelku trivialni". Uprimne receno, nepotrebuju. Takze mam dobrovolnika, ktery tohle implementuje do monav-u, navit-u, osmand-u a marble a ja nevim ceho jeste dalsiho? Tesim se na patche, a do doby nez budou aplikovany, muzeme prosim tagovat adresy dle wiki? (Mimochodem, zeme neni rovina; pro ceskou republiku je to asi jedno, ale kdyby nas zajimala jen ceska republika, tak opravdu neni nutne tagovat kod zeme). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

15.2.2014 11:12:15 (#30)
gravatar

Pavel Machek

<pavel at ucw.cz>
1036 1226
On Fri 2014-02-14 10:02:19, "Petr Mor?vek [Xificurk]" wrote: zobrazit citaci
> Dne 14.2.2014 08:29, Dalibor Jel?nek napsal(a): > > Ahoj, > > se nam ta debata nejak rozvasnuje. ;-) > > > >> Pokud m?m bod a chci z?skat v?echny administrativn? celky (K? a? st?t), ve kter?ch le??, tak op?t polo??m jeden jednoduch? dotaz na overpass API > > Tak ho sem napis. Ja ho neumim, vymyslet ho nechci, ale chtel bych se podivat, jak se to dela. > > > > Ja bych to addr:country=CZ daval vsude, protoze to treba zjednodusi > > vyhledavani bodu zajmu v prihranici. A do te adresy to proste tak nejak patri, > > i kdyz se zda, ze je to z naseho pohledu implicitni. > > Jak konkr?tn? to zjednodu??? > > Kdy? hled?m "Ulice 42, Obec", "Ulice, Obec", nebo "POI, Obec", tak tam > ani CZ nem?m a typicky to nepot?ebuji (ta obec sta??). > > A znovu mus?m opakovat, ?e pro tyhle ?daje existuj? spolehliv?j?? > zdroje, schv?ln? si dejte hledat v nominatimu "praha hlavn? n?dra??" a > zobraz? se v?m: > ?elezni?n? stanice Prague Main Railway Station, Legerova, Vinohrady, > Praha, Hlavn? m?sto Praha, Praha, 12000, ?esko > (hm, asi bych se m?l pod?vat, pro? to tam je anglicky :D) > A p?itom ten uzel neobsahuje jedin? addr:* nebo is_in tag.
Nominatim to zvladnul. Na http://wiki.openstreetmap.org/wiki/Routing je seznam pouzivanych programu na hledani. Zvladnou to vsechny z nich? zobrazit citaci
> A pokud jde o reverzn? ?kol, nap?. z?skat v?echny adresn? body t?eba v > Mikulov?, tak tady jsou: > http://overpass-turbo.eu/s/2w1 > Op?t, na to nen? pot?eba ??dn? addr:* nebo is_in tag.
A jak to udelam v josm bez overpassu? Jinak... ta zeme je soucasti adresy, pise se na dopisy zaslany ze zahranici. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

15.2.2014 11:30:39 (#31)
gravatar

Pavel Machek

<pavel at ucw.cz>
1036 1226
Ahoj! zobrazit citaci
> j? to rad?i zas slou??m do jednoho vl?kna. A rovnou se omlouv?m, ?e ty > tvoje dva maily a odpov?di na n? prom?ch?m, ale je to jedno t?ma, tak a? > je to pohromad?. > > > Dne 13.2.2014 18:20, Pavel Machek napsal(a): > >> Wiki nen? ??dn? norma... a nikdy nebyla. > > > > Ne? A co je tedy norma? talk-cz@ mailing list? > > Ne, talk-cz@ skute?n? taky ??dn? norma nen?. Norma pro OSM tagov?n? > toti? jednodu?e neexistuje. Jak? tagy jsou nebo nejsou po??v?no ur?uje > jen a pouze to, jestli skute?n? jsou nebo nejsou v datab?zi pou??v?ny. > Wiki slou?? jako dokumentace "best-practice". Rozhodn? nen? pravda, > ?e
Fajn. Takze je to best-practice. Od ktere se chces odchylit, a duvodem se zda byt "je mi lito 86MB v databazi". To myslim neni dobry duvod, proc se od best-practice odchylit. zobrazit citaci
> Import by se v prv? ?ad? m?l ??dit zdrav?m rozumem, a? n?sledn? n?jak?m > ?l?nkem na wiki. Zn?n? t?ch ?l?nk? se koneckonc? m?n? pr?v? na z?klad? > diskuze a p?edlo?en? racion?ln?ch argument?.
Muj zdravy rozum rika ze jinde se addr:country pouziva, tak by tam mel byt i nadale. zobrazit citaci
> Wiki nen? pot?eba opravovat, ono to tam u? toti? je. Jen jsi to asi > p?ehl?dl: > > The keys addr:housenumber=* und addr:street=* in principle are the only necessary ones if there are valid border polygons. > (http://wiki.openstreetmap.org/wiki/Addr)
Ale neni tam "due to space reasons, it is reasonable to delete addr:country when border polygons are available". zobrazit citaci
> T?ch "par bajtu navic" je ve skute?nosti mnohon?sobn? v?c ne? m? > kompletn? hranice ?R (jej?mu? stahov?n? se t?mi par bajty navic sna??? > vyhnout).
Hlavne se chci vyhnout programovani tech vypoctu. A nerad bych "opravoval" programy, ktere addr:country z nejakeho duvodu pouzivaji. zobrazit citaci
> >> Nev?m, co si m?m p?edstavit pod "mohl pracovat s adresama", ale... Pokud > >> chci dostat skute?n? v?echny adresn? body v ?R je to ot?zka jedin?ho > >> jednoduch?ho dotazu na overpass API. Pokud m?m bod a chci z?skat > >> v?echny > > > > Mam tady offline navigaci na n900. Fakt chci aby zustala offline, a > > ne, nebudu si instalovat posgresql pro to, a by mi fungovalo > > vyhledavani podle adresy. > > Nenapsal jsi, v ?em konkr?tn? by nastal probl?m, tak?e neum?m d?t > konkr?tn? odpov??. Ale p?edpokl?d?m, ?e n?jak ty data aktualizuje?. A z > toho, co jsi psal h?d?m, ?e tam necpe? p??mo cel? dump OSM dat, ale > d?l?? n?jak? pre-processing, nev?m ??m a jak ale divil bych se, kdyby to > neum?lo spolupracovat z relacemi hranic a spol?halo se jen a pouze na > addr:country, nebo is_in tag. A i kdyby neum?lo, tak existuje zm?n?n? > overpass API.
Mam tu monav, ano, obcas stahnu novy data. Ne, neumi to spolupracovat s relacemi hranic. Bohuzel pro to nektere ulice nevidi v Praze. zobrazit citaci
> J? netvrd?m, ?e se to "nikde a v?bec" nepou??v?... pr?v? naopak z > historick?ch d?vod? to jako ?pln? posledn? fallback pou??v? cel? ?ada > softwaru, ale je to skute?n? a? ten nejposledn?j?? fallback. Jednodu?e > tenhle tag je deprecated a nem? smysl ho d?le udr?ovat, proto?e existuj? > spolehliv?j?? cesty, jak se k dan?m informac?m dostat.
Existuji spolehlivejsi cesty, ktere ovsem maji jine nevyhody, a ne kazdy software je implementuje. zobrazit citaci
> > Opravdu si chces projit vsechen existujici software, a overit, ze uz > > to nikdo nepouziva? > > Nechci, cht?l jsem po tob? alespo? jeden konkr?tn? p??klad, k ?emu/kde > je to u?ite?n? - myslel jsem, ?e jsem to napsal dost jasn?, ne? A mysl?m > opravdu u?ite?n?, tzn. "S is_in/addr:country tagem 'tohle' funguje, bez > n?j ne."
Zda se ze napriklad navit potrebuje is_in tag: * Navit only works with is_in tags, can't work with boundaries. http://wiki.openstreetmap.org/wiki/Talk:Key:is_in Z osobni zkusenosti vim, ze monav neumi vyuzit hranice mest. Myslim ze z hranicemi zemi to bude podobne. zobrazit citaci
> >>> (A viz anglicka wiki, ktera vysvetluje, ze mesto v is_in muze byt jine > >>> nez v addr:city.) > >> > >> M?? konkr?tn? p??klad pro ?R? > > > > Proc bych mel mit priklad pro CR? > > Eh, to jako v??n?? Nu, dobr?... T?matem t?to diskuze je "Adresy z > RUIAN", to jsou adresy v ?R. Tvoji v??e uvedenou pozn?mku jsem si > vylo?il tak, ?e is_in tag by se v r?mci tohoto importu nem?l mazat, > proto?e je u?ite?n?, proto?e m??e obsahovat jin? m?sto ne? addr:city. > Jeliko? m? osobn? nenapad? ??dn? p??klad adresn?ho m?sta (importovan?ho > z RUIAN), kde by se tato vlastnost hodila, tak jsem se zeptal, jestli ty > n?jak? takov? m??.
Z jineho mailu: #Aha. Tak?e Kr?sn?, po?ta Ra?kovice m? b?t # #addr:city=Ra?kovice #is_in=Kr?sn? # #m?sto #addr:city=Kr?sn? #is_in=Kr?sn? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

15.2.2014 11:32:46 (#32)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
138
Dne 15.2.2014 11:12, Pavel Machek napsal(a): zobrazit citaci
> On Fri 2014-02-14 10:02:19, "Petr Mor?vek [Xificurk]" wrote: >> A znovu mus?m opakovat, ?e pro tyhle ?daje existuj? spolehliv?j?? >> zdroje, schv?ln? si dejte hledat v nominatimu "praha hlavn? n?dra??" a >> zobraz? se v?m: >> ?elezni?n? stanice Prague Main Railway Station, Legerova, Vinohrady, >> Praha, Hlavn? m?sto Praha, Praha, 12000, ?esko >> (hm, asi bych se m?l pod?vat, pro? to tam je anglicky :D) >> A p?itom ten uzel neobsahuje jedin? addr:* nebo is_in tag. > > Nominatim to zvladnul. Na http://wiki.openstreetmap.org/wiki/Routing > je seznam pouzivanych programu na hledani. Zvladnou to vsechny z nich?
Nev?m. Ale je jist?, ?e pokud to n?kter? z nich nezvl?d?, tak m? celkem probl?m bez ohledu na to, jak dopadne tahle na?e diskuze. Jen mal? ??st objekt? v datab?zi m? is_in tag a z adresn?ch bod? m? jen necel? polovina tag addr:country, pokud tedy n?kdo stav? svoje vyhled?v?n? jen a pouze nad t?mito daty, tak toho asi moc nenajde. zobrazit citaci
>> A pokud jde o reverzn? ?kol, nap?. z?skat v?echny adresn? body t?eba v >> Mikulov?, tak tady jsou: >> http://overpass-turbo.eu/s/2w1 >> Op?t, na to nen? pot?eba ??dn? addr:* nebo is_in tag. > > A jak to udelam v josm bez overpassu?
?tu to u? asi po des?t? a po??d to ned?v? smysl... J? tu uk??u, jak s ur?it?m n?strojem (overpass api) dos?hnout ur?it?ho c?le (sta?en? specifick?ch dat z n?jak? oblasti) a tvoje n?sledn? ot?zka je typu "A jak to m??u ud?lat jinak?" Zdrav?, Petr Mor?vek aka Xificurk

15.2.2014 11:42:32 (#33)
gravatar

Pavel Machek

<pavel at ucw.cz>
1036 1226
On Fri 2014-02-14 15:26:36, "Petr Mor?vek [Xificurk]" wrote: zobrazit citaci
> Dne 14.2.2014 13:35, Dalibor Jel?nek napsal(a): > > Ahoj, > > http://wiki.openstreetmap.org/wiki/Cs:JOSM/Plugins/CzechAddress#Adresy_v_OpenStreetMap > > tak to jsem nenasel. Cekal bych, ze to najdu na ceskych Map Features nebo Editing Standards. > > Neva, prilezitostne to tam dopisu. > > > >> Pokud jej zachov?me, tak jsem pro to, aby se to ud?lalo po??dn?: > >> [m?stn? ??st], [m?stsk? ??st], [m?sto], [okres], [kraj], CZ > >> S t?m, ?e minim?ln? z?pis bude: > >> [m?sto], [okres], [kraj], CZ > > > > Hmm. A nevadi nam, ze tam mame carky, kdyz tady > > http://wiki.openstreetmap.org/wiki/Key:is_in > > se zcela zjevne doporucujou stredniky? > > M? to teda vad? hodn?. St?edn?k by byl lep??, proto?e to je standardn? odd?lov?tko. > > Nav?c ta str?nka p??e, ?e vlastn? na po?ad? t?ch ??st? zas tak moc nez?le?? (i kdy? je lep?? > > je m?t se?azen?), ale my vlastn? ??dn? ??sti nem?me, tak?e zahrani?n? programy na > > to asi koukaj dost divn?. > > A je?t? by se tam mohl p?idat NUTS2 region, katastr?ln? ?zem?, ZSJ, PS?, > jm?no ulice, ... t?ch p?r bajt? nav?c nikoho nezabije :P > > A te? v??n? - dok??e n?kdo ??ct k ?emu by to m?lo b?t u?ite?n??
Aby fungoval existujici software, jako napriklad navit. (A ano, kus softwaru, ktery vezme .osm, a doplni tam is_in tagy podle hranic by asi nebyl spatny. Nekdo, kdo tvrdi jak jednoduche je tu informaci dopocitat by ho sem mohl napastovat :-). Asi by bylo dobry aby ten kus sw fungoval i pro jiny zeme nez je Ceska Republika. Pak by aspon bylo mozny navigaci pred spustenim jejiho zpracovani potrebny informace doplnit.) Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

15.2.2014 12:57:54 (#34)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
138
Dne 15.2.2014 11:30, Pavel Machek napsal(a): zobrazit citaci
> Fajn. Takze je to best-practice. Od ktere se chces odchylit, a duvodem > se zda byt "je mi lito 86MB v databazi". To myslim neni dobry duvod, > proc se od best-practice odchylit.
Zas mi podsouv?? n?co, co jsem nikdy ani v nejmen??m nenazna?oval - 86MB byla reakce na tv?ch "p?r bajt?" a ?e bys rad?i p?id?val addr:country, proto?e se ti nechce stahovat cel? hranice ?R. Best-practice na wiki ??k?, ?e jakmile existuj? spolehliv? polygony hranic, tak tyto tagy nejsou pot?eba a j? s t?m souhlas?m a zat?m nevid?m d?vod, pro? je nad?le udr?ovat, nebo dokonce n?kde p?id?vat. zobrazit citaci
>> Import by se v prv? ?ad? m?l ??dit zdrav?m rozumem, a? n?sledn? n?jak?m >> ?l?nkem na wiki. Zn?n? t?ch ?l?nk? se koneckonc? m?n? pr?v? na z?klad? >> diskuze a p?edlo?en? racion?ln?ch argument?. > > Muj zdravy rozum rika ze jinde se addr:country pouziva, tak by tam mel > byt i nadale.
M?st, kde se pou??v? addr:country je m?n? ne? m?st, kde se nepou??v?. Pro is_in tag je ten rozd?l je?t? mnohem v?razn?j?? - je ??dov? v?c objekt? bez n?j ne? s n?m. zobrazit citaci
> Mam tu monav, ano, obcas stahnu novy data. Ne, neumi to spolupracovat > s relacemi hranic. Bohuzel pro to nektere ulice nevidi v Praze.
... zobrazit citaci
> Zda se ze napriklad navit potrebuje is_in tag: > > * Navit only works with is_in tags, can't work with boundaries. > > http://wiki.openstreetmap.org/wiki/Talk:Key:is_in > > Z osobni zkusenosti vim, ze monav neumi vyuzit hranice mest. Myslim ze > z hranicemi zemi to bude podobne.
http://wiki.navit-project.org/index.php/OpenStreetMap Navit (resp. maptool, kter? p?ev?d? osm do bin?rn?ho form?tu pro navit) um? pou??vat jak hranice st?t?, tak i m?st. https://groups.google.com/forum/#!msg/monav-discuss/kWz7Xvao7jM/SBABYSQ4Oy0J Podle tohoto MoNav s n?jak?mi polygony pracovat um?, tak?e bude jen probl?m v tom, jak? vyu??v?. Z?rove? jsem ale nikde v dokumentaci nebo k?du nena?el zm?nku o tom, ?e by se pou??vala hodnota is_in nebo addr:country, tak?e jejich ponech?n?/dopln?n? stejn? nic nevy?e??. Co tam m?? d?l? ;-) zobrazit citaci
> Z jineho mailu: > > #Aha. Tak?e Kr?sn?, po?ta Ra?kovice m? b?t > # > #addr:city=Ra?kovice > #is_in=Kr?sn? > # > #m?sto > #addr:city=Kr?sn? > #is_in=Kr?sn?
Omlouv?m se, to jsem n?jak p?ehl?dl. Ale naprosto nesouhlas?m s t?mto pou?it?m. * addr:city by m?lo obsahovat jm?no obce, kde se AM nach?z? (tak jak je to i v RUIAN), v ??dn?m p??pad? by tam nem?lo b?t n?co jin?ho. * "po?ta Ra?kovice" je to sam? jako PS? 73907. Nem? smysl tu samou informaci duplikovat v OSM. Ani nen? pot?eba ji duplikovat v adrese na dopisu - jedin? v?znam je "pro kontrolu", tak?e kdy? nap??e? "Kr?sn?, po?ta Ra?kovice, PS? 12345", tak to pravd?podobn? dojde. Z vlastn? zku?enosti v?m, ?e ?esk? po?ta je schopn? doru?it i dopisy s hodn? zkomolenou adresou. Zdrav?, Petr Mor?vek aka Xificurk

15.2.2014 02:50:50 (#35)
gravatar

Petr Vejsada

<osm at propsychology.cz>
507
Ahoj, Dne So 15. ?nora 2014 11:32:46, Petr Mor?vek [Xificurk] napsal(a): zobrazit citaci
> > Nominatim to zvladnul. Na http://wiki.openstreetmap.org/wiki/Routing > > je seznam pouzivanych programu na hledani. Zvladnou to vsechny z nich? > > Nev?m. Ale je jist?, ?e pokud to n?kter? z nich nezvl?d?, tak m? celkem > probl?m bez ohledu na to, jak dopadne tahle na?e diskuze. > > Jen mal? ??st objekt? v datab?zi m? is_in tag a z adresn?ch bod? m? jen > necel? polovina tag addr:country, pokud tedy n?kdo stav? svoje > vyhled?v?n? jen a pouze nad t?mito daty, tak toho asi moc nenajde.
K tomuto tolik, ?e i ten Nominatim m? v??n? probl?m. Libochovany 129 - prost? to nenajde, a?koli m? dokonce hned dv? mo?nosti, jak to ud?lat. Bar?k existuje, existuj? hranice obce, existuj? hranice "?tvrti" - asi katastr?ln? ?zem?, existuje addr:city, addr:housenumber i addr:conscriptionnumber. Z toho v?cem?n? vypl?v?, ?e nebude schopen naj?t bar?k ve m?st? ani po zaveden? addr:place. Dotaz bude muset b?t na ??st obce (co? v p??pad? Libochovan jsou taky Libochovany), ov?em ne v?dy tomu tak bude. -- Petr

15.2.2014 03:02:41 (#36)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
138
Dne 15.2.2014 14:50, Petr Vejsada napsal(a): zobrazit citaci
> K tomuto tolik, ?e i ten Nominatim m? v??n? probl?m. > > Libochovany 129 - prost? to nenajde, a?koli m? dokonce hned dv? mo?nosti, jak > to ud?lat. Bar?k existuje, existuj? hranice obce, existuj? hranice "?tvrti" - > asi katastr?ln? ?zem?, existuje addr:city, addr:housenumber i > addr:conscriptionnumber.
A dokonce i is_in=Libochovany, ?steck? kraj, CZ Cht?lo by to p?ij?t na to, kde je zakopan? pes a pro? to nenajde. zobrazit citaci
> Z toho v?cem?n? vypl?v?, ?e nebude schopen naj?t bar?k ve m?st? ani po > zaveden? addr:place.
J? teda osobn? nevid?m, jak to z toho vypl?v? (v?dy? ani nev?me, pro? nenajde "Libochovany 129"!) A ?e nenajde adresu Praha 42 je sice ?koda, ale ??dn? tragedie. zobrazit citaci
> Dotaz bude muset b?t na ??st obce (co? v p??pad? > Libochovan jsou taky Libochovany), ov?em ne v?dy tomu tak bude.
To by nebylo a? tak katastrof?ln? - typicky chce? hledat podle n?zvu ulice, nebo ??sti obce (proto?e tam nejsou pojmenovan? ulice). Petr

15.2.2014 04:04:20 (#37)
gravatar

Marián Kyral

<mkyral at email.cz>
2234 2403
Dne 15.2.2014 12:57, Petr Mor?vek [Xificurk] napsal: zobrazit citaci
> Dne 15.2.2014 11:30, Pavel Machek napsal(a):
zobrazit citaci
> Co tam m?? d?l? ;-) > > >> Z jineho mailu: >> >> #Aha. Tak?e Kr?sn?, po?ta Ra?kovice m? b?t >> # >> #addr:city=Ra?kovice >> #is_in=Kr?sn? >> # >> #m?sto >> #addr:city=Kr?sn? >> #is_in=Kr?sn? > > Omlouv?m se, to jsem n?jak p?ehl?dl. Ale naprosto nesouhlas?m s t?mto > pou?it?m. > * addr:city by m?lo obsahovat jm?no obce, kde se AM nach?z? (tak jak je > to i v RUIAN), v ??dn?m p??pad? by tam nem?lo b?t n?co jin?ho. > * "po?ta Ra?kovice" je to sam? jako PS? 73907. Nem? smysl tu samou > informaci duplikovat v OSM. Ani nen? pot?eba ji duplikovat v adrese na > dopisu - jedin? v?znam je "pro kontrolu", tak?e kdy? nap??e? "Kr?sn?, > po?ta Ra?kovice, PS? 12345", tak to pravd?podobn? dojde. Z vlastn? > zku?enosti v?m, ?e ?esk? po?ta je schopn? doru?it i dopisy s hodn? > zkomolenou adresou.
Tak tohle je od Pavla trochu podp?sovka. V tom p?vodn?m emailu hned za t?m n?sledoval otazn?k. Taky jsem se zm?nil, ?e informace o po?t? je v obsa?ena v PS?. Nikdo to u? pak nekomentoval. Mari?n

15.2.2014 04:41:04 (#38)
gravatar

Dalibor Jelínek

<dalibor at dalibor.cz>
408 1253
Ahoj, tohle jsem nepochopil. Proc by to po zavedeni addr:place nefungovalo? Kdyz jsem to zkousel, tak to fungovalo vzdy na tvar addr:place cislo popisne. Praha 2295 to samozrejme nenajde, ale Libe? 2295 ano. U tech Libochovic to musi fungovat taky, kdyz si Nominatim docte addr:place do databaze. Dalibor Sent from my HTC
----- Reply message ----- From: "Petr Vejsada" <osm at propsychology.cz> To: "OpenStreetMap Czech Republic" <talk-cz at openstreetmap.org> Subject: [Talk-cz] Adresy z RUIAN Date: Sat, Feb 15, 2014 14:50 Ahoj, Dne So 15. ?nora 2014 11:32:46, Petr Mor?vek [Xificurk] napsal(a): zobrazit citaci
> > Nominatim to zvladnul. Na http://wiki.openstreetmap.org/wiki/Routing > > je seznam pouzivanych programu na hledani. Zvladnou to vsechny z nich? > > Nev?m. Ale je jist?, ?e pokud to n?kter? z nich nezvl?d?, tak m? celkem > probl?m bez ohledu na to, jak dopadne tahle na?e diskuze. > > Jen mal? ??st objekt? v datab?zi m? is_in tag a z adresn?ch bod? m? jen > necel? polovina tag addr:country, pokud tedy n?kdo stav? svoje > vyhled?v?n? jen a pouze nad t?mito daty, tak toho asi moc nenajde.
K tomuto tolik, ?e i ten Nominatim m? v??n? probl?m. Libochovany 129 - prost? to nenajde, a?koli m? dokonce hned dv? mo?nosti, jak to ud?lat. Bar?k existuje, existuj? hranice obce, existuj? hranice "?tvrti" - asi katastr?ln? ?zem?, existuje addr:city, addr:housenumber i addr:conscriptionnumber. Z toho v?cem?n? vypl?v?, ?e nebude schopen naj?t bar?k ve m?st? ani po zaveden? addr:place. Dotaz bude muset b?t na ??st obce (co? v p??pad? Libochovan jsou taky Libochovany), ov?em ne v?dy tomu tak bude. -- Petr _______________________________________________ Talk-cz mailing list Talk-cz at openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20140215/ee8b9dd8/attachment.html>

15.2.2014 04:46:28 (#39)
gravatar

Petr Vejsada

<osm at propsychology.cz>
507
Ahoj, Dne So 15. ?nora 2014 15:02:41, Petr Mor?vek [Xificurk] napsal(a): Z Changelogu verze 2.1 (posledn? stable): * support for addresses without a street (addr:place and conscription number house numbers) tak?e to vypad?, ?e schopnost nal?zt d?m bez ulice je vlastn? nov? vlastnost. Koukal jsem do gitu Nominatimu, nena?el jsem od release 2.1 ??dn? zm?ny v tomto smyslu. zobrazit citaci
> Dne 15.2.2014 14:50, Petr Vejsada napsal(a): > > K tomuto tolik, ?e i ten Nominatim m? v??n? probl?m. > > > > Libochovany 129 - prost? to nenajde, a?koli m? dokonce hned dv? mo?nosti, > > jak to ud?lat. Bar?k existuje, existuj? hranice obce, existuj? hranice > > "?tvrti" - asi katastr?ln? ?zem?, existuje addr:city, addr:housenumber i > > addr:conscriptionnumber. > > A dokonce i is_in=Libochovany, ?steck? kraj, CZ > Cht?lo by to p?ij?t na to, kde je zakopan? pes a pro? to nenajde. > > > Z toho v?cem?n? vypl?v?, ?e nebude schopen naj?t bar?k ve m?st? ani po > > zaveden? addr:place. > > J? teda osobn? nevid?m, jak to z toho vypl?v? (v?dy? ani nev?me, pro? > nenajde "Libochovany 129"!) > A ?e nenajde adresu Praha 42 je sice ?koda, ale ??dn? tragedie. > > > Dotaz bude muset b?t na ??st obce (co? v p??pad? > > Libochovan jsou taky Libochovany), ov?em ne v?dy tomu tak bude. > > To by nebylo a? tak katastrof?ln? - typicky chce? hledat podle n?zvu > ulice, nebo ??sti obce (proto?e tam nejsou pojmenovan? ulice). > > Petr > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz

15.2.2014 04:48:15 (#40)
gravatar

Petr Vejsada

<osm at propsychology.cz>
507
Ahoj, Dne So 15. ?nora 2014 16:41:04, Dalibor Jel?nek napsal(a): zobrazit citaci
> tohle jsem nepochopil. Proc by to po zavedeni addr:place nefungovalo? Kdyz > jsem to zkousel, tak to fungovalo vzdy na tvar addr:place cislo popisne. > Praha 2295 to samozrejme nenajde, ale Libe? 2295 ano. U tech Libochovic to > musi fungovat taky, kdyz si Nominatim docte addr:place do databaze.
no pr?v? - mn? by se l?bilo, kdyby to na?lo i Praha 2295. Ov?em?e by to bylo asi v?ce dom?. -- Petr

15.2.2014 06:57:12 (#41)
gravatar

Petr Vejsada

<osm at propsychology.cz>
507
Ahoj, Xificurkovy p?ipom?nky jsou mi velmi bl?zk? a sympatick?, nel?b? se mi duplikace dat. To je ide?ln? sv?t, ve kter?m nejsme. Jedna v?c je, rozhodnout se n?jak? tag nep?id?vat versus n?jak? tag mazat. V p??pad? addr:country a is_in by to bylo ve v?t?in? p??pad? maz?n?, nikoli nep?id?v?n?. Nechci nikomu rozb?jet Navit (p??klad) ani nikoho nutit p?ed?l?vat osm2navit. OSM snad nen? jen pro aj??ky a kartografy. Chyb?n? tag?, kter? mo?n? n?jak? soft vyu??v?, by mohlo stimulovat pokrok ve v?voji doty?n?ho software - v?voj??i by byli "nuceni" sv?j soft p?izp?sobit nov?mu obsahu datab?ze, jen si mysl?m, ?e zrovna nefunk?n? vyhled?v?n? v CZ v Navitu (p??klad) nezp?sob?, ?e v?voj??i v?eho nechaj? a vrhnou se na "opravu" Navitu. Proto se klon?m k tomu zahrnout do importu i addr:country a is_in. Tak?e P?id?vat, nahrazovat: addr:conscriptionnumber addr:provisionalnumber addr:streetnumber addr:housenumber addr:street addr:place addr:suburb addr:city addr:postcode addr:country=CZ is_in source:addr=cuzk:ruian ref:ruian:addr=nnnnnn Mazat: addr:provisional # cca 200 p??pad?, asi z?m?na s addr:provisionalnumber addr:number # n?kolik p??pad?, asi omyl addr:alternatenumber # asi 300 p??pad?, asi z?m?na s conscriptionnumber ref:ruian # Minimalis_import i jin? uir_adr:ADRESA_KOD ?i uir_adr:adresa_kod Jeliko? j obecn?mu konsensu ohledn? is_in a addr:country nejsp?? nedojde, chci poprosit, abyste se u? k p?id?v?n? t?chto tag? nevyjad?ovali, leda?e by nutk?n? ?i argumenty byly nep?ekonateln? siln?. Zato uv?t?m podn?ty k obsahu tagu is_in. K diskusi: - obsah tagu is_in - source:position - nev?m, k ?emu je. Mo?nosti ignorovat, mazat, i nov? p?idan?ch AM p?idat, ? - cokoli dal??ho ;) -- Petr

15.2.2014 08:32:44 (#42)
gravatar

Dalibor Jelínek

<dalibor at dalibor.cz>
408 1253
Tak prohledej archiv talk-cz. O tehle zmene v Nominatim jsem psal uz o dost drive. :-) Sent from my HTC
----- Reply message ----- From: "Petr Vejsada" <osm at propsychology.cz> To: "OpenStreetMap Czech Republic" <talk-cz at openstreetmap.org> Subject: [Talk-cz] Adresy z RUIAN Date: Sat, Feb 15, 2014 16:46 Ahoj, Dne So 15. ?nora 2014 15:02:41, Petr Mor?vek [Xificurk] napsal(a): Z Changelogu verze 2.1 (posledn? stable): * support for addresses without a street (addr:place and conscription number house numbers) tak?e to vypad?, ?e schopnost nal?zt d?m bez ulice je vlastn? nov? vlastnost. Koukal jsem do gitu Nominatimu, nena?el jsem od release 2.1 ??dn? zm?ny v tomto smyslu. zobrazit citaci
> Dne 15.2.2014 14:50, Petr Vejsada napsal(a): > > K tomuto tolik, ?e i ten Nominatim m? v??n? probl?m. > > > > Libochovany 129 - prost? to nenajde, a?koli m? dokonce hned dv? mo?nosti, > > jak to ud?lat. Bar?k existuje, existuj? hranice obce, existuj? hranice > > "?tvrti" - asi katastr?ln? ?zem?, existuje addr:city, addr:housenumber i > > addr:conscriptionnumber. > > A dokonce i is_in=Libochovany, ?steck? kraj, CZ > Cht?lo by to p?ij?t na to, kde je zakopan? pes a pro? to nenajde. > > > Z toho v?cem?n? vypl?v?, ?e nebude schopen naj?t bar?k ve m?st? ani po > > zaveden? addr:place. > > J? teda osobn? nevid?m, jak to z toho vypl?v? (v?dy? ani nev?me, pro? > nenajde "Libochovany 129"!) > A ?e nenajde adresu Praha 42 je sice ?koda, ale ??dn? tragedie. > > > Dotaz bude muset b?t na ??st obce (co? v p??pad? > > Libochovan jsou taky Libochovany), ov?em ne v?dy tomu tak bude. > > To by nebylo a? tak katastrof?ln? - typicky chce? hledat podle n?zvu > ulice, nebo ??sti obce (proto?e tam nejsou pojmenovan? ulice). > > Petr > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz
_______________________________________________ Talk-cz mailing list Talk-cz at openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20140215/a9b3955f/attachment-0001.html>

15.2.2014 08:35:47 (#43)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
138
Dne 15.2.2014 18:57, Petr Vejsada napsal(a): zobrazit citaci
> Jeliko? j obecn?mu konsensu ohledn? is_in a addr:country nejsp?? nedojde, chci > poprosit, abyste se u? k p?id?v?n? t?chto tag? nevyjad?ovali, leda?e by > nutk?n? ?i argumenty byly nep?ekonateln? siln?. Zato uv?t?m podn?ty k obsahu > tagu is_in. > > K diskusi: > > - obsah tagu is_in
Ahoj, dokud nebude jasn? ?emu m? obsah toho tagu slou?it, tak se t??ko shodnem na jeho form?tu. J? taky nechci n?komu zbyte?n? rozb?jet funguj?c? software, a proto m? zaj?m? kter? konkr?tn? v?c s is_in/addr:country tagem funguje a bez n?j ne. Pokud jsem n?co nep?ehl?dl, tak tu zat?m nikdo takovou neuvedl. Nominatim - um? polygony hranic, addr:country/is_in tedy nen? pot?eba. Navit - resp. maptool, kter? p?ev?d? osm form?t do bin?rn?ho form?tu pro navit, um? polygony hranic st?t? i m?st, is_in/addr:country tedy nen? pot?eba. MoNav - sice neum? polygony hranic, ale neum? ani is_in/addr:country. OsmAnd - um? polygony hranic, is_in/addr:country tedy nen? pot?eba. ... Ne opravdu jsem neproch?zel v?echen software, ale ?ist? ze statistik taginfo bych se fakt divil, kdyby na p??tomnost t?chto tag? n?co opravdu spol?halo. Zaj?m? m? n?jak? p??klad toho, kde jsou tyto tagy u?ite?n? mj. i proto, abysme si vyjasnili, jak? form?t/obsah by is_in m?lo m?t. Zdrav?, Petr Mor?vek aka Xificurk

15.2.2014 10:23:08 (#44)
gravatar

Václav Řehák

<rehakv01 at gmail.com>
63
zobrazit citaci
> > > J? taky nechci n?komu zbyte?n? rozb?jet funguj?c? software, a proto m? > zaj?m? kter? konkr?tn? v?c s is_in/addr:country tagem funguje a bez n?j > ne. Pokud jsem n?co nep?ehl?dl, tak tu zat?m nikdo takovou neuvedl. >
A nem??eme to vz?t opa?n?? Opravdu ti ta duplicita addr:country vad? na tolik, ?e m? smysl kv?li tomu zdr?ovat cel? import? Obecn? z?sada b?v? ned?lat duplicity, ale pro?? Aby nevznikaly rozpory mezi neaktualizovan?mi verzemi t?ch dat. Zrovna u RUIANu si nemysl?m, ?e by to byl probl?m, kdy? v?t?ina t?ch dat bude importov?na/udr?ov?na automaticky. Jinak ?e?eno, po??d chce? p??klady, co se rozbije, kdy? to odstran?me. M?? n?jak? p??klad, co se rozbije, kdy? to tam nech?me/p?id?me? T?ch p?r MB opravdu nen? argument ve sv?t? OSM, kde se importuj? jednotliv? stromy v parku a dal?? (pro m? a? nesmysln?) detaily. O is_in nemluv?m, tam je to asi opravdu nejasn?, k ?emu m? slou?it a i to rozsynchronizov?n? si dovedu p?edstavit o dost realisti?t?ji. V. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20140215/884c35f3/attachment.html>

15.2.2014 10:39:17 (#45)
gravatar

Pavel Machek

<pavel at ucw.cz>
1036 1226
On Sat 2014-02-15 16:04:20, Mari?n Kyral wrote: zobrazit citaci
> Dne 15.2.2014 12:57, Petr Mor?vek [Xificurk] napsal: > >Dne 15.2.2014 11:30, Pavel Machek napsal(a): > > >Co tam m?? d?l? ;-) > > > > > >>Z jineho mailu: > >> > >>#Aha. Tak?e Kr?sn?, po?ta Ra?kovice m? b?t > >># > >>#addr:city=Ra?kovice > >>#is_in=Kr?sn? > >># > >>#m?sto > >>#addr:city=Kr?sn? > >>#is_in=Kr?sn? > > > >Omlouv?m se, to jsem n?jak p?ehl?dl. Ale naprosto nesouhlas?m s t?mto > >pou?it?m. > >* addr:city by m?lo obsahovat jm?no obce, kde se AM nach?z? (tak jak je > >to i v RUIAN), v ??dn?m p??pad? by tam nem?lo b?t n?co jin?ho. > >* "po?ta Ra?kovice" je to sam? jako PS? 73907. Nem? smysl tu samou > >informaci duplikovat v OSM. Ani nen? pot?eba ji duplikovat v adrese na > >dopisu - jedin? v?znam je "pro kontrolu", tak?e kdy? nap??e? "Kr?sn?, > >po?ta Ra?kovice, PS? 12345", tak to pravd?podobn? dojde. Z vlastn? > >zku?enosti v?m, ?e ?esk? po?ta je schopn? doru?it i dopisy s hodn? > >zkomolenou adresou. > > Tak tohle je od Pavla trochu podp?sovka. V tom p?vodn?m emailu hned > za t?m n?sledoval otazn?k. Taky jsem se zm?nil, ?e informace o po?t? > je v obsa?ena v PS?. Nikdo to u? pak nekomentoval.
Za podpasovku sorry, ale proste to dle wiki vypada, ze v addr:city ma byt jmeno posty, ktere se nemusi nutne shodovat s tim kde to je. Ze Vam to prijde reduntantni s PSC... no to asi ano, ale chudak zahranicni uzivatel asi nema po ruce databazi mest odpovidajicich k PSC... coz je duvod proc mame addr:city. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

15.2.2014 11:46:26 (#46)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
138
Dne 15.2.2014 16:41, Dalibor Jel?nek napsal(a): zobrazit citaci
> Ahoj, > tohle jsem nepochopil. Proc by to po zavedeni addr:place nefungovalo? > Kdyz jsem to zkousel, tak to fungovalo vzdy na tvar addr:place cislo > popisne. Praha 2295 to samozrejme nenajde, ale Libe? 2295 ano. U tech > Libochovic to musi fungovat taky, kdyz si Nominatim docte addr:place do > databaze. > Dalibor
Ahoj, z toho, co jsem te? testoval to vypad?, ?e um? naj?t "Street 1", nebo " Place 2", ale ne oboj? - pokud je nastaveno addr:street, tak u? to nenajde kombinaci s addr:place. Ten p??klad s Libn? to um? jen proto, ?e existuje budova, kter? m? addr:place, ale nem? addr:street a z?rove? existuj? adresn? body, kter? maj? jak addr:place=Libe?, tak addr:street=Kovaneck?. ?koda, ?e neum? oboje, ale asi je to celkem o?ek?van? chov?n? - kdy? jsou pojmenovan? ulice, tak hled?m podle n?zvu ulice. Zdrav?, Petr Mor?vek aka Xificurk

16.2.2014 05:38:28 (#47)
gravatar

Petr Vejsada

<osm at propsychology.cz>
507
Ahoj, Dne So 15. ?nora 2014 18:57:12, Petr Vejsada napsal(a): zobrazit citaci
> K diskusi: > > - obsah tagu is_in > > - source:position - nev?m, k ?emu je. Mo?nosti ignorovat, mazat, i nov? > p?idan?ch AM p?idat, ?
source:position se nema?e, v p??pad? p?id?v?n? nov?ch bod? se p?id?v?. V is_in je moment?ln? text 'Is in ...', dokud se nedohodne, co s t?m. Na http://pedro.poloha.net/osm/ukazka.osm je ulice Milady Hor?kov? v Praze. Bot nevydal ??dn? varov?n?. Pros?m o kontrolu - p?eklepy a v?eho, co v?s napadne. JOSM proti ni?emu neprotestuje. Neuploadovat na OSM ;-) -- Petr

16.2.2014 09:37:12 (#48)
gravatar

hanoj

<ehanoj at gmail.com>
713
zobrazit citaci
> > - source:position - nev?m, k ?emu je. Mo?nosti ignorovat, mazat, i nov? > > p?idan?ch AM p?idat, ? > > > source:position se nema?e, v p??pad? p?id?v?n? nov?ch bod? se p?id?v?.
*** sp??e "source:loc" ne? "source:position" http://taginfo.openstreetmap.org/keys/source:position#combinations http://taginfo.openstreetmap.org/keys/source:loc#combinations hanoj -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20140216/6648b82b/attachment.html>

16.2.2014 11:06:57 (#49)
gravatar

Dalibor Jelínek

<dalibor at dalibor.cz>
408 1253
Ahoj, jo, to asi je lespi. Takze navthuji najit u adresniho bodu source:position source:pos a prendat obsah do source:loc a tagy smazat. a pokud nejsou, tak source:loc nastavit na cuzk:ruian. Zdravi, Dalibor From: hanoj [mailto:ehanoj at gmail.com] Sent: Sunday, February 16, 2014 9:37 AM To: OpenStreetMap Czech Republic Subject: Re: [Talk-cz] Uk?zkov? .osm Re: Adresy z RUIAN - 2. rekapitulace zobrazit citaci
> > - source:position - nev?m, k ?emu je. Mo?nosti ignorovat, mazat, i nov? > > p?idan?ch AM p?idat, ? > > > source:position se nema?e, v p??pad? p?id?v?n? nov?ch bod? se p?id?v?.
*** sp??e "source:loc" ne? "source:position" http://taginfo.openstreetmap.org/keys/source:position#combinations http://taginfo.openstreetmap.org/keys/source:loc#combinations hanoj -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20140216/238e2631/attachment-0001.html>

16.2.2014 11:28:27 (#50)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
138
Dne 16.2.2014 09:37, hanoj napsal(a): zobrazit citaci
>> > - source:position - nev?m, k ?emu je. Mo?nosti ignorovat, mazat, i nov? >> > p?idan?ch AM p?idat, ? >> > >> source:position se nema?e, v p??pad? p?id?v?n? nov?ch bod? se p?id?v?. > > *** sp??e "source:loc" ne? "source:position" > http://taginfo.openstreetmap.org/keys/source:position#combinations > http://taginfo.openstreetmap.org/keys/source:loc#combinations > > hanoj
Ahoj, nebylo by lep?? ty source tagy d?t p??mo na changeset (co? je v sou?asnosti doporu?ovan? postup pro importy)? Obzvl??t? u toho source:position, resp. source:loc bych se celkem b?l, ?e p?i editaci lidi posunou bod, ale zapomenou zm?nit/odmazat tag. V ?R je stejn? jen jeden zdroj pro tyhle data, tak?e nen? pot?eba na ka?d?m bodu explicitn? uv?d?t, ?e fakt poch?z? z RUIANu a ne odn?kud jinud. Zdrav?, Petr Mor?vek aka Xificurk

16.2.2014 12:02:45 (#51)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
138
Dne 15.2.2014 22:39, Pavel Machek napsal(a): zobrazit citaci
> Za podpasovku sorry, ale proste to dle wiki vypada, ze v addr:city ma > byt jmeno posty, ktere se nemusi nutne shodovat s tim kde to je. Ze > Vam to prijde reduntantni s PSC... no to asi ano, ale chudak > zahranicni uzivatel asi nema po ruce databazi mest odpovidajicich k > PSC... coz je duvod proc mame addr:city. > > Pavel >
Ahoj, j? teda tu anglickou str?nku [1] ch?pu tak, ?e tam m? b?t to, co se p??e do kolonky "m?sto" na ob?lku dopisu. A to m??e a nemus? b?t shodn? s m?stem, pod kter? adresn? m?sto administrativn?/?zemn? spad?, ale zrovna tak to m??e a nemus? b?t shodn? se jm?nem po?ty, kter? dan? m?sto obsluhuje. Probl?m je, ?e v ?R je to stra?n? maglajz. ?esk? po?ta m? sice n?jak? doporu?en? vzory psan? adres [2], ale moc moudr? z toho nejsem. P?ijde mi, ?e tam term?n "obec" pou??vaj? dost voln? a skute?n? se tv??? jako, ?e cht?j? hlavn? jm?no adresn? po?ty. D?sledn? aplikov?n? t?ch pravidel vede v mnoha p??padech k naprost?m kravin?m. Mysl?m, ?e bude lep?? se p?idr?et toho tvaru, co zobrazuje RUIAN, t.j. dr?et addr:city="N?zev obce". Zdrav?, Petr Mor?vek aka Xificurk [1] http://wiki.openstreetmap.org/wiki/Addr [2] http://www.ceskaposta.cz/cz/nastroje/uzitecne-informace/doporucene-vzory-postovnich-adres/doporucene-vzory-psani-postovnich-adres-id1078/

16.2.2014 12:03:25 (#52)
gravatar

Petr Vejsada

<osm at propsychology.cz>
507
Ahoj, m??e se st?t, ?e n?kter? adresn? entita bude m?t source:loc i source:position ?i source:pos z?rove?. Co m?m d?lat pak? Prost?m p?ejmenov?n?m tagu vytvo??m duplicitu. A kter? z nich si m?m vybrat a pou??t jeho hodnotu pro source:loc? Kdy? bude takov?ch p??pad? p?r, tak to oprav?m ru?n?, nicm?n? m??e se st?t, ?e naraz?m na lokalitu, kde bude takov?ch 10.000 a do toho stavu bych se fakt necht?l dostat. Dne Ne 16. ?nora 2014 11:06:57, Dalibor Jel?nek napsal(a): zobrazit citaci
> Ahoj, > > jo, to asi je lespi. > > > > Takze navthuji najit u adresniho bodu > > source:position > > source:pos > > a prendat obsah do > > source:loc > > a tagy smazat. > > > > a pokud nejsou, tak source:loc nastavit na cuzk:ruian. > > > > Zdravi, > > Dalibor > > > > > > From: hanoj [mailto:ehanoj at gmail.com] > Sent: Sunday, February 16, 2014 9:37 AM > To: OpenStreetMap Czech Republic > Subject: Re: [Talk-cz] Uk?zkov? .osm Re: Adresy z RUIAN - 2. rekapitulace > > > > - source:position - nev?m, k ?emu je. Mo?nosti ignorovat, mazat, i nov? > > > p?idan?ch AM p?idat, ? > > > > source:position se nema?e, v p??pad? p?id?v?n? nov?ch bod? se p?id?v?. > > *** sp??e "source:loc" ne? "source:position" > http://taginfo.openstreetmap.org/keys/source:position#combinations > http://taginfo.openstreetmap.org/keys/source:loc#combinations > > > > hanoj
-- Petr

16.2.2014 12:09:16 (#53)
gravatar

Petr Vejsada

<osm at propsychology.cz>
507
Ahoj, Dne Ne 16. ?nora 2014 11:28:27, Petr Mor?vek [Xificurk] napsal(a): zobrazit citaci
> nebylo by lep?? ty source tagy d?t p??mo na changeset (co? je v > sou?asnosti doporu?ovan? postup pro importy)? > Obzvl??t? u toho source:position, resp. source:loc bych se celkem b?l, > ?e p?i editaci lidi posunou bod, ale zapomenou zm?nit/odmazat tag. > > V ?R je stejn? jen jeden zdroj pro tyhle data, tak?e nen? pot?eba na > ka?d?m bodu explicitn? uv?d?t, ?e fakt poch?z? z RUIANu a ne odn?kud jinud.
Polohu nem?n?m, tedy zdrojem polohy nen? RUIAN (pokud j?m nebyl u? v p?vodn? adrese). Zdrojem polohy je RUIAN pouze u nov? p?id?van?ch bod?. To v?e pr?v? proto, ?e s bodem mohl n?kdo ?oupnout a posunout ho na lep?? polohu - nad vchod, nam?sto p?vodn?, m?n? vhodn? polohy. -- Petr

16.2.2014 12:16:44 (#54)
gravatar

Petr Vejsada

<osm at propsychology.cz>
507
Ahoj, jj, i v CZ: source:position | 45821 source:loc | 1113248 source:locality | 1 Dne Ne 16. ?nora 2014 09:37:12, hanoj napsal(a): zobrazit citaci
> > > - source:position - nev?m, k ?emu je. Mo?nosti ignorovat, mazat, i nov? > > > p?idan?ch AM p?idat, ? > > > > source:position se nema?e, v p??pad? p?id?v?n? nov?ch bod? se p?id?v?. > > *** sp??e "source:loc" ne? "source:position" > http://taginfo.openstreetmap.org/keys/source:position#combinations > http://taginfo.openstreetmap.org/keys/source:loc#combinations > > hanoj
-- Petr

16.2.2014 12:29:08 (#55)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
138
Dne 16.2.2014 12:09, Petr Vejsada napsal(a): zobrazit citaci
> Ahoj, > > Dne Ne 16. ?nora 2014 11:28:27, Petr Mor?vek [Xificurk] napsal(a): > >> nebylo by lep?? ty source tagy d?t p??mo na changeset (co? je v >> sou?asnosti doporu?ovan? postup pro importy)? >> Obzvl??t? u toho source:position, resp. source:loc bych se celkem b?l, >> ?e p?i editaci lidi posunou bod, ale zapomenou zm?nit/odmazat tag. >> >> V ?R je stejn? jen jeden zdroj pro tyhle data, tak?e nen? pot?eba na >> ka?d?m bodu explicitn? uv?d?t, ?e fakt poch?z? z RUIANu a ne odn?kud jinud. > > Polohu nem?n?m, tedy zdrojem polohy nen? RUIAN (pokud j?m nebyl u? v p?vodn? > adrese). Zdrojem polohy je RUIAN pouze u nov? p?id?van?ch bod?. To v?e pr?v? > proto, ?e s bodem mohl n?kdo ?oupnout a posunout ho na lep?? polohu - nad > vchod, nam?sto p?vodn?, m?n? vhodn? polohy. > > -- > Petr
Aha, tak to jsem z t? uk?zky moc nepochopil - tam maj? v?echny body source:position=cuzk:ruian. To by asi m?t nem?ly, vzhledem k tomu, ?e ji? existuj? a neposouv?? je, ne? Ale st?le plat? v??e uveden? ot?zka... V principu by v?echny adresn? body v ?R m?ly sv?m obsahem i pozic? b?t odvozeny od RUIAN. Jak?koliv odchylky od stavu RUIANu budou bu? opravy chyb (doufejme, ?e jich v datab?zi moc nen?), mal? po?oupnut? adresn?ho m?sta na "lep??" m?sto (nap?. bl??e k vchodu/schr?nce), p??p. dopln?n? n?jak?ch POI tag?. Ot?zkou tedy je, zda by nebylo vhodn?j?? tyhle glob?ln? tagy d?t p??mo na changesety importu (jak doporu?uj? import guidelines), na jednotliv?ch bodech by se pak u? p?id?vat nemusely - co se s t?m bodem b?hem importu p?esn? d?lalo, se uvid? v jeho historii. Zdrav?, Petr Mor?vek aka Xificurk

16.2.2014 01:00:20 (#56)
gravatar

Petr Vejsada

<osm at propsychology.cz>
507
Ahoj, Dne Ne 16. ?nora 2014 12:29:08, Petr Mor?vek [Xificurk] napsal(a): zobrazit citaci
> Aha, tak to jsem z t? uk?zky moc nepochopil - tam maj? v?echny body > source:position=cuzk:ruian. To by asi m?t nem?ly, vzhledem k tomu, ?e > ji? existuj? a neposouv?? je, ne?
V?echny maj? source:addr=cuzk:ruian. source:position=cuzk:ruian maj? jen nov? p?idan?. 9 se nov? p?id?v?, 111 se upravuje. A? kouk?m, jak kouk?m, vid?m to tak, jak p??u. Nezam?nil jsi to se source:addr? zobrazit citaci
> > Ale st?le plat? v??e uveden? ot?zka... V principu by v?echny adresn? > body v ?R m?ly sv?m obsahem i pozic? b?t odvozeny od RUIAN. Jak?koliv > odchylky od stavu RUIANu budou bu? opravy chyb (doufejme, ?e jich v > datab?zi moc nen?), mal? po?oupnut? adresn?ho m?sta na "lep??" m?sto > (nap?. bl??e k vchodu/schr?nce), p??p. dopln?n? n?jak?ch POI tag?.
Jestli to spr?vn? ch?pu, pak by to prakticky znamenalo zru?en? informace o zdroji polohy pro v?echny body a zaveden? p?edpokladu, ?e v?e poch?z? od CUZK, nen?-li uvedeno jinak. V praxi to tak je (pouze ty, kter? jsou zastoupeny v?ce ne? 100x): cuzk:km | 1155200 uhul:ortofoto | 353 uhul:ortofoto, cuzk:km | 287 ruian | 2900 zobrazit citaci
> > Ot?zkou tedy je, zda by nebylo vhodn?j?? tyhle glob?ln? tagy d?t p??mo > na changesety importu (jak doporu?uj? import guidelines), na > jednotliv?ch bodech by se pak u? p?id?vat nemusely - co se s t?m bodem > b?hem importu p?esn? d?lalo, se uvid? v jeho historii.
Jak? konkr?tn? hodnota source:loc by se tedy m?la d?vat na changeset? Mn? to vych?z? na cuzk:km, ov?em z?e?? na lokalit?. V okol? Vy?kova to bude 99% RUIAN, proto?e tam prost? skoro ??dn? adresy nejsou. V Praze to bude cuzk:km. -- Petr

16.2.2014 01:01:58 (#57)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
138
Dne 15.2.2014 22:23, V?clav ?eh?k napsal(a): zobrazit citaci
> > J? taky nechci n?komu zbyte?n? rozb?jet funguj?c? software, a proto m? > zaj?m? kter? konkr?tn? v?c s is_in/addr:country tagem funguje a bez n?j > ne. Pokud jsem n?co nep?ehl?dl, tak tu zat?m nikdo takovou neuvedl. > > > A nem??eme to vz?t opa?n?? Opravdu ti ta duplicita addr:country vad? na > tolik, ?e m? smysl kv?li tomu zdr?ovat cel? import? > > Obecn? z?sada b?v? ned?lat duplicity, ale pro?? Aby nevznikaly rozpory > mezi neaktualizovan?mi verzemi t?ch dat. Zrovna u RUIANu si nemysl?m, ?e > by to byl probl?m, kdy? v?t?ina t?ch dat bude importov?na/udr?ov?na > automaticky. > > Jinak ?e?eno, po??d chce? p??klady, co se rozbije, kdy? to odstran?me. > M?? n?jak? p??klad, co se rozbije, kdy? to tam nech?me/p?id?me? T?ch p?r > MB opravdu nen? argument ve sv?t? OSM, kde se importuj? jednotliv? > stromy v parku a dal?? (pro m? a? nesmysln?) detaily. > > O is_in nemluv?m, tam je to asi opravdu nejasn?, k ?emu m? slou?it a i > to rozsynchronizov?n? si dovedu p?edstavit o dost realisti?t?ji. > > V.
Ahoj, v?ak o addr:country u? jsem psal d??ve: zobrazit citaci
> Osobn? jsem tedy pro: nep?id?vat, ale nemazat (krom p??pad?, kdy tam je > n?jak? nesmysl).
Asi jsem to pak zbyte?n? zamotal t?m, ?e jsem za?al tak n?jak addr:country a is_in h?zet do jednoho pytle - to proto, ?e se objevily n?zory, ?e oba tagy jsou u?ite?n? a je ??douc? je v?ude ponechat a doplnit, ale zat?m nikdo neuk?zal, kde/jak/pro? jsou u?ite?n?. is_in m? oproti addr:country jeden z?sadn? probl?m - nen? jasn?, co by tam m?lo b?t, a tak nen? ani mo?n? jednodu?e zkontrolovat, jestli sou?asn? obsah na existuj?c?ch bodech je bl?bol, nebo spr?vn? hodnota. A asi t??ko vymysl?me Ten Spr?vn? Form?t(TM), dokud nebude jasn? k ?emu/kde se to pou??v?. Nep?id?v?n? a z?rove? nemaz?n? addr:country m? jeden pozitivn? vedlej?? efekt - pokud na tu hodnotu n?co p?eci jen spol?h?, tak: a) to bude i po importu fungovat ve stejn? m??e jako dote? b) je slu?n? ?ance, ?e si po importu n?kdo v?imne (a ozve se), ?e software XYZ nefunguje ?pln? v?ude, proto?e ten tag n?kde chyb?. Jakmile bude na stole konkr?tn? probl?m, tak bude rozhodov?n? ??dov? sna??? - bu? dopln?me tag na zbyl? body, nebo se nap??e patch, kter? to zvl?dne vy?e?it i bez addr:country. Zdrav?, Petr Mor?vek aka Xificurk

16.2.2014 01:14:32 (#58)
gravatar

Petr Vejsada

<osm at propsychology.cz>
507
Ahoj, proch?z?m si t?ch 9 nov? p?idan?ch bod?. Milady Hor?kov? 34 - uk?zn? pitom? um?st?n?ho bodu uprost?ed bar?ku. Vsad?m se, ?e Ha?kova 2 m? v RUIAN stejnou pozici. Milady Hor?kov? 135 - v?bec nele?? na ulici Milady Hor?kov?, ale v??me, ?e bar?k m? opravdu adresu Milady Hor?kov? 135. V?t?ina t?ch nov?ch bod? je um?st?na nevhodn? uprost?ed bar?ku. Milady Hor?kov? 98 je taky ?pln? jinde, rozhodn? ne na ulici Milady Hor?kov?, ov?em vchod tam m??e b?t. Dne Ne 16. ?nora 2014 12:29:08, Petr Mor?vek [Xificurk] napsal(a): zobrazit citaci
> > Polohu nem?n?m, tedy zdrojem polohy nen? RUIAN (pokud j?m nebyl u? v > > p?vodn? adrese). Zdrojem polohy je RUIAN pouze u nov? p?id?van?ch bod?. > > To v?e pr?v? proto, ?e s bodem mohl n?kdo ?oupnout a posunout ho na lep?? > > polohu - nad vchod, nam?sto p?vodn?, m?n? vhodn? polohy.
-- Petr

16.2.2014 01:28:20 (#59)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
138
Dne 16.2.2014 13:00, Petr Vejsada napsal(a): zobrazit citaci
> Ahoj, > > Dne Ne 16. ?nora 2014 12:29:08, Petr Mor?vek [Xificurk] napsal(a): > >> Aha, tak to jsem z t? uk?zky moc nepochopil - tam maj? v?echny body >> source:position=cuzk:ruian. To by asi m?t nem?ly, vzhledem k tomu, ?e >> ji? existuj? a neposouv?? je, ne? > > V?echny maj? source:addr=cuzk:ruian. source:position=cuzk:ruian maj? jen nov? > p?idan?. 9 se nov? p?id?v?, 111 se upravuje. A? kouk?m, jak kouk?m, vid?m to > tak, jak p??u. Nezam?nil jsi to se source:addr?
Aha, moje chyba - j? si proklikal jen p?r n?hodn?ch bod? v z?padn? ??sti a naprosto ?patn? z toho vyvodil, ?e to maj? v?echny. zobrazit citaci
>> >> Ale st?le plat? v??e uveden? ot?zka... V principu by v?echny adresn? >> body v ?R m?ly sv?m obsahem i pozic? b?t odvozeny od RUIAN. Jak?koliv >> odchylky od stavu RUIANu budou bu? opravy chyb (doufejme, ?e jich v >> datab?zi moc nen?), mal? po?oupnut? adresn?ho m?sta na "lep??" m?sto >> (nap?. bl??e k vchodu/schr?nce), p??p. dopln?n? n?jak?ch POI tag?. > > Jestli to spr?vn? ch?pu, pak by to prakticky znamenalo zru?en? informace o > zdroji polohy pro v?echny body a zaveden? p?edpokladu, ?e v?e poch?z? od CUZK, > nen?-li uvedeno jinak. V praxi to tak je (pouze ty, kter? jsou zastoupeny v?ce > ne? 100x): > > cuzk:km | 1155200 > uhul:ortofoto | 353 > uhul:ortofoto, cuzk:km | 287 > ruian | 2900 > >> >> Ot?zkou tedy je, zda by nebylo vhodn?j?? tyhle glob?ln? tagy d?t p??mo >> na changesety importu (jak doporu?uj? import guidelines), na >> jednotliv?ch bodech by se pak u? p?id?vat nemusely - co se s t?m bodem >> b?hem importu p?esn? d?lalo, se uvid? v jeho historii. > > Jak? konkr?tn? hodnota source:loc by se tedy m?la d?vat na changeset? Mn? to > vych?z? na cuzk:km, ov?em z?e?? na lokalit?. V okol? Vy?kova to bude 99% > RUIAN, proto?e tam prost? skoro ??dn? adresy nejsou. V Praze to bude cuzk:km. > > -- > Petr
Na tom changesetu by to podle m? nebylo pot?eba rozli?ovat (jestli se m?n?/dopl?uje adresa, nebo i pozice je vid?t p??mo z jeho obsahu), pou?il bych n?co jako: source=cuzk:ruian url=http://wiki.openstreetmap.org/wiki/POPIS_IMPORTU import=yes bot=yes comment=??? V historii ka?d?ho bodu pak bude nap?.: v1: import RUIAN v2: user123 zm?nil o p?r m?tr? pozici v3: user456 p?idal shop=* ... T?m p?dem na v?ech vytvo?en?ch nebo zkontrolovan?ch bodech by nebylo pot?eba source:addr, source:loc by se nechalo jen pokud obsahuje n?jakou jinou ne? s RUIANem souvisej?c? hodnotu, nap?. 'uhul:ortofoto'. Zdrav?, Petr Mor?vek aka Xificurk

16.2.2014 02:22:49 (#60)
gravatar

Václav Řehák

<rehakv01 at gmail.com>
63
Ano, takto bych s t?m souhlasil. V. Dne 16. ?nora 2014 13:01 "Petr Mor?vek [Xificurk]" <petr at pada.cz> napsal(a): zobrazit citaci
> Dne 15.2.2014 22:23, V?clav ?eh?k napsal(a): > > > > J? taky nechci n?komu zbyte?n? rozb?jet funguj?c? software, a proto > m? > > zaj?m? kter? konkr?tn? v?c s is_in/addr:country tagem funguje a bez > n?j > > ne. Pokud jsem n?co nep?ehl?dl, tak tu zat?m nikdo takovou neuvedl. > > > > > > A nem??eme to vz?t opa?n?? Opravdu ti ta duplicita addr:country vad? na > > tolik, ?e m? smysl kv?li tomu zdr?ovat cel? import? > > > > Obecn? z?sada b?v? ned?lat duplicity, ale pro?? Aby nevznikaly rozpory > > mezi neaktualizovan?mi verzemi t?ch dat. Zrovna u RUIANu si nemysl?m, ?e > > by to byl probl?m, kdy? v?t?ina t?ch dat bude importov?na/udr?ov?na > > automaticky. > > > > Jinak ?e?eno, po??d chce? p??klady, co se rozbije, kdy? to odstran?me. > > M?? n?jak? p??klad, co se rozbije, kdy? to tam nech?me/p?id?me? T?ch p?r > > MB opravdu nen? argument ve sv?t? OSM, kde se importuj? jednotliv? > > stromy v parku a dal?? (pro m? a? nesmysln?) detaily. > > > > O is_in nemluv?m, tam je to asi opravdu nejasn?, k ?emu m? slou?it a i > > to rozsynchronizov?n? si dovedu p?edstavit o dost realisti?t?ji. > > > > V. > > Ahoj, > > v?ak o addr:country u? jsem psal d??ve: > > Osobn? jsem tedy pro: nep?id?vat, ale nemazat (krom p??pad?, kdy tam je > > n?jak? nesmysl). > > Asi jsem to pak zbyte?n? zamotal t?m, ?e jsem za?al tak n?jak > addr:country a is_in h?zet do jednoho pytle - to proto, ?e se objevily > n?zory, ?e oba tagy jsou u?ite?n? a je ??douc? je v?ude ponechat a > doplnit, ale zat?m nikdo neuk?zal, kde/jak/pro? jsou u?ite?n?. > > is_in m? oproti addr:country jeden z?sadn? probl?m - nen? jasn?, co by > tam m?lo b?t, a tak nen? ani mo?n? jednodu?e zkontrolovat, jestli > sou?asn? obsah na existuj?c?ch bodech je bl?bol, nebo spr?vn? hodnota. A > asi t??ko vymysl?me Ten Spr?vn? Form?t(TM), dokud nebude jasn? k > ?emu/kde se to pou??v?. > > Nep?id?v?n? a z?rove? nemaz?n? addr:country m? jeden pozitivn? vedlej?? > efekt - pokud na tu hodnotu n?co p?eci jen spol?h?, tak: > a) to bude i po importu fungovat ve stejn? m??e jako dote? > b) je slu?n? ?ance, ?e si po importu n?kdo v?imne (a ozve se), ?e > software XYZ nefunguje ?pln? v?ude, proto?e ten tag n?kde chyb?. Jakmile > bude na stole konkr?tn? probl?m, tak bude rozhodov?n? ??dov? sna??? - > bu? dopln?me tag na zbyl? body, nebo se nap??e patch, kter? to zvl?dne > vy?e?it i bez addr:country. > > Zdrav?, > Petr Mor?vek aka Xificurk > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz >
-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20140216/617a9079/attachment.html>

16.2.2014 02:24:21 (#61)
gravatar

Petr Vejsada

<osm at propsychology.cz>
507
Ahoj, za??n? mi to trochu p?ipom?nat diskusi o administrativn?ch hranic?ch, kam by sta?ilo p?id?vat addr:place ;-). Osobn? nepova?uji source:loc za d?le?it? ?daj a klidn? bych ho vypustil. Mimochodem - s?zku bych vyhr?l - roh Milady Hor?kov? a Ha?kovy - v RUIAN jsou ob? adresy na stejn?m m?st? uprost?ed bar?ku. Ha?kovu d?lal Petr Dlouh? podle UIR_ADDR, nikdy jsem nezkoumal, jak to funguje a jak je tam ur?ena poloha, nicm?n? tak, jak jsou um?st?ny adresn? body v Ha?kov? bych dal source:loc=zdrav?_rozum ;-) Dne Ne 16. ?nora 2014 13:28:20, Petr Mor?vek [Xificurk] napsal(a): zobrazit citaci
> > Jak? konkr?tn? hodnota source:loc by se tedy m?la d?vat na changeset? Mn? > > to vych?z? na cuzk:km, ov?em z?e?? na lokalit?. V okol? Vy?kova to bude > > 99% RUIAN, proto?e tam prost? skoro ??dn? adresy nejsou. V Praze to bude > > cuzk:km.
zobrazit citaci
> Na tom changesetu by to podle m? nebylo pot?eba rozli?ovat (jestli se > m?n?/dopl?uje adresa, nebo i pozice je vid?t p??mo z jeho obsahu), > pou?il bych n?co jako: > source=cuzk:ruian > url=http://wiki.openstreetmap.org/wiki/POPIS_IMPORTU > import=yes > bot=yes > comment=???
Tohle by ?lo. zobrazit citaci
> > V historii ka?d?ho bodu pak bude nap?.: > v1: import RUIAN > v2: user123 zm?nil o p?r m?tr? pozici > v3: user456 p?idal shop=* > ... > > T?m p?dem na v?ech vytvo?en?ch nebo zkontrolovan?ch bodech by nebylo > pot?eba source:addr, source:loc by se nechalo jen pokud obsahuje n?jakou > jinou ne? s RUIANem souvisej?c? hodnotu, nap?. 'uhul:ortofoto'.
Tohle by taky ?lo, respektive je mi to jedno, nicm?n? ?erv??ek - vy?aduje to p?tr?n? v historii uzlu a tedy to sni?uje u?ivatelskou p??v?tivost editace a z?sk?v?n? informac?. To znamen?, ?e bych se musel kouknout na posledn? changeset, pak na historii a z toho dovozovat, jak? je vlastn? sou?asn? stav uzlu. Znamenalo by to, ?e informaci, kter? je te? dostupn? hned, by bylo t?eba dovozovat. Podobn? jako a? si Navit (p??klad) spo??t? podle hranic, kde se vlastn? nach?z?. No nic, jdu dod?l?vat dal?? test, zda se adresn? m?sto nach?z? do 50m od ulice, ke kter? pat??. -- Petr

18.2.2014 07:26:28 (#62)
gravatar

Petr Vejsada

<osm at propsychology.cz>
507
Ahoj, Dne Ne 16. ?nora 2014 13:28:20, Petr Mor?vek [Xificurk] napsal(a): zobrazit citaci
> Na tom changesetu by to podle m? nebylo pot?eba rozli?ovat (jestli se > m?n?/dopl?uje adresa, nebo i pozice je vid?t p??mo z jeho obsahu), > pou?il bych n?co jako: > source=cuzk:ruian > url=http://wiki.openstreetmap.org/wiki/POPIS_IMPORTU > import=yes > bot=yes > comment=??? > > V historii ka?d?ho bodu pak bude nap?.: > v1: import RUIAN > v2: user123 zm?nil o p?r m?tr? pozici > v3: user456 p?idal shop=* > ... > > T?m p?dem na v?ech vytvo?en?ch nebo zkontrolovan?ch bodech by nebylo > pot?eba source:addr, source:loc by se nechalo jen pokud obsahuje n?jakou > jinou ne? s RUIANem souvisej?c? hodnotu, nap?. 'uhul:ortofoto'.
m??e? je?t? up?esnit, co je 'nesouvisej?c? s RUIAN'? Resp. souvisej?c? s RUIAN? uir_adr? cuzk:km? mvcr:adresa? D?k. -- Petr BTW: t?ch is_in je dnes dle m? DB 2.069.921. Hranice Geofabrik.

18.2.2014 07:44:34 (#63)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
138
Dne 18.2.2014 19:26, Petr Vejsada napsal(a): zobrazit citaci
> Ahoj, > > Dne Ne 16. ?nora 2014 13:28:20, Petr Mor?vek [Xificurk] napsal(a): > >> Na tom changesetu by to podle m? nebylo pot?eba rozli?ovat (jestli se >> m?n?/dopl?uje adresa, nebo i pozice je vid?t p??mo z jeho obsahu), >> pou?il bych n?co jako: >> source=cuzk:ruian >> url=http://wiki.openstreetmap.org/wiki/POPIS_IMPORTU >> import=yes >> bot=yes >> comment=??? >> >> V historii ka?d?ho bodu pak bude nap?.: >> v1: import RUIAN >> v2: user123 zm?nil o p?r m?tr? pozici >> v3: user456 p?idal shop=* >> ... >> >> T?m p?dem na v?ech vytvo?en?ch nebo zkontrolovan?ch bodech by nebylo >> pot?eba source:addr, source:loc by se nechalo jen pokud obsahuje n?jakou >> jinou ne? s RUIANem souvisej?c? hodnotu, nap?. 'uhul:ortofoto'. > > m??e? je?t? up?esnit, co je 'nesouvisej?c? s RUIAN'? Resp. souvisej?c? s > RUIAN? uir_adr? cuzk:km? mvcr:adresa? D?k.
Pro tyto ??ely bych za shodn? pova?oval ruian, cuzk:ruian (p??p. dal?? variace) a cuzk:km. Ten zbytek bych asi rad?i nechal odd?len? - kdo v?, co v t?ch rejst??k?ch tenkr?t bylo nebo nebylo. zobrazit citaci
> -- > Petr > BTW: t?ch is_in je dnes dle m? DB 2.069.921. Hranice Geofabrik.
Je drsn?, ?e u n?s v ?R je 3x v?c bod? s is_in ne? v cel?m zbytku sv?ta. A dal??m zaj?mav?m poznatkem z ?esk?ho taginfo je, ?e adresn? body (a to je?t? nejsou v OSM v?echny) u n?s tvo?? cca 70% v?ech "tagovan?ch" bod?. Zdrav?, Petr Mor?vek aka Xificurk

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