Re: [talk-cz] Jak slepy import obcas dokaze znicit mapu...

[Mirek Dlask]

Všechno se odvíjí od téměř bezbřehé volnosti jakou OSM poskytuje.
Jednu věc lze mapovat dvěma i více způsoby a neexistuje žádná „Rada
starších“, která by vybrala jedinou, správnou možnost.
Hlavně. Kdo a jak by dodržování kontroloval, vymáhal a prohřešky postihoval.

Názvy ulic můžou být:
- podle pravidel českého pravopisu (pozor, pravidla jsou vymahatelná pouze
pro školní výuku) - používají mapy.cz
- podle RUIAN, část je podle starých, část podle aktuálních pravidel v
závislost na preferencích obce
- všechna počáteční písmena velká (chybí tradice, pro někoho nepřijatelné)
- všechna počáteční písmena malá (vylučuji předem)

Pár příkladů kde koliduje adresa a název ulice.

http://osmose.openstreetmap.fr/cs/map/#zoom=17=50.120629=14.619605=2060=1%2C2%2C3==

Typografická pravidla - občasný výskyt
F.V.Veselého - číslo popisné z RUIAN
F. V. Veselého - ulice v mapě

Stará vs nová pravidla pravopisu - Praha a okolí jak je vidno při oddálení
mapy výskyt masivní
Ve žlíbku - číslo popisné z RUIAN
Ve Žlíbku  - ulice v mapě
-
http://osmose.openstreetmap.fr/cs/map/#zoom=18=50.051119=14.669204=2060=1%2C2%2C3==
Nedělitelná mezera
V Kukli - číslo popisné z RUIAN
V Kukli - ulice v mapě

Vážně je tam pole?
https://www.openstreetmap.org/way/434373740/history
---

Někde je chyba viditelná, přesto ji nikdo neopraví, ani neupozorní autora.
http://osmose.openstreetmap.fr/cs/map/#zoom=17=49.886129=17.085134=2060=1%2C2%2C3==
https://www.openstreetmap.org/way/548140453
https://www.openstreetmap.org/node/5333118003

Tam kde systém funguje, lze najít, nejen ulice chybně pojmenované, ale i ty
nepojmenované.
http://osmose.openstreetmap.fr/cs/map/#zoom=17=49.724004=17.073022=2060=1%2C2%2C3==
https://www.openstreetmap.org/way/241188095

Osmose má spoustu vrstev, stačí si vlevo vybrat.
Kromě Osmose připomínám geofabrik.de . Poskytuje totéž trošku jinak + něco
navíc.
http://tools.geofabrik.de/osmi/?view=addresses=14.51850=49.99648=16=0.35=buildings,buildings_with_addresses,postal_code,entrances_deprecated,entrances,no_addr_street,street_not_found,interpolation,interpolation_errors,connection_lines,nearest_points,nearest_roads,nearest_areas,addrx_on_nonclosed_way

Průšvih je, že v té změti pseudochyb ty opravdové nikdo nenajde. Ani není
ochoten něco hledat.
Takže? Takže jako obvykle nic?

Mirek D.

pá 18. 12. 2020 v 4:03 odesílatel r00t via talk-cz <
talk-cz@openstreetmap.org> napsal:

> Ahoj Mirku,
>
> > Tak je to opraveno.
> Diky za opravu a taky za alespon castecne vysvetleni toho co se stalo.
> Import jsem tady podeziral
> nepravem, ale z changesetu to proste na import vypadalo.
>
> Je jasne ze OSM je mapa kterou muze editovat kazdy a tak se proste podobne
> chyby obcas stat mohou.
> Otazka spis je, co se s tim da delat? Pokud se tohle stane v oblasti
> kterou nikdo nas zrovna
> aktivne nesleduje a nevyuziva, zustane podobny problem v mape treba
> nekolik let. A zadny z nastroju
> jako OSMCha nebo Achavi ten puvodni changeset nevidi jako podezrely -
> protoze proste nijak divny neni.
> I kdyz asi hromadne prejmenovani hodne prvku, co melo puvodne vlastni
> jmena, na jedno a to same, by
> nejaky ten red-flag pridat mohlo.
>
> Ale stejne tak neznam zadny nastroj co by kontroloval, jestli ulice ve
> meste se stejnym jmenem navazuji
> na sebe - hodne stejne pojmenovanych kousku, co nenavazuji na sebe,
> vetsinou znamena ze je neco spatne.
> Podobnou kontrolou by se asi prislo na vic chyb.
>
> Protoze jinak je to jenom o nahode, kdy clovek na neco takoveho nahodou
> narazi...
>
> r00tcz
>
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] Jak slepy import obcas dokaze znicit mapu...

[Mirek Dlask]

Tak je to opraveno.
https://www.openstreetmap.org/changeset/96026703
V dobách kdy bylo hodně nepojmenovaných ulic jsem měl vrstvu ulic z RUIAN,
ze které jsem v JOSM kopíroval potřebné.
Název a ref, pokud byla nutná i oprava geometrie tak celý segment ulice.
Není o páchání dobra, ale o mojí nešikovnosti. Zatím nevím jak jsem vybral
ulice mimo zorný úhel a ty následně přejmenoval.
Mirek

čt 17. 12. 2020 v 18:56 odesílatel r00t via talk-cz <
talk-cz@openstreetmap.org> napsal:

> Ahoj,
>
> Pri prochazeni poslednich poznamek v mape a jejich reseni jsem narazil na
> nasledujici situaci v
> Odolene Vode:
> https://www.openstreetmap.org/#map=16/50.2322/14.4108=N
>
> V mape je asi 30x ulice Akatova, viz vsechny ty poznamky.
> Pokud se podivam na historii zmen k nektere z tech ulic:
>
> https://www.openstreetmap.org/way/26190785/history#map=15/50.2312/14.4129=N
> Je jasne ze za to muze changeset #73855351 od Minimalise:
> https://overpass-api.de/achavi/?changeset=73855351
> Vsechny ulice maji stejne ref:ruian:street. Data na RUIANu a adresni mista
> jsou v poradku, vsechny
> maji spravne ulice, takze nevim co se tam pred rokem stalo.
>
> Ale je uplne jedno odkud se to tam dostalo, co je smutne je ze tohle je
> typicky pripad slepeho importovani
> hlouposti. Rucne by tohle nikdo nikdy do mapy nezadal, 30 stejne
> pojmenovanych ulic proste neni normalni!
> A predtim tam ty ulice byly pojmenovane spravne, uz nejakych 9 let.
>
> Timto bych chtel poprosit Vas vsechny co importuji data do OSM, divejte se
> jaka data do OSM davate!
> Je jedno jestli jde o LPIS, RUIAN, CUZK:KM... takovahle obrovska chyba se
> do mapy nikdy nemela
> dostat. Casto se stava ze import prepise pracne zmapovane oblasti, data
> ktere nekdo osobne posbiral
> v terenu a misto toho se do mapy nasype nejaky paskvil. Jako vzdy nejvic
> skody se da zpusobit tim, ze
> se pacha "dobro" za kazdou cenu...
>
> Vsechny ulice planuju opravit dneska vecer, do te doby se muzete divat na
> tu "nadheru" v mape.
>
> r00tcz
>
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] Jak slepy import obcas dokaze znicit mapu...

[Mirek Dlask]

Ahoj,
nech to, já to opravím.
Jenom pro pořádek. Není to importem. Asi jsem měl nějaký výběr ulic, kterým
jsem všem najednou zkopíroval nesprávné jméno. Jinak si to neumím vysvětlit.
Mirek D.

čt 17. 12. 2020 v 18:56 odesílatel r00t via talk-cz <
talk-cz@openstreetmap.org> napsal:

> Ahoj,
>
> Pri prochazeni poslednich poznamek v mape a jejich reseni jsem narazil na
> nasledujici situaci v
> Odolene Vode:
> https://www.openstreetmap.org/#map=16/50.2322/14.4108=N
>
> V mape je asi 30x ulice Akatova, viz vsechny ty poznamky.
> Pokud se podivam na historii zmen k nektere z tech ulic:
>
> https://www.openstreetmap.org/way/26190785/history#map=15/50.2312/14.4129=N
> Je jasne ze za to muze changeset #73855351 od Minimalise:
> https://overpass-api.de/achavi/?changeset=73855351
> Vsechny ulice maji stejne ref:ruian:street. Data na RUIANu a adresni mista
> jsou v poradku, vsechny
> maji spravne ulice, takze nevim co se tam pred rokem stalo.
>
> Ale je uplne jedno odkud se to tam dostalo, co je smutne je ze tohle je
> typicky pripad slepeho importovani
> hlouposti. Rucne by tohle nikdo nikdy do mapy nezadal, 30 stejne
> pojmenovanych ulic proste neni normalni!
> A predtim tam ty ulice byly pojmenovane spravne, uz nejakych 9 let.
>
> Timto bych chtel poprosit Vas vsechny co importuji data do OSM, divejte se
> jaka data do OSM davate!
> Je jedno jestli jde o LPIS, RUIAN, CUZK:KM... takovahle obrovska chyba se
> do mapy nikdy nemela
> dostat. Casto se stava ze import prepise pracne zmapovane oblasti, data
> ktere nekdo osobne posbiral
> v terenu a misto toho se do mapy nasype nejaky paskvil. Jako vzdy nejvic
> skody se da zpusobit tim, ze
> se pacha "dobro" za kazdou cenu...
>
> Vsechny ulice planuju opravit dneska vecer, do te doby se muzete divat na
> tu "nadheru" v mape.
>
> r00tcz
>
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] Hasičská hřiště

[Mirek Dlask]

Ahoj,
kdysi jsem něco takového mapoval. Tag odněkud okoukal.
Teď jsem našel několik polygonů (way).
370196383
436353591
470702796
266679284
361528886
279755114
556802992
680425424
322680914
504531282
352860019
792451867
322542571

út 24. 11. 2020 v 13:14 odesílatel Miroslav Suchy 
napsal:

> Mapy.cz se chystají mapovat hasičská hřiště:
>   https://www.facebook.com/Mapy.cz/posts/10159108223149388
> Tak jsem se díval jak je na tom OSM - protože je fakt, že takových ploch
> je v ČR docela dost. A... zdá se, že nic
> takového v mapě vůbec nemáme
> Asi nejblíž by mohlo být
>   leisure=pitch
>   sport=firefighter
> Ale ten atribut sportu jsem si vymyslel. Nějaké nápady jak to mapovat?
>
> Mirek
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] Import zastávek veřejné dopravy Jihočeského kraje

[Mirek Dlask via talk-cz]

Co jsou to skutečně používané názvy?
hřbitov
ke hřbitovu
na hřbitov
Nový hřbitov
Boleslav, Nový hřbitov
Který je ten pravý, kdo o tom rozhodne?


V Jižních Čechách je několik bezejmenných zastávek, které jsi přidala
zhruba před rokem.
Za jakou dobu si myslíš, že místní doplní ty svoje použiváné názvy, nebo
vůbec nějaké názvy?
Jsou tři roky dostatečná doba? Zdá se, že ne!
https://www.openstreetmap.org/node/1654527858

MD

po 14. 9. 2020 v 23:49 odesílatel majka  napsal:

>
> 14. 9. 2020 22:23:00 Mirek Dlask :
>
> > ref=1
> >
> > K návrhům Majky
> > ref_name bych použil v případě kdy nemám jiný identifikátor (ref, kod,
> id).
> > Dal bych přednost official_name které zobrazí Osmand po rozkliknuti
> Detailu, ref_name nemá v datech.
> > Do name patří celý název. Jednodílný až trojdílný. Ten název není pouze
> v e-datech, ale i na označnících a odjezdových e-tabulích, alespoň tady na
> severu na linkách integrovaných do PID a IDOL.
>
> No, žiju na divokém Jihu. Takže MHD už byla zmíněná - používané názvy u
> MHD nejsou jednotné ani v krajském městě v tom, jestli (jak) se používá
> která část kompletního názvu.  K tomu přidej název typu "Dobrá Voda u Č.
> Budějovic,,Domov důchodců", který se z praktických důvodů nikdy nepoužívá
> celý a všude se to zkracuje.
> Název zastávky na místě taky může být úplně jiný než je v datech, resp.
> tam můžeš najít kde co. Data: Hluboká nad Vltavou, U Pulců, na místě z
> každé strany něco jiného - tohle <https://goo.gl/maps/zjL9DDb8a7mmQpTX8> (když
> se podíváš dovnitř té zastávky, ten název "U Pulců" tam je k zahlédnutí
> taky) a k tomu na druhé straně klasická zastávka MHD + Jihotrans
> jednoznačně jako "U Pulců".
> Vesnické zastávky jsou kapitola sama pro sebe, od našlechtěných čekáren s
> názvem místa po otřískané tabule. Případně taky skoro tajné místo, kde
> možná nějaký autobus někdy zastaví.
> Takže z mého pohledu jsou varianty dvě. Může se to nacpat to do ref_name s
> tím, že to "někde" je, a nelézt do zelí místním. Ti si to zmapují podle
> vlastní úvahy - stejně by to mělo přijít časem do relací tam, kde to ještě
> není.  Nebo se to dá všude narvat těmi oficiálními jmény, tj. prakticky to
> zmapovat podle jízdních řádů bez ohledu na skutečně používané názvy. V
> Budějovicích je ale třeba MHD zmapovaná alespoň tak, jak to používá
> dopravní podnik, a tímhle bych do toho hodila vidle. K těm používaným
> názvům se jinak než na místě nedá dostat.
> Jakákoli jiná verze jen spojí dohromady nevýhody a nepřinese vůbec nic
> užitečného.
> Majka
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] Import zastávek veřejné dopravy Jihočeského kraje

[Mirek Dlask]

Měl jsem na mysli toto.

Bítov,most BÍTOVMOST
Bítov [ZN],,most BÍTOVMOST
Bítov,,most BÍTOVMOST

Vlašim [BN],,záv. VLAŠIMZÁV
Vlašim,,záv. VLAŠIMZÁV
Vlašim,záv. VLAŠIMZÁV

Mladá Boleslav,aut.st. MLADÁBOLESLAVAUTST
Mladá Boleslav,,aut.st. MLADÁBOLESLAVAUTST
Mladá Boleslav,,Aut.st. MLADÁBOLESLAVAUTST

Podobných trojic a dvojic jsou tam desítky.

MD


po 14. 9. 2020 v 22:52 odesílatel Mikoláš Štrajt  napsal:

> Ahoj,
>
> > Vím pouze o celostátním registru zastávek bez polohy a jednoznačné
> identifikace (ftp://ftp.cisjr.cz/). Některé zastávky jsou tam i třikrát.
> V OSM těžko použitelné.
>
>
> třikrát jsou, protože jsou jízdní řády (resp. zastavení) plánovány na
> konkrétní označník v rámci zastávky. Třeba moje autobusová linka dříve
> stavěla na dvou zastávkách Smíchovské nádraží za sebou. Podobně některé
> tramvaje staví na zastávce Nákladové nádraží Žižkov a hned pak v Nákladové
> nádraží Žižkov v Olšanské ulici (která se ale na zastávkovém sloupku
> jmenuje jenom Nákladové nádraží Žižkov).
>
>
> > Postrádám datový sklad, kam by se daly uložit datové sady použitelné v
> OSM. Aby je mohl použít/prohlédnout každý.
>
>
> Pro jízdní řády se o něco takového pokouší projekt transitland -
> http://transit.land/
>
>
> --
>
> Severák
>
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] Import zastávek veřejné dopravy Jihočeského kraje

[Mirek Dlask]

Ahoj,
jaké zastávky v okolí Říčan máš na mysli? Ty integrované v PID jsou
všechny. Scházejí zastávky v Říčanech - nejezdila tam MHD a pak už jsem se
tam nevrátil.

Máš odkaz na republiková data včetně polohy? Máš lidi, kteří se tomu budou
věnovat? Jak chceš tu konzistenci zajistit?
Třeba názvy zastávek. Jaký tvar preferovat? Jak zabránit pozdějším změnám?
Turnov,Terminál u žel.st .
Turnov, Terminál u žel. st.
Turnov,Terminál u železniční stanice + varianty s nedělitelnou mezerou.
Turnov,Terminál U Železniční stanice
Turnov,Terminál U Železniční stanice (10)  varianty s číslem označníku
10 - nevím která aplikace k name přidá i name z relace
public_transport=stop_area a v seznamu zastávek linky zobrazí - Turnov,
Terminál u žel. st. (10)

Vím pouze o celostátním registru zastávek bez polohy a jednoznačné
identifikace (ftp://ftp.cisjr.cz/). Některé zastávky jsou tam i třikrát. V
OSM těžko použitelné.

V OSM by bylo velké překvapení, pokud by se veřejná doprava dala zmapovat
pouze jedním způsobem.
highway=bus_stop vs. public_transport=* + bus=yes - není vyřešeno ani po
několika letech.
Identifikace označníku:
local_ref  vs. ref
local_ref - umí pouze dopravní mapa, Osmand ani OPNV ne.
ref -  umí Osmand a OPNV, dopravní mapa ne
Přidávat oboje?
local_ref=1
ref=1

K návrhům Majky
ref_name bych použil v případě kdy nemám jiný identifikátor (ref, kod, id).
Dal bych přednost official_name které zobrazí Osmand po rozkliknuti
Detailu, ref_name nemá v datech.
Do name patří celý název. Jednodílný až trojdílný. Ten název není pouze v
e-datech, ale i na označnících a odjezdových e-tabulích, alespoň tady na
severu na linkách integrovaných do PID a IDOL.
Když jsem se před lety rozhlížel co dávají do name ostatní převažoval
upravený název - bez dvojčárek s mezerami za čárkami a tečkami. Někde navíc
bez zkratek.
U MHD stačí třetí část názvu - do doby než někdo zprovozní příměstskou
linku využívající zastávky MHD a chce vědět kde začíná/končí město.

Jednoznačný identifikátor zastávky ref:JCK. Rozhodně používat (hodí se při
změně názvu).
Asi to je ref:CRZ - číslo centrálního registru zastávek. To je k dispozici
i v datech Libereckého a Královéhradeckého kraje. V době, kdy jsem mapoval
Liberecko jsem to nevěděl, používal jsem ref:idol.

Postrádám datový sklad, kam by se daly uložit datové sady použitelné v OSM.
Aby je mohl použít/prohlédnout každý.

MD

po 14. 9. 2020 v 0:02 odesílatel Pavel Machek  napsal:

> Ahoj!
>
> > Na https://geoportal.kraj-jihocesky.gov.cz/gs/zastavky-verejne-dopravy/
> >  > je
> > už delší dobu pod licencí CC0 k dispozici seznam všech autobusových
> > a vlakových zastávek Jihočeského kraje, tj. licence zde by měla být
> > bez problémů. Nejnovější data jsou z června 2020. Namátkovou
> > kontrolou jsou místa zastávek přesně.
>
> Ano, import zastavek by byl super.
>
> Ale nesel by udelat primo z centralniho informacniho systemu?
>
>
> https://cs.wikipedia.org/wiki/Celost%C3%A1tn%C3%AD_informa%C4%8Dn%C3%AD_syst%C3%A9m_o_j%C3%ADzdn%C3%ADch_%C5%99%C3%A1dech
>
> Bylo by dobre mit zastavky v cele republice, a mit je
> konzistentni. Muzu pomoct s importem v okoli Rican...
>
> Mejte se,
>
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] was:highway=primary

[Mirek Dlask]

Ahoj,
před časem jsem taky našel  - was:highway - na vjezdu do Slaného.
Podle ŘSD by to měla být jednička (primary) ref=16J.
Původně byla primary, teď je secondary. Přes Slaný dokonce jako
tertiary. Může na to někdo mrknout a případně to opravit?
Nevím proč to měnil bez ověření a já tomu nerozumím.

Osmose:http://osmose.openstreetmap.fr/cs/map/#zoom=14=50.23891=14.11022=4061=1%2C2%2C3==

ŘSD:https://geoportal.rsd.cz/webappbuilder/apps/7/

ZABAGED:https://geoportal.cuzk.cz/geoprohlizec/

Jako bonus přidávám ještě id bodů s historic:amenity=*
1979273508 691097416 6386415580 2893335665 330094293 7025542872
1497170668 3916536437 308815471 3948265661 3470869220 320245518
3410705815 2317580750 1809620387 2331882610 3906502503 3247827929
6712175248 1276244833 346315792 1664530060 4566466595 2077722890
1388680195 1651248019 3659018204 3310246926 5068486960 1892117710
5776698021 617233421 4988304267 893061695 5167979382 2306638848
296682895 4546915926

id bodů historic:shop=*
1427357563 1427274250 1547034921 1365491040 1365491036 3918461346
3918461348 4815039530 4791474122 429943266 5530679678

Stačí čísla zkopírovat do schránky v JOSM  CTRL+SHIFT+O => v roletce
Typ objektu - uzel -> tlačítko - Stáhnout objekt

nebo méně pohodlně na
webuhttps://www.openstreetmap.org/node/1427357563https://www.openstreetmap.org/node/1427274250https://www.openstreetmap.org/node/1547034921https://www.openstreetmap.org/node/1365491040https://www.openstreetmap.org/node/1365491036https://www.openstreetmap.org/node/3918461346https://www.openstreetmap.org/node/3918461348https://www.openstreetmap.org/node/4815039530https://www.openstreetmap.org/node/4791474122https://www.openstreetmap.org/node/429943266https://www.openstreetmap.org/node/5530679678

Jednu editační válku jsem vzdal, do další nejdu.


Dne ne 10. kvě 2020 16:14 uživatel Pavel Pilát 
napsal:

> Souhlasím. Stalo se. Díky! :-)
>
> On Fri, May 8, 2020 at 11:40 PM Marián Kyral  wrote:
>
>> Já bych tu cestu smazal.
>>
>> Marián
>>
>> -- Původní e-mail --
>> Od: Pavel Pilát 
>> Komu: OpenStreetMap Czech Republic 
>> Datum: 8. 5. 2020 15:17:32
>> Předmět: [talk-cz] was:highway=primary
>>
>> Co si myslíte o takto otagovaném bývalém úseku silnice?
>>
>> https://www.openstreetmap.org/way/780526664
>>
>> Ponechat, neponechat? V terénu už po tom žádná známka neexistuje. Teď je
>> tam pole.
>> ___
>> talk-cz mailing list
>> talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz
>> https://openstreetmap.cz/talkcz
>>
>> ___
>> talk-cz mailing list
>> talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz
>> https://openstreetmap.cz/talkcz
>>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] PID import dat

[Mirek Dlask]

Ahoj,
nějaký čas přidávám zastávky. Původně jsem to považoval za přípravu na
integraci Boleslavska do PIDu. Ta se zatím nekonala. Ale vzhledem k tomu,
že se zastávkám nikdo systematicky nevěnuje (čti nikdo mi do toho nekecá),
tak v tom pokračuji. U všech je ref:PID z GTFS, takže pokud převládne
názor, že je třeba něco změnit, nebude to problém.
Jiná situace je u linek. Většinou jde o opravy. Z PIDu jsem jich přidal
minimum. Něco jsou editace plynoucí z editací něčeho jiného. Stačí někde
rozdělit a pojmenovat ulici, po které prochází 10 autobusových linek a jsem
naráz posledním editorem všech deseti linek (jejich relací).
Veřejné dopravě v Praze se asi nejvíc věnuje (věnoval?) itamas80.

Bylo by dobré mít v OSM všechny zastávky, což je reálné a dá se to vcelku
snadno udržovat. Co už je složitější jsou přestupní uzly.

Ještě složitější jsou linky. Dají se velmi snadno rozbít, třeba neopatrnou
editací něčeho jiného. Špatně se pracuje s variantami vedení linek,
opakovanými průjezdy jedním místem, další komplikace je nutnost mít
rozdělené cesty na odbočkách. Možná proto jsou neudržované, některé stále
jako public_transport:version=1. To, že jsou některé validní, nemusí
znamenat, že jsou úplné. Jiné jsou úplné, ale nejsou validní.
I když bych linky dělal poloautomaticky z GTFS, tak výsledek nebude
odpovídat vynaloženému úsilí.

 U tebe to může být jinak. Předpokládám, že víš do čeho jdeš a víš jak na
to.
Možná by nebyla od věci nějaká ukázka čeho chceš dosáhnout a v jaké kvalitě.
Počítáš s aktualizacemi?

Mirek

pá 13. 3. 2020 v 10:54 odesílatel Jozef Matejička 
napsal:

> CC0 podle  https://wiki.openstreetmap.org/wiki/Import/ODbL_Compatibility by
> měla býti kompatibilní.
>
> Vypadá to, že data již importoval uživatel Minimalis. Poslal jsem mu
> správu.
>
> On Thu, 12 Mar 2020 at 21:51, Petr Schönmann  wrote:
>
>> Ahoj, myslim ze trasy nemusis dolovat z polohy vozu. Tady by to slo taky.
>> Nevim jak s licenci, ale pokud to jsou opendata tak by to snad slo ;)
>> http://opendata.praha.eu/dataset/dpp-jizdni-rady
>>
>> On Thu, Mar 12, 2020, 13:25 Jozef Matejička  wrote:
>>
>>> Na Root-u jsem našel článek o tom jak PID zveřejnil polohy autobusů.
>>>
>>> https://www.root.cz/clanky/sledovani-polohy-vozidel-pid-kde-je-prave-muj-autobus/
>>>
>>>
>>> Někdo se tím již zaoberal? Ať neobjevuji Ameriku.
>>>
>>> Jestli licence je kompatibilní, zavžuji, že bych od nich vytáhnul trasy
>>> linek v Praze.
>>>
>>> J.
>>> ___
>>> talk-cz mailing list
>>> talk-cz@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-cz
>>> https://openstreetmap.cz/talkcz
>>>
>> ___
>> talk-cz mailing list
>> talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz
>> https://openstreetmap.cz/talkcz
>>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] landuse v Praze pouze s ZHS jmenem

[Mirek Dlask]

Ahoj,
ta oblast plus minus kopíruje Letenské sady. Proč totéž mapovat ještě jako
„zeleň na návsi“?
Překladač Google tu čínštinu překládá jako „Lightner Park“. Nebylo by
vhodnější tu čínštinu zkopírovat na Letenské sady a cestu smáznout? Park je
přesnější než „zeleň na návsi“.
Letenské sady jsou zde https://www.openstreetmap.org/way/25738281

st 23. 10. 2019 v 18:26 odesílatel mahdi1234  napsal:

> cau,
>
> Narazil jsem na foru o MagicEarth na toto
> https://www.openstreetmap.org/way/405092597 - jmeno cele oblasti je jen
> v ZHS, muze nekdo mistni doplnit CZ nebo smazat tu cinstinu, jestli tam
> nepatri?
>
> dik,
> mahdi
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] Jízdní řády a linky MHD

[Mirek Dlask]

Souhrn je například v katalogu otevřených dat

https://data.gov.cz/datov%C3%A9-sady?dotaz=zast%C3%A1vky%C3%A1nka=1

Bohužel často jsou zastávky  zjednodušeny do jednoho bodu někdo uprostřed.
Polohová přesnost je mnohde, třeba i vpražském PIDu špatná.

M.D.

út 1. 10. 2019 v 22:37 odesílatel Mikoláš Štrajt  napsal:

> Zdar,
> probíraly se tu teď linky MHD. Vzhledem k tomu, že se o danou tématiku
> zajímám, tak zkusím shrnout, jaký je stav:
>
> Pro ČR existuje tzv. Celostátní informační systém o jízdních řádech. Jeho
> data byla po letech bojů Chapsu se Seznamem více méně otevřena pro širokou
> veřejnost. Celou tu historii si můžete přečíst na wiki -
> https://cs.wikipedia.org/wiki/Celost%C3%A1tn%C3%AD_informa%C4%8Dn%C3%AD_syst%C3%A9m_o_j%C3%ADzdn%C3%ADch_%C5%99%C3%A1dech
>
> Data najdete zde - ftp://ftp.cisjr.cz/ - nicméně (pokud vím) neobsahují
> žádné geografické informace, tj. pro OSM jsou v podstatě k ničemu.
>
> Pro nás zajímavější jsou data ve formátu GTFS - z těch se totiž dají
> vytáhnout jak jízdní řády, tak poloha zastávek a přibližná trasa linek.
>
> Krásně to má zpracované Praha  - viz https://pid.cz/o-systemu/opendata/
>
> Ještě jsem to našel pro Liberec - https://www.dpmlj.cz/opendata
>
> Další město už jsem nenašel, ale kde se dá hledat spojení na Google maps,
> tak to místní DP nebo IDS umí vygenerovat.
>
> U některých měst jdou sehnat alespoň seznamy zastávek, viz Plzeň:
>
>
> https://opendata.plzen.eu/dataset/gis-doprava-mestska-hromadna-doprava-zastavky-mhd
>
> * * *
>
> Co se týká zobrazování - já mám rozepsanou prohlížečku jízdních řádů. Viz
> http://jizdnirady.svita.cz/pid (zrovna včera jsem tam nahrál data)
>
> Pavel Machek má nějaký vyhledávač, ale netuším jak moc je to použitelné -
> https://gitlab.com/tui/tui/tree/master/timetab/
>
> + jde říct, že když máme GTFS tak už jsou použitelné různé opensource
> nástroje
>
> * * *
>
> A co se týká importu dat do OSM:
>
> Kdyby byl zájem, můžu napsat nějakou aplikaci, která tahle GTFS data
> předádět na nějaký GeoJSON nebo něco podobného a my to pak budeme moci
> importovat/opisovat podobně jako se to dělá např. s poštovníma schránkama.
> Nicméně NECHCI být ten, kdo to bude překlikávat, zas tolik času nemám (ani
> v zimě :-D).
>
> --
> Severák
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] Mapovani MHD was Re: SotM deníček - den třetí

[Mirek Dlask]

Ahoj,
rozdíl tam přece jen je. Trasu autobusem si vybrat nemohu. Jízdu s pistolí
na spánku řidiče vylučuji. Nechci jezdit tímto -
https://cs.wikipedia.org/wiki/V%C4%9Bze%C5%88sk%C3%BD_v%C5%AFz . Proto
„nepotřebuji vědět kudy".

Naopak cestu si rád vybírám a současná míra jejich zjednodušení mi vyhovuje.
Tvoje reakce je zbytečná. Popisuješ totéž jako „jzvc" jen jinými slovy.

Pro jistotu.
Nemám v úmyslu na současném stavu nic měnit. Už dnes je možné mít v
relacích veřejné dopravy pouze zastávky. Stačí ignorovat hlášky validátorů.

A proč?
Seznam zastávek vyčtu z jízdního řádu vždy,  trasu linek často nedokážu ani
odhadnout. Následně může někdo trasu projet, zaznamenat a k zastávkám ji
přidat.

Závěrem
se ještě vrátím k povzdechnutí od „jzvc"

oficielni reneder OSM pokud dobre vidim uz nejakych 8 let s klidem ignoruje
oficielne odsouhlaseny standard pro tagovani hromadne dopravy. Jinak
receno, ani ty zastavky na mape videt nejsou.

Za současnou situaci můžeme všichni kdo k tagům public_transport přidáváme
highway , railway. Pokud bychom je nepřidávali celosvětově, tak by se
nějaký čas zastávky nevykreslovaly a pak se vidělo. Nebo taky nevidělo.


M.D.


po 30. 9. 2019 v 20:31 odesílatel Petr Vozdecký  napsal:

> Od: Mirek Dlask 
> Předmět: Re: [talk-cz] Mapovani MHD was Re: SotM deníček - den třetí
>
> Ahoj,
> nepotřebuji vědět kudy bus jede. Jestli po Hlavní, nebo Souběžnou mi je
> jedno.
>
>
> To je jako: ...nepotřebuji vědět, kudy ta cesta/pěšina/silnice vede, stačí
> mi jen křižovatky, zjednodušíme si to na 2D drátový model a vše bude
> snazší, bude se to líp spravovat, nemusí se řešit změny geometrie cest mezi
> křižovatkami, bude to zabírat míň místa všude, navigovat "za 200m doleva"
> to bohatě stačí...
>
>
> Těch argumentů "pro" se dá najít vlastně strašně moc... ...a nakonec si
> strašně zjednodušíme práci... ...a vlastně úplně všechno :)
>
>
> vop
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] Mapovani MHD was Re: SotM deníček - den třetí

[Mirek Dlask]

po 30. 9. 2019 v 17:09 odesílatel jzvc via talk-cz <
talk-cz@openstreetmap.org> napsal:

> Dne 30.9.2019 v 13:33 Mirek Dlask napsal(a):
>
> Ahoj,
> nepotřebuji vědět kudy bus jede. Jestli po Hlavní, nebo Souběžnou mi je
> jedno. Zajímá mě odkud kam, kdy to jede a kdy tam budu.  O kompletních
> časech odjezdů a příjezdů můžeme v OSM jenom snít.
> Vkládat do relací pouze zastávky je dobrá myšlenka. Problém je, že by se
> data musela  udržovat někde mimo OSM. Pokud nemám cesty, nemám podle čeho
> bych zastávky seřadil a seřazení hlídal.
> Naopak by odpadly problémy s udržováním relací tras a fragmentací cest.
>
> Jako variantu bych omezení jenom na zastávky podpořil. Je to někde mezi
> route_ref na zastávkách, kde nemám návaznost na další zastávky a
> kompletními relacemi zastávek + cest.
>
> Nezajima me nejaka geometrie budov, staci mi vedet, ze tam nejaka je,
> natoz aby me zajimal nejaky 3d model. Stejne tak me nezajima jestli ma
> silnice 2, 3 nebo 10 pruhu ... mam pokracovat? Uplne stejne se totiz z OSM
> da vyhodit 99% dat ktery tam jsou, protoze zrovna me naprosto nezajimaji (a
> navic ty informace stejne 99% objektu nema). Nekoho ale zajima muzou a
> muzou mu poskytnout vemi podstatnou informaci. Treba na tema jak dlouho to
> pojede, pripadne kolik ho to bude stat (kupodivu je jizdny dost casto dany
> km ...)
>
> Proto si ja osobne myslim, ze skutecna trasa autobusovych a jinych linek
> je proste neco, co do OSM patri, bez ohledu na to, jak blbe to je nebo neni
> aktualne udrzovane. Ono se totiz vzhledem k tomu, jak podobna data
> (ne)zobrazuje mapa, neni cemu divit.
>
>
>  Netvrdím, že trasy  do mapy nepatří. Jenom bych (možná) měl mít možnost
veř. dopravu mapovat bez nich. Je jednodušší stáhnout si v JOSM zastávky a
vyhledat např:
"U1528Z2" OR "U1526Z2" OR "U1525Z2" OR "U1524Z2" OR "U1502Z1" OR "U1503Z4"
OR "U280Z3" OR "U62Z2" OR "U388Z4" OR "U1158Z82"
vložit do relace a seřadit. Je to PID linka 906. Předpoklad -  že tam někdo
ty ref, nebo ref:PID dal.

Vyzkoušel jsem si i mapování linek abych otestoval jejich 'nerozbitnost'.
Třeba https://www.openstreetmap.org/relation/10024893
Je to zkrátka přinejmenším pracnější.
Vůbec jsem neuspěl v Turnově, kde jsem si nechal cesty seřadit, čímž se
dokonale rozřadily. Možná se k tomu někdy vrátím.

Umím si představit variantu, kdy jsou v OSM jenom zastávky a jinde v OSM
uloženy trasy včetně cest pro ty zvědavější. Vím, určitě už něco takového
existuje, nevím jestli pro ČR.

M.D

>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] Mapovani MHD was Re: SotM deníček - den třetí

[Mirek Dlask]

Ahoj,
nepotřebuji vědět kudy bus jede. Jestli po Hlavní, nebo Souběžnou mi je
jedno. Zajímá mě odkud kam, kdy to jede a kdy tam budu.  O kompletních
časech odjezdů a příjezdů můžeme v OSM jenom snít.
Vkládat do relací pouze zastávky je dobrá myšlenka. Problém je, že by se
data musela  udržovat někde mimo OSM. Pokud nemám cesty, nemám podle čeho
bych zastávky seřadil a seřazení hlídal.
Naopak by odpadly problémy s udržováním relací tras a fragmentací cest.

Jako variantu bych omezení jenom na zastávky podpořil. Je to někde mezi
route_ref na zastávkách, kde nemám návaznost na další zastávky a
kompletními relacemi zastávek + cest.

M.D.


po 30. 9. 2019 v 10:01 odesílatel <0174  napsal:

> Ahoj,
> ona je podle mě hlavní otázka, jak přesně potřebujeme vědět, kudy to
> "opravdu jezdí".
> Příklad - několik let jsem dojížděl z vesnice do blízkého města. Autobus
> měl dané zastávky a obvyklou trasu, ale pokud byla kolona, jel jinudy. Což
> znamená ve všední dny třeba polovinu spojů (ve špičce jich jezdí víc). Pak
> je tam úsek, kde se dá jet buď kratší trasou, kde jsou po cestě semafory,
> nebo delší bez semaforů. Většina řidičů jezdí tou delší, ale jsou řidiči,
> kteří raději jedou tou kratší - pokud trefí zelené na semaforech, je to
> rychlejší.
> Myslím si, že podobné stavy jsou poměrně běžné a zažil jsem je i na jiných
> linkách. A vzhledem k tomu, v jakém stavu relace silniční hromadné dopravy
> v ČR jsou, tak mi zjednodušení relací jen na zastávky přijde jako dobrý
> krok - alespoň jako varianta. Protože jen ta linka zmíněná výše má několik
> variant sama o sobě a zmapování všech variant + neoficiálních variant (Jak
> zjistíme tu oficiální? Musí existovat? Musí mapper spojem jezdit pár týdnů,
> aby zjistil varianty? Co když se oficiální a reálná liší?) je určitě
> alespoň na hodinu pro zkušeného mappera. Příměstských linek jsou u větších
> měst desítky. A pak se překope křižovatka a řidiči pojedou jinudy...
> nemyslím si, že máme kapacity a chuť to udržovat.
>
> Jiná věc je železnice, kde je podle mého názoru důležitější vědět "vlak
> jede tudy" - i kvůli přejezdům apod. - osobní vlaky na tratích u nás tvoří
> zásadní část dopravy, narozdíl od autobusů na našich silnicích. Navíc je to
> jednodušší na mapování, protože strojvůdce se předpokládám nemůže
> rozhodnout "dnes pojedu tudy".
>
> Vojta
>
> pá 27. 9. 2019 v 19:55 odesílatel jzvc via talk-cz <
> talk-cz@openstreetmap.org> napsal:
>
>> Dne 26.9.2019 v 13:03 Pavel Machek napsal(a):
>> > On Tue 2019-09-24 08:37:01, jzvc via talk-cz wrote:
>> >> Dne 23.9.2019 v 23:08 xkomc...@centrum.cz napsal(a):
>> >>> Naposledy ahoj,
>> >>>
>> >>> dnes to bude stručnější, protože ráno jsem se ještě snažil nachystat
>> na
>> >>> prezentaci co to šlo a pořád dokola ji pročítal, tak jsem toho moc
>> >>> nestihl. Nicméně, hodně zajímavé byly Lightening talks VII, kde mluvil
>> >>> SK53 o mapování poštovních schránek v UK (všichni, co mapují schránky
>> v ČR
>> >>> by měli shlédnout - máme toho ještě hodně co dohánět :-D), pak člověk
>> z
>> >>> Geofabriku představoval OSMInspector pro hledání chyb v routovacích
>> >>> relacích a na to navazoval poslední příspěvek, ve které padl návrh na
>> >>> zrušení routovacích relací (tj. veřejná doprava, cyklotrasy, pěší
>> trasy,
>> >>> ...) jak je známe a jejich nahrazení systémem "routovacích relací", ve
>> >>> kterých by byly jen body, přes které se má jít a o výběr cesty by se
>> >>> staral hledač tras.
>> >> Cus,
>> >>
>> >> pokud mi skleroza slouzi tohle se tu uz kdysi probiralo, a minimalne v
>> >> podminkach CR to nemuze fungovat. Jednoduse proto, ze temi body by z
>> logiky
>> >> veci byly zastavky, a hledat muzes tak maximalne nejkratsi nebo
>> >> "nejrychlejsi" trasu, ale to neni vzdy ta, po ktere MHD realne
>> > Jasne ze to fungovat muze. Krome zastavek by tam bylo i par bodu ktere
>> > ukazou kudy to doopravdy jezdi...
>>
>> To by me zajimalo, jak by sis to predstavoval. Dam ti par prikladu:
>>
>> 1) rekneme ze uvazujes nekratsi trasu. Krizovatka cestou se zmeni na
>> kruhac, coz udela tech par metru, ktery zmenej nejkratsi trasu na zcela
>> jinudy. Ale MHD jezdi porad stejne. Dokonce pokud bude editace v trase
>> trochu zivejsi, muze automat klidne co den vykazovat jinou trasu. Editor
>> silnic nema tuseni ze tam mas nejakou virtualni a v datech neexistujici
>> trasu. Naopak, pokud edituje soucasny stav, tak vidi pripadne prerusene
>> relace a muze je snadno doplnit. Editor tras prozmenu netusi, ze rozdil
>> mezi trasou ktera se mu prave zobrazila a jinou je trebas 10cm.
>>
>> 2) kdyz se prozmenu trasa zmeni, bude kazdy jeden editor resit, proc mu
>> pridani "jeho" pomocneho bodu vygeneruje uplnou blbost. Mozna po par
>> dnech prijde na to, ze musi nejaky fake bod odebrat. A pak si bude
>> nejspis muset pokazdy par hodin pockat, nez neco nekde trasu
>> pregeneruje, aby overil, ze vede tam, kde by chtel. Coz zcela
>> automaticky povede k tomu, ze "pro zjednoduseni" prida vsechny body na
>> trase, protoze se prece nebude 

Re: [talk-cz] Praha zveřejňuje otevřená data o parkování v ulicích města

[Mirek Dlask]

Ahoj,
porovnej si
- Praha IPR nejnovější ortofoto
- Praha IPR mimovegetační ortofoto

Nejnovější orotofoto je špatně zkalibrovaný - rozdíl cca 10 metrů.
A pokud ji IPR použilo pro mapování, tak je to o 10m posunutý.
Nevím jestli by šla udělat nějaká korekce na datech.


ne 20. 1. 2019 v 21:51 odesílatel Marián Kyral  napsal:

> On 20. 01. 19 19:29, Majka wrote:
> > Už se nějak definitivně usadil způsob značení parkovacích zón? Protože
> > když jsem se na to ptala posledně, nic takového nebylo.
> > Majka
>
>
> Parkovací zóny jsem zatím vynechal, ale mrknul jsem na parkovací
> automaty. Pro představu jsem je nahodil do POI-Importeru:
>
> https://osm.kyralovi.cz/POI-Importer-testing/#map=15/50.0757/14.4176=PrgParking
>
> Chybí jich opravdu hodně. Ručně bych to nedělal :-D
>
> Nicméně je tam vidět, jak (ne)přesné ty souřadnice jsou. Občas to
> vychází doprostřed domu :-(
> Akorát nevím, jestli je problém už v datech nebo v převodu EPSG:5514 na
> EPSG:4326.
>
> Konverzní skript je tady:
>
> https://github.com/mkyral/osm/tree/master/import/Praha-Parkovac%C3%AD_automaty
>
> Marián
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-cz] Mapy.cz a OSM data v CZ (a jinde)

[Mirek Dlask]

Zastávky
zkusím poslat ještě jednou i s odkazem, když už to mám zpracovaný.
Ulice
Psal jsem na OÚ, aniž bych čekal nějakou odpověď. Taky žádná nepřišla.
Důvody nezveřejnění neznám jenom spekuluji na základě např.:
https://ct24.ceskatelevize.cz/domaci/551-maji-ulice-se-stejnym-nazvem-obce-se-ale-do-jejich-prejmenovani-prilis-nehrnou
https://opavsky.denik.cz/zpravy_region/dve-ulice-se-stejnym-nazvem-v-obci-zmeny-se-nekonaji-20170903.html



čt 20. 12. 2018 v 13:23 odesílatel Jan Dudík  napsal:

> Mapy.cz zkus zaurgovat, případně nahlásit znova, taky jim některé mnou
> zaslané věci zapadly.
>
> To s těmi názvy ulic se mi moc nezdá, mě třeba nechtěli dát do map.cz
> cyklostezku Josefa Cepáka
> https://openstreetmap.cz/#map=18/48.99336/14.45956=t
> přestože je v terénu
> https://photos.app.goo.gl/3CXHQcyotDkrO7F73
> a přestože o tom psali v novinách, protože není v RUIAN
>
> JAnD
> ---
> Ing. Jan Dudík
> projekce dopravních staveb
> tel. 777082195
>
>
> čt 20. 12. 2018 v 12:46 odesílatel Mirek Dlask  napsal:
>
>> Ahoj,
>> dva postřehy.
>> 1) názvy ulic
>> na mapy.cz dokážou získat názvy ulic od obcí, které je odmítají
>> zveřejnit v RUIAN. Asi s ohledem na občany - výměna dokladů. Vím tedy o
>> jedné obci - 50.5269072N, 14.9436308E.
>> Otázka je, jestli tato data od obcí dokážeme vyjednat sami, nebo se
>> spojíme s mapy.cz.
>>
>> 2) chybné opravy
>> dávno tomu jsem jim hlásil chybu v mapě - polohu zastávek autobusu. Čekal
>> jsem, že je posunou. Přidali tam ještě jednu a vymysleli pro ni název.
>> Do dnešního dne stav nezměněn.
>>
>> https://mapy.cz/zakladni?x=14.9332506=50.5155224=16=pubt=15327880=50.52%2014.62
>> https://openstreetmap.cz/#map=16/50.5155/14.9353=t
>>
>> Špatně opraveno (neopraveno) mají ještě zde.
>> https://openstreetmap.cz/#map=16/50.3900/14.9019=t
>>
>> https://mapy.cz/zakladni?x=14.8986838=50.3900376=16=firm=2376458
>>
>> Nevím jestli hledat  protekci, nebo kontakt, kam případně chybné opravy
>> hlásit. Nebo jsem sám, kdo neumí chybu nahlásit?
>> Pro úplnost dodám, že jsem svoji příslušnost k OSM zatajil ;-)
>>
>> Ještě jeden rozdíl, zkusím nahlásit přes opraváře.
>> https://openstreetmap.cz/#map=18/50.48674/14.90663=t
>>
>> https://mapy.cz/zakladni?x=14.9052445=50.4866704=17=pubt=15325863
>>
>> M.D.
>>
>> st 19. 12. 2018 v 22:47 odesílatel Tom Ka 
>> napsal:
>>
>>> Ahoj,
>>>
>>> z jednani s Mapy.cz (po uspesnem navazani diskuze na SotM CZ v Brne),
>>> zacinaji nest prvni drobne ovoce. Mapy.cz vyuzivaji (nebo v brzke dobe
>>> budou) nasledujici data z OSM pro CZ (i zahranici):
>>>
>>> - poštovní schránky (amenity=post_box)
>>> - popelnice na separovaný odpad
>>> (amenity=recycling+recycling_type=container)
>>> - SOS telefony (emergency=phone)
>>> - telefonní budky (amenity=telephone)
>>> - stojany pro kola (amenity=bicycle_parking)
>>> - automaty na jízdenky (vending=public_transport_tickets)
>>> - parkovací automaty (vending=parking_tickets)
>>> - železniční přejezdy (railway= level_crossing)
>>>
>>> Jednak jim nahlasene chyby v techto vecech budou rovnou opravovat v
>>> OSM, jednak jakakoliv prace komunity se behem par tydnu projevi na
>>> mapy.cz.
>>>
>>> Krome toho zrejme na komunitu (a/nebo spolek) budou smerovat jednani o
>>> vyuziti otevrenych dat ruznych mest, zmineny byly Ceske Budejovice a
>>> parkovaci automaty, takze to muze byt motivace pro nas zkusit se v
>>> tomto angazovat a do OSM patricna data dostat.
>>>
>>> Mejte se tom.k
>>>
>>> ___
>>> Talk-cz mailing list
>>> Talk-cz@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-cz
>>> https://openstreetmap.cz/talkcz
>>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz
>> https://openstreetmap.cz/talkcz
>>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-cz] Mapy.cz a OSM data v CZ (a jinde)

[Mirek Dlask]

Ahoj,
dva postřehy.
1) názvy ulic
na mapy.cz dokážou získat názvy ulic od obcí, které je odmítají zveřejnit v
RUIAN. Asi s ohledem na občany - výměna dokladů. Vím tedy o jedné obci -
50.5269072N, 14.9436308E.
Otázka je, jestli tato data od obcí dokážeme vyjednat sami, nebo se spojíme
s mapy.cz.

2) chybné opravy
dávno tomu jsem jim hlásil chybu v mapě - polohu zastávek autobusu. Čekal
jsem, že je posunou. Přidali tam ještě jednu a vymysleli pro ni název.
Do dnešního dne stav nezměněn.
https://mapy.cz/zakladni?x=14.9332506=50.5155224=16=pubt=15327880=50.52%2014.62
https://openstreetmap.cz/#map=16/50.5155/14.9353=t

Špatně opraveno (neopraveno) mají ještě zde.
https://openstreetmap.cz/#map=16/50.3900/14.9019=t
https://mapy.cz/zakladni?x=14.8986838=50.3900376=16=firm=2376458

Nevím jestli hledat  protekci, nebo kontakt, kam případně chybné opravy
hlásit. Nebo jsem sám, kdo neumí chybu nahlásit?
Pro úplnost dodám, že jsem svoji příslušnost k OSM zatajil ;-)

Ještě jeden rozdíl, zkusím nahlásit přes opraváře.
https://openstreetmap.cz/#map=18/50.48674/14.90663=t
https://mapy.cz/zakladni?x=14.9052445=50.4866704=17=pubt=15325863

M.D.

st 19. 12. 2018 v 22:47 odesílatel Tom Ka  napsal:

> Ahoj,
>
> z jednani s Mapy.cz (po uspesnem navazani diskuze na SotM CZ v Brne),
> zacinaji nest prvni drobne ovoce. Mapy.cz vyuzivaji (nebo v brzke dobe
> budou) nasledujici data z OSM pro CZ (i zahranici):
>
> - poštovní schránky (amenity=post_box)
> - popelnice na separovaný odpad
> (amenity=recycling+recycling_type=container)
> - SOS telefony (emergency=phone)
> - telefonní budky (amenity=telephone)
> - stojany pro kola (amenity=bicycle_parking)
> - automaty na jízdenky (vending=public_transport_tickets)
> - parkovací automaty (vending=parking_tickets)
> - železniční přejezdy (railway= level_crossing)
>
> Jednak jim nahlasene chyby v techto vecech budou rovnou opravovat v
> OSM, jednak jakakoliv prace komunity se behem par tydnu projevi na
> mapy.cz.
>
> Krome toho zrejme na komunitu (a/nebo spolek) budou smerovat jednani o
> vyuziti otevrenych dat ruznych mest, zmineny byly Ceske Budejovice a
> parkovaci automaty, takze to muze byt motivace pro nas zkusit se v
> tomto angazovat a do OSM patricna data dostat.
>
> Mejte se tom.k
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

[Talk-cz] Liberec - oprava křižovatky

[Mirek Dlask]

Ahoj,
narazil jsem na "rozbitou" křižovatku před libereckým nádražím. Máte-li
někdo čas a chuť tak ji prosím opravte. Já se k tomu dostanu až zítra.
M.D.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-cz] JOSM: otevření daného pohledu v browseru

[Mirek Dlask]

Vyber objekt a v  menu si vybereš Zobrazit -> Rozšířené informace (web).
Klávesová zkratka CTRL+SHIFT+I

ne 14. 10. 2018 v 10:53 odesílatel Pavel Pilát 
napsal:

> Lze z JOSM vyvolat otevření prohlížeče a načtení www.openstreet.org na
> místě, které zrovna edituju?
>
> Díky a hezký den
>
> Pavel Pilát
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-cz] Poštovní schránky - aktualizace doby výběru

[Mirek Dlask]

Díky za vysvětlení. Aktuální situaci v datech neznám, ale v době před
zveřejňováním čísel schránek mi párování fungovalo vcelku spolehlivě i bez
číslování.


po 8. 10. 2018 v 23:08 odesílatel majka  napsal:

> On Mon, 8 Oct 2018 at 20:48, Mirek Dlask  wrote:
>
>> Ahoj,
>> 1. Pokud bude pošta dělat rošády, nebo dokonce šachovat s čísly schránek,
>> tak se dají poštovní data spárovat s poštovními daty z předchozího měsíce.
>>
>
> *Už to vypadá, že budu mít připraveno, a budu se vydávat na import list. 
> *Ještě
> tomu potřebuji udělat několik kol kontroly, abych se nesekla na něčem, co
> mě nenapadlo - protože jsem původně nepočítala s tím, že to přečíslování je
> tak časté. Hodnoty v OSM jsou tedy už delší dobu špatně, a bohužel jsem je
> brala za správná.
>
> To párování není tak jednoduché jak vypadá - protože pošta šachuje jak s
> čísly schránek, tak i s tím popisem a když se to "dobře" sejde, tak i se
> souřadnicemi, které udávají. Takhle "naivně" jsem si to také představovala,
> a tak i byly připravené ty kontrolní skripty. Bohužel, takhle to nefunguje,
> takže to opravdu bude minimálně ve dvou krocích, možná raději ve třech, kdy
> kontrola vůči umístění bude také. Navíc nám jedno přečíslování už uteklo,
> bylo někdy mezi zářím/říjnem loňského roku a cca dubnem.  Kdyby nebylo
> míst, kde je několik schránek velmi blízko u sebe, dalo by se to u toho, co
> už v mapě máme, udělat podle souřadnic. Bohužel, nedá, zvlášť vzhledem k
> tomu, že některé schránky mají stále ještě od pošty udávanou polohu
> (souřadnicemi) i několik kilometrů od správného místa. Některá depa na to
> dlabou více než jiná, a hlavně více než je zdrávo :)
> Dnes konečně mi to začalo fungovat tak, jak si představuji a snad pošta
> nevymyslí ještě něco, čím to zase naboří. Překvapení se jim docela daří.
>
> Poznámka k přehledu poštovních schránek.
>> Například http://josm.poloha.net/cz_pbox/depo.php?id=29407
>> V pravém sloupci 'Zdroj' mám první řádek 201808 další 201802. Čekal bych
>> 201809 nebo 201810. Jsem zmaten :-)
>>
>
>> Dnes jsem si vyfotil schránku 29407:291 která by měla být zrušena, ale
>> schránka je stále na svém místě. A to i v aktuálních datech České pošty,
>> které jsem si teď stáhl.
>>
>
> *Obojí je způsobeno tímtéž: Marián neměl čas ten přehled aktualizovat,
> takže se mu porovnává proti souboru z minulého měsíce.*
>
> "Zrušená" schránka často znamená, že je zrušená jen dočasně. Tohle je
> klasický případ, kdy jí zrušili po dobu výstavby té nové čekárny, tedy
> alespoň předpokládám. Často to bývá po dobu rekonstrukce ulice (pošťák se k
> ní nedostane) nebo po dobu rekonstrukce objektu, na kterém normálně
> schránka je.
> Proto se nechystám schránky automaticky rušit, ale pokud to půjde
> mechanicky, budou přepsané jako disused:amenity=post_box fixme tagem a
> označením, za jaké období se to dělalo.  Pak, jednou za čas (po roce?)
> pokud se ta schránka nenajde v datech pošty, bych tyhle "disused"
> definitivně vymazala.
>
> Majka
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-cz] Poštovní schránky - aktualizace doby výběru

[Mirek Dlask]

Ahoj,
1. Pokud bude pošta dělat rošády, nebo dokonce šachovat s čísly schránek,
tak se dají poštovní data spárovat s poštovními daty z předchozího měsíce.
Nepárovat podle čísla, ale podle adresy a místa, případně polohy. Výsledkem
bude převodní tabulka která řekne:
Schránka v Horní Dolní 24  X:XXX přečíslovaná na X:XXY.
Ruční práce by se mohla rapidně snížit.
Moc nerozumím tagu source:collection_times. Například CP201802 může být
stejné až do CP205001
Nemusí tě zajímat od kdy je čas výběru platný. Buď zůstane stejný, nebo se
změní a aktualizuješ.
Stále předpokládám, že porovnáváš OSM data a data pošty.
Ale možná si to jako neprogramátor představuji moc jednoduše.

Poznámka k přehledu poštovních schránek.
Například http://josm.poloha.net/cz_pbox/depo.php?id=29407
V pravém sloupci 'Zdroj' mám první řádek 201808 další 201802. Čekal bych
201809 nebo 201810. Jsem zmaten :-)

Dnes jsem si vyfotil schránku 29407:291 která by měla být zrušena, ale
schránka je stále na svém místě. A to i v aktuálních datech České pošty,
které jsem si teď stáhl.
Je tam nová čekárna a schránka posunutá pod stříšku.

Mirek D.

st 3. 10. 2018 v 17:27 odesílatel majka  napsal:

> Zdravím všechny.
>
> Už tu padla otázka aktualizace doby výběru schránek, a asi nastal čas se
> tím začít zabývat.
> Začala jsem v malém zkoušet zda mám šanci nějaký automatizovaný edit dát
> dohromady, a vypadá to nadějně. Musíme jen doufat, že Česká pošta nebude
> dělat v datech větší zmatek než dosud. Nějaké vstupní kontroly už mám
> hotové z minulého měsíce, kdy jsem to dělala kvůli těm zrušeným depům, a
> vypadá to, že se při tom daří ty změny odchytit.
>
> Zatím jen nástin, jak by to vypadalo: Na základě nových dat se ověří,
> jestli pošta nedělala nějaké rošády s čísly schránek. Pokud ano, depa,
> kterých se to týká, by se z aktualizace doby výběru kompletně vyjmula, a
> přečíslování se ošetřilo zase ručně.
> Vytáhla bych schránky, které mají v OSM ref, a tam, kde se proti OSM doba
> výběru změnila, by se připravil update. Přibyl by další tag (který tam už u
> některých schránek je, a to source:collection_times, ve kterém by byl
> označen datum souboru České pošty, tj. tento měsíc CP:201810).
>
> Ta případně vynechaná depa by se mohla udělat samostatně až poté, co dojde
> k odkontrolování správnosti toho převodu a kontrole na případné nové
> duplicity.
>
> Jestli vše půjde dobře, mohlo by být vše připraveno během tohoto měsíce.
> Pak bych vyrazila na import list a nechala to posvětit tam. Zároveň při tom
> budu zjišťovat, zda lokální importy (omezené jen na ČR) je opravdu nutné
> import listem prohánět, protože se ohledně toho informace kapku rozchází -
> podle některých informací by mělo stačit to zdokumentovat a probrat jen
> tady.
>
> Majka
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-cz] Body uvnitř stejně tagovaných ploch

[Mirek Dlask]

Zkus Osmose
http://osmose.openstreetmap.fr/cs/map/#country=czech_republic_jihomoravsky=4080=1%2C2%2C3=4080=17=49.5694420=16.6614084=1
a můžeš si odzoomovat a začít opravovat ;-)
Nebo jestli chceš seznam objektů označkovaných dvakrát pro Jihomoravský
kraj.
http://osmose.openstreetmap.fr/cs/errors/?country=czech_republic_jihomoravsky=4080=1%2C2%2C3
a kompletní přehled chyb ...
http://osmose.openstreetmap.fr/cs/errors/?country=czech_republic_jihomoravsky==1%2C2%2C3
Další možnost je přímo zobrazení v mapě. To se nedá odkazovat, musíš se tam
doklikat a přesunout postupně. Potom si už pamatuje poslední pozici na mapě.
http://osmose.openstreetmap.fr/cs/map/
-
Sousední fara je využívána církví?  Pak doplnit religion a denomination,
možná office?

so 15. 9. 2018 v 19:15 odesílatel Marián Kyral  napsal:

> On 9/15/18 3:14 PM, Jan Macura wrote:
>
> Ahoj,
>
> On Sat, 15 Sep 2018 at 10:33, Vladimír Slávik 
> wrote:
>
>> PS: Nemám preference jak to má být, jen nechcu dělat půlku práce,
>> případně zrovna tu co se nehodí :-)
>>
>
>  preference je rozhodně toto neduplikovat.
> Kdy je vhodnější samostatný bod a kdy označení funkce přidat ke geometrii
> celého objektu je na posouzení v každém případě zvlášť. Souhlasím s tím, co
> napsal Mirek Dlask.
> Pokud je možné nakreslit kostel jako polygon, pak označení, že jde o
> kostel, patří na ten polygon, protože asi až na vzácné výjimky je celá ta
> stavba kostelem, a ne že je uvnitř budovy vestavěný kostel.
>
> Čili ta editace ad (2) je zcela zbytná a smazatelná.
>
>
> Tak tak. JOSM řve, když najde POI uvnitř stejně otagovaného polygonu
> (parkoviště, kostel...)
> iD to už má taky? Nebo ještě pořád ne.
>
> Není na to nějaký QA nástroj? Rychle jsem kouknul na keepright a osmi, ale
> nic takového jsem tam nenašel.
>
> Marián
>
>
> H.
>
> ___
> Talk-cz mailing 
> listTalk-cz@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-czhttps://openstreetmap.cz/talkcz
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-cz] Body uvnitř stejně tagovaných ploch

[Mirek Dlask]

Ahoj,
preference jsou značně individuální.
U kostelů dávám přednost tagování na budově.
- není moc vícefunkčních kostelů
- render může budovu kostela zvýraznit.
Naopak obchody je lepe mít jako bod
- jedno pekařství jsem "stěhoval" už dvakrát
- v jedné budově může být více obchodů.

so 15. 9. 2018 v 10:33 odesílatel Vladimír Slávik 
napsal:

> Ahoj,
> všiml jsem si (po roce...) že doslova pár hodin po mé úpravě která dala
> vzniknout kostelu (1) někdo přidal i kostel jako bod uprostřed (2). Tak
> teď tam jsou dva objekty.
>
> Vzhledem k tomu že moje mapování je asi jak medvěd po zimním spánku -
> jak se k tomuhle má člověk stavět v poslední době? Je to stále tak jaksi
> libovolně, s tím že většina starých objektů je jen bod? Nebyl jsem
> schopný najít které pravidlo na to vlastně platí, akorát se matně
> pamatuju že snad body všude přidávávali lidi co používali nějakou
> navigaci co neuměla nic jiného než body...
>
> (1) https://www.openstreetmap.org/way/102468040
> (2) https://www.openstreetmap.org/node/5145289501
>
> PS: Nemám preference jak to má být, jen nechcu dělat půlku práce,
> případně zrovna tu co se nehodí :-)
>
> V+
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-cz] Fody na www.openstreetmap.cz

[Mirek Dlask]

S rozdělením na 'znaceni' a 'rozcestnik' souhlas.
'silnicni' pro 'znaceni' určitě ne. Celá trasa Greenway Jizera je značena
malými tabulkami 'znaceni' a rozhodně nevede celá jen po silnici. Je bez
pásového značení. Nevede jen po silnici  a nedá se celá projet na silničním
kole.
Žluté cyklorozcestníky vídám opravdu jen u silnic, i když ukazují na
odbočku na polní (lesní) cestu.
Ale rozdělení na silniční - trekové - gravel bike - MTB bych u fotek vůbec
neřešil.

čt 13. 9. 2018 v 14:22 odesílatel Tom Ka  napsal:

> Dne 13. září 2018 13:50 majka  napsal(a):
> >
> >
> > On Thu, 13 Sep 2018 at 13:42, Mirek Dlask  wrote:
> >>
> >> Kromě běžných cyklorozcestníků
> >> https://osm.fit.vutbr.cz/fody/files/19162.jpg
> >> máme ještě cyklotabule https://osm.fit.vutbr.cz/fody/files/18214.jpg ,
> což
> >> je v OSM předpokládám také rozcestník.
> >
> >
> > Co je pak tohle? Osobně považuji za cyklorozcestník, protože po jižních
> > Čechách jsem na "běžný" cyklorozcestník nenarazila.
>
> To se snazim celou dobu ukazat a navrhnout tagovani (Fody, OSM ted
> neresim) - jedna vec je
>
>  https://osm.fit.vutbr.cz/fody/files/19162.jpg
>
> a druha pak
> https://osm.fit.vutbr.cz/fody/files/18214.jpg
> a take tohle:
> https://osm.fit.vutbr.cz/fody/files/18263.jpg
>
> Takze at se nekam dobereme, opakuji navrh ve Fody rozlisovat prvni
> pripad pomoci tagu 'cyklo' (+'rozcestnik') a druhy (v obou variantach)
> jako 'silnicni' (+ rozcestnik).
>
> Tohle: https://osm.fit.vutbr.cz/fody/files/17711.jpg za mne psada to
> druhe skupiny a ve Fody bych tagoval: 'silnicni' (+ 'znaceni') protoze
> rozcestnik to neni - nema to ani text smeru ani kilometraz apod.
>
> Pohnem se s tim nekam?
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-cz] Fody na www.openstreetmap.cz

[Mirek Dlask]

Máš pravdu. Nejedná se o typické pásové značení.
Cyklotabulka se šipkou, jako třeba tato
https://osm.fit.vutbr.cz/fody/files/17711.jpg , plní stejnou funkci jako
typické pásové značení se šipkou na odbočkách pěších tras. Také je
nefotíme, nemapujeme.
 Fotit je má smysl pokud není cyklotrasa zmapovaná a nechci/nemůžu ji
zmapovat. Je-li zmapováno nemá smysl takovou fotku přidávat.
Kromě běžných cyklorozcestníků https://osm.fit.vutbr.cz/fody/files/19162.jpg
máme ještě cyklotabule https://osm.fit.vutbr.cz/fody/files/18214.jpg , což
je v OSM předpokládám také rozcestník.



čt 13. 9. 2018 v 11:05 odesílatel Zdeněk Pražák  napsal:

> no zrovna u těch cyklotabulek s číslem trasy se podle mne nejedná o
> typické značení ala pásové značky KČT (neboť jsou většinou umístěny u
> rozcestí cest a udávají, kterou cestou se má pokračovat) a proto je jejich
> zmapování podle mne vhodné.
>
> čt 13. 9. 2018 v 9:27 odesílatel Tom Ka  napsal:
>
>> Dne 12. září 2018 17:13 Zdeněk Pražák  napsal(a):
>> > na stránce https://openstreetmap.cz/git/tom.k/Fody/wiki/AddingPhotos
>> uvádíš:
>> >
>> > silniční cyklo
>> >
>> > jedná se o silniční žluté tabule s černým textem
>> > Cedulka jen s číslem trasy není rozcestník, odpovídá značce na stromě u
>> > turistické trasy, nevkládejte vůbec, nebo označte jako 'znaceni' a
>> 'cyklo'.
>> >
>> > bylo by vhodné tedy u cyklorozcestníků (cedulek s číslem trasy) při
>> > nahrávání fotek doplnit možnost označení tagu znaceni
>>
>> Ahoj, par postrehu/nametu/myslenek:
>>
>> - pri nahravani (pres osmap.cz) asi nikdy nebudou k dispozici vsechny
>> dostupne tagy, bylo by to spise kontraproduktivni - podle mne je
>> vhodne tam mit zakladni nejpouzivanejsi (jestli to jsou ty , ktere
>> jsou tam ted je druha otazka)
>> - zrovna u znaceni to osobne beru tak, ze to nekdy je fajn (pesi,
>> cyklo asi i jine) ale nema smysl zapraskat DB tunou fotek znaceni, v
>> tom nevidim zadny prinos, takze tyhle veci, ktere se mohou hodit ale
>> nechceme je ve velkem by asi bylo vhodne "nepropagovat" resp.
>> nepobizet lidi - s tim pak souvisi treba to, ze tato tagy se musi
>> doplnit az ve Fody rucne?
>>
>> - uz delsi dobu premyslim, jak oddelit (tagovani, pravidla, pripadne
>> dalsi veci) cyklo "silnicni" - zluto/cerne a "ala pesi KCT". Zatim mi
>> to vede na neco jako:
>> pesi+rozcestnik resp. pesi+znaceni
>> cyklo+rozcestnik resp. cyklo+znaceni - pro 'ala pesi KCT'
>> -> tyhle dve mohou mit asi stejna pravidla
>>
>> silnicni+rozcestnik resp. silnicni+znaceni - pro "zluto/cerne silnicni
>> cedule"
>> -> tohle bude mit obecne jina pravidla, jaka moc nevim, ani to zvlast
>> nefotim, ani nijak specialne nevyuzivam
>>
>> Co vy na to (nejen Zdenek) ?
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz
>> https://openstreetmap.cz/talkcz
>>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-cz] WeeklyOSM CZ 421

[Mirek Dlask]

Ahoj
V menu Mapové podklady -> Nastavení mapových podkladů  - klikni vpravo
skoro dole na +TMS
zadej
2. URL https://osm.fit.vutbr.cz/strava/all/{zoom}/{x}/{y}.png

3.  přiblížení 16
5. vrstvu pojmenuj

Pokud provozuješ neaktuální verzi JOSM bude asi v URL místo {zoom} {z}
https://osm.fit.vutbr.cz/strava/all/{z}/{x}/{y}.png

po 3. 9. 2018 v 8:01 odesílatel Zdeněk Pražák  napsal:

> mohl bych poprosit o popis postupu jak to dostat do JOSM - co je třeba a
> kde nastavit a co povolit
> Děkuji
> Pražák
>
> út 28. 8. 2018 v 8:07 odesílatel Tom Ka  napsal:
>
>> Pokud by byl zajem, muzu zkusit pridat jako vrstvu na osmap.cz a
>> udelat vlastni kopii dat jako maji kluci na freemap.sk - Martine, jak
>> resite aktualnost, nijak nebo jednou za cas rucne?
>>
>> Bye
>>
>> Dne 27. srpna 2018 21:21 Martin Ždila 
>> napsal(a):
>> > On Mon, Aug 27, 2018 at 7:24 PM Milan Cerny 
>> wrote:
>> >>
>> >> Zaujal mě příspěvek o Strava heatmap pro mapování OSM na Slovensku.
>> Dobrá
>> >> práce, jen škoda, že to neumí i celé ČR, jen kousek Moravy.
>> >> Uměl by někdo něco podobného i pro ČR? Je to hodně užitečný a přesný
>> zdroj
>> >> dat. S tím stávajícím do zoomu 12 se moc pracovat nedá, 16 už je o
>> něčem
>> >> jiném.
>> >
>> >
>> > Vyuzil som https://github.com/species/osm-tiledownloader plus
>> prilozeny diff
>> >
>> > --
>> > Ing. Martin Ždila
>> > OZ Freemap Slovakia
>> > tel:+421-908-363-848
>> > mailto:martin.zd...@freemap.sk
>> > http://www.freemap.sk/
>> >
>> >
>> >
>> > ___
>> > Talk-cz mailing list
>> > Talk-cz@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-cz
>> > https://openstreetmap.cz/talkcz
>> >
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz
>> https://openstreetmap.cz/talkcz
>>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-cz] 3D mapa v OSM - pěkná hračka - dejte zoom

[Mirek Dlask]

Ahoj,
problém je, že nejsou jen budovy natrasované z ruian, ale i různé stodoly,
kůlny, altánky obkreslené z katastrální mapy.
Např. dvě vedle sebe
https://www.openstreetmap.org/way/82649162 - tam opravdu něco je.
https://www.openstreetmap.org/way/82647218 - tady naopak už nic není. Je
dobré nejenom přidávat, ale i odstraňovat.
https://www.openstreetmap.org/way/82647210 - a při trasování dávat pozor,
co člověk přidává.

Ale abych měl jasno i já - tedy všichni.
Milancer  mi píše, že jsem rozbil vysílač Mělník.
Ten má tři nadzemní části.
https://www.openstreetmap.org/way/455101362 - základna
https://www.openstreetmap.org/way/455101363 - střední část
https://www.openstreetmap.org/way/455101364 - špička

Tady by mělo stačit přetagovat základnu na building = yes , zbylé dvě části
nechat jako building:part = yes. Relaci není třeba vytvářet. Že?
Pro úplnost by neškodilo přidat highway = service + area = yes na
základovou desku https://www.openstreetmap.org/way/455101361 .


Co když bude třeba střední část větší než základna?  Bude building = yes
rovněž základna (část s menší plochou) a všechny části je nutné vložit do
relace?




Dne 8. března 2018 22:10 Jan Macura  napsal(a):

> 2018-03-08 21:53 GMT+01:00 Vladimír Semotán :
>
>> Máte pravdu, používám i "house" a další tagy. I přesto si troufám,
>> tvrdit, že se to oblast od oblasti dost liší. Občas prostě bývá jen
>> building="yes".
>>
>
>  Určitě se to bude oblast od oblasti lišit, to je obecný nešvar
> OpenStreetMap, nehomogennost kvality dat. Nicméně těch souvislých oblastí s
> building="yes" by v současnosti mělo být minimum (podrobně viz RÚIAN).
>
>
>
>> Že building:part může být mimo budovu jsem nevěděl. I jsem se tady na to
>> před časem ptal a koukal na wiki. Je to pro mě špatná zpráva, protože v
>> qgisu a SHP souborech relace nezpracuju.
>>
>
> Ano, a mám za to, že jsem v tom smyslu odpovídal. V archivu ale pátrám
> marně.
>
> H.
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Zkratky v názvech ulic (Was: Nedělitelné mezery)

[Mirek Dlask]

A tohle je co?
http://vdp.cuzk.cz/vdp/ruian/ulice/463795

Dne 12. února 2018 22:57 Jan Martinec <j...@martinec.name> napsal(a):

> Ahoj,
> ani RÚIAN nepomůže k jednoznačnosti, naopak: Ivan Petrovič promine, ale
> RÚIAN má náměstí I.P.Pavlova, ÚMČ má náměstí I.P.Pavlova, na cedulích je
> náměstí I.P.Pavlova, v reálu se říká Í Pé Pavlova (ba i metro hlásí
> "I.P.Pavlova" a všechny ostatní mapy mají "náměstí I.P.Pavlova," jakkoli
> ani jedno není pro náš případ úplně relevantní); jenom OSM to ví úplně
> nejsprávněji, na rozdíl od celého zbytku světa, a má celý a úplný jméno,
> "náměstí Ivana Petroviče Pavlova" - sice v jakémsi platónském slova smyslu
> jakoby správně, ale úplně mimo realitu (neboli "OTGR? Jen když se to
> hodí."). Neboli ano, profesor byl Ivan Petrovič Pavlov, ale úplný, celý a
> oficiální název náměstí _obsahuje_ zkratku, ale sám zkratkou  _není_.
>
> TL;DR: jako obvykle - OSM má svět mapovat, tj. popisovat, nikoli
> projektovat, tj. předepisovat - _zejména_ pak má popisovat v místech, kde
> se svět neřídí pravidly (protože ve zcela logickém světě netřeba mapy a
> naopak).
>
> Zdar,
> Honza Piškvor Martinec
>
> Dne 12. 2. 2018 20:44 napsal uživatel "Petr Vozdecký" <v...@seznam.cz>:
>
> Ahoj,
>
> začal bych u toho odkazu, který Majka postovala na wiki: "V OSM by mělo
> být rozepsané celé (nepoužívejte zkratky
> <https://wiki.openstreetmap.org/wiki/Cs:N%C3%A1zvy#Zkracov.C3.A1n.C3.AD_.28ned.C4.9Bjete_to.29>)".
> Článek je totiž zjevně překladem anglického originálu a kapitola s původním
> názvem "Abbreviation (don't do it)" podle mě popisuje to, že mapper nemá
> automaticky používat zkratky tam, kde je vidí na ceduli a má si zjistit
> skutečný celý název.
> Pro diskutované případy s názvy T.G.M. atd. to v českých podmínkách dle
> mého platí asi do té míry, že nelze slepě napsat zkratku názvu ulice jen
> proto, že "kratší je to přehlednější", případně "bylo to na ceduli", ale je
> správné jako název zvolit oficiální název (zde je asi rozhodující názor
> obce, byť jsem tu vícekrát četl, že komunita upřednostňuje data z RÚIAN).
> No a Majka asi vcelku správně vidí jako vhodné doplnit databázi OSM o
> nezkrácené názvy. Otázkou je, které názvy do kterých tagů. Na wiki totiž
> čtu, že name_official je určen pouze pro názvy států...
>
> vop
>
> -- Původní e-mail --
> Od: Jan Dudík <jan.du...@gmail.com>
>
> Komu: OpenStreetMap Czech Republic <talk-cz@openstreetmap.org>
> Datum: 12. 2. 2018 15:32:46
> Předmět: Re: [Talk-cz] Nedělitelné mezery v názvech ulic
>
> Jo, toť otázka.
> https://openstreetmap.cz/#map=18/48.96086/14.47347=d vs.
> https://openstreetmap.cz/#map=18/48.96086/14.47347=x vs.
> https://mapy.cz/s/2okEA a http://www.c-budejovice.cz/n
> azvy-budejovickych-ulic
>
>
>
>
> ---
> Ing. Jan Dudík
> projekce dopravních staveb
> tel. 777082195
>
> Dne 12. února 2018 14:14 Mirek Dlask <dlas...@gmail.com> napsal(a):
>
> Ahoj,
>
> jsem pro 1). Nedělitelné mezery mají více nevýhod, než výhod.
>
>
> Navíc jsem od známé dostal takovou drobnou prosbu, snad se sem hodí.
> 
> 
> _
>
> S hrůzou jsem zjistila, že už nebydlím v ulici T. G. Masaryka. Aniž bych
> se složitě stěhovala, bydlím v ulici Tomáše Garrigue Masaryka.
> Naštěstí se nezbláznilo město, ale pouze mapa, kterou si mi doporučil. Už
> jsem začala vymýšlet, co s dokladama, abych nemusela na úřady.
> .
> Můžeš zjednat nápravu?
> .
> Z tégémasaryka zdraví 
> 
> __
>
> Rád bych odpověděl a nevím co. Je to chyba, nebo schválený, chtěný stav?
> Na wiki jsem našel pouze toto.
>
> Ustálené zkratky
> Nepoužíváme ustálené zkratky "nám.", "ryb.". Způsobují problémy při
> vyhledávání objektu.
>
>
> Ani zmínka o tom, že by se neměly používat zkratky křestních jmen. Něco
> jsem přehlédl?
> Ať se podívám na mapy.cz nebo na google.cz/maps zkratky používají. Jak to
> ti čerchmanti dělají, že nemají "problémy při vyhledávání objektů"?
>
> Mirek
>
> Dne 17. ledna 2018 13:49 Matej Lieskovský <lieskovsky.ma...@gmail.com>
> napsal(a):
>
> Ahoj!
>
> Pomalu pracuju na tom již zmiňovaném systému na polo-automatickou údržbu
> street relací a tak narážím na různé podivnosti v databázi, kterých bych si
> jinak nevšiml. Třeba mě to upozorňuje na to, když jednotlivé segmenty té
> samé ulice mají různé názvy, což chytá i tak

Re: [Talk-cz] Nedělitelné mezery v názvech ulic

[Mirek Dlask]

Díky Majko za odkaz a nakonec i za tu I. P. Pavlova. Vážně jsem za svůj už
poměrně dlouhý život, neslyšel o nikom kdo by místo ípé Pavlova mluvil o
náměstí Ivana Petroviče Pavlova. Nevím co na to cizinec, který přijde
metrem na I. P. Pavlova a naráz se ocitne na náměstí s podivným dlouhým
jménem. Dovolím si tvrdit, že většina evropanů zná lépe slintající psa pana
Palova, než jeho křestní jména.

Dne 12. února 2018 22:47 majka  napsal(a):

> Problém je, že ty ulice se dlouhým názvem nejmenují a žádná zkratka to
> není. Tím dlouhým názvem se na tu ulici nemáte šanci doptat - všichni
> místní budou přemýšlet, o čem to mluvíte.
>
> Je to specifický případ, který by se měl i v datech ukázat, nehledě na
> heslo "rozepisujte zkratky". Nechcete mi snad říct, že je nutné opravit
> třeba tohle
> .
>
> 2018-02-12 22:23 GMT+01:00 Jan Sten Adámek :
>
>> Ahoj,
>>
>> já dávám do name plný název (bez jakýchkoliv zkrácenin, podle Wiki) a do
>> short_name zkrácený tvar, takže to Nominatim najde i podle krátkého tvaru.
>> IMO je to stejné, jako když název v RÚIAN používá „nám.“, „tř.“ nebo
>> „nábř.“.
>>
>> Mapy.cz i Google mají asi nějakou tabulku pro plná jména, která
>> nezobrazují, protože je umí vyhledávat a přitom se nenechají zmást chybnými
>> jmény: „Karla Jaroslava Mašky“ najde K. J. Mašky, Blansko, ale „Karla
>> Jaromíra Mašky“ již ne. Ale vypadá to na (polo-)automaticky generovanou
>> tabulku, protože obsahuje (pro ruční zpracování) očividné chyby: třeba
>> „Jarmily Václava Živcových“ je na Mapy.cz nutné zadat bez „a“ mezi
>> křestními jmény (J. V. Živcových, Rudná), ale opět se nenechá zmást a
>> nenajde „Jaroslavy Václava Živcových“; Google tohle jméno ulice nejspíš
>> nedokázal rozluštit, protože se mi jej nepodařilo najít jinak než zkrácené.
>>
>> official_name by asi také šlo použít, ale to je IMO spíš pro případy, kdy
>> oficiální jméno obsahuje navíc slova, která se běžně v name neuvádí (třeba
>> „Kostel svatého Jiří“ pro name „svatý Jiří“), ne pro rozepisování zkratek.
>> Při editaci OSM jsem již také viděl klíč long_name, ale ten není
>> dokumentovaný ani podporovaný Nominatimem.
>>
>> Sten
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz
>>
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Nedělitelné mezery v názvech ulic

[Mirek Dlask]

Preprocesor nemám, vystačil bych si s převodní tabulkou. Přesvědčil bych
nějakého renderistu, aby si z převodní tabulky udělal  UPDATE . SET
name  FROM .. a posoudil bych, jestli výsledek odpovídá
vynaloženému úsilí. Pokud ano, stejnou cestou bych 'svoji pravdu' šířil dál.

Nevím jak to máš vymyšleno ty. Co když ti do mapy přidám novou odbočku. To
ji chceš "ručně" upravit a přidat do relace?
Obavu mám ještě z něčeho jiného. Jak dlouho to hodláš vydržet a co potom?
V neposlední řadě mi vadí další narušení vazby mezi názvem ulice a názvem
ulice na adresních bodech.
Ale chápu moje řešení je moc jednoduché. Ty potřebuješ naštvat co nejvíc
lidí, udělat okolo co největší humbuk, a nakonec všechno urovnat, aby ses
moh v sívíčku poplácat po ramenou jakej seš pašák.

Dne 12. února 2018 14:33 Matej Lieskovský 
napsal(a):

> Ahoj!
>
>
> Jakou zásadní nevýhodu jsem zatím neslyšel? Máš ten preprocesor?
>
> (Sorry, pokud zním trochu hrubě, spěchám)
>
> Ať se daří,
>
> Matej
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Nedělitelné mezery v názvech ulic

[Mirek Dlask]

Ahoj,

jsem pro 1). Nedělitelné mezery mají více nevýhod, než výhod.


Navíc jsem od známé dostal takovou drobnou prosbu, snad se sem hodí.
_

S hrůzou jsem zjistila, že už nebydlím v ulici T. G. Masaryka. Aniž bych se
složitě stěhovala, bydlím v ulici Tomáše Garrigue Masaryka.
Naštěstí se nezbláznilo město, ale pouze mapa, kterou si mi doporučil. Už
jsem začala vymýšlet, co s dokladama, abych nemusela na úřady.
.
Můžeš zjednat nápravu?
.
Z tégémasaryka zdraví 
__

Rád bych odpověděl a nevím co. Je to chyba, nebo schválený, chtěný stav? Na
wiki jsem našel pouze toto.

Ustálené zkratky
Nepoužíváme ustálené zkratky "nám.", "ryb.". Způsobují problémy při
vyhledávání objektu.


Ani zmínka o tom, že by se neměly používat zkratky křestních jmen. Něco
jsem přehlédl?
Ať se podívám na mapy.cz nebo na google.cz/maps zkratky používají. Jak to
ti čerchmanti dělají, že nemají "problémy při vyhledávání objektů"?

Mirek

Dne 17. ledna 2018 13:49 Matej Lieskovský 
napsal(a):

> Ahoj!
>
> Pomalu pracuju na tom již zmiňovaném systému na polo-automatickou údržbu
> street relací a tak narážím na různé podivnosti v databázi, kterých bych si
> jinak nevšiml. Třeba mě to upozorňuje na to, když jednotlivé segmenty té
> samé ulice mají různé názvy, což chytá i takové prkotiny, jako je
> nedělitelná mezera (nbsp).
>
> Vím, že se tady před rokem vedl flame na téma nedělitelných mezer a k
> žádnému konsenzu to (pokud vím) nevedlo.
>
> Přijde mi rozumné, aby všechny segmenty ulice měly identické name tagy.
> Část důvodu, proč celé tyhle street relace dělám je i snaha o automatickou
> synchronizaci name: tagů napříč všemi segmenty. Když napíšu nbsp do
> tagů relace, tak mi to asi náhodní editoři nerozbijou a jsem ochoten to pak
> opravovat.
>
> Co mám dělat?
>
> 1) Odstraňuj nbsp z názvů ulic
> 2) Tam, kde se vyskytují obě varianty, preferuj tu bez nbsp
> 3) Tam, kde se vyskytují obě varianty, preferuj tu častější
> 4) Tam, kde se vyskytují obě varianty, preferuj tu s nbsp
> 5) Přidávej (ručně) nbsp do názvů ulic
> 6) Celý koncept toho, že se má ulice jmenovat stejně, je špatně
>
> Ať se daří,
> Matej
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Náměstí a třídy

[Mirek Dlask]

*** Správci územní identifikace jsou stavební úřady, které ho vkládají do
ČÚZK RUIAN. Ne OSM, ani ÚJČ. V jednotlivých případech si dokážu představit
řešení problémů zeleného stromu života. Určitě ale ne takto plošným
zásahem, který vzešel z několika zkušeností bez debaty zde.

--- Rozumím tomu dobře, že hromadně je špatně, ale jednotlivě, cíleně a
dlouhodobě nerespektovat oficiální názvy ulic je v pořádku? Pražáci se v
OSM řídí ÚJČ a přitom adresní body jsou dle RUIAN a nikomu to nevadí? Proč
neprosadí změnu oficiálního názvu?

http://tools.geofabrik.de/osmi/?view=addresses=14.55908;
lat=50.0=16=1.00=buildings,
buildings_with_addresses,postal_code,street_not_found,nodes_with_addresses_
interpolated,interpolation,interpolation_errochybně
jsours,nearest_points,nearest_roads


A tak změní ulici Za kovárnou -> Za Kovárnou a adresní body nechají být.
Analogicky se teď změnila  tř -> třída, aniž by se změna dotkla adresních
bodů.
Jaký to má smysl?

Například mapy.cz ponechávají zkratky, ale jinak zdá se, dávají přednost ÚJČ
https://mapy.cz/s/1az3n
před RUIAN
http://vdp.cuzk.cz/vdp/ruian/ulice/483338

Zkratky
https://mapy.cz/s/1FzYx
RUIAN
http://vdp.cuzk.cz/vdp/ruian/ulice/292591

Ale stále platí.
Ulice v adrese = název ulice.

V OSM jsme u adresních bodů dali přednost RUIAN a doufám, že to platí i pro
názvy ulic. Tak proč to mnozí, nejenom v Praze, nerespektují?
Sjednocený název ulice s ulicí na adresním bodu usnadňuje dohledání
nepojmenovaných a chybějících ulic.
Aktuálně převládá chaos.

Možná je to impuls ke změně, nebo alespoň ke zpřesnění pravidel.

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz


___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] 5x červená

[Mirek Dlask]

Ahoj
A do jaké délky lze trasu považovat za krátkou, spojovací ...?

http://www.openstreetmap.org/relation/369235
http://www.openstreetmap.org/relation/941048

Nevím jak před 30 lety, ale v současnosti asi pár výjimek bude.

Mirek

Dne 22. srpna 2016 11:32 Michal Poupa  napsal(a):

> Tak to nevím kým a jak je třeba  to posvětit ale je to tak asi už 30 let
> :-)
>
>
> 22. 8. 2016 v 10:54, Petr Holub :
>
> > Ahoj,
> >
> >> Přednostní volba barev pro značky:
> >>
> >> *  trail_red.svg>  červená –
> >> dálkové nebo hřebenové trasy
> >> *  trail_blue.svg>  modrá –
> >> významnější trasy
> >> *  trail_green.svg>  zelená –
> >> místní trasy
> >> *  trail_yellow.svg>  žlutá –
> >> krátké trasy, spojovací cesty, zkratky
> >
> > ano - toto lze najit i na wikipedii. Ale mas to overene z KCT?
> >
> > Petr
> >
> >
> > ___
> > Talk-cz mailing list
> > Talk-cz@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-cz
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Chybné vs. neexistující rozcestníky

[Mirek Dlask]

Díky,
V Osmand i JOSM otevřeno bez problémů.
 Taky v JOSM nepoužívám, jenom jsem zkoušel, zda není problém jen v Osmandu.

M.D.

Dne 17. července 2016 15:43 Tom Ka  napsal(a):

> Dne 17. července 2016 15:22 Tom Ka  napsal(a):
> >>
> -
> >> Citace z weekly 310:
> >> "... chybné rozcestníky ve formátu GPX například pro použití offline v
> >> programech jako Locus apod."
> >>
> >> Problém je, že soubor neotevře JOSM, ani Osmand. Pro další použití
> >> konvertuju v GPSPrune, což je zbytečná komplikace.
> >> Jako by před
> >> xmlns="http://www.topografix.com/GPX/1/1;
> >> chybělo
> >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> >
> > V JOSM jsem nemel nikdy potrebu otvirat, podivam se na to a min. v
> > OsmAndu vyzkousim a pripadne poupravuju pokud to nejak rozumne pujde.
>
> Doplneno, v JOSM si uz nestezuje, vyzkousej prosim i u sebe.
>
> Bye
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

[Talk-cz] Chybné vs. neexistující rozcestníky

[Mirek Dlask]

Ahoj,
Jak dlouho musí být rozcestník v reálu odstraněn, než může být vymazán z
mapy? Často mají ref a patrně i polohu obšlehnuté od KČT. KČT je tedy
eviduje. Mazat, nebo nechat?
např.
 osmap.cz/node/1373168288 - zrušen v roce 2014
Aktuálně viz https://api.openstreetmap.cz/table/id/8529
osmap.cz/node/4252052450 není minimálně od r. 2011
osmap.cz/node/4252007446 nikdy nebyl
osmap.cz/node/4252007448 nikdy nebyl
osmap.cz/node/4240958023 nikdy nebyl, je to cca 1 rok mladá trasa
osmap.cz/node/418397065 je tam pouze cyklominitabulka, rozcestník
nepamatuju.
osmap.cz/node/4261153960 - odbočka aktuálně nevede na vrchol, ale jen ke
skalnímu převisu bez rozcestníku. Asi nový stav.
Původní provedení je vidět na
https://mapy.cz/turisticka?x=14.7401123=50.6011950=17=0
Je jich ještě víc, ale pro ilustraci snad stačí.
-
Operátor je stále cz:KČT?
https://taginfo.openstreetmap.org/tags/operator=cz:K%C4%8CT

nebo jsem něco přehlédnul?
https://taginfo.openstreetmap.org/tags/operator=K%C4%8CT 3849 krát!
https://taginfo.openstreetmap.org/tags/operator=KCT
https://taginfo.openstreetmap.org/tags/operator=cz:KCT
-
Citace z weekly 310:
"... chybné rozcestníky ve formátu GPX například pro použití offline v
programech jako Locus apod."

Problém je, že soubor neotevře JOSM, ani Osmand. Pro další použití
konvertuju v GPSPrune, což je zbytečná komplikace.
Jako by před
xmlns="http://www.topografix.com/GPX/1/1;
chybělo
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;

M.D.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Zase ty rozcestníky...

[Mirek Dlask]

Ahoj,
na http://map.openstreetmap.cz/work2/ mi jdou.

Dne 17. července 2016 9:28 Jakub Konečný  napsal(a):

> Ahoj,
> vůbec se mi nezobrazují chybné rozcestníky. Ani na rawgitu, ani na
> osmap.cz. Je chyba jen u mě nebo to nejede nikomu? Pohodlně se přes to
> nahrávají fotky, nerad bych se vracel ke starému způsobu z
> old.openstreetmap.cz :)
>
> Kuba
>
> Dne 3. července 2016 21:23 Marián Kyral  napsal(a):
>
>> Ahoj,
>> nevím jak vám, ale mně nefunguje ani přesun rozcestníku a ani editace
>> ref/poznámky. Tam klikám na ta pole a nic se neděje :-(
>>
>> Něco rozbilo? A šlo by to dát do pořádku? :-D
>>
>> Marián
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz
>>
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] traumabody v OSM

[Mirek Dlask]

OK, tak jdu na tom zapracovat. Ty tři bodíky co jsem přidal včera dotaguju
ještě o emergency=access_point.
Zjistil jsem totiž, že Osmand mi je najde, na rozdíl od highway=* .
Navíc je jich v OSM většina  tagovaná oběma způsoby.
Je otázka, jestli nedoplnit emergency i pro další body alespoň v ČR.

Na wiki nemám přístup, protože NAT ...

Dne 6. července 2016 10:57 Karel Volný  napsal(a):

> zdar,
>
> >1. Je to stále "Návrh: Náhrada značky highway=emergency_access_point"
> -
> >viz wiki?
>
> já nevím, jak to aktuálně po formální stránce funguje, přijde mi spíš, že v
> posledních letech nefunguje ... visí to tam dva roky a nic se neděje ...
>
> >2. Proč nemáme ve wiki jednu možnost respektive preferovanou možnost?
>
> protože to tam nikdo nenapsal :-)
>
> >3. Od návrhu (2008) poměr 18556:670 ve prospěch
> >highway=emergency_access_point. Ze 670 jich je drtivá většina v
> Německu.
>
> je hodně pravděpodobné, že osm let staré tagování bude mít více výskytů než
> dva roky starý návrh - pokud se nedospělo k dohodě o hromadné záměně
>
> vzhledem k tomu, jak to (ne)funguje, ono "mávnutí kouzelného proutku",
> kterým
> se to změní, bych neočekával, a tím spíše bych prostě začal používat
> tagování
> nové, a tím v jeho prospěch změnil výše uvedený poměr
>
> pokud bychom se měli řídit jen tím, čeho je víc, co je zavedenější, tak se
> nezmění nikdy nic, to je de facto zdůvodnění kruhem, je toho hodně, tak to
> použijeme, a tím, že to použijeme, toho bude ještě víc, a protože je toho
> víc,
> je důvod to používat atd.
>
> já nejsem příznivcem toho, aby se furt něco předělávalo a dělaly změny jen
> pro
> změny, ba právě naopak, ale v tomto konkrétním případě mi to dává smysl,
> protože 'highway' považuji za principiálně špatně - a v tom původním
> hlasování
> se s tou námitkou nikdo pořádně nevypořádal
>
> jediný argument, co v diskusi padl, je, že by tam měla vést cesta, když
> tam má
> dojet sanitka, a tudíž že je to podobné jako bus_stop, ale to je s
> prominutím
> blbost - jednak tam vůbec cesta být nemusí (proč sanitka, může to být u
> místa
> vhodného k přistání vrtulníku), a jednak bus_stop je skutečně vlastností té
> silnice (má to vliv na dopravu, je tam ostrůvek, záliv, značka, whatever),
> zatímco ten access_point nic takového neimplikuje, je to cedule jako
> kterákoliv jiná (rozcestníky taky tagujeme information=guidepost a ne
> highway=guidepost), případně je u toho ještě něco dalšího jako
>
> > U nás nula. Od jakého počtu se dá tag označit za "slušně zavedený?
>
> mluvil jsem o klíči 'emergency', nikoliv o jeho konkrétní hodnotě
> 'access_point'
>
> všimni si, že se tak taguje spousta užitečných věcí, jako třeba umístění
> veřejných defibrilátorů, záchranné kruhy atp., do čehož ten access_point
> IMO
> krásně zapadá - viz
> http://wiki.openstreetmap.org/wiki/Key:emergency_(facilities)
>
> - mimochodem, je-li řeč o záchranných kruzích, v rámci projektu
> nebezpecnejezy.cz jsou krom záchranných prostředků instalovány i cedule
> obsahující mj. název, říční kilometr a souřadnice, kteréžto pro HZS plní
> přesně tuto funkci ... což je krásný příklad, jak je to 'highway' absolutně
> mimo, neb často jsou umístěny přímo na konstrukci jezu (její pobřežní
> části),
> a ke spoustě jezů žádná cesta nevede
>
> ... a jdu napsat Petrovi jestli nám dá data
>
> > 4. JOSM emergency=access_point nezná.
>
> https://josm.openstreetmap.de/newticket ;-)
>
> > Sečteno podtrženo - záměr dobrý, provedení nic moc.
>
> tož je potřeba na tom provedení zapracovat, že :-)
>
> K.
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Špatná velikost písmen v názvech ulic importovaných z UIR-ADR

[Mirek Dlask]

Ahoj,
už ten nadpis máš špatně. Pro import aktualizaci adres se už dost dlouho
používá RUIAN. http://vdp.cuzk.cz/
Chybějící adresy se sice už řešily, ale jak je vidět nevyřešily. Na vině je
rozpor mezi stavovým výpisem (měsíčně) a aktualizacemi ve výměnném formátu
RUIAN.
Co to je špatná velikost písmen?  http://prirucka.ujc.cas.cz/?id=186 kde se
píše.

PČP jsou závazná pouze pro školní jazykovou výuku. Pro ostatní uživatele
češtiny mají jen formu doporučení. Některé obecní, městské úřady
a magistráty stále setrvávají u staršího způsobu psaní, zejména pokud jde
o předložková spojení (viz bod 2.1
). Starší způsob psaní
často odůvodňují tím, že změna by pro ně byla finančně náročná.

Tedy. Ve škole musíš PČP dodržovat, pokud zasedneš v obecní komisi pro
pojmenování ulic, můžeš se na pravidla vybodnout.

Dne 6. července 2016 9:41 Lukáš Karas  napsal(a):

> Ahoj, možná se toto téma již v listu řešilo, ale žádné vlákno jsem nenašel.
> Případně mě omluvte.
>
> Píšu aplikaci nad knihovnou OSM Scout, při importu Česka jsem si všiml že
> ve
> výsledné databázi chybí mnoho adres. Po dalším zkoumání jsem zjistil že
> hodnota "addr:street" neodpovídá žádné blízké ulici (knihovna se snaží z
> adres
> vytvořit stromovou strukturu, pokud nenajde odkazovanou ulici, náměstí nebo
> sídliště..., adresu nepřidá do databáze). Po dalším zkoumání jsem zjistil
> že
> mnoho adresních bodů má špatnou velikost písmen v tagu "addr:street",
> například v ulici "V Olšinách" je mnoho (96) adres které mají ulici
> uvedenou
> jako "V olšinách".
>
> Hledání ulic jsem v knihovně udělal chytřejší, aby ignorovalo velikost
> písmen.
> Nevím ale jestli její autor přijme merge request. V každém případě si
> myslím
> že data v OSM by měla být opravena. Ale není to na ruční práci, jen v Praze
> jsem našel 10 tisíc záznamů. Je tu někdo by byl schopný napsat automatický
> script? Mohu dodat log z importu kde jsou chyby vypsány...
>
> Lukáš
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] traumabody v OSM

[Mirek Dlask]

Jsem zmaten.
Na jednu stranu uznávám, že emergency=access_point dává smysl ale.

   1. Je to stále "Návrh: Náhrada značky highway=emergency_access_point" -
   viz wiki?
   2. Proč nemáme ve wiki jednu možnost respektive preferovanou možnost?
   3. Od návrhu (2008) poměr 18556:670 ve prospěch
   highway=emergency_access_point. Ze 670 jich je drtivá většina v Německu. U
   nás nula. Od jakého počtu se dá tag označit za "slušně zavedený?
   4. JOSM emergency=access_point nezná.


Sečteno podtrženo - záměr dobrý, provedení nic moc.

Dne 5. července 2016 20:39 Karel Volný  napsal(a):

> zdar,
>
> dovolil bych si upozornit na existenci
> http://wiki.openstreetmap.org/wiki/Tag:emergency=access_point
>
> - osobně mi to přijde lepší, highway nedává smysl (vůbec to nemusí být na
> cestě), a klíč 'emergency' je docela slušně zavedený
>
> K.
>
> Dne Út 5. července 2016 12:51:50, Milan Cerny napsal(a):
> > Zdravím, poslední dobou se zejména na horách vyskytují stále častěji
> > traumabody, podle kterých lze v případě záchranná akce snadno lokalizovat
> > konkrétní místo v terénu. Často jsou součástí rozcestníků, ale jsou i
> > samostatné, na křižovatkách cest. Přijde mi užitečné tyto body zanést do
> > OSM. Otázkou je, jak je tagovat.
> >
> > http://api.openstreetmap.cz/img/guidepost/u_pramene_vltavy_VO422.jpg
> >
> > http://gis.izscr.cz/wpgis/traumabody/
> >
> > ___
> > Talk-cz mailing list
> > Talk-cz@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-cz
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] traumabody v OSM

[Mirek Dlask]

Ahoj,
Našel jsem.
http://wiki.openstreetmap.org/wiki/Cs:Tag:highway%3Demergency_access_point

Přidal jsem tři na Ralsku a nesouhlasí mi souřadnice, tak jsou umístěné
podle fotek.
Například https://www.openstreetmap.org/node/4284074781
má souřadnice 50°32'25" N 14°44'35" E

Dne 5. července 2016 12:51 Milan Cerny  napsal(a):

> Zdravím, poslední dobou se zejména na horách vyskytují stále častěji
> traumabody, podle kterých lze v případě záchranná akce snadno lokalizovat
> konkrétní místo v terénu.
> Často jsou součástí rozcestníků, ale jsou i samostatné, na křižovatkách
> cest.
> Přijde mi užitečné tyto body zanést do OSM. Otázkou je, jak je tagovat.
>
> http://api.openstreetmap.cz/img/guidepost/u_pramene_vltavy_VO422.jpg
>
> http://gis.izscr.cz/wpgis/traumabody/
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Pomocny rozcestnik

[Mirek Dlask]

Situaci u bakovského nádraží považuju za extrém - krátká vzdálenost +
směrovka odbočky mimo hlavní rozcestník. Nevím kolik podobných případů
máme. Nevím jestli je to dostatečný důvod pro zavedení "pomocné směrovky".
Většina neznačených odboček je dlouhá sto a více metrů.
Například: https://www.openstreetmap.org/relation/6086475 a rozcestník tady
patrně nikomu nevadí.
Tuto relaci uvádím umyslně. Protože je to typická odbočka končící
informační tabulkou (ne/rozcestníkem).
http://api.openstreetmap.cz/table/ref/MB035
Tady váhám, zda jde o rozcestník, nebo informační tabuli, nebo ještě něco
jiného - nového.

Mimochodem, tento úsek je hezkou ukázkou toho, proč neobkreslovat ze
seznamáckých map, ani z těch turistických.
https://mapy.cz/turisticka?x=14.9015113=50.4994127=16
vs
http://openstreetmap.cz/#map=17/50.49722/14.90410=kKG

Mirek

Dne 4. dubna 2016 14:55 Petr Vozdecký <v...@seznam.cz> napsal(a):

> (z drivejsi diskuse cilene odbocuji samostatne tema)
>
> Mirku,
>
> Tvoje poznamka otevrela pripadnou diskusi ke specifickemu "problemu" - v
> terenu se nachazi dost "pomocnych smerovek", presne jako ve tvem pripade u
> nadrazi Bakov nad Jizerou
> http://openstreetmap.cz/#map=20/50.47161/14.92327=kKG
> V uvedenem pripade je pred budovou nadrazi pomocna smerovka "K vychodisti
> turistickych tras 50 m ->" (bez uvedeni barvy a bez znaceni v terenu). O
> tech  50 m dale je "klasicky" rozcestnik a dle mapy nekde vedle (coz je s
> podivem, cekal bych to na rozcestniku) je sipka "<- Bakov n. J. (nadrazi)
> 50 m".
> Pokud je mapovani presne dle faktickeho stavu v terenu, jsou na 100m 3
> "rozcestniky", z toho ale dva "pomocne", ktere nemaji v terenu zadnou
> znacku. Nabizi se tedy otazka, zda tyto "pomocne" rozcestniky netagovat
> zvlastni znackou pro to, aby napr. mohly byt vykreslovany odlisnym zpusobem
> (jina/mensi znacka, jen pri vetsim priblizeni apod.). Mj. prave proto, ze
> vlastne nejde o rozcestniky...
>
> vop
>
> BTW: Diky za skladane fotografie (kdyz neni mozne dostat cely rozcestnik
> do 1 snimku, je to lepsi nez "x" snimku), viz nedaleky MB192 Bakov nad
> Jizerou, Podhradi
>
> -- Původní zpráva --
>
> Od: Mirek Dlask <dlas...@gmail.com>
> Komu: OpenStreetMap Czech Republic <talk-cz@openstreetmap.org>
> Datum: 3. 4. 2016 19:35:21
> Předmět: Re: [Talk-cz] Podivny rozcestnik
>
> Ahoj,
> vyloučím-li možnost hodit si korunou, můžeš se podívat u turistů.
> http://trasy.kct.cz/
> Nevím jestli to není vykrádání ...
> Proto se řídím pravidlem, že platí novější.
>
> Osobně dávám každý rozcestník samostatně a zůstává tam pokud to někdo
> nezmění.
> Například
> http://openstreetmap.cz/#map=17/50.47047/14.92050=kKG
>
> Mirek
>
> Dne 3. dubna 2016 19:07 Miroslav Suchý <miros...@suchy.cz> napsal(a):
>
> Dneska jsem odlovil podivny rozcestnik.
>   http://map.openstreetmap.cz/img/guidepost/20160402_111445_HDR-1.jpg
> By me zajimalo co mam napsat do ref= ?
>
> Zda se SY009 je rozcestnik co je o 300m dal a SY033 vznikl nedavno a
> nektere cedulky presunuli ze SY009.
>   http://map.openstreetmap.cz/img/guidepost/20160402_112032-1.jpg
> Navic druha cast toho rozcestniku SY033
>   http://map.openstreetmap.cz/img/guidepost/20160402_111427-1.jpg
> (na ceduli uvedeno stare SY009)
> Obe ty smerovky jsou sice vedene jako jeden, ale kazda je na jine strane
> silnice a je mezi nimi tak 15 metru.
>
> Takze krome toho ref= by mne zajimalo jestli je mam zakreslit jako jeden
> rozcestnik (kde?) nebo jako dva rozcestniky.
>
>
> Cela situace je zde:
> http://openstreetmap.cz/#map=18/49.71122/16.11914=kKG
>
> Mirek
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Podivny rozcestnik

[Mirek Dlask]

Ahoj,
vyloučím-li možnost hodit si korunou, můžeš se podívat u turistů.
http://trasy.kct.cz/
Nevím jestli to není vykrádání ...
Proto se řídím pravidlem, že platí novější.

Osobně dávám každý rozcestník samostatně a zůstává tam pokud to někdo
nezmění.
Například
http://openstreetmap.cz/#map=17/50.47047/14.92050=kKG

Mirek

Dne 3. dubna 2016 19:07 Miroslav Suchý  napsal(a):

> Dneska jsem odlovil podivny rozcestnik.
>   http://map.openstreetmap.cz/img/guidepost/20160402_111445_HDR-1.jpg
> By me zajimalo co mam napsat do ref= ?
>
> Zda se SY009 je rozcestnik co je o 300m dal a SY033 vznikl nedavno a
> nektere cedulky presunuli ze SY009.
>   http://map.openstreetmap.cz/img/guidepost/20160402_112032-1.jpg
> Navic druha cast toho rozcestniku SY033
>   http://map.openstreetmap.cz/img/guidepost/20160402_111427-1.jpg
> (na ceduli uvedeno stare SY009)
> Obe ty smerovky jsou sice vedene jako jeden, ale kazda je na jine strane
> silnice a je mezi nimi tak 15 metru.
>
> Takze krome toho ref= by mne zajimalo jestli je mam zakreslit jako jeden
> rozcestnik (kde?) nebo jako dva rozcestniky.
>
>
> Cela situace je zde:
> http://openstreetmap.cz/#map=18/49.71122/16.11914=kKG
>
> Mirek
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] RUIAN - příliš mnoho podlaží (aneb Utajený Manhattan)

[Mirek Dlask]

Ahoj,
reklamační formuláře jsou zde.
http://reklamace.cuzk.cz/formular/index.php
Nezkoumal jsem to, ale zdá se,že zrovna počet podlaží se reklamovat nedá.

Dne 26. února 2016 14:27 Jan Martinec  napsal(a):

> Ahoj,
>
> celkem náhodou jsem v mapě našel tuhle skupinu mrakodrapů v Praze na
> Košíku:
> http://osmbuildings.org/?lat=50.04562=14.51788=16.2=0=30
> - podle dat nejvyšší budovy v ČR.
> Pohledem do RÚIANu je evidentní, co je špatně - 9 podlaží krát 8 vchodů
> vedle sebe je 72 podlaží nad sebou :D
>
> Z Overpassu Turbo mi vylezla celkem slušná hromada takových mrakodrapů, a
> drtivá většina je v Praze:
>
> [out:json][timeout:25];
> // gather results
> (
>  // 20-99
>  way["building:levels"~"^[3456789][0-9]$"]({{bbox}});
> );
> // print results
> out body;
> >;
> out skel qt;
>
> Něco jsem nahlásil na ruian.poloha.net , ale zdá se mi, že tohle není
> překlep - že to bude nějaká chyba v algoritmu při zadávání nových staveb (s
> více vchody - všechno jsou to novostavby v posledních cca pěti letech) do
> RÚIANu: že to dopočítá podlaží součtem všech podlaží u vchodů. Kam
> reportovat takový problém, věděl by někdo?
>
> (A ještě detail: mám ruian.poloha.net zmínit ve wiki na Cs:RUIAN/chyby
> ?Teď to vypadá, že se mají reportovat tam, o poloze.net vím jen z talk-cz)
>
> Mějte se,
> Honza Piškvor Martinec
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Tracer LPIS - drobne relikty puvodnich drivev ymapovanych poli a luk po pretrasovani podle LPIS

[Mirek Dlask]

Ahoj,

při pohledu na některé moravské vinice tě chápu.
http://www.openstreetmap.org/#map=16/48.8652/16.9001

Navíc
- ruční aktualizace natrasovaných území může být někde problém
- nevím k čemu jsou ref, která se i po drobné změně polygonu mění
- problémem jsou i překrývající se plochy
https://www.openstreetmap.org/way/334303196#map=17/48.86319/16.90110

Přesto bych nikoho neomezoval.

Mirek
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Tagování škol

[Mirek Dlask]

Zdravím všechny OSMáky, ale i žáky jiných ročníků ;-)
Nevidím žádný důvod pro uvádění adresy školy v jejím názvu. Pokud znám,
hledám adresu, pokud ji neznám adresa v názvu mi nepomůže.

Název školy je v rozporu s pravidly pravopisu.
*Vyšší odborná škola, Obchodní akademie, Střední odborná škola a Jazyková
škola ...*
*by se správně měla jmenovat*
*Vyšší odborná škola, obchodní akademie, střední odborná škola a jazyková
škola ...*
viz http://prirucka.ujc.cas.cz/?id=188#nadpis16  (6.1.2)

Nebylo by od věci přidat nejen ke každé škole ještě
name:dle_pravidel_ceskeho_pravopisu
Protože se opět najde editor ignorující oficiální název a bude trvat na
názvu spravne_cesky_podle pravidel_ceskeho_pravopisu.

Nějakou zkušenost s tím už mám.  Ustoupil jsem, i když to za moudré
nepovažuji.
Zájemce odkazuji na historii jedné ulice.
http://www.openstreetmap.org/way/31066551#map=19/50.18789/14.66445

Editor neargumentuje oficiálním názvem, ale oficiálním pravopisem :-) .

REDIZO, nebo IZO?
Jestli dobře vidím RED IZO je identifikátor školy jako právnické osoby.
IZO je identifikátor školského zařízení (škola, družina, jídelna).
Asi bych dal přednost IZO, pro případ, že se někdo rozhodne oddělit družinu
od školy.
Na wiki je pouze ref a nevím proč vymýšlet něco jiného.
http://wiki.openstreetmap.org/wiki/Tag:amenity=school

   - ref <http://wiki.openstreetmap.org/wiki/Key:ref>=*, if schools are
   numbered


Přidám otázky.
1) Např. gymnázium a základní škola v jedné budově, v jednom areálu.
Otagovat areál jako amenity=school
budovu building=school
bod pro ZŠ (amenity=school)
bod pro gympl (amenity=college)
?

2) Máme nějakou možnost jak otagovat školní jídelnu? Ne každá škola jídelnu
má.

Perlička.
Osmand mi amenity=college najde jako "Kolej". Chyba v překladu?

Mirek Dlask

Dne 26. října 2015 22:37 Jiří Nováček <gfresh...@gmail.com> napsal(a):

> Zdravím konferenci, vím že teď frčí spíše turistické trasy :) , ale mám
> dva dotazy ohledně tagování českých škol:
>
> * Název školy - domnívám se, že do mapy patří oficiální "úřední" název
> školy. Některé názvy jsou dosti šílené, namátkou příklad:
> *Vyšší odborná škola, Obchodní akademie, Střední odborná škola a Jazyková
> škola s právem státní jazykové zkoušky EKONOM, o.p.s., Litoměřice,
> Palackého 730/1*
> kdy toto celé je (podle mě jediný správný) název školy, včetně té ulice a
> města. Někdy se (např. v "konkurenčních" mapách) objevují různé zkrácené
> názvy ve stylu "SPŠE a VOŠ", nenašel jsem ale žádnou důvěryhodnou informaci
> o tom, že by takovéto zkrácení bylo také platným označením školy. Například
> v rejstříku škol a školských zařízení <http://rejskol.msmt.cz/> MŠMT nebo
> na webu České školní inspekce <https://portal.csicr.cz/School/600010767>
> u škol žádná zkracená verze názvu uvedena není.
> Proč se na to vlastně ptám - takto dlouhý název vypadá na renderu někdy
> dost šíleně, ale pokud vím, tak je pro nás mnohem důležitější správnost
> samotných dat, než grafická podoba libovolného renderu OSM dat. Asi by šlo
> do tagu "name" dávat zkrácenou verzi a do nějakého jiného tagu dávat platný
> úřední název, ale to je podle mě přesně to ohýbání dat pro potřeby
> vizualizace, ke kterému by nemělo docházet. Myslím si to správně?
>
> * Školy mají přiděleno tzv. REDIZO <http://www.zkratky.cz/REDIZO/16611>,
> což by měl být unikátní identifikátor školy, mohu použít tag ve stylu
> ref:redizo = 123456 ?
>
> Za případné názory předem děkuji
> Jirka Nováček
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] ortofoto v JOSM

[Mirek Dlask]

Ahoj,

špatně je toto.
=={proj(EPSG:4326)}


Není důvod tam mít projekci natvrdo.
Buď tu část změň na

=={proj}

nebo si vytvoř novou vrstvu
http://geoportal.cuzk.cz/WMS_ORTOFOTO_PUB/service.svc/get?

Na neprůhledné vrstvy nechávám formát obrázků image/jpeg. Png je možná
trošku ostřejší, ale na plochách má nepěkný tečky (možná jenom u mě na
Ubuntu).

M.D.

2015-08-31 18:48 GMT+02:00 Zdeněk Pražák :

> Dobrý den
> používal jsem pro kontrolu rybníků a potoků v josm ortofoto na
> následujícím url :
>
> wms:
> http://geoportal.cuzk.cz/WMS_ORTOFOTO_PUB/service.svc/get?FORMAT=image/png=1.1.1=WMS=GetMap=GR_ORTFOTORGB=={proj(EPSG:4326)}={width}={height}={bbox}=null=1.1.1=WMS=GetMap==={proj}={width}={height}={bbox}
>
> nyní jsem si aktualizoval JOSM na verzi 8694 a když si chci jako
> podkladovou vrstvu zobrazit ortofoto tak se mi objeví hláška, že
> {proj(EPSG:4326)} není platný argument WMS, zkontrolujte url
>
> Co je špatně
> Pražák
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Ortofoto Re: Je možno kopírovat z jiných map?

[Mirek Dlask]

Používám barevnou ortofotomapu jako ověřovací zdroj.
http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/freemap#Ov.C4.9B.C5.99ovac.C3.AD_zdroje

Zatím nikdo neřekl (nenapsal), že je to licenčně, právně plnohodnotná
náhrada černobílé ortofotomapy.

Příklady použití té barevné ověřovací:
Např. chci natrasovat budovy v části obce Pusté Žibřidovice.
První na co narazím je silnice procházející skrz domy např. čp. 46 a 58.
http://www.openstreetmap.org/node/332525687#map=19/50.08680/16.97840
Z ortofota je zřejmé, že chyba je v OSM. Data z RUIAN se kryjí s
ortofotomapou.

Nic mi nebrání silnici opravit podle vrstvy s katastrální mapou -
http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/freemap#WMS_.C4.8C.C3.9AZK_-_katastr.C3.A1ln.C3.AD_mapa


Na druhý pohled nacházím budovy, které patrně již neexistují a které podle
míry destrukce buď ignoruji, nebo trasuji a měním na building=ruins.

Pak jsou budovy o jejichž tvaru, či poloze mám pochybnosti. Např.:
http://www.openstreetmap.org/node/840081158
Co když obtáhnu tvar budovy? Ignoruji tvar střechy, dokonce i komín.
Poruším nějakou licenci, nařízení, zákon?

Bohužel v RUIAN jsou budovy reprezentovány jen definičním bodem.
Tvar budovy chybí, takže například babička z Pustých Žibřidovic si nemůže
ověřit, zda je její chaloupka  v katastrální mapě správně zanesena.
Tvar budovy v tomto případě neodpovídá  ani tvaru parcely
http://vdp.cuzk.cz/vdp/ruian/parcely/1425326809.
A tvaru parcely neodpovídá ani budova podle ortofotomapy.


Podobně. Pokud si tužkou naskicuji ženskou postavu z proslulé malby
proviním se něčím? Vzhledem k mému umění nakreslím postavičku hodící max.
na dveře dámského WC.

Nevím jestli  někdo dokáže v nedokonalém obrysu postavy/budovy najít zdroj
inspirace/informace.
Kde je hranice mezi dovoleným a zakázaným?

Jiný příklad použití.
Cesta o které vím, že prochází mezi loukou a polem, přesto v OSM místy
zasahuje do lpis pole, či lpis louky. Předpokládám, že mi nic nebrání v
ověření na ortofotomapě a opravě cesty.

Podobně hranice lpis pole a uhul lesa. Z ortofomapy si ověřím, že les je až
k poli a můžu jeho hranice posunout.
Ale co když je tam něco dalšího? Můžu mezi pole a les vložit pruh louky,
křoví ...?
Stále nevím, kde je hranice mezi tím, co smím a tím, co je zakázáno.

Všechny WMS služby poskytované ČÚZK mají stejné podmínky užití. Katastrální
mapu smíme používat (obkreslovat), zatímco ortofotomapa je pouze ověřovací
zdroj?

http://geoportal.cuzk.cz/(S(bthhcyy5do50tnklvyt0jwux))/Default.aspx?mode=TextMetaside=wms.verejnetext=WMS.verejne.uvodhead_tab=sekce-03-gpmenu=311

M.D.


Dne 1. července 2015 11:57 Pavel Machek pa...@ucw.cz napsal(a):

 On Fri 2015-06-26 06:16:09, Jachym Cepicky wrote:
  cenia imho neni uredni dilo a pokud si pamatuju, mame explicitni
 nesouhlas
  s pouzivanim ortofota z cenie jako podklad pro kresleni, pouze pro
 vizualni
  kontrolu.

 Tak ja nevim jestli je to cenia, stary cernobily ortofoto, pokryva
 celou republiku, ve slusnym rozliseni, bylo chvili na openaerial
 map, dovoleni jsme meli. Funguje nekomu? Pripadne.. co pouzivate?

 Pavel

 --
 (english) http://www.livejournal.com/~pavelmachek
 (cesky, pictures)
 http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-cz

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] DIBAVOD - Re: LPIS - objem dat, zjednodušení kontur

[Mirek Dlask]

Ahoj,

na ověření třeba vrstva s vodou
wms:
http://geoportal.cuzk.cz/WMS_ZABAGED_PUB/service.svc/get?FORMAT=image/pngtransparent=TRUEVERSION=1.1.1SERVICE=WMSREQUEST=GetMapLAYERS=GL_BH140A,GL_BH140B,GP_NF120,GL_BI020A,GL_BI020B,GL_BI030,GB_BB005,GL_BH010A,GL_BH010B,GP_BH095,GB_BH180,GL_BH180,GB_BH170A,GB_BH170B,GB_BH170C,GL_BH142STYLES=SRS={proj}WIDTH={width}HEIGHT={height}BBOX={bbox}

Nic aktuálnějšího, nekomerčního asi není.

M.

Dne 28. června 2015 9:20 Marián Kyral mky...@email.cz napsal(a):

  Ahoj,
 tak jsem narazil na další vyschlý rybník z dibavodu:
 http://www.openstreetmap.org/#map=19/49.75718/18.33327

 Na ortofoto CUZK i seznamu žádný rybník není. Je tam spíše pole nebo
 louka:
 http://www.mapy.cz/zakladni?x=18.3330048y=49.7572035z=18base=ophoto

 Chtělo by to nějakou aktuální a funkční DIBAVOD WMS. Nemáte něco? Případně
 nějaký jiný nápad?

 Marián

 Dne 3.6.2015 v 08:12 Marián Kyral napsal(a):


 -- Původní zpráva --
 Od: Marián Kyral mky...@email.cz mky...@email.cz
 Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org
 talk-cz@openstreetmap.org
 Datum: 3. 6. 2015 7:09:40
 Předmět: [Talk-cz] DIBAVOD - Re: LPIS - objem dat, zjednodušení kontur


 -- Původní zpráva --
 Od: Petr Vejsada o...@propsychology.cz o...@propsychology.cz
 Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org
 talk-cz@openstreetmap.org
 Datum: 2. 6. 2015 19:33:00
 Předmět: Re: [Talk-cz] LPIS - objem dat, zjednodušení kontur

 Ahoj,

 Dne Út 2. června 2015 19:07:56, Marián Kyral napsal(a):

  Dočistit data po importu LPIS, DIBAVOD, RUIAN (upravit navazující
 plochy,
  přidat cesty...), dodělat vesnice a městečka (landuse, POI), vrhnout se
 na
  MHD, vyčistit hlášení Osmose, Keep right...

 jasně jasně, jen, myslím, narážíme na nedostatek zdrojů. Praha zveřejnila
 cca
 300 záchodů s otevírací dobou, cenou a wheelchair, tak to by se dalo
 dohrát,
 dále přesné chodníky, ale to asi není potřeba importovat.

 S těmi zdroji - asi se pomalu dostáváme do stavu, že místní znalost a
 vlastní
 oči bude jedním z mála použitelných zdrojů. Ani ortofoto leckde
 neodpovídá, je
 zastaralé.

 Třeba toto: http://ruian.poloha.net/17/50.17475/12.38610

 v OSM je voda, na fotce je kdovíco, na landuse z parcel žádná voda není.
 Je
 potřeba to vidět. Není to jediné místo, které ukazuje vodu jen na mapě v
 OSM.
 Na druhé takové místo si teď už neumím vzpomenout, kde to bylo. Bylo to
 podobné, také lom či co a zmizelá voda. Nebo naopak, lom je zlikvidován a
 nově
 je voda ... nevím, to je to.


  Letecké mapy od Seznamu a satelitní mapy Bingu tam vodu mají. A s
 ohledem na charakter terénu, stačí, když trochu více zaprší a zase tam bude
 kaluž :-D


  A jak tak koukám, tato voda byla naimportována z DIBAVODu. Bylo by dobré
 v DIBAVODu ověřit aktuální status. Nevíte někdo, zda je někde dostupný
 online náhled? Tak aby se z toho dal udělat doplněk do PointInfa.


  Našel jsem: http://www.dibavod.cz/ , ale stahovat shapefile a řešit jeho
 zpracování se mi moc nechce. Následně jsem našel:
 http://heis.vuv.cz/data/spusteni/pgstart.asp?pg=EVIDENCE$Obecne$PripojeniDatOnlinepgload=1ico=icoopenwms.pngnadpis1=Stav%20vodn%EDch%20%FAtvar%F9nadpis2=WMS%20slu%9Ebypagenavig=%DAvodn%ED%20str%E1nka%20%20%3E%20%20Datab%E1ze%20%20%3E%20%20Mapy%20a%20data%20%20%3E%20%20ISVS%20-%20VODA%20%20%3EStav%20vodn%EDch%20%FAtvar%F9%20%3E%20WMS%20slu%9Eby%20%3E%20


  Přes toto jsem se dále doklikal k mapě s vyhledáváním, kde jsem zadal
 dibavod:id: 113010250007. No a nevrátilo mi to nic. Takže je dost možné, že
 nádrž je opravdu zrušena.


  No tak asi nic. Data ke stažení jsou z roku 2010 a z WMS jsem zatím
 dostal jen prázdný obrázek s copyrightem :-(

 Marián


 ___
 Talk-cz mailing 
 listTalk-cz@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-cz



 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-cz


___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Osmose Česká republika

[Mirek Dlask]

Nedávno jsem našel toto

http://geoportal.cuzk.cz/(S(edrn34aqju5rgehhxpqqot5a))/Default.aspx?mode=TextMetaside=wms.verejnemetadataID=CZ-CUZK-WMS-ZABAGED-PmetadataXSL=metadata.sluzbamenu=3113

Mám problém. Nemám Nastavení mapy ani Předvolby značení

Není to nějakej plugin (JOSM)

Mirek

Dne 8. prosince 2014 19:27 Marián Kyral mky...@email.cz napsal(a):

  Dne 8.12.2014 18:23, Mirek Dlask napsal(a):

 Ahoj,

  6136  5323 level 3  :-)
 Příčina? Opravuju chyby po Vás a nikdo neopravuje moje chyby.


 To víš. Nemůžeme všichni dělat všechno ;-)

  Takže můžete začít ... třeba

  Cesta protínající vodu
 Duplikované hodnoty source=uhul:ortofoto; cuzk:km; uhul:ortofoto
 Multiple numbers 34 in way Profesora Františka Vojtíška - je to node
 klasická adresa housen a conscriptionn...

  Way node tagged like way - někde  jsem okoukal kombinaci  tunnel=culvert
 + waterway=stream. Jednoduché a levné. A najednou je to špatně.  Přitom v
 ZABAGED jsou propustky nejen liniové, ale i bodové, někde jsou mosty. Já
 většinou používal bod.


 On ten propustek vždy má nějakou reálnou délku. Takže bod asi moc dobře
 není.

 Já na to zatím moc nekoukal, ale co mne praštilo do očí. je použití noexit
 - Já myslel, že to je klasická slepá ulice, ale dle definice na wiki, stačí
 aby dál pokračoval chodník a už se noexit používat nemá. No tak si to zase
 všechno pěkně smažu :-(

  Jak je to vůbec s použitím WMS vrstev ZABAGED ?

  http://geoportal.cuzk.cz/WMS_ZABAGED_PUB/service.svc/get?


 Vůbec netuším, o tomhle zdroji jsem nevěděl.


 Postavit propustek v JOSM je docela šichta. Většinou je nutné si vyrobit
 body a pak teprve krájet. A otagovat.


 Nastavení mapy / Předvolby značení a přidat One click settings.



 Trochu ulehčí tagování.

 Marián

  Navíc na mnoha místech je v reálu voda pod městem, v OSM ji rozstřikují
 projíždějící auta.
 Teď mám staženou oblast kde je 516 křížení cesty a vody.  Jdu rychle
 opravovat, ať máte míň chyb než já ;-)

  Mirek

 Dne 8. prosince 2014 17:15 Marián Kyral mky...@email.cz napsal(a):

  Dne 8.12.2014 09:10, Kasparek Tomas napsal(a):

  -- Původní zpráva --
 Od: Marián Kyral mky...@email.cz mky...@email.cz
 Škoda, myslel jsem, ze uděláme soutěž, ale píše mi to jen: Vice než 500 :-)

  kdo ma min nebo kdo vic :-D ?


 Kdo nic nedělá, nic nezkazí, že? ;-)

 Ale mohl by to být poměr počet změněných objektů vs. počet chyb. ;-)

  Bye




 ___
 Talk-cz mailing 
 listTalk-cz@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-cz



 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-cz




 ___
 Talk-cz mailing 
 listTalk-cz@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-cz



 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-cz


___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Osmose Česká republika

[Mirek Dlask]

Tak pro pomalejší než jsem já je
Nastavení mapy / Předvolby značení a přidat One click settings.
Upravit - Nastavení...- třetí ikona shora

Díky
Mirek

Dne 8. prosince 2014 19:27 Marián Kyral mky...@email.cz napsal(a):

  Dne 8.12.2014 18:23, Mirek Dlask napsal(a):

 Ahoj,

  6136  5323 level 3  :-)
 Příčina? Opravuju chyby po Vás a nikdo neopravuje moje chyby.


 To víš. Nemůžeme všichni dělat všechno ;-)

  Takže můžete začít ... třeba

  Cesta protínající vodu
 Duplikované hodnoty source=uhul:ortofoto; cuzk:km; uhul:ortofoto
 Multiple numbers 34 in way Profesora Františka Vojtíška - je to node
 klasická adresa housen a conscriptionn...

  Way node tagged like way - někde  jsem okoukal kombinaci  tunnel=culvert
 + waterway=stream. Jednoduché a levné. A najednou je to špatně.  Přitom v
 ZABAGED jsou propustky nejen liniové, ale i bodové, někde jsou mosty. Já
 většinou používal bod.


 On ten propustek vždy má nějakou reálnou délku. Takže bod asi moc dobře
 není.

 Já na to zatím moc nekoukal, ale co mne praštilo do očí. je použití noexit
 - Já myslel, že to je klasická slepá ulice, ale dle definice na wiki, stačí
 aby dál pokračoval chodník a už se noexit používat nemá. No tak si to zase
 všechno pěkně smažu :-(

  Jak je to vůbec s použitím WMS vrstev ZABAGED ?

  http://geoportal.cuzk.cz/WMS_ZABAGED_PUB/service.svc/get?


 Vůbec netuším, o tomhle zdroji jsem nevěděl.


 Postavit propustek v JOSM je docela šichta. Většinou je nutné si vyrobit
 body a pak teprve krájet. A otagovat.


 Nastavení mapy / Předvolby značení a přidat One click settings.



 Trochu ulehčí tagování.

 Marián

  Navíc na mnoha místech je v reálu voda pod městem, v OSM ji rozstřikují
 projíždějící auta.
 Teď mám staženou oblast kde je 516 křížení cesty a vody.  Jdu rychle
 opravovat, ať máte míň chyb než já ;-)

  Mirek

 Dne 8. prosince 2014 17:15 Marián Kyral mky...@email.cz napsal(a):

  Dne 8.12.2014 09:10, Kasparek Tomas napsal(a):

  -- Původní zpráva --
 Od: Marián Kyral mky...@email.cz mky...@email.cz
 Škoda, myslel jsem, ze uděláme soutěž, ale píše mi to jen: Vice než 500 :-)

  kdo ma min nebo kdo vic :-D ?


 Kdo nic nedělá, nic nezkazí, že? ;-)

 Ale mohl by to být poměr počet změněných objektů vs. počet chyb. ;-)

  Bye




 ___
 Talk-cz mailing 
 listTalk-cz@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-cz



 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-cz




 ___
 Talk-cz mailing 
 listTalk-cz@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-cz



 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-cz


___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] opět problém placeholder

[Mirek Dlask]

Ahoj,

Pokud budeš vydávat novou verzi pamatuj, že v modulu RUIAN je u stavebních
objektů start_date = dokonceni a není to plati_od.
Testing 30416

Mirek

Dne 14. září 2014 21:06 Marián Kyral mky...@email.cz napsal(a):

  Ahoj,
 posledně jsem si danou oblast natáhl do JOSM a chybějící pole jsem
 naklikal znova. Většina bodů se použila znova, ty ostatní jsem pomocí
 validátoru smazal.

 Dle všeho klikáš moc rychle a máš pomalejší počítač, takže se ti podaří
 vyvolat dvě tracer vlákna a ty si ta data navzájem přepisují. Nicméně snad
 se to brzo podaří vyřešit. Martin Švec mi poslal vylepšenou verzi Traceru,
 která tento problém řeší. Jen co otestuji, uvolním. Doufám, že co nejdříve.

 Marián

 Dne 14.9.2014 19:35, Zdeněk Pražák napsal(a):

 nahrával jsem dnes další pole v okolí chocně - před nahrátím jsem je
 kontroloval validátorem a ten mi nic nehlásil
 při nahrávání se mi však objevila hláška placeholder node not found for
 reference -55613 in way -7

 Zbývá nenahrátých 680 nodů

 co s tím mám dělat


 ___
 Talk-cz mailing 
 listTalk-cz@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-cz



 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-cz


___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Hlášení chyb RUIAN přímo z JOSM

[Mirek Dlask]

Ahoj,
co víme?
Katastrální mapa je právní stav. Stav před změnou čísla, ulice, části obce
...
ZABAGED je stav, který se blíží skutečnosti a nenajdete tam např. Jevany
ev.5020 (stav před přečíslováním, tak jak je v KM) . Ale v ZABAGED najdete
Jevany ev.20.
Kdo má data, může si porovnat Jevany čev 1-5001, 6-5006, 14-5014 . Co
mají tyto dvojice společné?. Ano  jsou zcela bez geometrie. Tedy? Zanikly
ještě před přečíslováním.
RUIAN včetně Marushky obsahují vše.

Technicky jsou všechna data v jedné databázi.
Právní stav (KM) obsahuje vždy jak geometrii SO tak geometrii definičního
bodu SO. Naopak nemá geometrii definičního bodu AM. Číslo se zobrazuje na
souřadnicích geometrie SO.
Naopak reálný SO neobsahuje geometrii SO, má  geometrii definičního bodu SO
a má geometrii definičního bodu AM.
Všechno je to zabaleno do obalu dalších chyb, neúplných dat a zmatků.
Dají se nalézt řetězce chyb. Kdo hledá najde ...

Takže, milá komunito. Je načase přestat obkreslovat KM a kdo má čas, ať ho
raději věnuje probíhajícímu importu.
Samozřejmě bude nutné se nějak vypořádat s neexistujícími AM, které jsme si
do OSM zavlekli obkreslováním KM, ale i následnými importy. Včetně těch
mých.

Zdraví Mirek


Dne 1. května 2014 10:45 Petr Vejsada o...@propsychology.cz napsal(a):

 Ahoj,

 Dne St 30. dubna 2014 23:43:22, Marián Kyral napsal(a):

   2) Chyby strojově nedohledatelné - (dvůr jako budova, nekompletní
   budova, chybějící budova...)

 Chybějící budova nemusí být chyba. V katastru jsou jen budovy v katastru
 evidované a je-li v terénu reálně budova, která není evidovaná v katastru,
 tak
 v něm prostě není a být nemá . není to chyba. Měli bychom dávat pozor,
 abychom nehlásili chyby, které chybami nejsou.

   Zaroven by ale bylo dobry, kdyby to fungovalo i zpatky = pokud nekde
   nareportuju chybejici geometrii, tak v okamziku, kdy se v RUIAN
   pripadne objevi, by se mela rovnou prenyst do osm (a bug by mel
 zmizet).
 
  Tak tenhle nápad se mi líbí. Všechna hlášení by se shromažďovala v
  nějaké lokálním systému na hlášení chyb a buď by se jednou za čas
  vygeneroval a poslal email s nejnovějšími chybami, nebo by sis mohl
  report stáhnout sám. Nicméně, to automatické uzavírání chyb bude
  fungovat jen pro první typ. Jak ve skriptu zjistíš, že opravená
  geometrie je správná? Spíše bych to viděl na možnost stáhnout si
  předpřipravený soubor pro JOSM a v něm to pak zkontrolovat a nahrát do
 JOSM.

 Umím zjistit, kdy se v RUIAN něco změnilo, tedy přesněji - vím datum, kdy
 jsem
 si nahrál změnu do databáze. Změny z RUIAN nahrávám téměř každý den. Proč
 k té
 změně došlo, to už nevím, tedy neumím poznat, zda jde o opravu chyby nebo
 skutečnou změnu situace.

 
  V každém případě by bylo fajn, kdyby se nám nejprve podařilo zbavit se
  chyb systematicky vznikajících. Někde musí být nějaká chyba. Těch duchů
  sdílejících pozici s jinou budovou je podezřele moc.

 Moje tušení, že v RUIAN jsou historická data, se začíná blížit jistotě. To
 je
 tak - v OSM je aktuální adresní místo. Třeba teď co mám rozdělané - Praha
 Dubeč, Na hádku 1613. To je v OSM i v RUIAN, RUIAN ID 25102664 a patří k
 normální budově s geometrií. A chce se mi nově přidat Na hádku 613 (opět to
 oblíbené přičítání násobku 1000), RUIAN ID 30721369 a patří k duchovi.

 Prostě někde jim vypadlo z kódu 'where not deleted' nebo nějaká taková
 blbost,
 která má ovšem dost závažné důsledky. Možná je to tak velký průšvih, že teď
 nevědí, co s tím, aby nepadaly hlavy ... Tihle duchové jsou nejen v
 databázi,
 dostupné přes výměnný formát, ale jsou i v těch interaktivních formulářích
 (Ověření adresy - detail - přeít na budovu. Třeba ten příklad Kováků
 č.or.
 30. Nebo to, co mám rozdělané - Dubeč, Na hádku 1613 X Dubeč, 613 (bez
 ulice)

 http://vdp.cuzk.cz/vdp/ruian/adresnimista/25102664 (1613, OK, bylo v OSM)
 http://vdp.cuzk.cz/vdp/ruian/adresnimista/30721369 (613, IMO už
 neexistuje,
 nebylo v OSM)

 a příslušné budovy:

 http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/24643092 (OK)
 http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/30072301 (duch)


   ***
   Osobne me ovsem nejvic zarazi nesoulad KM a RUIAN, coz znamena, ze
   kazde vychazi z jinych (jakych???) dat ??? Na to ze budova je celkem
   jasne zakreslena v (digitalni) KM a neni v RUIAN narazim celkem
   pravidelne. Stejne jako na zmineny problem s panelaky, ktere jsou v KM
   rozdeleny na vchody, ale v RUIAN je to jak kde - nekdy jedna budova,
   nekdy po vchodech  (zcela bez ohledu na stavebni provedeni - to je
   ruzne, nekdy jde stavebne o jedinou budovu, nekdy o vice)

 máš nějaký příklad budovy, která je v *digitální* KM a není v RUIAN? To
 bych
 chtěl ověřit; dostaly se ke mně nějaké indicie, že ruian2pgsql prý občas
 při
 aktualizaci vynechá geometrii, tak bych to chtěl ověřit, zda opravdu není v
 tomto chyba na naší straně.

 Ta druhá část může souviset s právním stavem. V jednom případě může být
 velký
 panelák právně jako jedna budova s několika vchody a v druhém případě to
 může
 být právně 

Re: [Talk-cz] Hlášení chyb RUIAN přímo z JOSM

[Mirek Dlask]

Ahoj,

Např. http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/22482296 - celá obec
Čím.
http://cuzk.cz/Dokument.aspx?AKCE=META:SESTAVA:MDR002_XSLT:WEBCUZK_ID:623806

a řada dalších.
 ruian2pgsql asi neumí aktualizovat data u existujících záznamů.

Mirek



Dne 1. května 2014 17:30 jzvc j...@tpfree.net napsal(a):

 Dne 1.5.2014 10:45, Petr Vejsada napsal(a):


 máš nějaký příklad budovy, která je v *digitální* KM a není v RUIAN? To
 bych
 chtěl ověřit; dostaly se ke mně nějaké indicie, že ruian2pgsql prý občas
 při
 aktualizaci vynechá geometrii, tak bych to chtěl ověřit, zda opravdu není
 v
 tomto chyba na naší straně.


 Cus, pokud dobre vidim ... tak napriklad nadrazi Semily


 cp. 94 - jedna z budov podel trati, v KM zcela zjevne geometrii ma (je tam
 duch). Pritom samotna budova nadrazi cp. 95 tam je.

 Sel sem se podivat primo ke zdroji - http://vdp.cuzk.cz/marushka
 A tam jsou budovy obe, rozdelene (tzn i ta, co nema CP - 4141/1 a 4141/2).

 = opravdu to vypada na nejaky bug v prenosech dat. Jinak klasicky na to
 narazim v radach garazi a pod.

 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-cz

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] CzechAddress zahájil činnost a ještě není zabanován

[Mirek Dlask]

Ahoj,

souhlasím. Opravdu je lepe data rozdělit
Před stiskem Nahrát změny na server nastavit si na záložce Rozšířené -
Nahrát data po částech.
500 je vyhovující.

Mirek


Dne 31. března 2014 20:17 Petr Holub ho...@ics.muni.cz napsal(a):

 Ahoj,

  Zátěžový test byl proveden na okrese Karviná, což je cca 44 tisíc
 adresních
  míst. Vygenerování .osm je v pohodě, pár desítek minut. Editace v JOSM
 cca 6
  hodin práce. Nejvíce zabrat dostal OSM server, který nestihl uzavřít
 changeset
  včas a JOSM vytimeoutoval. Následně ovšem changeset uzavřel, takže je to
  nahrané.

 jsi si jist, ze se to povedlo nahrat cele?  A mas nastavene nahravani
 po castech? (Upload - Advanced - Upload in chunks - pouzivam nastaveni
 po 500)

 Petr


 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-cz

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Minimalis_import

[Mirek Dlask]

Zdravím všechny,
Měl jsem tady něco málo rozvrtáno, tak jsem to poslal. Jinak vyčkávám, co z
nikdy nekončící diskuze vypadne za závěr. Mám pocit, že už jsem na dané
téma napsal vše. Dlouhou chvíli si krátím přidáváním ulic (KV, ČB ...) a
přidal jsem něco málo adres, které nejdou spárovat automaticky. Dost jsem
po sobě mazal - duplicity a některé adresy u kterých jsem doplnil pozici a
ukázalo se, že je to nejspíš blbost.
Pokud začneš s importem ještě v tomto desetiletí, tak se hlásím mezi
dobrovolníky.

Zdraví Mirek Dlask


Dne 20. února 2014 9:35 Petr Vejsada o...@propsychology.cz napsal(a):

 Ahoj,

 abychom se dobře bavili, tak zase běží Minimalis_import, například
 https://www.openstreetmap.org/changeset/20360277

 To se budeme přetahovat? I když, možná má pravdu a než se tady dohodneme,
 tak
 on bude mít adresy naimportované.

 --
 Petr, p...@propsychology.cz
 p


 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-cz

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Minimalis_import

[Mirek Dlask]

Nejsem pesimista, jenom rýpal. ;-)
Jsem rád, že je vidět nějaký pokrok, ale asi bych byl radikálnější ...
Ulice - vytvořím vrstvu a z ní kopíruju to co mě zajímá. Potíž je v tom, že
ulice v Ruain jsou nepochopitelně fragmentovaný a navíc každý segment má
jinou orientaci. Navíc jsou problémy na křižovatkách (překřížené cesty,
nebo nedotažené). Ale pracovat se s tím dá. Některý ulice bych z katastr.
mapy nedal ani omylem. Večer můžu poslat nějakou javu, nebo ukázku ulic pro
ilustraci.

Mirek


Dne 20. února 2014 12:33 Marián Kyral mky...@email.cz napsal(a):

  Dne 20.2.2014 11:59, Mirek Dlask napsal:

 Zdravím všechny,
 Měl jsem tady něco málo rozvrtáno, tak jsem to poslal. Jinak vyčkávám, co
 z nikdy nekončící diskuze vypadne za závěr. Mám pocit, že už jsem na dané
 téma napsal vše. Dlouhou chvíli si krátím přidáváním ulic (KV, ČB ...) a
 přidal jsem něco málo adres, které nejdou spárovat automaticky. Dost jsem
 po sobě mazal - duplicity a některé adresy u kterých jsem doplnil pozici a
 ukázalo se, že je to nejspíš blbost.
 Pokud začneš s importem ještě v tomto desetiletí, tak se hlásím mezi
 dobrovolníky.


  Pesimisto :-D

 Já si naopak myslím, že se brzo začne.  Pokud se právě nebudu vrtat v javě
 (už to vypadalo, že jsem ty duplicitní body eliminoval, ale furt to není na
 100% :-( ), tak taky rád vypomůžu. Ještě přemýšlím, co budeme následně
 dělat se zjištěnými problémy, Chtělo by to nějak konsolidovat a následně
 hromadně nahlásit, ať se to nemusí dělat po jedné.

 BTW: ty chybějící ulice jsi hledal jak? Máš na to nějaký skript?

 Marián



 Zdraví Mirek Dlask


 Dne 20. února 2014 9:35 Petr Vejsada o...@propsychology.cz napsal(a):

 Ahoj,

 abychom se dobře bavili, tak zase běží Minimalis_import, například
 https://www.openstreetmap.org/changeset/20360277

 To se budeme přetahovat? I když, možná má pravdu a než se tady dohodneme,
 tak
 on bude mít adresy naimportované.

 --
 Petr, p...@propsychology.cz
 p


 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-cz


 ___
 Talk-cz mailing 
 listTalk-cz@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-cz



 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-cz


___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Ruian jako zdroj dat

[Mirek Dlask]

Ahoj,
Účet mi nebyl zablokován kvůli neprůhlednému názvu. U importů panuje obava
z toho že:
- jde o licenčně nevyhovující, nebo nedůvěryhodný zdroj dat -
http://wiki.openstreetmap.org/wiki/Potential_Datasources - neznají, tedy
nesplněno
- dojde k poškození, nebo vymazání původních dat (viz francouzský katastr)
- proto chtějí popis způsobu na import@ - nesplněno
- dojde k přetěžování serveru nadměrným objemem dat, nebo opakovaným
zasíláním dat nevalidních (duplicitní body, body sirotci bez vazeb)
- importovaná data jsou příliš podrobná, proto požadavek na zjednodušení
takových dat
- importovaná data jsou nepřesná a dochází ke kolizi se stávajícími
objekty.
Mám opačný problém. Data jsou příliš přesná a dochází ke kolizi s
nepřesnými daty v OSM.

Při výběru názvu účtu jsem se řídil poslední větou
http://wiki.openstreetmap.org/wiki/Import/Guidelines#Use_a_dedicated_user_account

Importy jsou dvojí
automatický režim - jeden nástroj - jedno místo - jeden účet
uživatelský režim - jeden zdroj používá více importérů - každý importér
může využívat více zdrojů, přičemž jednotlivé zdroje odlišuje tagem source=*
Každý importér má svůj dedikovaný účet nickname_import. Nic mu nebrání
založit si další účty. Musí ale použít jiný e-mail (velmi kritizovaný
požadavek)
Celé mi to připadá logické a nemusíme se obávat, že ten, kdo první použil
Ruian jako zdroj bude muset vše udělat sám...

---
hanoj napsal
*** informaci o garage v RUIAN imho neni.

imho je :-)

Garáže s číslem evidenčním

http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/24789321
http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/24789330
http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/24789461
http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/24789488
http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/24789453
http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/24789470
http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/24789381
http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/24789402
http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/24789399
http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/26210274

Kdo si chce vyzkoušet
SELECT concat('http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/',kod)
FROM rn_stavebni_objekt
WHERE zpusob_vyuziti_kod = 18
AND typ_kod = 2
LIMIT 10;

Zítra  is_in a spol.

M.D.



Dne 1. prosince 2013 1:20 hanoj eha...@gmail.com napsal(a):

  rad bych se Mirka zastal, protoze mam dojem, ze to jaky zvolil
  nazev uctu, je spise podruzna zalezitost a mam pocit, ze kritika, ktera
  se na nej ted snasi je trochu zbytecna a spis odrazujici od dalsi prace.
 *** Zvolil si nepruhledny nazev importniho uctu, byl zablokovan, nikde
 nic nepopsal co skutecne dela, takze je legitimni, kdyz to alespon
 zpetne udela. Kritika neni urazka, ale nastroj jak delat veci lepe.

  Koneckoncu, kdyz ja rucne obmalovavam katastralni mapu, tak delam
  neco velmi podobneho a taky to delam pod svym nickem a nic zvlastniho
  se z meho nicku nevycte.
 *** Taky te nikdo nebanuje a obkreslujes po jednotlivych objektech ne?

  Pocitam, ze to hlavni je, ze na vytvorene objekty dava tagy source a ref,
  ktere rikaji odkud data pochazi a jak vznikla. A to snad staci ne?
 *** Staci to pokud nedelas import. Vytvoření metadat o importu je na
 několik hodin, ale vytvořit je může jen on, protože je má v hlavě.

  Pokud ovsem Hanoj narazi jen na to, ze pouziva
  source:addr=ruian nebo source=ruian
  a radsi by byl, aby pouzil source=cuzk:ruian
  tak to je asi rozumny pozadavek a myslim, ze minimalis to bude schopen
 snadno
  opravit, pokud mu bude odblokovan ucet. ;-)
 *** ja nechci na nic narazet, proste rad bych videl nekde popsane proc
 to dela jinak nez dosud nebo prave tak
 *** pokud se bavime jen o adresnich bodech (a ja dosud nevim zda jsou
 jedinym predmetem importu), pak je na prvni pohled vhodnejsi mit
 source tag=cuzk:ruian a nabytecnost is_in, ktery se uz drive
 vypoustel

  Naopak si myslim, ze vzhledem k popsane slozitosti importu dat z RUIAN
  je velmi vhodne, ze pro svou konkretni metodu a vysledek prace si
  zvolil ucet, ktery primo odkazuje na jeho osobu, ale da se odlisit
  od kresleni, ktere dela jako minimalis rucne.
 *** proc ne, ale vzhledem k politice importu bude pro jeden ucet
 fungovat prave jeden zdroj.

  Na druhou stranu by asi bylo hodne dobre, kdyby napsal onu stranku na
 ceske wiki,
  kam by pro zacatek uplne stacilo copypastnout sve predchozi maily o
 tomhle
  projektu. Aby ta informace nekde byla jasne a prehledne i pro dalsi,
 pokud
  by chteli na jeho praci navazat, resp. o tom projektu diskutovat na
 jednom prehlednem miste.
 *** CP doufam ne, budu veřit že lakoničnost a výstižnost převáží nad
 esejemi.

  Dal by me zajimalo, jestli si nemyslite, ze by bylo vhodne, pokud teda
 bude mit Mirek
  naladu pokracovat, doplnovat k budovam i ty doplnujici informace, jako
 je treba
  ucel objektu. Nabizi se bud rovnou pouzit (a trochu rozsirit) tak
 building, treba
  building=garage, nebo mene konfliktni novy 

Re: [Talk-cz] Ruian jako zdroj dat

[Mirek Dlask]

Ahoj,
Díky za odkaz a připomenutí ruian2osm a dovolím si pár námětů. Neodvažuju
se do kodu sahat na githubu.
- v Node je třeba  změnit int Id na Long Id totéž u setId, getId
- v OsmLoader také final Listint loadedIds na final ListLong loadedIds
(je tam několikrát)
Pak už to funguje.

Asi trošku větší zásah, asi pro někoho jiného.
isIn - je-li část obce stejná jako obec vracíme jen obec, kraj, stát to je
ok
doplnit
jinak vrátit část obce, obec, kraj, stát
chybí podpora addr:place u adres bez ulice - buď je addr:street není-li tak
vložit addr:place
nejsem si úplně jistý zda máš v párování ref:ruian.
Prezentace výsledků. Geometrie bodu mi nic neříká. Pokud se chci podívat na
jeho polohu v JOSM stačí mi id resp ref
U SRID bych dal přednost 5514 a metrům, u 4326 budu teprve zkoumat  kolik
nastavit v match-max-distance
Ukládají se někam data stažená z OSM?
Jakou má funkci přepínač --update?
Rozjezd velmi dobrý, potencionál značný jen to využít ...
---
Pro ostatní.
Pár slov na wiki dám, dejte mi čas týden, na utřídění myšlenek a
zavzpomínání, co všechno jsem ještě neuvedl. Nevím zda tam přidat nějaké
příklady z Ruian. Z OSM je nečekejte. Nechci tady nikoho uvádět do rozpaků.

Například jsem nezmínil to, že aktualizuji pouze AM jako body. Ne že by
nešli aktualizace adres na budovách, ale místy opravdu nejdou.
Nejdou na SO s více vchody a tedy více AM, kde je na SO pouze jedno AM a
ostatní scházejí . Potíž je nad takový SO s jedním AM umístit nové body.
Dochází k překryvu čísel a jejich nečitelnosti. Jednoduché řešení nemám.

Nezmínil jsem ještě zdvojení AM na rohových SO. V Ruian jsou body pro
vedlejší i hlavní ulici na sobě, což se JOSM nelíbí. I přes jeho odpor  to
tak nechávám v případech, kdy jsou obě čísla identická a liší se pouze
ulice. U AM s číslem orientačním je pak posouvám ručné k hraně SO. Navíc
ani nevím, zda u těchto SO jsou opravdu využitelné (existují?) oba vchody.
Ale co jsem namátkou kontroloval tak jsou i v adresy.xml. Jak to udělat
automaticky nevím.
-
Abychom se posunuli dál.
Hanoj by konečně mohl být ve své kritice konstruktivnější a napsat svoji
představu o názvech importních účtů pro případ více uživatelů + jeden
hlavní pro automat.

Nějaký čas vyčkám, zda se někdo ujme vývoje nějakého polo/automatu.
Teoreticky je možné velmi rychle aktualizovat neproblematická data a
průběžně opravovat problémy. I nová data se dají přidat tam, kde
prokazatelně nic není, velmi rychle. Máme řadu obcí, kde nikdy žádný import
neproběhl.
Sám bych se rád lehce upozadil a věnoval se těm problémům.

Interně si můžeme říct, že moje činnost byla opravdu více import, než
odvozování ... Tedy pokud porovnám objem dat. Že ruční práce je
zdlouhavější na věci nic nemění.
Navenek bych to ovšem opravdu prezentoval jako odvozování. Nebo jsem se
domníval, že jde o odvozování.

Rozumím tomu dobře že Ruian není mezinárodně uznán jako zdroj dat? Není ani
zde http://wiki.openstreetmap.org/wiki/Import/Catalogue

Zatím jsem připravil následující vysvětlení.

Dobrý den,
Jmenuji se Mirek Dlask V rámci OSM požívám účty Minimalis a
Minimalis_import. Rád bych vysvětlil svoji činnost, která vedla k
zablokování mého účtu Minimalis_import.
Už více než rok jsou k dispozici data z veřejných zdrojů, jejichž garantem
je Český úřad zeměměřičský a katastrální úřad. Jedná se o projekt s
příspěvkem EU. Data jsou k dispozici volně bez licence.
Bohužel data o nemovitostech byla v minulosti zanedbána a i v současné době
obsahují řadu nepřesností a chyb. Jejich použití bez ruční korekce je pro
potřeby OSM problematické. Proto se domnívám, že nejde o  čistý import, ale
o odvozování s použitím dat z Ruian jako zdroje.
Úpravy provádím přímo v databázi. K uvedené činnosti nepotřebuji žádné
speciální programové vybavení. Pouze pár řádků programu v Javě, kterým
vytvořím výstupní *.osm soubor. Ten otevřu v JOSM, data zkontroluji proti
katastrální mapě a po validaci odesílám.
Hledám způsob, jak zlegalizovat svůj postup a dosáhnout uznání Ruian jako
regulérního zdroje dat. O Ruian jako o schváleném zdroji dat je zmínka i na
českých wiki stránkách OSM. Wiki stránky popisující úskalí importu
připravuji. Celá problematika je diskutována od počátku projektu na talk.cz
.
Bohužel se do dnešního dne nenašel nikdo, kdo by celou záležitost
prezentoval na  imports@ list.
Z dat obsažených v Ruian budou v první fázi importovány adresní body,
stavební objekty a síť ulic ve městech kde chybějí. S importem jiných dat
se prozatím nepočítá.
Cíl projektu - aktualizace stávajících adresních bodů, doplnění nových
adresních bodů, přidání nových budov.
Místo - území ČR
Označení dat - source = cuzk:ruian
Doba trvání

Re: [Talk-cz] Ruian jako zdroj dat

[Mirek Dlask]

 ...   Zde je nedostižným vítězem Liberec. Aktualizace místy
velmi pracná.

Druhým importem jsou data označená uir_adr:ADRESA_KOD. Pro ta jsou
charakteristické. Neúplné tagování a polohová nepřesnost, ale i otazníky v
addr:housenumber
Aktualizace bez problémů - uir_adr:ADRESA_KOD je totožný jako kod AM v
rn_adresni_misto

Oba importy nesprávně rozlišují velikost písmen (U Studánky vs. U studánky.
Navíc se místy vzájemně překrývaly (překrývají?) a vytvářely duplicity (MB,
ME, Říčany )

Nemohu nevzpomenout individuální obkreslování KM. Kvalita různá. Od name
27/1 až po takřka dokonalou práci... Aktualizace místy opravdu nemožná
(zbytečná).

Budoucnost nepatří aluminiu, ale Ruian. Pokud bude zájem, jsem k dispozici.
Samozřejmě ideální by byla skupina programátorů .. Osobně jsem doufal, že
se někdo přidá k fordfrogovi (on možná taky). Na druhou stranu nevím zda
bych jako programátor relaxoval programováním.
Možná by se hodil nějaký školní projekt ... ale na zázraky jsem nikdy
nevěřil.

M.D.




Dne 27. listopadu 2013 10:09 Dalibor Jelínek dali...@dalibor.cz napsal(a):

 Cau,

 koukal jsem na to zbezne. Stahlo mi to 300MB dat je v bodech, coz vypada,
 ze partyzanujes, uz celkem dlouho. ;-)

 Celkem se mi to zatim libi.



 Treba jsem hodne rad, ze pouzivas addr:place, tak kde nejsou ulice, takze
 to pak pujde najit.



 Vypada to, ze ovsem nedelas jen adresni body, ale i budovy.

 Jako trochu neprijemne, ale asi nevyhnutelne vidim, ze kdyz takhle
 naimportujes vesnici,

 tak tam si tretina domu chybi, takze je ji stejne potreba dodelat rucne.

 Predpokladam, ze v RUIANu jsou jen budovy postavene dle nejakeho
 stavebniho rizeni

 a ze mensi stavby, ktere asi neprochazi tolik a urednim simlem tam nejsou.

 Je to tak?



 Ovsem nekdy to dela nehezke vezi, jako tady id=244571117, kdy ten dum je
 tam

 jen castecne. Da se tomu nejak vyhnout?



 Predpokladam, ze ten import je poloautomaticky, ze kontrolujes, jestli tam
 uz neco nenakreslil nekdo drive.

 Je to tak?



 Na jiny problemek jsem narazil v nejake vesnici, kam si asi adresy uz dal
 drive.

 Byly tam nejake adresni body, ktere jsou podle RUIAN jinde, nez mi ukazuje
 KM.

 Co ma pak vice pravdu? V tomhle pripade se mi zdalo, ze logictejsi misto
 je to, ktere

 ukazovala KM, ale nevim, proc k tomu rozdilu dochazi a jaka data jsou
 lepsi.



 A kdyz uz ti s tim adresnim bodem pohnu, tak ti mam zachovat ref:ruian

 a prepsat source:addr z ruian na cuzk:km? Nebo to mam nechat a pripsat

 treba addr:loc=cuzk:km?



 Proc nekde jsou tvoje adresy o chloupek mimo nez body v KM?

 Treba id=2517820160



 Jsi schopen a ochoten poskytnout svuj importovaci software i jinym, aby ho
 mohli pouzivat?



 Je v RUIAN k dispozici vice informaci treba k budovam, ktere bychom mohli
 nejak vyuzit?

 Nebo ten obrys je vse, co se da vytahnout?



 Zdravi,

  Dalibor





 *From:* Mirek Dlask [mailto:dlas...@gmail.com]
 *Sent:* Tuesday, November 26, 2013 10:28 PM
 *To:* OpenStreetMap Czech Republic
 *Subject:* Re: [Talk-cz] Ruian jako zdroj dat



 1) import adresních bodů

 2) Minimalis_import

 3-4) vycházel jsem z předchozích diskuzí zde a částečně ze zvyklostí
 vyčtených v OSM datech.

 Pochopil jsem, že hledat řešení akceptovatelné všemi je zbytečná ztráta
 času. Takže možná tak trochu partyzánština.



 M.D.





 Dne 26. listopadu 2013 22:19 hanoj eha...@gmail.com napsal(a):

 Ahoj,

 možná by neškodilo dodat:
 1) co jsi dělal
 2) pod jakým účtem
 3) kde je k tomu popis postupu a metadata k výsledku
 4) kdy jsi to výše uvedené předhodil talk-cz k připomínkám

 díky hanoj


 Dne 26. listopadu 2013 22:04 Mirek Dlask dlas...@gmail.com napsal(a):
  Ahoj komunito
 
   Jak už jsem psal nedávno, byl jsem na svoji záškodnickou činnost (
 import
  dat Ruian z uživatelského účtu)  upozorněn P Normanem. Po založení
  dedikovaného účtu a pár importech jsem byl bloknut s následujícím
  vysvětlením.
 
  would you please, before continuing any of your imports, e-mail
  d...@osmfoundation.org and explain how you have conformed to our import
  guidelines (see http://wiki.openstreetmap.org/wiki/Import)? I couldn't
 find
  any discussion about your proposed import on the imports@ list and the
  source of your data is unclear.
 
  Frederik Ramm
  OSMF Data Working Group
 
  Vzhledem k mojí neochotě se někam registrovat a ještě menšímu
 diplomatickému
  umění něco vysvětlovat bych tuto ne/milou povinnost přenechal někomu
 jinému.
  Třeba už je někdo registrován a jeho angličtina je lepší než ta moje. Ani
  nevím co a jak vysvětlovat e-mailem.
  Hlásí se někdo dobrovolně?
 
  M.D.

 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-cz



 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-cz


___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org

[Talk-cz] Ruian jako zdroj dat

[Mirek Dlask]

Ahoj komunito

 Jak už jsem psal nedávno, byl jsem na svoji záškodnickou činnost ( import
dat Ruian z uživatelského účtu)  upozorněn P Normanem. Po založení
dedikovaného účtu a pár importech jsem byl bloknut s následujícím
vysvětlením.

would you please, *before* continuing any of your imports, e-mail
d...@osmfoundation.org and explain how you have conformed to our import
guidelines (see http://wiki.openstreetmap.org/wiki/Import)? I couldn't find
any discussion about your proposed import on the imports@ list and the
source of your data is unclear.

Frederik Ramm
OSMF Data Working Group

Vzhledem k mojí neochotě se někam registrovat a ještě menšímu
diplomatickému umění něco vysvětlovat bych tuto ne/milou povinnost
přenechal někomu jinému. Třeba už je někdo registrován a jeho angličtina je
lepší než ta moje. Ani nevím co a jak vysvětlovat e-mailem.
Hlásí se někdo dobrovolně?

M.D.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Ruian jako zdroj dat

[Mirek Dlask]

1) import adresních bodů
2) Minimalis_import
3-4) vycházel jsem z předchozích diskuzí zde a částečně ze zvyklostí
vyčtených v OSM datech.
Pochopil jsem, že hledat řešení akceptovatelné všemi je zbytečná ztráta
času. Takže možná tak trochu partyzánština.

M.D.



Dne 26. listopadu 2013 22:19 hanoj eha...@gmail.com napsal(a):

 Ahoj,

 možná by neškodilo dodat:
 1) co jsi dělal
 2) pod jakým účtem
 3) kde je k tomu popis postupu a metadata k výsledku
 4) kdy jsi to výše uvedené předhodil talk-cz k připomínkám

 díky hanoj


 Dne 26. listopadu 2013 22:04 Mirek Dlask dlas...@gmail.com napsal(a):
  Ahoj komunito
 
   Jak už jsem psal nedávno, byl jsem na svoji záškodnickou činnost (
 import
  dat Ruian z uživatelského účtu)  upozorněn P Normanem. Po založení
  dedikovaného účtu a pár importech jsem byl bloknut s následujícím
  vysvětlením.
 
  would you please, before continuing any of your imports, e-mail
  d...@osmfoundation.org and explain how you have conformed to our import
  guidelines (see http://wiki.openstreetmap.org/wiki/Import)? I couldn't
 find
  any discussion about your proposed import on the imports@ list and the
  source of your data is unclear.
 
  Frederik Ramm
  OSMF Data Working Group
 
  Vzhledem k mojí neochotě se někam registrovat a ještě menšímu
 diplomatickému
  umění něco vysvětlovat bych tuto ne/milou povinnost přenechal někomu
 jinému.
  Třeba už je někdo registrován a jeho angličtina je lepší než ta moje. Ani
  nevím co a jak vysvětlovat e-mailem.
  Hlásí se někdo dobrovolně?
 
  M.D.

 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-cz

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Import RUAIN (Re: Kdo je Petr1868?)

[Mirek Dlask]

Ahoj,

V prvé řadě je nutné dát dohromady pravidla pro import dat z RUIAN.
Před časem mi totiž P. Norman po několika importech dat napsal.
-

The import guidelines
http://wiki.openstreetmap.org/wiki/Import/Guidelines require
that imports be done from a dedicated account, after consultation with the
local community and imports@ and be documented on the wiki. This was not
done here.

*I can find no record of consultation with the imports@ mailing list. Where
is it?*

*You need to use a dedicated account*



Považoval jsem za dostatečnou diskuzi zde, v místní komunitě.

Na můj dotaz zda je nutný speciální účet i pro opravy (doplnění)
stávajících dat ne/odpověděl.



Perhaps someone else from the Czech community can help you.

Leave the data you have already imported in.

Consultation has to include the imports@ list, not just the local liste



Osobně si myslím, že import je lépe provádět z osobního účtu. Neumím si
představit, jak se po importu dat z dedikovaného účtu přepínám do osobního
a zpřesňuju ulice, aby  nezasahovaly do stavebních objektů, případně měním
tok potoků...

Ptám se tedy tebe, místní komunito.

Je nutný dedikovaný účet?

Je někdo ochoten (schopen) zlegalizovat Ruian jako zdroj dat pro OSM? Viz
požadavky P. Normana.

Zdraví Mirek


Dne 3. října 2013 15:27 Václav Řehák rehak...@gmail.com napsal(a):


 Dne 3. října 2013 14:09 Zdeněk Pražák zpra...@seznam.cz napsal(a):

 Když někdo napíše jako postupovat při tomto importu, klidně se toho ujmu
 ale já jsem pouze uživatel ne programátor


 Aha. On je to dost velký úkol. Zaprvé si nejsem jistý, jestli už byla
 nalezena shoda, jak má import probíhat a hlavně je pak k tomu zapotřebí
 ještě dost programování.

 Jen mi připadá principiálně neefektivní překreslovat budovy tracerem z
 obrázku, když alespoň na části území existují ta data v digitálním formátu
 s použitelnou licencí. Přesně z toho důvodu jsem nedokončil svůj import
 adresních bodů v Děčíně starou metodou (zahrnující ruční odhadování hranic
 části obce) v naději, že RUIANem se to zfoukne rychleji a přesněji.

 V.

 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-cz


___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Podivná mapa KN (ovály)

[Mirek Dlask]

Ahoj,
mám problém jen na území s digi mapou. Naskenované části fungují bez
problémů.



wms:
http://wms.cuzk.cz/wms.asp?service=WMSVERSION=1.1.1REQUEST=GetMapSRS={proj}LAYERS=parcelni_cisla_i,obrazy_parcel_i,RST_KMD_I,hranice_parcel_i,DEF_BUDOVY,RST_KN_I,dalsi_p_mapy_i,prehledka_kat_prac,prehledka_kat_uz,prehledka_kraju-linieFORMAT=image/pngtransparent=TRUEWIDTH={width}HEIGHT={height}BBOX={bbox}

Zdraví Mirek Dlask




Dne 29. května 2013 7:09 JV j@seznam.cz napsal(a):

 Zdravím všechny,
 pokud narazíte na podivnosti v katastrální mapě (nesmyslné ovály), tak mi,
 prosím, na mojí adresu pošlete Vaši konfiguraci WMS pro services.cuzk.cza 
 ideálně i odchycený WMS požadavek. Potvrzuji podobné chování např. na
 Androidu v iKatastr, ale stejná oblast se přes webový ikatastr.czzobrazuje 
 správně. Takže bude asi trochu oříšek přijít na příčinu a budu
 vděčný za jakékoliv podklady.

 Děkuji a přeji příjemný den
 Jiří Veselý

 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-cz


___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] rúian - struktura dat adresních bodů

[Mirek Dlask]

Ahoj,

tak si pro zajímavost rozebereme ještě jednu obec. říkejme ji třeba Branžež
;-)
http://www.openstreetmap.org/?lat=50.50603lon=15.0707zoom=15layers=M

Výcuc z adresy.xml

obec nazev=BRANŽEŽ kod=2643 MinPSC=294 02 MaxPSC=294 02

cast nazev=BRANŽEŽ kod=2643 MinPSC=294 02 MaxPSC=294 02
a p=10/

cast nazev=NOVÁ VES kod=11757 MinPSC=294 02 MaxPSC=294 02
ulice nazev=KURANDOV kod=162124
a e=10/

ulice nazev=SKALIČKA kod=162122

ulice nazev=UŠÁTKO kod=162123

ulice nazev=ZA VILOU kod=162126

cast nazev=ZAKOPANÁ kod=19154 MinPSC=294 02 MaxPSC=294 02
a p=10/

Branžež sama o sobě nemá pojmenované ulice
Část Nová Ves má pseudoulice. Ve skutečnosti jsou to chatové osady.

Pochopitelně funguje doručování v obou variantách. Správnější je asi ta
druhá, i když Nová Ves je jen částí Branžeže.
Branžež
Zakopaná 10

Nová Ves
Zakopaná 10

Doručitelné je i
Branžež
Kurandov 10

Branžež
Kurandov če. 10

Nová Ves
Kurandov 10

Nová Ves
Kurandov če. 10


Skoro kulatej čverec :-)

Mirek


Dne 8. srpna 2012 11:06 Petr Morávek [Xificurk] xific...@gmail.comnapsal(a):

 Ahoj,

 Libor Pechacek wrote:
  Navázal jsem na Tvůj výrok, že ti přijde zbytečné tam znova
  vypisovat informaci, která už je jednou na relacích hranic.  Názvy
  katastrálních území se od názvů obcí nepatrně liší.  Co jsem se teď
 díval, tak
  názvy KÚ mají často ještě nějaký místopisný přílepek - Doksy u Máchova
 jezera
  (normální smrtelníci znají jen jako Doksy), Obora v Podbezdězí (Obora)
 nebo
  Břevniště pod Ralskem.
 
  Když tedy například zkusíš rekonstruovat is_in bodu
  http://www.openstreetmap.org/browse/node/983573832 z relací
 administrativních
  hranic, dojdeš k trochu jinému výsledku:
  současné is_in = Břevniště, Hamr na Jezeře, Liberecký kraj, CZ
  vs
  odvozené is_in = Břevniště pod Ralskem, Hamr na Jezeře, Liberecký kraj,
 CZ
 
  Nejsem si jist, který z názvů je správný, nicméně jsem si celkem jist,
 jak sám
  hledám sídla v mapě. ;)

 Proto jsem už v prvním mailu psal alespoň pro administrativní jednotky
 od obce výš, tím jsem myslel, že je zbytečné uvádět část okres Česká
 Lípa, Liberecký kraj, Severovýchod, CZ.
 Nic z toho se na obálku nepíše. Zároveň se to dá komplet odvodit z
 relací hranic, kdyby to někdo přeci jen k něčemu potřeboval.

 Jméno části obce by se rozhodně mělo do importovaných dat nějakým
 způsobem dostat, nejsem si jistý jestli is_in tag je nejvodnější místo,
 ale pokud se tak dohodnem, budiž.

  3) Osobně si myslím, že addr:city by mělo obsahovat jméno obce a to sice
  z čistě praktických důvodů - je to položka, která se typicky píše na
  obálku, máme netriviální počet přesahů, kdy adresní body patřící pod
  obec A, leží na území obce B (sice se tyhle anomálie pomalu odstraňují,
  ale existují).
 
  Vložení názvu části do addr:city podle mě problém systémově vyřeší
 alespoň
  pro ČR - jméno části obce (ve smyslu §27 odst. 2 zákona o obcích) je
 podle
  mých dosavadních zkušeností v rámci KÚ jednoznačné a nemá další dělení.

 Ne, v addr:city by skutečně měl být název obce, nikoliv části obce.

 Kdyby mi někdo posílal dopis na adresu.
 Benešovo nám. ***
 Zelené Předměstí [takhle se jmenuje část obce]
 53002
 tak by se s tím pošta asi nakonec nějak poprala, ale není to zrovna
 preferovaný zápis mojí adresy, tím je:
 Benešovo nám. ***
 Pardubice
 53002

 Petr


 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-cz


___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] rúian bot - první výsledky testů

[Mirek Dlask]

Díky za hodně zajímavé výstupy.

Že se liší OSM od RÚIAN není překvapení, ale rozdíl mezi RÚIAN a KM je
zarážející. Čekal bych, že používají stejná data, ale zjevně tomu tak není.

Všechny body v Doksech, které nejsou v RÚIAN jsou v KM i OSM
Zkoušel jsem dva body z Kosmonos. Tam pro změnu jsou v RÚIAN, ale v KM jsou
domečky/chatičky bez čp/če.

Čemu nerozumím.
POINT(14.9199488 50.4377038) CZ, 29306 Kosmonosy, Květinová 979 má
protějšek
http://www.openstreetmap.org/browse/node/1238703135/history přesně na místě
jako v KM, tedy na ulici ;-)
Přesto, že má protějšek, je  v Not matched RÚIAN addresses:
Znamená to, že je příliš vzdálen?
Neměl by být onen protějšek v  Not matched OSM addresses: ?
Nebo by byl vymazán?

Nekonzistence dat vypadá takto
Not matched OSM addresses:
POINT(14.9130038 50.4308788) CZ, null null, null 1396

Duplicity to selektí skvěle.

Ještě jeden zajímavej bod
POINT(14.9097779 50.4360764) CZ, 293 06 null, Na Radouči 1326
Na něm je připíchnutá lékárna, čímž není vidět čp. (docela blbý ne? pro
navigace asi OK)
http://www.openstreetmap.org/browse/node/1781453132/history

Navíc na stejné budově je další nekonzistence
http://www.openstreetmap.org/browse/node/1238706528/history

Zakončím pozitivní zprávou.
Na této budově je ještě jeden adresní bod, který je na stejném místě v OSM,
KM i RÚIAN.


Mirek

Dne 6. srpna 2012 19:27 Miroslav Šulc fordf...@fordfrog.com napsal(a):

  v příloze posílám log z bota. tady pak ještě výtah z logy pro ty, kterým
 se nebude chtít zip otevírat:

 Loaded 1 632 OSM nodes
 Loaded 2 044 RÚIAN nodes
 Matching nodes by full address...
 0 nodes matched
 Matching nodes by street...
 Matched RÚIAN node POINT(14.901064 50.4144003) CZ, 29301 Mladá Boleslav,
 Ptácká 28/29 and OSM node POINT(14.9009875 50.4211801) CZ, null null,
 Ptácká 28/29 but their distance 0,0067802 is over the limit 0,005
 Matched RÚIAN node POINT(14.9009205 50.4145706) CZ, 29301 Mladá Boleslav,
 Ptácká 295 and OSM node POINT(14.9001738 50.4229025) CZ, null null, Ptácká
 295 but their distance 0,0083653 is over the limit 0,005
 Matched RÚIAN node POINT(14.9043758 50.4183866) CZ, 29301 Mladá Boleslav,
 Folprechtova 1259 and OSM node POINT(14.9031463 50.4242688) CZ, null null,
 Folprechtova 1259 but their distance 0,0060093 is over the limit 0,005
 1 398 nodes matched
 Matching nodes by conscription/provisional number...
 Matched RÚIAN node POINT(14.9063657 50.4280101) CZ, 29301 Mladá Boleslav,
 U stadionu 983 and OSM node POINT(14.919441 50.4385282) CZ, null null,
 Jižní 983 but their distance 0,0167808 is over the limit 0,005
 Matched RÚIAN node POINT(14.901064 50.4144003) CZ, 29301 Mladá Boleslav,
 Ptácká 28/29 and OSM node POINT(14.9009875 50.4211801) CZ, null null,
 Ptácká 28/29 but their distance 0,0067802 is over the limit 0,005
 Matched RÚIAN node POINT(14.9009205 50.4145706) CZ, 29301 Mladá Boleslav,
 Ptácká 295 and OSM node POINT(14.9001738 50.4229025) CZ, null null, Ptácká
 295 but their distance 0,0083653 is over the limit 0,005
 Matched RÚIAN node POINT(14.9059945 50.4299041) CZ, 29301 Mladá Boleslav,
 Na Radouči 1078 and OSM node POINT(14.9109589 50.4126665) CZ, null null,
 Třída T. G. Masaryka 1078 but their distance 0,0179382 is over the limit
 0,005
 Matched RÚIAN node POINT(14.9043758 50.4183866) CZ, 29301 Mladá Boleslav,
 Folprechtova 1259 and OSM node POINT(14.9031463 50.4242688) CZ, null null,
 Folprechtova 1259 but their distance 0,0060093 is over the limit 0,005
 Matched RÚIAN node POINT(14.9091991 50.4195372) CZ, 29301 Mladá Boleslav,
 Palackého 1396 and OSM node POINT(14.9130038 50.4308788) CZ, null null,
 null 1396 but their distance 0,0119628 is over the limit 0,005
 202 nodes matched
 Total matched nodes: 1 600
 Total unmatched nodes - RÚIAN: 444, OSM: 32
 Maximum matched node distance: 0,0023727 (RÚIAN: POINT(14.9013315
 50.422053) CZ, 29301 Mladá Boleslav, Pod skalou 303 OSM: POINT(14.9006775
 50.4243338) CZ, null null, Pod Skalou 303)

 ff




___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] rúian bot - první výsledky testů

[Mirek Dlask]

Jestli jsem správně pochopil, chce ff ty bližší body posunout (bude-li
třeba) a vymazat se budou muset ty vzdálenější, z předchozího importu.

http://www.openstreetmap.org/browse/changeset/1964311

Mirek

Dne 7. srpna 2012 21:47 Libor Pechacek lpecha...@gmx.com napsal(a):

 On Mon 06-08-12 19:27:13, Miroslav Šulc wrote:
 [...]
  Ptácká 28/29 and OSM node POINT(14.9009875 50.4211801) CZ, null null,
  Ptácká 28/29 but their distance 0,0067802 is over the limit 0,005

 A vida!  Bod z KM+ČUZK importu beznadějně mimo, opravený UIR-ADR je jen o
 13
 metrů vedle na jiném domě. :)

 Co se týče Mladé Boleslavi, duplicity jsem tam vytvořil já s tím, že budu
 brzy
 mít skript, kterým je odstraním.  Inu, skript je od té doby stále skoro
 hotový.

 Jak už jsem psal dříve, souhlasím s nahrazením svých importů daty z RÚIAN.
 Tedy tyto body mazat, pokud jsou ve verzi 1 a jsem jejich vlastníkem.

 Libor

 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-cz

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] rúian bot - první výsledky testů

[Mirek Dlask]

A taky ti musíme držet palce ;-) při řešení duplicit adresních bodů :-(
M. Boleslav, Debř ...
Docela by mě zajímal počet.

Co s nima? Smazat ty vzdálenější, co nejdříve, respektive pře aktualizací?

Už jsem jednou zmiňoval, že na některých adresních bodech jsou další tagy.

name, amenity, operator,
http://www.openstreetmap.org/browse/node/1767482902/history

Převést tagy na nové body, nebo budovy?
Jinak co jsem našel, už jsem před časem opravoval.

V budoucnu bude asi problém se jmény ulic
http://tools.geofabrik.de/osmi/?view=addresseslon=15.18443lat=50.46818zoom=18opacity=0.97overlays=buildings,buildings_with_addresses,postal_code,nodes_with_addresses_defined,nodes_with_addresses_interpolated,no_addr_street,street_not_found,interpolation,interpolation_errors,connection_lines,nearest_points,nearest_roads

Tím tvým postupem se vlastně i aktualizuje název ulice u adresního bodu.
Ulici na Václava Havla bude muset přejmenovat člobrda.

Mirek

Dne 6. srpna 2012 12:29 Miroslav Šulc fordf...@fordfrog.com napsal(a):

 Dne 6.8.2012 08:05, hanoj napsal(a):
  co se týče načítání bodů z api, tak jsem to omezil na nody, které mají
 tag
  addr:housenumber a tag addr:country=CZ (doufám, že adresní body v čr
 mají
  aspoň tyto tagy, pokud ne, tak bych to musel udělat jinak).
  *** jakým způsobem budeme pracovat s OSM addr, které jsou vloženy v
  polygonech budov(building=yes)? Převedeme tyto addr informace před
  prací bota na z polygonu body (centroindy polygonů) ?

 dobře že se o nich zmiňuješ, na ně jsem úplně zapomněl. upravím bota
 tak, aby načítal i adresy z budov. následně při aktualizaci by pak bot
 údaje o adrese z budovy mohl smazat a vytvořil by nový adresní bod.

  pro testy jsem použil BOX(14.63 50.55,14.68 50.58).
 
  pro párování bodů jsem nastavil maximální povolenou vzdálenost na 0.005,
  *** na prvni pohled mi neni zrejme co je cilem parovani, ale v k.u.
  Tuřany, k.u. Chrlice je běžná vzdálenost bodů addr v OSM (import z
  UIR-ADR) vůči WMS CUZK:KM 10 až 30 metrů,

 cílem párování je zjistit, který bod z osm odpovídá kterému bodu z
 rúian. na základě toho pak může dojít ze strany bota k aktualizaci již
 existujícího bodu místo odstranění jednoho a vytvoření druhého, takže
 dojde k zachování historie. neumím přepočítávat vzdálenost ze stupňů na
 metry, ale odhadem ten limit 0.005 bude asi tak 500m. ono když bota
 pustím na malém území, tak tenhle parametr nehraje roli, ale když bych
 ho pustil na celé čr, tak se potřebuju vyhnout tomu, aby mi pároval mezi
 sebou body z opačných krajů republiky jako shodné (vzhledem k tomu, že u
 některých adresních bodů v osm chybí addr:city, tak je to možné). takhle
 bot spáruje jen body, které jsou v od sebe vzdálené maximálně 500m. (v
 příkladu, který jsem uváděl v prvním mailu, je maximální vzdálenost dvou
 spárovaných bodů cca 100m.)
  h.
  hanoj
 ff

 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-cz


___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] rúian bot - první výsledky testů

[Mirek Dlask]

Test box na duplicity 14.9   50.44   ,14.9250.41
Není to celá MB.

Kněžmost - místo kde č.p. nedostavají domy ale dvorky .-)

http://maps.fordfrog.com/?zoom=18lat=50.49012lon=15.03952layers=B00FFF



Dne 6. srpna 2012 15:27 Miroslav Šulc fordf...@fordfrog.com napsal(a):

  Dne 6.8.2012 15:00, Mirek Dlask napsal(a):


  A taky ti musíme držet palce ;-) při řešení duplicit adresních bodů :-(
 M. Boleslav, Debř ...
 Docela by mě zajímal počet.


 kdyžtak mi pošli boudning box pro oblast, kde je hodně duplicit, a já na
 tom pustím bota a uvidíme, co z něj vyleze.

  Co s nima? Smazat ty vzdálenější, co nejdříve, respektive pře
 aktualizací?


 no, jestli se nepletu, tak duplicity se vyfiltrují tím botem, protože
 první bod se namapuje na odpovídající bod v rúian, a druhý bod už nebude na
 co namapovat, takže zbyde a bot ho bude brát jako nadbytečný a určený k
 odstranění.

  Už jsem jednou zmiňoval, že na některých adresních bodech jsou další
 tagy.

  name, amenity, operator,
 http://www.openstreetmap.org/browse/node/1767482902/history

  Převést tagy na nové body, nebo budovy?
 Jinak co jsem našel, už jsem před časem opravoval.


 taky jsem si toho všimnul. vzhledem k tomu, že bot u bodů, které existují
 v rúian i v osm, provede aktualizaci bodu v osm, tak ke ztrátě informací
 nedojde (upraví pouze adresní tagy + source). jiná situace je u duplicit,
 tam je otázka, který bod si bot vybere (aktuálně ten bližší k souřadnicím v
 rúian) a tam pak může dojít ke ztrátě určitých tagů. asi by se to dalo
 nějak ošetřit, např že by bot přidával větší váhu bodu, který má více tagů,
 ale to je otázka, jestli by to nemělo negativní vliv na párování. na budovy
 bych to asi (aspoň v tuhle chvíli) nepřeváděl, protože budov je v osm
 nesrovnatelně méně než adresních bodů. osobně ani netuším, zda je tohle
 tagování adresních bodů (amenity apod) ok nebo by se to mělo dělat jinak.

  V budoucnu bude asi problém se jmény ulic

 http://tools.geofabrik.de/osmi/?view=addresseslon=15.18443lat=50.46818zoom=18opacity=0.97overlays=buildings,buildings_with_addresses,postal_code,nodes_with_addresses_defined,nodes_with_addresses_interpolated,no_addr_street,street_not_found,interpolation,interpolation_errors,connection_lines,nearest_points,nearest_roads

  Tím tvým postupem se vlastně i aktualizuje název ulice u adresního bodu.
 Ulici na Václava Havla bude muset přejmenovat člobrda.


 přesně tak, bot by měl zvládnout i přejmenování ulic na adresních bodech
 (ale ne na ulicích). určitě by nebyl problém někam reportovat změnu názvu
 ulice (adresy obecně), aby to pak někdo mohl ručně zkontrolovat a
 zaktualizovat případně související objekty (název ulice apod).


  Mirek


 ff


  Dne 6. srpna 2012 12:29 Miroslav Šulc fordf...@fordfrog.com napsal(a):

 Dne 6.8.2012 08:05, hanoj napsal(a):
  co se týče načítání bodů z api, tak jsem to omezil na nody, které mají
 tag
  addr:housenumber a tag addr:country=CZ (doufám, že adresní body v čr
 mají
  aspoň tyto tagy, pokud ne, tak bych to musel udělat jinak).
  *** jakým způsobem budeme pracovat s OSM addr, které jsou vloženy v
  polygonech budov(building=yes)? Převedeme tyto addr informace před
  prací bota na z polygonu body (centroindy polygonů) ?

 dobře že se o nich zmiňuješ, na ně jsem úplně zapomněl. upravím bota
 tak, aby načítal i adresy z budov. následně při aktualizaci by pak bot
 údaje o adrese z budovy mohl smazat a vytvořil by nový adresní bod.

  pro testy jsem použil BOX(14.63 50.55,14.68 50.58).
 
  pro párování bodů jsem nastavil maximální povolenou vzdálenost na
 0.005,
  *** na prvni pohled mi neni zrejme co je cilem parovani, ale v k.u.
  Tuřany, k.u. Chrlice je běžná vzdálenost bodů addr v OSM (import z
  UIR-ADR) vůči WMS CUZK:KM 10 až 30 metrů,

 cílem párování je zjistit, který bod z osm odpovídá kterému bodu z
 rúian. na základě toho pak může dojít ze strany bota k aktualizaci již
 existujícího bodu místo odstranění jednoho a vytvoření druhého, takže
 dojde k zachování historie. neumím přepočítávat vzdálenost ze stupňů na
 metry, ale odhadem ten limit 0.005 bude asi tak 500m. ono když bota
 pustím na malém území, tak tenhle parametr nehraje roli, ale když bych
 ho pustil na celé čr, tak se potřebuju vyhnout tomu, aby mi pároval mezi
 sebou body z opačných krajů republiky jako shodné (vzhledem k tomu, že u
 některých adresních bodů v osm chybí addr:city, tak je to možné). takhle
 bot spáruje jen body, které jsou v od sebe vzdálené maximálně 500m. (v
 příkladu, který jsem uváděl v prvním mailu, je maximální vzdálenost dvou
 spárovaných bodů cca 100m.)
  h.
  hanoj
 ff

 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-cz




 ___
 Talk-cz mailing 
 listTalk-cz@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-cz



 ___
 Talk-cz mailing list
 Talk-cz

Re: [Talk-cz] rúian bot - první výsledky testů

[Mirek Dlask]

Je otázka, zda nejsou v RÚIAN adresní body domů bez č.p. , asi tam budou
adresní body rozestavěných domů. Ty v OSM předpokládám nejsou.
Nebo by se asi zobrazovaly tečky bez čísel!?

Buď zkusit zmenšit boxík na nějaké garáže, nebo průmysl bez č.p. ,
nebo SELECT adresních bodů bez čísel popisných a zároveň evidenčních,
jsou-li ...



150 je fakt nějak moc

Mirek

Dne 5. srpna 2012 23:30 Miroslav Šulc fordf...@fordfrog.com napsal(a):

  tak jsem dodělal bota do stádia, že načte body z osm api a z rúian db,
 pokusí se je spárovat a vygeneruje nějaké statistiky. pokud se někdo chce
 podívat do kódu, tak je k dispozici na
 https://github.com/fordfrog/ruian2osm

 co se týče načítání bodů z api, tak jsem to omezil na nody, které mají tag
 addr:housenumber a tag addr:country=CZ (doufám, že adresní body v čr mají
 aspoň tyto tagy, pokud ne, tak bych to musel udělat jinak).

 pro testy jsem použil BOX(14.63 50.55,14.68 50.58).

 pro párování bodů jsem nastavil maximální povolenou vzdálenost na 0.005,
 nicméně největší vzdálenost mezi shodnými body je 0,0009538 (RÚIAN:
 POINT(14.6562825 50.5617608) CZ, Doksy, Hálkova 890 OSM: POINT(14.6553375
 50.5616313) CZ, null, Hálkova 890,
 http://maps.fordfrog.com/?zoom=18lat=50.56166lon=14.65557layers=0B0FTF).
 u tohohle bodu je zajímavé, že údaj v kú je jiný než údaj v rúian (je to
 vidět z kú vrstvy, u nás ale zatím neproběhla digitalizace).

 co se týče propojování, tak úspěšnost byla následující:
 Total matched nodes: 1 136
 Total unmatched nodes - RÚIAN: 150, OSM: 15

 z toho mj vyplývá, že pokud jsem nikde neudělal chybu, tak v dané oblasti
 je oproti rúian navíc 15 adresních bodů a 150 jich chybí (což je opravdu
 dost na tak malé území, aspoň podle mě).

 k párování ještě poznámka. to že se body sprárovaly ještě neznamená, že
 osm obsahuje kompletní adresy. jak jsem psal jinde, u nás kompletně chybí
 addr:city, součástí adresy není ani addr:postcode. párování probíhá v
 několika cyklech, nejdříve podle celé adresy, nespárované body se pak
 porovnávají podle ulice a čísla, a to co zbyde se nakonec porovná pouze
 podle čísla. ve všech případech se ještě zohledňuje vzdálenost bodů. pro
 programátory podrobnější info tady:
 https://github.com/fordfrog/ruian2osm/blob/next_release/src/main/java/com/fordfrog/ruian2osm/AddressNodesMatcher.java

 tady je ještě údaj o průměrné vzdálenosti propojených bodů:
 Average matched node distance: 0,046

 v příloze posílám (snad proleze zip) kompletní log z bota. uvítal bych,
 pokud by se někdo na ten log podíval, jestli tam nenajde ještě něco
 zajímavého (nějaké zjevné chyby, na co si dát pozor apod.). stejně tak,
 pokud budete někdo chtít, abych pustil bota (samozřejmě pouze v testovacím
 režimu) na nějaké vaší oblíbené oblasti, tak mi pošlete bounding box a já
 vám pošlu log z bota.

 ff

 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-cz


___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] (skoro) funkční rúian wms vrstvy

[Mirek Dlask]

První budovy jsem objevil v Mnichově Hradišti ulice Víta Nejedlého jižně od
křižovatky s Harantovou a Čsl. armády. Dá se říct, že to proti cuzk:km sedí
Pro změnu tady nejsou ani ulice ani adresní body.

Zdá se mi, že tam nejsou budovy v cuzk:km označené tečkou.

Chce to trpělivost. Někde to končí chybou, někde se zatím vykresluje bílá
tma.
Ta tma přebíjí jak vrstvy pod sebou, tak nad sebou.



Dne 19. července 2012 17:03 Miroslav Šulc fordf...@gmail.com napsal(a):

  Dne 19.7.2012 16:54, jzvc napsal(a):

 Dne 19.7.2012 16:22, Miroslav Šulc napsal(a):

 ahoj,

 na adrese http://wms.fordfrog.com/wms? jsou k dispozici vrstvy z rúian
 dat. data se ještě importují do databáze, takže tam nejsou zatím
 kompletní, ale někde už jsou vidět (např. bělá pod bezdězem).


 Cece ja ti nevim, ale bez A/ zaznamu to asi nebude zrovna dostupny ...
 ;D

 tak to se omlouvám, při nastavování dns záznamu mi tam vypadla
 (bez)významná tečka :-) opravil jsem to, ale chvíli bude trvat, než se to
 refreshne na dns serverech. pokud bys to chtěl vyzkoušet už teď, tak je
 potřeba si dát do hosts následující řádek:

 46.4.118.148wms.fordfrog.com

 ff

 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-cz


___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] (skoro) funkční rúian wms vrstvy

[Mirek Dlask]

Dne 19. července 2012 22:50 Miroslav Šulc fordf...@gmail.com napsal(a):

  Dne 19.7.2012 22:27, jzvc napsal(a):

 Dne 19.7.2012 19:05, Miroslav Šulc napsal(a):

 co se týče ulic, tak ty jsou údajně špatně vyexportované (tj. xml soubory
 neobsahují správná data), takže to se ještě může zlepšit. s těma budovama
 bude asi ta kvalita dost různorodá.


Ulice jsou vážně bída, zatím bych to neřešil


  A pozor, prave se narazil na misto kde samozrejme nesedi ani adresni body
 (ostatne KM je ze stejnyho zdroje), takze jak tu nekde vejs nekdo
 navrhoval, ze se vsechny smazou a nahradej ... tak osobne jsem teda velmi
 vyrazne proti jakymukoli mazani cehokoli, protoze uz z tohodle nastrelu je
 zjevny, ze by to nadelalo vic skody nez uzitku.


 nevím jak probíhal původní import adresních bodů, ale já mám bohužel tu
 smůlu, že narážím na chybějící adresní body. dům, ve kterým bydlím (asi 50
 let starý) v osm mapě není, podobné to bylo s domem jedné firmy v praze,
 kam jsem jel. a namátkově když se podívám, tak je vidět, že těch adresních
 bodů v osm chybí relativně dost. bez nějaké automatizace není šance to
 udržovat aktuální.

 ff

 Stačí se podívat na Mladou Boleslav. Spousta duplicit. Třeba Dukelská 1310
a přitom oba leží kdesi v prostoru.
Ručně to dohromady nikdo nedá a tuším, že to nebude jenom Boleslav
U novostaveb nejsou adresní body vůbec a většinou nejsou zakresleny ani
budovy. Spousta nezakreslených garáží.

Dají se vymazat adresní body ze zadaného čtverce?


Otázka automatizace není ANO - NE, ale jak

Co takhle selektivní přístup.
Máme řadu obcí, kde jsou jen adresní body. Proč si nevybrat, některou z
nich a nezkusit import budov podle čísla obce.
Jde to?

Našel někdo někde číselník obcí?

Chce to postupovat od toho nejméně složitého a nekonfliktního, k tomu
složitějšímu.

Další je otázka struktury dat v OSM. Je kam vložit například rozšířené
údaje o budovách?
Nebo alespoň ID jednotlivých importovaných objektů?

Mirek

___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-cz


___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] automatizace aktualizace adresních bodů

[Mirek Dlask]

Problémů adresních bodů je několik

Poloha
- nezdařený předchozí import viz historie
http://www.openstreetmap.org/browse/node/296553548/history
Že by si od roku 2009 nikdo nevšimnul čísel na chodníku?
Navíc tam mohou být zásahy odmítačů

- přesun z důvodů, že něčemu překážely (jméno restaurace )
- přesun omylem
- přesun kvůli označení vchodu, protože je asi nefunkční tohle
http://wiki.openstreetmap.org/wiki/Key:entrance

- chyba ve zdroji dat a následný přesun adresního bodu. To je potřeba nějak
označit.
source = knowledge  ??

K adresním bodům jsou přidané další tagy
- name a pak se to vzájemně přebíjí
- nekonzistence s katastrem tuším formou poznámky

Takže je potřeba analyzovat i to co je tam navíc a proč.

Mirek

Dne 20. července 2012 0:43 Miroslav Šulc fordf...@fordfrog.com napsal(a):

 Dne 20.7.2012 00:23, Miroslav Šulc napsal(a):
  dovolil jsem si změnit předmět, aby to někde nezapadlo :-)
 
  Dne 19.7.2012 23:46, Mirek Dlask napsal(a):
  Dají se vymazat adresní body ze zadaného čtverce?
  to by podle mě mělo jít. otázka ovšem je, jestli mazat, nebo upravovat.
  já bych se spíš přikláněl k upravování, jelikož je pak jasně vidět
  historie. další věc je řekněme vyjetí rozdílu mezi osm a rúian, tj. co
  nám přebývá na jedné a na druhé straně. to by nám mělo udělat přehled o
  stavu dat.
 
  Otázka automatizace není ANO - NE, ale jak
  s tím souhlasím :-)
 
  Co takhle selektivní přístup.
  Máme řadu obcí, kde jsou jen adresní body. Proč si nevybrat, některou
  z nich a nezkusit import budov podle čísla obce.
  Jde to?
  já osobně bych to viděl spíš tak, že bychom měli primárně věnovat nějaký
  čas analýze dat, úvahám o tom co a jak aktualizovat, a hlavně jak to
  následně udržovat.
 
  co se týče analýzy dat, tak bychom asi měli vědět, kolik nám toho v osm
  chybí, kolik toho přebývá (a proč), kolik adresních bodů by se přesunulo
  o víc jak x metrů (a proč) a v jaké oblasti apod. z toho by pak mělo být
  aspoň částečně jasné, co by import adresních bodů obnášel.
 
  co se týče importu a aktualizací, tak řekněme, že by se např. postupně v
  osm zaktualizovaly adresní body, tj. upravil by se jejich stav podle
  rúian (přesuny, odstranění duplicit, vymazání neexistujících, přidání
  nových) a označily by se nějakým tagem, např. bot, v případě nějaké
  větší vzdálenosti od původní polohy by se ještě přidal nějaký další tag,
  např. verify. pak, pokud někdo adresní bod opraví (protože je třeba
  posunutý), tak změní tag bot na no-bot a skript bude vědět, že v
  případě změn daného adresního bodu má zakázáno bod aktualizovat. v
  takovém případě někam (třeba sem) napíše info o tom, že v rúian došlo u
  daného bodu ke změně. pokud by šlo například o opravu, která je v
  souladu s osm, tak by se bod ručně upravil a přidal by se opět tag
  bot. v případě smazání bodu z rúian lze předpokládat, že má bod zmizet
  z osm a skript by se nikoho neptal. samozřejmě lze z práce skiptu
  generovat logy, aby se dala jeho činnost jednoduše dohledat, posílat
  mailem reporty apod.

 k tomuhle bych ještě dodal, že by se samozřejmě dala označit určitá
 oblast, kde víme, že osm souřadnice jsou správné a rúian je má špatně a
 někde mimo (jak psal jzvc o místě kde nesedí adresní body), jako
 no-bot a ty by se rovnou vůbec neaktualizovaly. tohle by právě měla
 odchytit ta analýza dat, konkrétně větší než rozumná vzdálenost mezi
 souřadnicemi stejných bodů.

  takový systém by umožňoval automatické aktualizace se zachováním přidané
  hodnoty maperů. samozřejmě je to jen hrubý nástřel, co mě právě napadlo,
  jak by to mohlo fungovat. je to spíš námět k diskusi.
 
  Našel někdo někde číselník obcí?
  je např. součást rúian dat.
 
  Chce to postupovat od toho nejméně složitého a nekonfliktního, k tomu
  složitějšímu.
 
  Další je otázka struktury dat v OSM. Je kam vložit například rozšířené
  údaje o budovách?
  Nebo alespoň ID jednotlivých importovaných objektů?
  to je samozřejmě předpokladem toho, aby nějaký bot dokázal s adresními
  body jednoznačně pracovat. když se dívám třeba na adresní body tady u
  nás, tak tam jednoznačný identifikátor není. je tam jen (z těch
  relevantních údajů) domovní číslo a případně název ulice (+ souřadnice),
  takže systém by musel na začátku hledat odpovídající adresní bod podle
  těchto údajů.
 
  Mirek
  ff

 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-cz


___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] kde můžu pomoct?

[Mirek Dlask]

Ahoj,
Pokud v JOSM klikneš na ikonu Stáhnout data z OSM serveru (3. ikona zleva)
objeví se ti výřez mapy. Pravým myšítkem se přesunuješ na potřebné místo,
kolečkem myši zoomuješ   a levým vybíráš oblast, kterou chceš stáhnout.
GPS záznamy stáhneš tak, že nad mapou zaškrtneš Zdroje a typy dat: Surová
GPS data a klikneš na stáhnout. Pokud jsou v dané oblasti nějaké záznamy
zobrazí se v nové vrstvě.

Mirek


Dne 12. července 2012 10:24 Jan Dudík jan.du...@gmail.com napsal(a):

  Dál se pak, pokud se rád touláš v přírodě, můžeš zapojit do mapování
  turistických tras.  Na to je třeba vyrazit s GPSkou a foťákem do lesů a
  posbírat potřebné informace.  Kdybys chtěl vědět víc, můžu vysvětlit.
  na tohle používám osmand+ a mám stažený i osmtracker. nějak jsem ale
  nepochopil, jak dostanu track do josm. četl jsem něco, že mám track
  nahrát na osm a pak si ho stáhnout, ale nikde v josm jsem nenašel, jak
  se tracky stahují.

 V normální GPS se dá nastavit, aby se prošlé trasy ukládaly a pak je
 pomocí kabelu stáhnout do PC, kam se uloží jako GPX soubory. A ty pak
 otevřu v JOSM nebo se dají nahrát na osm server.

 JD

 --
 Ing. Jan Dudík

 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-cz

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

[Talk-cz] Duplicity administrativních hranic

[Mirek Dlask]

Zdravím,
jestli to dobře chápu jsou hranice (katastru?) )některých obcí zdvojeny.

Například Branžež

původní relace
http://www.openstreetmap.org/browse/relation/426610/history

nová, opakovaně upravovaná
http://www.openstreetmap.org/browse/relation/441968/history

Není to jenom Branžež, viz sady změn.

Mirek
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz