from:"Petr Vejsada"

Ahoj,

už je tma a tak se těžko fotí slušných světel nemaje, tak alespoň ilustrační 
miniaturu.

Dobrý pokec s p. Součkem a jeho nádhernou kolegyní - užitečné informace k 
reklamacím. Nejspíš půjde reklamovat "budova místo dvora" přes definiční bod, a 
to snad i poměrně rychle. Dám vědět jak na to.

Tak nezpychněme ;-)

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

Re: [Talk-cz] Jak vznikají chyby v RUIAN

Ahoj,

já myslím, že budova může stát na více parcelách, ale jen jedna z nich je ta 
"identifikační". V KM to asi řešili tak, že zakreslili definiční bod na všechny 
parcely, na kterých stavba stojí a při digitalizaci se neměli čeho chytit.

Ty oddělené části jsou, myslím, zbytky po nepovedené opravě. Lépe je to vidět 
zde: http://ruian.poloha.net/building.php?kod=6204317

Tam je vidět původní geometrie, jen ten úzký kousek. Pak to opravili, je tam 
vidět budova co vypadá jako budova, ale na ten kousíček zapomněli a ten tam 
zůstal.

Jinak ty opravy rozřezaných budov často řeší tak, že všechny ty části nechají v 
RÚIAN, ale smažou jim geometrii. Tu jednu zbylou s geometrií pak opraví. Někdy 
i správně :-)

Dne Út 21. listopadu 2017 14:47:41, Jan Macura napsal(a):

> No přes ten jejich XML-based formulář toho fakt moc nevyřídíme. Ta záměna
> budova-nádvoří by možná šla, nevím (posun definičního bodu).
> 
> Na opravu rozřezaných budov v KN moc šance není. Bez geometrickýho plánu se
> parcely nespojí.
> Taky existují budovy, které jsou rozřezané a některá jejich část v RÚIANu
> chybí, ačkoliv všechny parcely/části parcel jsou označeny v KM jako budova.
> Oddělené části pak třeba mají i stejné RÚIAN ID, viz např.:
> http://ruian.poloha.net/building.php?kod=41941063 . To by mohla být chyba
> exportu ISKN->RÚIAN.. ?
> 
> H.
> 
> 

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

Re: [Talk-cz] Fwd: DŮLEŽITÉ_Vyhlášení soutěže Společně otevíráme data_Zvláštní cena

Tak jsem se zapsal do toho Google formuláře. Pojďte ještě někdo, ať se tam 
nebojím :)

Dne Po 20. listopadu 2017 18:41:26, Jachym Cepicky napsal(a):

> kdyz tam bude za komunitu víc lidí, tak je to myslím ok
> 
> já v tuhle dobu zítra opravdu nemůžu
> 
> jestli tam je prostor na rečnění nevim, ale štěstí přeje připraveným
> 
> 2-3 lidi?
> 
> Petr, Majka, ...?
> 
> On Mon, 20 Nov 2017, 17:08 Petr Vejsada,  wrote:
> 
> > Ahoj,
> >
> > Dne Po 20. listopadu 2017 16:31:08, majka napsal(a):
> >
> > > Jestli jsem našla dobře, tak je to už zítra
> >
> > Zítra v Dlouhé? No vlastně bych mohl a coby hlavní autor CzechAddress
> > (tedy velký vyžírač opendat) by se to asi i hodilo. Mohu také zmínit, že
> > proud dat není jen od státní správy k OSM ale i naopak (hlášení budov).
> > Tedy myskím, že to generování reklamačních XML bude tak do týdne, nicméně
> > data pro státní správu sbíráme už 3 roky. ?
> >
> > --
> > 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] Jak vznikají chyby v RUIAN

Přemýšlím jak využít stávající možnosti reklamací.

Nejspíš to nepomůže. Každý z těch odřezků má svojí identifikační parcelu, t.j. 
tu, na které leží. Postup opravy je vlastně smazání všech staveb až na jednu. 
Jen nevíme na kterou. Takže nám je to k ničemu a úřadu nejspíš taky. Pokud není 
lepší zdroj než KM :(

Dne Po 20. listopadu 2017 20:07:49, Jan Macura napsal(a):

> No hej. Myslel jsem, že tohle je jasný...
> Otázka zní, jak nám ta informace pomůže. 🤔
> 
> H.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

[Talk-cz] Jak vznikají chyby v RUIAN

Ahoj,

tak mi konečně došlo jak vznikají ty rozřezané budovy a chyby typu budova místo 
dvora. Ono je to špatně už v té analogové KM. Definiční body jsou zakreslené na 
nádvoří a pak už se to jen zdigitalizuje. Např. 
http://ruian.poloha.net/20/50.07749/14.46369/bk

Rozřezané domy - to samé v bledě modrém - 
https://ruian.poloha.net/20/50.06357/14.54795/kb . Už v KM jsou zakreslené 
definiční body nikdy neexistujících budov :-/

--
Petr

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

Re: [Talk-cz] Fwd: DŮLEŽITÉ_Vyhlášení soutěže Společně otevíráme data_Zvláštní cena

Ahoj,

Dne Po 20. listopadu 2017 16:31:08, majka napsal(a):

> Jestli jsem našla dobře, tak je to už zítra

Zítra v Dlouhé? No vlastně bych mohl a coby hlavní autor CzechAddress (tedy 
velký vyžírač opendat) by se to asi i hodilo. Mohu také zmínit, že proud dat 
není jen od státní správy k OSM ale i naopak (hlášení budov). Tedy myskím, že 
to generování reklamačních XML bude tak do týdne, nicméně data pro státní 
správu sbíráme už 3 roky. ?

--
Petr



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

Re: [Talk-cz] Fwd: DŮLEŽITÉ_Vyhlášení soutěže Společně otevíráme data_Zvláštní cena

Dne Po 20. listopadu 2017 14:18:25, Jachym Cepicky napsal(a):

> Hradecká 18, 130 00 Praha 3

Tam? To mám 5 minut pěšky z domova.

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

Re: [Talk-cz] Fungující transformace z Křováka!

Dne Po 20. listopadu 2017 15:02:53, Marián Kyral napsal(a):

> Ono někdy totiž KM jaksi neodpovídá ortoforo. Budova ve skutečnosti leží na 
> pozemku trochu jinde, nebo je jinak natočená.

Jednou mi přišlo, že je KM opravdu hodně posunutá vůči ortofotu. Pak jsem to 
prohlédl pozorněji a zjistil jsem, že to tak není. Jednalo se o vysoké budovy a 
ortofoto není brané  vždy kolmo. Půdorys v KM/RUIAN ale přesně seděl na místo 
na zemi a bylo to posunuté ne vůči baráku na zemi, ale vůči střeše.

Petr


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

Re: [Talk-cz] Fungující transformace z Křováka!

Dne Po 20. listopadu 2017 14:38:56, Jan Macura napsal(a):

> > V budovách TODO přibylo asi 1300 kousků kvůli změně.
> 
> 
> Kvůli změně v RÚIAN? Jakože vznikly (nově se postavily nebo zaměřily)? Nebo
> to myslíš jinak?

Ano, kvůli té změně. Počítá se to tak, že když je alespoň 70% plochy budovy v 
RUIAN pokryto budovou v OSM, tak je to jakoby OK, tedy jakoby ještě v 
toleranci. Pokud je pokryto méně než 70% plochy, tak se bere jako nezmapovaná. 
Tím, že se posunul RUIAN se v některých případech muselo stát, že budova v OSM 
přestala pokrývat alespoň 70% plochy budovy.

Není to nic nečekaného. Spíš jsem se bál, aby to nebyly desetitisíce :-).


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

Re: [Talk-cz] Fungující transformace z Křováka!

Ahoj,

tak hotovy všechny vrstvy (adresy, budovy, ulice, parcely, landuse, 
budovy-todo). V budovách TODO přibylo asi 1300 kousků kvůli změně.

Posun v Jablunkově vůči KM je dle Qgisu 2.7 cm, viz obrázek. Je to zase ta 
plackárna u autobusového nádraží.

Lepší to se stávajícím gridem nebude. Ty necelé 3cm tuším zcela odpovídají 
deklarovaným vlastnostem toho gridu.

Petr


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

Re: [Talk-cz] Fungující transformace z Křováka!

2017-11-19 Tema obsahu Petr Vejsada

Ahoj,

tak budovy jsou překlopené podle gridu, zbytek probíhá (vleče se to jako šnek).

--
Petr


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

Re: [Talk-cz] nenačítají se dlaždice lpis

2017-11-16 Tema obsahu Petr Vejsada

 Vážený návštěvníku,

momentálně probíhá plánovaná servisní údržba a informační systémy MZe jsou 
nedostupné.

Doba odstávky je plánována do 19. 11. do 23:59.

 

Omlouváme se za případné komplikace.

Dne Pá 17. listopadu 2017 07:12:23, Zdeněk Pražák napsal(a):

> chtěl jsem dnes opravit některá natrasovaná pole LPIS ale nenačítá se mi v 
> JOSM vrstva dlaždic LPIS

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

Re: [Talk-cz] Posouvání adresních bodů (Was: Adding housenumbers with StreetComplete)

2017-11-13 Tema obsahu Petr Vejsada

Ahoj,

je pravda, že pokud nedojde v RUIAN ke změně adresního místa, tak se po 
zdigitalizování neaktualizuje. Aktualizuje se jen tehdy, když přijde do RUIAN 
nějaká změna.

Užil jsem si před půl rokem http://www.openstreetmap.org/changeset/49969338 , 
kdy v RUIAN aktualizovali všechny adresy v Praze. Nechápal jsem a až dodatečně 
jsem přišel na to, že se jednalo o změnu čísel volebních obvodů. Changeset má 
cca 1 změn oproti běžným 3000. Tomu už je zabráněno, teď se zpracovává jen 
taková změna, která má vliv na OSM, tedy když se mění něco, co nás zajímá. Bylo 
to opravdu dost práce.

To jsem odbočil. Nově digitalizované oblasti by se daly reimportovat, ale je to 
šílená a mnohdy zbytečná práce. Ne všude jsou ty adresy špatně. Pokud někdo ví 
o oblasti, kde je to špatně, mohu vygenerovat změnový soubor pro reimport, jak 
se to kdysi dělalo. Je to soubor, co se načte do JOSM. K němu patří HTML soubor 
s varováními a doporučeními, na co si dát pozor. Po ruční kontrole pak 
uploadnout do OSM.

Seznam digitalizací KÚ tak, jak přicházely do RUIAN, je zde: 
http://poloha.net/rss/newdkm . Je jich cca 3200.

S těmi obrovskými posuny adres proti domům jsem se setkal v Brně a v Kolíně, co 
si pamatuju. Právě na základě toho se upravoval algoritmus.

Petr

Dne Út 14. listopadu 2017 00:22:09, Jan Macura napsal(a):

> 2017-11-13 19:34 GMT+01:00 Miroslav Suchy :
> 
> > Nebo celá vesnice byla posunutá, tj. adresní body
> > byli o 50 metru na východ. Celá ulice.
> >
> 
> Body byl*y*  (!)
> Anyway, tohle je ten případ, který jsem měl na mysli, když jsem vznášel
> dotaz. Pokud dobře hledám na OSM Wiki, tak import adres proběhl v roce
> 2014. Tehdy bylo použitelně digitálních asi 75 % k.ú. Dnes jich je
> použitelně digitálních přes 90 %. Tzn. za ty 3 roky se ve spoustě území v
> RÚIANu objevily domečky, které někdo přetrasoval do OSM, ale adresní body,
> které se často ocitly (systematicky) mimo polygon budovy, se za tu dobu
> nehnuly ani o tu setinu milimetru ;-) Posouvat ručně? Bylo by to fakt na
> palici, určitě bude snazší cesta.
> 
> H.

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

Re: [Talk-cz] Posouvání adresních bodů (Was: Adding housenumbers with StreetComplete)

2017-11-13 Tema obsahu Petr Vejsada

Ahoj,

no jasně, pokud vidíš, že je adresní bod špatně, tak ho posunout.

Adresní bod nemusí být ve středu budovy. Ideální je na vchodu. Tak by to mělo 
být v RUIAN.

Robot ty "chytré" posuny nedělá od začátku importu, protože v dávných dobách 
jsme si mysleli, že RUIAN je svatý a zaručeně vše správně :-). Teprve postupem 
času se nalézaly ty chyby, co v něm jsou a dopilovával se ten algoritmus, jak 
co nejlépe zautomatizovat umístění adresního bodu.

Co by šlo udělat, je pustit stávající algoritmus na celou ČR a nechat si 
vygenerovat varování. Je otázkou jaká varování. Případů, kdy adresní bod v OSM 
je na jiné pozici než v RUIAN budou statisíce. Případů. kdy je adresní bod dále 
než 10 metrů od budovy budou desetitisíce. ?

Zkráceně - prioritu má umístění adresy tak jak je v OSM. Teprve když to vypadá, 
že je to divně, zkouší se umístění bodu z RUIAN. Tam se testují vzdálenosti od 
polygonu budovy či definičního bodu, zda adresa neleží na jiném domě než ke 
kterému patří apod. To by se vše dalo a prohnat tím znovu celou ČR. Jen by na 
následné ruční procházení byl potřeba dost velký a výkonný tým :-).

O reklamacích adresních bodů jsme, pokud vím, zatím neuvažovali. Když se koukám 
na popis na ČÚZK, tak tam se dá reklamovat prakticky všechno a tedy by to šlo 
určitě snáze než reklamace stavebních objektů. Adresy naštěstí nemají jinou 
geometrii než definiční bod :-).

Dotáhnu ty reklamace budov do podoby, jak jen to bude možné (tedy myslím 
hlášení těch neexistujících). Ty chybné geometrie je běh na dlouhou trať. Buď 
by museli začít přijímat takový typ reklamace a nebo to táhnou přes tu změnu 
definičního bodu. Tam ale může být problém s tím, abychom dokázali posunout 
definiční bod o více než 5 metrů, aby reklamace byla přijata. Třeba u těch 
rozřezaných budov je definiční bod +- správně.

Pak můžeme uvažovat o reklamacích adres.?

Petr

Dne Po 13. listopadu 2017 15:43:03, majka napsal(a):

> >
> > žádoucí editace by to mohla být pouze manuálně a za intenzivního používání
> > hlavy ;-). Robot to už dávno dělá a není to vůbec triviální.
> 
> 
> Myslím, že tuším odkud přišel dotaz - najdu odpovídající adresní bod blízko
> budovy, ale není "uvnitř" budovy. Předpokládám, že častěji to budou právě
> nepravidelné budovy či multipolygony, kdy adresní bod padne např. na
> parkoviště - bývá to do geometrického středu, a ta vzdálenost může být
> podle velikosti budovy dost značná. Případně už jsem taky viděla
> "přestěhovanou" budovu - adresní bod o cca 200 m jinde než je ve
> skutečnosti. Byl uprostřed čtyřpruhové ulice, takže možná opravdu nějaké
> přestěhování. Ty areály jsou něco trochu jiného, ale co tyhle případy?
> Posunout - neposunout? Hlásit - nehlásit?
> Zatím jsem v těch pár případech adresní bod přesouvala.


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

Re: [Talk-cz] Posouvání adresních bodů (Was: Adding housenumbers with StreetComplete)

2017-11-13 Tema obsahu Petr Vejsada

Ahoj,

žádoucí editace by to mohla být pouze manuálně a za intenzivního používání 
hlavy ;-). Robot to už dávno dělá a není to vůbec triviální.

Při podezřelých posunech robot generuje varování a procházím to ručně, přičemž 
se snažím používat tu hlavu.

Příklad: adresa je 150 metrů od baráku, ale ten barák je obrovský sklad v 
obrovském areálu a ta adresa je u vjezdu do toho areálu, tedy ačkoli je velmi 
daleko od baráku, je správně.

Petr


Dne Po 13. listopadu 2017 14:29:45, Jan Macura napsal(a):

> k tomuhle mě napadá: to posouvání adresních bodů dovnitř polygonů budov je
> žádoucí editace? Ručně? Nebo se zkusíme zamyslet a pustíme na to robota?
> Přemýšlelo se o tom už někdy dřív?


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

Re: [Talk-cz] Hlášení budov (Was: Fungující transformace z Křováka!)

2017-11-12 Tema obsahu Petr Vejsada

Ahoj,

Dne Ne 12. listopadu 2017 20:39:23, jzvc napsal(a):

> Cus, posilani je jedna vec, ale co tahle aby traser budovy omarkovany 
> jako zbourany nebo se spatnou geometrii netrasoval, pripadne alespon 
> zanadaval?

teď jsem si jednak trochu zatracoval. V některých KÚ vice-méně OK, v jiných 
typické chyby - budova a zbytek parcely reverzně, tedy budova zakreslená tam, 
kde není a nezakreslená tam, kde je, geometrie nakřivo proti ortofoto, však to 
známe.

Také jsem si dal práci a prošel a opravil většinu z těch budov připravených k 
nahlášení, tedy jen ty, co se aktualizovaly. Když říkám aktualizovaly, myslím 
tím, že ve změnách přišla nějaká věta týkající se té budovy. Při té 
příležitosti jsem objevil několik natrasovaných budov, ačkoli byly šedivé, tedy 
jako špatné. Jo, Tracer by mohl nadávat, když někdo bude chtít trasovat budovu 
označenou jako chybnou.

Něco opravili. Tak například bylo zadáno, že budova neexistuje a pak z RUIAN 
zmizela. To je OK, takže jsem to smazal z našeho seznamu. Také opravili několik 
rozřezaných budov hranicí parcel nebo administrativní hranicí. Ty opravovali 
tak, že u jedné části opravili geometrii a u druhé části, respektive budovy, 
geometrii smazali. V RUIAN je pak budova 2x. Jednou s kompletní a správnou 
geometrií na jednom KÚ a podruhé bez geometrie v druhém KÚ. Nevím jak to je, 
když je budova na hranici KÚ, zda patří do obou ... ale takováto je současná 
praxe. Samotný definiční bod nám vlastně nevadí.

Pak opravili některé budovy rozřezané parcelou. Tady to často zvorali. Z 
geometrie udělali multipolygon. Jeden polygon z toho multi je správná geometrie 
a druhý polygon je zbytek z té původní geometrie, například zde:

http://ruian.poloha.net/building.php?kod=22266933

To oranžové je původní geometrie před opravou a to černé je po opravě. Je to 
prostě problém se trefit :-)

Další příklady:
http://ruian.poloha.net/building.php?kod=6204317
http://ruian.poloha.net/building.php?kod=19059035
http://ruian.poloha.net/building.php?kod=15835715

> To ze by urady zacly ty svoje hruzy opravovat ... pro zajimavost, 
> vytahni si % budov s nepravouhlyma tvarama, a pak zauvazuj na tema, 
> kolik % jich je nepravouhlych v realu.

Je jich málo, ale bohužel ne nula. Nelze proto považovat všechny šišaté budovy 
za špatné a musí se každá ověřovat :-(.

Jak vidno, tak v případě, že je uložená původní geometrie (=z doby zadání na 
seznam chybných budov), tak se zobrazuje mapa i s původní geometrií, ta 
oranžová. To je tedy i odpověď na otázky, zda původní geometrie jsou v DB - 
jsou, ale bohužel ne všechny. Neukládal jsem je od začátku ale až od cca léta 
2015.  V té době jsem jednorázově uložil všechny geometrie, ovšem nejsou to ty 
původní, ale ty z léta 2015.

Dál plánuji zobrazovat historii každé z těch budov (co kdy kdo změnil), filtry 
na tu tabulku a pak se pustím do generování toho XML. Momentálně opravdu můžeme 
hlásit jen neexistující budovy. Geometrie se pokouším protlačit přes ten 
definiční bod. Jen když nový definiční bod nebude alespoň 5m od původního, 
reklamaci nevezmou.

Navrhuji přejmenovat důvod 3 - "Budova byla zbourána" na "Stavební objekt 
neexistuje". Mnohé budovy nemohly být zbourány už proto, protože nikdy 
neexistovaly :-).

--
Petr


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

Re: [Talk-cz] import relací

Ahoj,

pusť si Josm, v české verzi Soubor -> Stáhnout objekt -> Relaci 2332889, 
zaškrtnout, že se všemi podřízenými prvky, OK, Save (Uložit), osmosis --read...

Jsem byl zvědavý a zkusil to, výsledný soubor má 63MB, což není taková hrůza. 
Můžu ti ho poslat, ať netrápíš servery.

V té relaci nejsou úplně všechny koleje (dalo se čekat).

Dne St 8. listopadu 2017 23:24:37, Petr Bolf napsal(a):

> zdravím,
> 
> omlouvám se za dotaz, možná bude nakonec chyba mezi židlí a klávesnicí, 
> ale nemohu najít řešení.
> 
> Potřebuji naimportovat relaci, v mém případě železniční síť, která je 
> zde http://www.openstreetmap.org/relation/2332889.
> 
> Potřebuji s tím dál programově pracovat, tak jsem se rozhodl použít 
> osmosis a naimportovat do postgresql databáze. Příkaz může vypadat třeba 
> takto.
> 
> curl http://www.openstreetmap.org/api/0.6/relation/2332889 | osmosis 
> --read-xml file=- --wp host=xx user=xx password=xx database=gis Toto 
> funguje a naplní tabulku relations právě jednou relací a tabulku 
> relation_members v ní obsaženými relacemi (případně cestami). A já 
> potřebuji rekurzivně stáhnou vše až na úroveň bodů. Nenašel jsem jiný 
> způsob, tak jsem si to naprogramoval tak, že v osm souboru projdu 
> všechny elementy member a z atributu rel udělám další http dotaz na 
> realci,nebo cestu. Případně na bod. Nepřijde mi to příliš efektivní, je 
> to pomalé, bodů je opravdu hodně, možná i docela zatěžuju server. Jak 
> správně postupovat? díky Petr Bolf

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

Re: [Talk-cz] Hlášení budov (Was: Fungující transformace z Křováka!)

Ahoj,

tvůj optimizmus nesdílím ani v jedné věci.

Mnohokrát jsem ten seznam procházel, zda něco není opraveno. Našel jsem 
"samovolně" opravené dvě budovy a ty jsem ze seznamu smazal.

Stačí projít ty, u nichž je na začátku vykřičník (znamená, že v RUIAN došlo ke 
změně). Pokud je to stále špatně, tak stačí kliknout na ten důvod a jen ho 
potvrdit (aktualizuje se datum, vykřičník zmizí a budeme vědět, že je to stále 
špatně, protože v RUIAN se nic nezměnilo).

Procházím teď "svoje" budovy znovu. Našel jsem další 2 opravené, řadu 
neopravených. Dokonce i takové, které byly "opravené". Příklad: 
http://ruian.poloha.net/19/49.5361751391298/13.353297570223/B - geometrie 
budovy je jakoby správně, jenže ve skutečnosti z ní udělali multipolygon - 
jedna část multipolygonu je OK (to je ta budova) a druhá část je zase nesmyslně 
sousední parcela.

Doprojdu to, odstraním vykřičníky kde mohu a budova bez vykřičníku je zaručeně 
stále špatně. Pokud by něco v RUIAN měnili, vykřičník se zase objeví.

K druhému bodu musíme vycházet z toho, co lze reklamovat přes XML. Můžeme 
ohlásit neexistenci částí rozkrojené budovy. Ale které existují a které ne? 
Dalo by se odhadnout podle informací o budově v RUIAN. Některé budovy nemají 
žádné informace (patra, využité, zastavěná plocha) a jiné ano. Zastavěná plocha 
- můžeme zkusit odhadnout, zda plocha odpovídá skutečnosti. No a kdyby zbyla už 
jen ta správná budova, bude mít špatnou geometrii. No a která identifikační 
parcela je správně a která ne, když budova leží na několika parcelách? Co 
adresní místa, ke které rozkrojené části patří?

Je to boj :)

Dne St 8. listopadu 2017 20:21:52, majka napsal(a):

> Řekla bych,  že s výjimkou toho nejaktuálnějšího je nám ten seznam ale dost
> k ničemu,  nebo ne?
> Protože od roku 2015 toho bude dost opraveno i bez nás.
> 
> Nejdou nějak jednoduše hlásit ty "rozkrojené" budovy, kde má jedna fyzická
> budova několik kódů RIUAN podle toho, na jaké parcele stojí?
> Tohle by mohlo jít z dat dohledat a odkontrolovat,  osobně to po
> natrasování částí spojuji a čísla nechávám všechna.
> 
> 
> Dne 8. 11. 2017 19:51 napsal uživatel "Petr Vejsada" :
> 
> Jinak ten seznam se syslí zde: http://ruian.poloha.net/neplatne-budovy/

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

Re: [Talk-cz] Hlášení budov (Was: Fungující transformace z Křováka!)

Ne, není pro parádu. Všechno je uchováno v DB. Dělalo se to ještě v době, než 
ČÚZK tyto reklamace zprovoznil. Byly zde o tom diskuse s p. Součkem. V té době 
nikdo nevěděl, že (zatím?) nepůjdou reklamovat geometrie

Možná jsem to napsal nesrozumitelně, to, že by si měl reklamace podávat každý 
sám. Ano, ale ten XML soubor by se vygeneroval na webu a dotyčný by ho jen 
uploadl na ČÚZK.


Dne St 8. listopadu 2017 19:21:57, Jan Macura napsal(a):

> Takže to zaškrtávátko "Hlásit ČÚZK" při hlášení chyby přes PointInfo je tam
> jenom tak pro parádu? Trochu zklamání...
> 
> H.


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

Re: [Talk-cz] Hlášení budov (Was: Fungující transformace z Křováka!)

Dne St 8. listopadu 2017 18:19:11, Petr Vejsada napsal(a):

> takže obecná reklamace nefunguje, musí být konkrétní, například navržení 
> nového definičního bodu.

Done :-)


reklamace.xml
Description: XML document
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Hlášení budov (Was: Fungující transformace z Křováka!)

Ahoj,

to máš pravdu, neposílalo, až dnes ten pokus.

Důvodem je hlavně to, že nejdou jednoduše reklamovat ty chybné geometrie.

Pak jsou ještě další věci, které by bylo fajn dořešit. Například platí, že 
výslednou zprávu dostaneš až po vyřešení celého balíku. Když budou v balíku 
reklamace pro několik katastrálních pracovišť, může jedno katastrální 
pracoviště zdržovat vyřešení celého balíku. Tedy by se to mělo dělit i podle 
katastrálních pracovišť...

Tak o tom pojďme diskutovat, jak co s tím dál, jak to dořešit.

Jinak ten seznam se syslí zde: http://ruian.poloha.net/neplatne-budovy/

Na úřadě je to zde: http://reklamace.cuzk.cz - klik na Hromadná reklamace. 
Neposílá se to do mailových schránek, ale ČÚZK na to má systém. V době, kdy 
jsme s tím sběrem dat začínali, tak ten systém ještě nebyl. Právě p. Souček na 
tom hodně spolupracoval.

Dne St 8. listopadu 2017 19:35:54, Jan Macura napsal(a):

> 2017-11-08 19:30 GMT+01:00 Petr Vejsada :
> 
> > Ne, není pro parádu. Všechno je uchováno v DB. Dělalo se to ještě v době,
> > než ČÚZK tyto reklamace zprovoznil. Byly zde o tom diskuse s p. Součkem. V
> > té době nikdo nevěděl, že (zatím?) nepůjdou reklamovat geometrie
> >
> 
> Ok, ale zatím se na ČÚZK nic neposílalo, hej? Používal jsem to v domnění,
> že každá jednotlivá chyba přijde do mailové schránky příslušnému
> katastrálnímu pracovišti, např.
> 
> H.

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

Re: [Talk-cz] Fungující transformace z Křováka!

Dne St 8. listopadu 2017 18:33:16, Jan Macura napsal(a):

> ..a až pak jsem se podíval do dat. Už chápu. Administrativní hranice jsou
> taky z RÚIANu. Pak ale nechápu něco jiného: jak vám mohly sedět admin
> hranice na státní hranici??   To Němcům, Polákům ani Slovákům
> nevadilo, že jim lezeme do území? 

Administrativní hranice dělá někdo jiný (Xificurk), jak dělá transformaci z 
Křováka nevím.

Administrativní hranice z RUIAN používám pro aktualizaci adres, vlastně se jen 
testuje, zda adresní bod leží uvnitř administrativních hranic. Pokud leží mimo, 
přidávají se explicitní tagy (City apod.)

Nicméně ta konverze by se měla udělat opravdu komplet.

Objevil se problém, padá mi Postgres několikrát do hodiny, tedy přesněji zabíjí 
ho OOM killer. Je to zvláštní, ale příčinou bude pouze existující zázname ve 
spatial_ref_sys s odkazem na ten grid. Když jsem ten odkaz na grid smazal, tak 
to nepadá. Tedy ještě kolem toho bude zábava :)


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

[Talk-cz] Diff budov RÚUIAN <-> OSM (Was: Fungující transformace z Křováka!)

Dne St 8. listopadu 2017 06:53:28, Marián Kyral napsal(a):

> V dalším kroku by se pak už snadno daly porovnávat i ty atributy. A to buď 
> nějakou tabulkou - budova | atributy OSM | atributy RUIAN - aby bylo vidět, 
> kde třeba došlo ke změně. Tady bych neřešil změnu geometrie.

OK tak potřebujeme vymyslet jak budovy k sobě spárovat.

- bude-li ref:ruian:building a nebudou od sebe moc daleko, tak je to jasné
- nebude-li ref:ruian:building tak podle překryvu

v RÚIAN i v OSM jsou občas na sobě budovy naplácané a pak to bude těžké. 
Relativně těch naplácaných přes sebe není tolik.

Asi by to ve většině případů šlo zcela zautomatizovat - pokud nebude pochybnost 
o tom, že k sobě budovy patří, šlo by na to udělat něco jako je teď na adresy. 
Ovšem že to může být v RÚIAN špatně a v OSM dobře.

Pak co s tím zbytkem? Asi tu navrhovanou tabulku.

Dala by se taky udělat další vrstva nebo nějaká značka, třeba by mohla být na 
budově značka, která říká, že by se budova měla přetrasovat (a tím aktualizovat 
ty atributy).

Které atributy by to měly být?

building=
building:ruian:type
building:levels
building:flats

Další atributy? Přípojky elektřiny, vody a plynu asi ne.

Tak přemýšlejme.


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

[Talk-cz] Hlášení budov (Was: Fungující transformace z Křováka!)

ad hlášení budov

zkoušel jsem reklamaci toho, co nás trápí nejvíce, a to jsou IMO chybné
geometrie budov. Navrhnout novou geometrii v rámci reklamace nelze
(pochopitelně).

Zkusil jsem reklamovat 3 chybné geometrie v mém okolí, tedy vím na 100%, že
jsou geometrie špatně. Vytvořil jsem XML s reklamací (příloha) a do poznámky
napsal, že je chybně geometrie. XML je validní, ale bohužel dostal jsem jen
hlášku:

"Vaše žádost neobsahovala žádnou reklamaci, kterou bychom mohli akceptovat." :-(

takže obecná reklamace nefunguje, musí být konkrétní, například navržení nového
definičního bodu.

No teď mě napadá, že přes ten definiční bod by se to dalo někdy protlačit. V
uvedeném příkladu by to možná šlo. Je tam další podmínka, že nový definiční bod
musí ležet alespoň 5m od stávajícího a na polygonu budovy či identifikační
parcele. Nj, jenže návrhy nových definičních bodů v DB nemáme.

Na obrázku jsou ty 3 budovy, které jsem zkoušel reklamovat. Hvězdy jsou
definiční body, žluté hvězdy jsou definiční body, které by se měly posunout. Do
poznámky pak napsat, že je špatně geometrie budovy? V tomto případě body leží
uvnitř chybného polygonu budovy a leží na identifikační parcele (jak teď, tak
by ležely i po přesunu).

Zkusím toto poslat ještě jednou s těmi přesunutými definičními body a dám vědět
výsledek.

Z ostatních reklamovatelných věcí bychom asi mohli využít jen zrušení budovy.
Co se dá reklamovat je pěkně popsané v poznámkách přímo ve vzorovém XML na
http://reklamace.cuzk.cz/formular/www/info/hromadna_reklamace_ruian.xml

Ještě bych mohl vzít databázi a hromadně vyreklamovat situace, kdy definiční
bod leží úplně jinde než vlastní budova, ale takový select si přeci mohou
napsat sami.

OK. Dejme tomu, že bychom zahájili odesílání reklamací na ty zbourané budovy.
Původní myšlenka byla, že to tam budu čas od času posílat sám. Teď se mi jeví
jako výhodnější udělat to tak, aby si reklamace posílal každý sám. Představuji
si to tak, že by se vytvořila reklamační sada. Uživatel by si vybral své
vlastní označené budovy k reklamaci, z toho by se vytvořil reklamační XML a
zároveň by se této reklamační sadě přidělilo nějaké ID. Měli bychom sledovat
stav reklamace, tedy něco jako:

- reklamační soubor vytvořen
- reklamační soubor předán ČÚZK
- reklamace ukončena

Asi by měla být i možnost z reklamační sady odebírat jednotlivé budovy nebo
určovat, jak reklamace dopadla (OK, odmítnuta pro formální chybu, ... ???)

A jak to naprogramovat, aby to bylo user friendly?

@Marián, prosím tě, mohl bys udělat něco se svým mailovým klientem? Ve tvých
zprávách se nedá najít co je citace a co píšeš nově. Je to opravdu nepřehledné.
Díky :)

Dne St 8. listopadu 2017 07:08:16, Marián Kyral napsal(a):

> BTW, to nahlašování chyb zpět na ČÚZK asi aktuálně nijak neprobíhá že?

oso.xml
Description: XML document
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Fungující transformace z Křováka!

2017-11-07 Tema obsahu Petr Vejsada

Ahoj,

Honza M. popisuje tu jasnou věc, že aktualizací by se úplně všechny budovy v 
RUIAN posunuly. Na východě hodně, jinde méně, ale posunuly by se. A nejde jen o 
budovy, ale o všechny geometrie (parcely, hranice všech možných 
administrativních celků, ...) Přeci je blbost přetransformovat jen budovy a 
příslušné parcely nechat nakřivo.

Diff budov, když bude budova v OSM mít ref, tak je to jednoznačné, když ho mít 
nebude, tak se také nemusím strefit. Asi nějak navázat na tu buildings-todo? Ta 
funguje tak, že když je RUIAN budova pokryta budovou z OSM z méně než 70% 
plochy tak se bere jako v OSM nezmapovaná (modrá). Dalo by se třeba reverzně 
brát za spárované budovy ty, které se překrývají na více než 70% plochy. A u 
spárovaných porovnat ty atributy.

Je zase v provozu ta oranžová vrstva buildings-grid 
http://tile.poloha.net/budovy-grid/{z}/{x}/{y}.png , nahlížecí na 
http://ruian.poloha.net/index-with-grid.php

Asi by bylo také dobré se dopátrat, jakým způsobem se to spravilo, aby to zase 
v příští verzi postgisu/geosu zase někdo nerozbil. Ta definice SRID 5514 je IMO 
v postgisu fakt blbě, viz obrázek orloje- Dosti jiná čísla v +towgs84.

Jestli to správně chápu, tak při použití +nadgrids se ignoruje +towgs84, takže 
s gridem je jedno kterou definici vezmu. Bez gridu je to brutál posun. Na 
jihovýchodě podstatně menší než v Praze.

Dne Út 7. listopadu 2017 22:41:52, Marián Kyral napsal(a):

> A to vadí? Jak často přetrasováváš celou vesnici? Maximálně přetrasuješ jen 
> navázané budovy, takže třeba blok. Ten zbytek bude mít tak malý posun, že to 
> nebude stát za tu námahu. A jednou to stejně někdo přetrasuje.
> 
> Btw: technicky to nebude nová verze budovy, ale uzlů.
> 
> @Petr: tak mne napadlo, že by nebyla špatná vrstva "budovy-attr-diff", kde by 
> byly budovy, které se v osm a ruian liší třeba počtem pater, nebo jsou v 
> ruian a v osm je jen building=yes.
> Samozřejmě by se musely ošetřit zjevné chyby aka 0 pater. Co myslíš?___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

[Talk-cz] Fungující transformace z Křováka!

2017-11-07 Tema obsahu Petr Vejsada

Ahoj,

jsem si zase chvíli hrál se spatial_ref_sys. Do postgisu se dostal oficiální 
řádek se SRID 5514, který se liší od našeho používaného. Nejenže se liší, ale 
je také pěkně blbě - vše je šouplé o několik metrů (!) na jiho-jihovýchod.

Nicméně jsem si hrál dál a zkusil zase přidat +nadgrids=czech a celkem vyděšeně 
zírám na to, že v Jablunkově, tedy v oblasti, kde byly největší posuny, teď 
vizuálně vše sedí na CUZK:KM naprosto přesně. Těžko říct, zda byla chyba v 
Geosu nebo Postgisu. No jukněte na obrázek z Jablunkova.

Zkontroloval jsem sever, jih, západ, Prahu a Brno a vizuálně vše sedí přesně na 
pixel.

Tak myslíte, že mám ty geometrie v RUIAN updatnout?

To je skoro na výstřel z Aurory, ostatně je 7. listopadu :-)

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

Re: [Talk-cz] SimpleSAMLphp error report

2017-10-17 Tema obsahu Petr Vejsada

Ahoj Majko & All,

hlavně pro ostatní, problém byl v IPV6 konektivitě u Contabo. Komunikace 
probíhá přednostně po IPV6, což ale nešlo a tak vše padalo na timeoutech.

Contabo na problému ještě pracuje, ale poradili mi nastavit natvrdo MAC 
příslušného routeru, což pomohlo a teď IPV6 jde (a doufám, že už půjde stále).

--
Zdraví
Petr

Dne Út 17. října 2017 14:02:29 jsi napsal(a):

> SimpleSAMLphp Error Report
> 
> Message from user:
> 
> snaha o přihlášení na openstreetmap pro nahlášení chyby budovy na RUIAN
> 
> 
> Exception: SimpleSAML_Error_Error: UNHANDLEDEXCEPTION
> Backtrace:
> 0 /var/www/simplesamlphp/www/module.php:180 (N/A)
> Caused by: Exception: Contacting request_token endpoint on the OAuth Provider 
> [statuscode: unknown]: 
> :https://www.openstreetmap.org/oauth/request_token?oauth_callback=http%3A%2F%2Fruian.poloha.net%2Fsimplesaml%2Fmodule.php%2Fauthosm%2Flinkback.php%3Fstateid%3D_c4d26469434846fc65e82538ea99fc56f72bec2a4a&oauth_consumer_key=6PzdmV00PZ0mX9SRkbCb4uxoWZyUrCFmpzwOiMev&oauth_nonce=6c4d6facfc8efd526b7378182252e53d&oauth_signature=k8XL96muA9%2BrlVGhLSIZVNe3TtM%3D&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1508241509&oauth_version=1.0
> Backtrace:
> 7 /var/www/simplesamlphp/modules/oauth/lib/Consumer.php:65 
> (sspmod_oauth_Consumer::getHTTP)
> 6 /var/www/simplesamlphp/modules/oauth/lib/Consumer.php:76 
> (sspmod_oauth_Consumer::getRequestToken)
> 5 /var/www/simplesamlphp/modules/authosm/lib/Auth/Source/OSM.php:72 
> (sspmod_authosm_Auth_Source_OSM::authenticate)
> 4 /var/www/simplesamlphp/lib/SimpleSAML/Auth/Source.php:193 
> (SimpleSAML_Auth_Source::initLogin)
> 3 /var/www/simplesamlphp/lib/SimpleSAML/Auth/Simple.php:141 
> (SimpleSAML_Auth_Simple::login)
> 2 /var/www/simplesamlphp/lib/SimpleSAML/Auth/Simple.php:83 
> (SimpleSAML_Auth_Simple::requireAuth)
> 1 /var/www/simplesamlphp/modules/core/www/as_login.php:33 (require)
> 0 /var/www/simplesamlphp/www/module.php:137 (N/A)
> 
> URL:
> http://ruian.poloha.net/simplesaml/module.php/core/as_login.php
> 
> Host:
> mapserv
> 
> Directory:
> /var/www/simplesamlphp
> 
> Track ID:
> ac280c89a4
> 
> Version: 1.14.8
> 
> Report ID: d16091bf
> 
> Referer: http://ruian.poloha.net/building.php
> 
> 
> 
> This message was sent using SimpleSAMLphp. Visit the SimpleSAMLphp 
> homepage.
> 

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

[Talk-cz] Stěhování poloha.net

2017-10-08 Tema obsahu Petr Vejsada

Ahoj,

za chvíli nastane (doufám) krátký výpadek poloha.net za účelem stěhování z 
Amsterdamu do Mnichova k Contabo.

V Contabo jsou "trošku" výhodnější parametry, nuž posuďte sami.

TransIP (současný hosting):
Cena: 25E/měsíc
RAM: 4GB
Disk: 150GB SSD
CPU: 2

Contabo (nový hosting):
Cena: 9E/měsíc
RAM: 12GB
Disk: 300GB SSD
CPU: 4

Stěhování proběhne tak, že je synchronizovaná DB na starém a novém 
hostingu přes streaming replikaci. Následně vypnu služby na starém 
hostingu a na novém udělám major upgrade na PostgreSQL 10, což nelze dělat 
online a prakticky doba upgrade databáze je tou dobou výpadku. Je to 
odzkoušené, tak se to snad naostro povede stejně jako se povedlo při 
pokusu. Po upgrade DB zapnu služby na starém i novém serveru tak, že že 
vše na starém serveru se bude obracet na databázi na novém serveru. Pak 
přijde změna DNS a v průběhu několika hodin už byste měli dostávat IP 
adresu nového hostingu. Do té doby se dají očekávat pomalejší odezvy, 
neboť databáze bude v jiné zemi než web.

IP adresa nového serveru je 5.189.142.205 a 2a02:c207:2014:1541::1.

Díky Michalu Grézlovi, že tento nový hosting objevil :).

--
Petr

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

Re: [Talk-cz] Zabaged výškopis

Díky za informaci, tak to je škoda, že to nelze využít. Nicméně neopomenu 
si rýpnout, že je to vytvořené za naše (daňových poplatníků) peníze.

Dne St 6. září 2017 16:24:01, Martin Landa napsal(a):

> Zdravim,
> 
> Dne 6. září 2017 15:41 Petr Vejsada  napsal(a):
> > roztomilý soubor: https://ulozto.cz/!XHQme8mUgkbA/zabaged-vyskopis-zip
> 
> data z databaze ZABAGED, co vim, tak nepodlehaji rezimu "otevrenych
> dat". Vami zmineny link podle vseho vede na nelegalne sirena data.
> Martin

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

Re: [Talk-cz] Zabaged výškopis

díky, teorie odpovídá obsahu. Jsou to vrstevnice v různých výškách a 
obvykle tam, kde je svah,

Dne St 6. září 2017 16:18:33, majka napsal(a):

> K těm doplňkovým vrstevnicím jen trocha teorie:
> měly by být použité tam, kde klasické rozpětí vrstevnic nestačí pokrýt
> terén - tedy třeba pokud by klasické rozpětí zmapovaných vrstevnic 
schovalo
> výrazné lokální výškové rozdíly v terénu. Víceméně nemají předepsaný
> výškový krok.

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

Re: [Talk-cz] Zabaged výškopis

screenshot z QGISu http://osm.poloha.net/vyskopis-qgis.png

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

[Talk-cz] Zabaged výškopis

Ahoj,

roztomilý soubor: https://ulozto.cz/!XHQme8mUgkbA/zabaged-vyskopis-zip

Obsahuje vrstevnice po 10 metrech pro celou republiku, dále vrstevnice po 
dvou metrech, ale bohužel jen západní půlku republiky. Pak doplňkové 
vrstevnice, to jsem nepochopil přesně, co to je - prostě někde jsou a jsou 
hodně husté, nejméně po dvou metrech.

Další roztomilost, kterou soubor obsahuje, jsou hranice vodstva - potoky, 
řeky, rybníky, moře a oceány chybí ;-). Je tam opravdu kdejaká louže.

No otázka samozřejmě je, jak je to se Zabaged, zda je to úřední dílo atd.

--
Petr

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

Re: [Talk-cz] Import dat do QGisu

Ahoj,

to záleží, jak to kdo nakreslil. Tracer dělá relace, když je uvnitř budovy 
díra, pak dělá multipolygon inner/outer. Složitější věci jako části budov 
apod. je třeba zakreslit ručně a pak záleží na preciznosti mapera a také 
jeho místní znalosti.

Co se týká výšek budov, tak v Praze by ti mohly pomoci pražské datasety 3D 
- http://www.geoportalpraha.cz/cs/opendata

Dne St 6. září 2017 15:20:33, Vladimír Semotán napsal(a):

> Zajímalo by mě, jestli jsou v OSM datech části budov nějak logicky 
spojeny,
> nějakou relací, nebo nějakým tagem?

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

Re: [Talk-cz] FYI: Body záchrany v pražských lesích

Ahoj,

on nezmizel celý dataset. Zmizely jen atributy (sloupce), konkrétně mimo 
jiné zmizela ta čísla lamp.

Co mi zbylo z dob, kdy tam čísla ještě byla:

 count |  ctmtp_popi| has_id
---+
62 | svítidlo na objektu - povrch. znak | f
   624 | svítidlo na objektu - povrch. znak | t
   692 | svítidlo na stožáru - povrch. znak | f
 96683 | svítidlo na stožáru - povrch. znak | t
   758 | svítidlo slav. osvět. na objektu   | t
   906 | svítidlo slav. osvět. na soklu | t
 2 | svítidlo slav. osvět. na stožáru   | f
   152 | svítidlo slav. osvět. na stožáru   | t

has_id znamená, zda je či není kýžené číslo lampy.

Dne Čt 17. srpna 2017 22:02:52, Jan Macura napsal(a):

> Ahoj,
> 
> co se lamp týče, podrobnou evidenci nevede jen Eltodo v hlavním městě, 
ale
> prakticky v každé větší vsi, kde se nějaké VO vyskytuje to mají 
začmárané
> do mapy s nějakými čísly.
> Problém, který je minimálně tam, kde VO spravuje ČEZ ES, je pro nás ten, 
že
> tyhle tzv. poziční čísla nemusí být stabilní, tj. občas se můžou změnit, 
a
> to i dost radikálně.
> Možná i to by mohl být racionální důvod, proč ten dataset z Opendat 
Práglu
> zmizel.

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

Re: [Talk-cz] ruian budovy - kudy začít? (Was: Import dat do QGisu)

Ahoj,

http://poloha.net/content/co-je-co-tu-je

je na to vrstva, která se dá přidat do JOSM. Ty nezmapované budovy se 
zobrazují modře.

Stačí jen uploadnout do JOSM a při přepočtu ta modrá zmizí.

Petr

Dne St 6. září 2017 14:42:51, Jan Martinec napsal(a):

> ten seznam mě zaujal, pár z těch obcí navštěvuju i fyzicky a byl bych s
> to doplnit - ale nedohledal jsem ani na webu, ani na osmap.cz, ani na
> wiki, z čeho poznám chybějící budovy. Řekněme, že třeba bych chtěl
> doplnit Českou Třebovou - jak poznám, které budovy patří do těch 161
> nezmapovaných? Stačí mapovat z leteckých podkladů? (A až je zmapuju,
> stačí je uploadnout do mapy, nebo mám nějak pingnout i tuhle stránku?)
> 
> Díky a mapování zdar,
> 
> 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] Fwd: Re: FYI: Body záchrany v pražských lesích

2017-08-16 Tema obsahu Petr Vejsada

Ahoj,

tak musím vzít své nadšené tvrzení zpět. Mám starší tabulku, původem právě 
z geoportálu, kde ta čísla lamp jsou. Od té doby brutálně očesali obsah, 
takže v datech teď není _žádná_ jednoznačná identifikace!!!

Tu starší tabulku i s čísly lamp mám, je tam skoro 100 tisíc lamp i s 
čísly. Od té doby přibylo cca 7000 lamp, ty nemám. Bohužel stará data s 
novými není podle čeho spárovat, jedině podle polohy :-(

Dne Út 15. srpna 2017 00:34:18, Jan Martinec napsal(a):

> On 08/14/2017 11:11 PM, Petr Vejsada wrote:
> > Ahoj,
> > 
> > tak to jsi mě pobavil :-). No když Eltodo kšeftuje, proč ne. Eltodu 
asi
> > ještě nikdo neprozradil, že jeho vzácné hou-nou je součástí digitální
> > technické mapy Prahy a všechny jeho lampy včetně průběhu drátů k nim 
jsou
> > součástí opendat :-))).
> > 
> > http://www.geoportalpraha.cz/cs/opendata
> 
> No vida, tam by to bejt mohlo, to je pravda. A dokonce s kompatibilní
> licencí. Super, tohle mě nenapadlo :)
> 
> HPM
> 
> ___
> 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] Fwd: Re: FYI: Body záchrany v pražských lesích

2017-08-14 Tema obsahu Petr Vejsada

Ahoj,

tak to jsi mě pobavil :-). No když Eltodo kšeftuje, proč ne. Eltodu asi 
ještě nikdo neprozradil, že jeho vzácné hou-nou je součástí digitální 
technické mapy Prahy a všechny jeho lampy včetně průběhu drátů k nim jsou 
součástí opendat :-))).

http://www.geoportalpraha.cz/cs/opendata

Dne Po 14. srpna 2017 16:48:04, Jan Martinec napsal(a):

> Takhle kompletní evidenci lamp i s veřejným označením si vede jen Eltodo
> (nebo kdo to teď pro Prahu spravuje), vede si ji pro MHMP (takže vně 
Prahy
> se s tím nepotkáte), a hlavně - data mají, ale nedají, páč je to prý
> unikátně cenné (zřejmě "zpeněžitelné"?) hou-nou.

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

Re: [Talk-cz] Aktualizace adres v Praze

2017-07-14 Tema obsahu Petr Vejsada

Tak jedná se o změnu v čísle volebního obvodu. Buďto dochází k 
přečíslování a nebo se volební obvody mění, předělávají.

Dne Pá 14. července 2017 10:11:12, Petr Vejsada napsal(a):

> Ahoj,
> 
> dobrej nápad. Bude stačit stáhnout jen Prahu k 31.5.2017 a porovnat s 
tím,
> co mám v DB teď.
> 
> Dne Pá 14. července 2017 08:44:47, Marián Kyral napsal(a):
> > Ahoj,
> > a nešlo by tam ještě zapracovat porovnání s předchozími RUIAN daty? 
Zda
> 
> se
> 
> > opravdu změnila?
> > To by ale asi vyžadovalo držet si tu předchozí verzi.
> 
> ___
> 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] Aktualizace adres v Praze

2017-07-14 Tema obsahu Petr Vejsada

Ahoj,

dobrej nápad. Bude stačit stáhnout jen Prahu k 31.5.2017 a porovnat s tím, 
co mám v DB teď.

Dne Pá 14. července 2017 08:44:47, Marián Kyral napsal(a):

> Ahoj,
> a nešlo by tam ještě zapracovat porovnání s předchozími RUIAN daty? Zda 
se
> opravdu změnila?
> To by ale asi vyžadovalo držet si tu předchozí verzi.



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

[Talk-cz] Aktualizace adres v Praze

2017-07-13 Tema obsahu Petr Vejsada

Ahoj,

někde na úřadech začali provádět podivné věci. V průběhu července 
zaktualizovali cca 95 tisíc adres v Praze. V červenci (do teď) 
zaktualizovali další tisíce. Počet zaktualizovaných už se blíží celkovému 
počtu adres v Praze. Asi ještě nějaké aktualizace přijdou, ale už by to 
nemělo být masivní, i když nechápu ani současné důvody. U naprosté většiny 
nejspíš o žádnou aktualizaci nešlo, jen zapsali znovu stejná data do 
RÚIAN. Což ale je pro robota změna a změnu zpracuje; tedy pokud usoudí, že 
v OSM jsou významně odlišná data od RÚIAN, zaktualizuje. Snažím se to 
procházet, hodně kontrol je automatických, ale občas nezafungují, protože 
jsou v RÚIAN třeba špatně zakreslené budovy a v tom případě bod posunuje 
adresní místo na budovu a nenechává ho na budově jiné či desítky metrů 
daleko.

Snad to nezpůsobí moc velký zmatek. Není v mých silách procházet všechny 
adresy v Praze, kde se co zvoralo. Snad toho moc nebude.

Hlavně doufám, že Praha není jen předehrou pro celou ČR.

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


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

Re: [Talk-cz] nefunguje taskmanager turistických tras

2017-06-28 Tema obsahu Petr Vejsada

v té době byl reboot kvůli výměně kernelu, tak to bylo nejspíš v době, než 
vše nastartovalo.

Dne St 28. června 2017 18:40:09, Zdeněk Pražák napsal(a):

> nezkoušel, protože po chvíli to bylo v pořádku
> Pražák
> 
> 2017-06-28 10:42 GMT+02:00 Tom Ka :
> > To je na petra vejsadu, zkousel jsi mu napsat primo na ten mail v 
chybe?
> > 
> > Bye
> > 
> > 2017-06-27 18:23 GMT+02:00 Zdeněk Pražák :
> > > taskmanager turistických tras mi při pokusu o uložení dává 
následující
> > > hlášku
> > > 
> > > Internal Server Error
> > > 
> > > The server encountered an internal error or misconfiguration and was
> > 
> > unable
> > 
> > > to complete your request.
> > > 
> > > Please contact the server administrator at p...@propsychology.cz to 
inform
> > > them of the time this error occurred, and the actions you performed 
just
> > > before this error.
> > > 
> > > More information about this error may be available in the server 
error
> > 
> > log.
> > 
> > > co se děje
> > > 
> > > 
> > > 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

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

Re: [Talk-cz] Nekonzistence CUZK - MVCR

2017-06-05 Tema obsahu Petr Vejsada

Ahoj,

není potřeba s tím dělat nic. Jsou to chyby státní správy, které byly 
importovány i do RÚIAN. Z RÚIAN jsou postupně státní správou odstraňovány. 
Při importu adres mi pokaždé zůstane několik desítek nodů, které mají jen 
tuto poznámku. To znamená, že CzechAddress to správně schroustal, 
odstranil, co tam být nemá a zůstala jen poznámka. Pro mě je to signál k 
ruční kontrole, což stále poctivě dělám. Doufám, že většina prochází 
automaticky.

Těžko říct, jak dlouho oprava bude trvat. Už probíhá několik let a IMO 
bude ještě mnohonásobně více let probíhat.

Typicky jde o záměnu popisného a orientačního čísla, dále mraky 
duplicitních čísel, jako ev. 45 a 5045 zároveň, evidenční i popisné číslo 
současně u jedné budovy atd.atd.

Ty poznámky byly do OSM zaneseny, protože nikdo, včetně státní správy, 
nebyl schopen dobrat se reality. Ten stav trvá dodnes, byť se odstraňuje.

Z tohoto důvodu nejsou dodnes importovány z RÚIAN adresy obce Kozojedy a 
Jevany z okr. Praha-Východ. V Kozojedech je ten bordel extrémní.

Dne Po 5. června 2017 13:43:02, Petr Schönmann napsal(a):

> Ahoj, koukal jsem do TAGINFO a narazil na tento note. Jde o nějakou 
chybu
> co by se měla eliminovat ? Je toho poměrně dost ( 30k+ node ).
> 
http://taginfo.openstreetmap.cz/tags/note=Nekonzistence%20cuzk%3Akm%20a%20mv
> cr%3Aadresa#overview Mám takové tušení že to byl nějaký relikt po 
importu
> adresních bodů. Je nějaký postup jak tyto body ověřit a eliminovat tak
> tento note ?

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

Re: [Talk-cz] RUIAN posun - konečné řešení?

2017-01-08 Tema obsahu Petr Vejsada

Ahoj,

mezitím jsem zjistil, že jsem kecal a že mám nejnovější proj ;-)

Udělal jsem testy podle té stránky 
http://freegis.fsv.cvut.cz/gwiki/S-JTSK_/_Grid a dostal jsem naprosto stejné 
výsledky, jaké se očekávají na oné 
stránce, a to jak v postgisu tak cs2cs.

Dne Ne 8. ledna 2017 23:53:11, Petr Morávek [Xificurk] napsal(a):

> Opravdu to vypadá, že ČUZK transformaci do EPSG:4236 dělá blbě a vzniká
> tam dodatečná chyba.

Jako že my to máme dobře a ČÚZK špatně? Oó B-)

--
Petr


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

Re: [Talk-cz] RUIAN posun - konečné řešení?

2017-01-03 Tema obsahu Petr Vejsada

Dne Út 3. ledna 2017 20:38:14, Petr Vejsada napsal(a):

> Pustím se teď do toho Seidlova díla.

Výsledek víceméně stejný, ale nemám dost nový proj, abych mohl dát +czech.

Upgrade proj-> rekompilace geos,gdal, postgis etc., možná v noci.

Petr


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

Re: [Talk-cz] RUIAN posun - konečné řešení?

2017-01-03 Tema obsahu Petr Vejsada

Ahoj,

příloha. KM, růžové jsou transformací z 5514 tak, jak je v postgisu, tedy 7 
prvková transformace. Oranžové jsou přes grid, odkazovaný v mé zprávě.

Pustím se teď do toho Seidlova díla.

Dne Út 3. ledna 2017 09:15:09, Petr Morávek [Xificurk] napsal(a):

> Ahoj,
> 
> mohl bys prosím poslat konkrétní příklad, kde je vidět posun, o kterém
> mluvíš? Mám pocit, že se v tomhle vlákně míchá více věcí dohromady -
> jeden o voze, druhý o koze ;)
> Ideálně nějaký obrázek s dvěma vrstvama a popisem, z jakého zdroje a
> jakými transformacemi vznikly.
> 
> S pozdravem,
> Petr Morávek aka Xificurk
> 
> Dne 1.1.2017 v 13:16 Petr Vejsada napsal(a):
> > Ahoj po čase :-)
> > 
> > nejprve chci moc poděkovat všem podporovatelům, penízky se opravdu hodí.
> > Díky moc.
> > 
> > Na poloha.net proběhl před nějakou dobou dlouho slibovaný major upgrade a
> > je zaktualizované vše, od OS přes post[gres|gis], mapnik etc., vlastně
> > instalováno from scratch znovu, aby se vše pročistilo. Mapnik je tedy
> > chytřejší a pokus se zdá, že je pomalejší, tak to zcela určitě je :(. To
> > se vědělo už dříve.
> > 
> > K tématu - pokusně jsem obnovil TMS vrstvu budovy-grid a zdá se, že s
> > úplně
> > stejným (blbým) výsledkem, jako byly pokusy před dvěma lety.
> > 
> > Grid stažený z
> > http://web.archive.org/web/20091003020944/http://git.zcu.cz/grid/czech.lla
> > .
> > 
> > Zavedl jsem švindl projekci se SRID 999, která zní:
> > 
> > +proj=krovak +lat_0=49.5 +lon_0=24.83 +alpha=30.2881397222
> > +k=0. +x_0=0 +y_0=0 +ellps=bessel +nadgrids=cze
> > ch +pm=greenwich +units=m +no_defs
> > +towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56
> > 
> > Transformaci tabulky s budovami jsem provedl příkazem:
> > 
> > update grid set hranice=
> > (st_transform(st_setsrid(st_transform(hranice,5514),999),900913));
> > 
> > tedy - z 900913, ve které mám RUIAN uložen, transformace zpět na 5514 a
> > odtud transformace zpět na 900913 přes grid.
> > 
> > Výsledek na tile.poloha.net vrstva budovy-grid, zobrazitelné na
> > http://ruian.poloha.net.
> > 
> > Vrstva http://tile.poloha.net/budovy-grid/{z}/{x}/{y}.png
> > 
> > Zkoušel jsem i do pokusného schematu čerstvě importovat Jablunkov, je to
> > stejné, jako když udělám výše uvedenou transformaci, tedy blbě.
> > 
> > 
> > Takže od počátku roku 2014, kdy jsme dělali tyto pokusy, jsme se nikam
> > neposunuli :-)
> > 
> > Jinak v novém postgisu/proj už je definice Křováka 5514, u ostatních
> > Křováků toliko poznámka:
> > 
> > --- EPSG 5515 : S-JTSK/05 / Modified Krovak
> > ---
> > -- (unable to translate)
> > ---
> > --- EPSG 5516 : S-JTSK/05 / Modified Krovak East North
> > ---
> > -- (unable to translate)
> > ---
> > 
> > Tak jestli někoho napadlo, proč se to pořád posunuje opačným směrem, než
> > bychom čekali ...
> > 
> > 
> > A PF 2017!
> > 
> > --
> > 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] RUIAN posun - konečné řešení?

2017-01-01 Tema obsahu Petr Vejsada

Ahoj po čase :-)

nejprve chci moc poděkovat všem podporovatelům, penízky se opravdu hodí. Díky 
moc.

Na poloha.net proběhl před nějakou dobou dlouho slibovaný major upgrade a je 
zaktualizované vše, od OS přes post[gres|gis], mapnik etc., vlastně 
instalováno from scratch znovu, aby se vše pročistilo. Mapnik je tedy 
chytřejší a pokus se zdá, že je pomalejší, tak to zcela určitě je :(. To se 
vědělo už dříve.

K tématu - pokusně jsem obnovil TMS vrstvu budovy-grid a zdá se, že s úplně 
stejným (blbým) výsledkem, jako byly pokusy před dvěma lety.

Grid stažený z 
http://web.archive.org/web/20091003020944/http://git.zcu.cz/grid/czech.lla .

Zavedl jsem švindl projekci se SRID 999, která zní:

+proj=krovak +lat_0=49.5 +lon_0=24.83 +alpha=30.2881397222 
+k=0. +x_0=0 +y_0=0 +ellps=bessel +nadgrids=cze
ch +pm=greenwich +units=m +no_defs 
+towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56

Transformaci tabulky s budovami jsem provedl příkazem:

update grid set hranice= 
(st_transform(st_setsrid(st_transform(hranice,5514),999),900913));

tedy - z 900913, ve které mám RUIAN uložen, transformace zpět na 5514 a odtud 
transformace zpět na 900913 přes grid.

Výsledek na tile.poloha.net vrstva budovy-grid, zobrazitelné na 
http://ruian.poloha.net.

Vrstva http://tile.poloha.net/budovy-grid/{z}/{x}/{y}.png

Zkoušel jsem i do pokusného schematu čerstvě importovat Jablunkov, je to 
stejné, jako když udělám výše uvedenou transformaci, tedy blbě.


Takže od počátku roku 2014, kdy jsme dělali tyto pokusy, jsme se nikam 
neposunuli :-)

Jinak v novém postgisu/proj už je definice Křováka 5514, u ostatních Křováků 
toliko poznámka:

--- EPSG 5515 : S-JTSK/05 / Modified Krovak
---
-- (unable to translate)
---
--- EPSG 5516 : S-JTSK/05 / Modified Krovak East North
---
-- (unable to translate)
---

Tak jestli někoho napadlo, proč se to pořád posunuje opačným směrem, než 
bychom čekali ...


A PF 2017!

--
Petr

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

Re: [Talk-cz] osmap.cz: Tur. trasa zobrazovaná tam, kde není ani v datech

2016-10-10 Tema obsahu Petr Vejsada

Ahoj všem,

díky Mariánovi za upozornění. Jednalo se o chybu, takovou tu hnusnou, 
která se projeví jen výjimečně.

Stručně řečeno, pomíchaly se jabka s hruškami, tedy nodes a ways. V jisté 
tabulce pro Mapnik, ze které se ty tur. cesty počítají, je sloupec s 
názvem parts. Ten obsahuje seznam osm_id, které jsou součástí relace. 
Nevím proč, asi z historických důvodů (?) jsou tam opravdu jen osm_id (bez 
specifikace, zda se jedná o node nebo way). A tak se pomíchaly nodes a 
ways tak, že node, který má stejné osm_id jako předmětná way, je členem 
relace, kterážto je turistickou trasou. Proto se tam ty barvy vykreslily.

Chyba opravena, týkala se tří cest.

Overlay turistických tras se překresluje každý den, trvá to chvilku. Teď 
jsem ho kvůli té chybě překreslil také, takže overlay je už správně. 
Základní turistická mapa bude překreslena dnes (úterý) dopoledne.

Dne Út 4. října 2016 07:54:51, Marián Kyral napsal(a):

> Divné, divné. Trasy se už obnovily (změny co jsem dělal v sobotu tam už
> jsou), v datech na téhle ulici žádné relace nejsou, ale stejně se tam
> zobrazuje modrá a žlutá.
> 
> Petře,
> můžeš se na to prosím kouknout?
> 
> 
> 
> https://openstreetmap.cz/#map=17/49.02545/14.48029&layers=dKAGB
> (https://openstreetmap.cz/#map=17/49.02545/14.48029&layers=dKAGB)
> 
> http://www.openstreetmap.org/way/262117266
> 
> Díky,
> Marián
> 
> 
> -- Původní zpráva --
> Od: Marián Kyral 
> Komu: OpenStreetMap Czech Republic 
> Datum: 30. 9. 2016 11:47:24
> Předmět: Re: [Talk-cz] osmap.cz: Tur. trasa zobrazovaná tam, kde není 
ani v
> datech
> 
> "
> No může to být nějaká chyba, která už je opravena. Ovšem vrsta 
"Turistické
> trasy ČR" se obnovuje jen každých pár dní, takže to tam ještě visí. Je
> docela pravděpodobné, že to zase brzo samo zmizí.
> 
> Bohužel přidání cesty do relace nijak nemění historii té cesty, jen 
relace,
> takže pokud to mezitím zase někdo smazal, tak už to asi není jednoduše
> dohledatelné. Leda si stáhnout změny za posledních pár dní a pohledat v
> nich.
> 
> Marián
> 
> 
> -- Původní zpráva --
> Od: majka 
> Komu: talk-cz@openstreetmap.org
> Datum: 30. 9. 2016 10:46:18
> Předmět: [Talk-cz] osmap.cz: Tur. trasa zobrazovaná tam, kde není ani v
> datech
> 
> "
> 
> 
> 
> 
> 
> Mohl byste se prosím někdo podívat na to, proč se mi ukazuje na https://
> openstreetmap.cz/#map=17/49.02545/14.48029&layers=dKAGB
> (https://openstreetmap.cz/#map=17/49.02545/14.48029&layers=dKAGB) tur. 
trasa
> (resp. dvě, modrá a žlutá) tam, kde žádná není a v datech jí nevidím, a 
ani
> nevidím nějakou nedávnou změnu?
> 
> 
> Jedná se o ulici Na Babě, kterou na rozdíl od zobrazení "Turistické 
trasy
> EU" zobrazují "Turistické trasy ČR" modrožlutě.
> 
> 
> Bohužel se mi to nedaří najít ani v historii změn - nabíhá tam spousta
> balastu okolo.
> 
> 
> Díky.
> 
> Majka
> 
> 
> ___
> 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] Kde má být adresa?

2016-03-24 Tema obsahu Petr Vejsada

Ahoj,

V RÚIAN je adresa úplně nesmyslně prakticky v Ruské ulici. V OSM je, koukám, 
dvakrát - jednou na tom ředitelství a podruhé v Ruské na místě, kde je v 
RÚIAN.

V RÚIAN náleží ta adresa k budově ředitelství. No, pěkný zmatek.

IMO je nejlepší umístění tam, kde to předpokládáš, tedy u vjezdu vrátnice.


Dne Čt 24. března 2016 16:44:23, Matěj Cepl napsal(a):

> Dobrý den,
> 
> vytvořil jsem právě http://www.openstreetmap.org/note/532505 ...
> kde má být správně adresa? V tomto případě je v OSM adresa
> Šrobárova 50 hluboko v areálu nemocnice (byť je to budova
> ředitelství), přičemž cedulka samotná je pochopitelně na ulici
> vedle vrátnice
> (https://mcepl.fedorapeople.org/tmp/p20140831_175826.jpg)
> 
> Ne, že by to bylo nějak zásadní, spíše jsem zvědavý.
> 
> Matěj

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

[Talk-cz] Planovane omezeni provozu tuto noc

2016-03-21 Tema obsahu Petr Vejsada

On Tuesday morning March 22nd between 01:00 and 03:00 CEST maintenance will
take place in the cluster in which your VPS is hosted. In the past weeks a bug
was discovered in the firmware of the redundant switches in this cluster.
During this maintenance the firmware of the switches will be replaced in turns.
This will cause a failover to occur between switches.

Due to this failover your VPS could briefly suffer from decreased accessibility.
Afterwards the connectivity of your VPS will automatically be restored.
No response is required from your part.

Kind regards,
TransIP

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

Re: [Talk-cz] RUIAN chybejici budovy - rozsireni

2016-03-15 Tema obsahu Petr Vejsada

Zdravim,

existuje http://osm.poloha.net/buildings_source_stats.csv , coz je statistika 
celkem
za celou CR podle source (km, ruian), to asi nestaci,;-)

K cemu to ma byt uzitecne? K doplnovani techto tagu? Proc?

Ptam se, protoze je to opet spousta pocitani, zjistovat
u nekolika milionu budov, na kterem katastralnim uzemi lezi je
docela narocne.

--
Zdravi
Petr

On Tue, Mar 15, 2016 at 09:25:47AM +0100, Janda Martin wrote:
> Dobry den,
> 
>   nevim jestli je toto spravne misto. Ale bylo by mozne na strance 
> http://ruian.poloha.net/budovy/ doplnit sloupec s poctem budov ktere nejsou 
> definovany pres RUIAN.
> 
> Tzn. maji definovano building=* a zaroven chybi nektery z nasledujicich tagu
> "building:ruian:type"
> "ref:ruian:building"
> 
>   Dekuji
>   Martin
> 
> ___
> 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] Data IPR Praha

2016-03-04 Tema obsahu Petr Vejsada

Ahoj,

ty záchody jsou i na Geoportálu Praha jako otevřená data.

--
Petr

Dne Pá 4. března 2016 23:18:45, Martin Landa napsal(a):

> > Zkusil jsem si je cvičně naimportovat do uMap - zde je výsledek:
> > http://umap.openstreetmap.fr/cs-cz/map/import-ipr_74319
> 
> pouze na okraj, pripominam, ze soucasna licence dat IPR neumoznuje
> jejich zacleneni do OSM. Martin

___
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)

2016-02-26 Tema obsahu Petr Vejsada

Ahoj,

to nejsou žádné mrakodrapy, to jsou přízemní domky. Opravdový mrakodrap mají 
kousek od Temelína, http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/79519385

:) (2571 pater)

--
Petr

Dne Pá 26. února 2016 14:27:37, Jan Martinec napsal(a):

> celkem náhodou jsem v mapě našel tuhle skupinu mrakodrapů v Praze na
> Košíku:

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

Re: [Talk-cz] Renderování turistických značek

2016-02-24 Tema obsahu Petr Vejsada

On Tue, Feb 23, 2016 at 11:09:26PM +0100, Petr Vejsada wrote:

> koukám na to a je to tak, že mezinárodní trasy (iwn nebo e-road) přeplácnou 
> ty 
> místní. Něco s tím udělám.

uz jsem udelal :)

--
Petr

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

Re: [Talk-cz] Renderování turistických značek

2016-02-23 Tema obsahu Petr Vejsada

Ahoj,

koukám na to a je to tak, že mezinárodní trasy (iwn nebo e-road) přeplácnou ty 
místní. Něco s tím udělám.

--
Petr

Dne Út 23. února 2016 22:29:15, Miroslav Suchý napsal(a):

> Pokud je pochybnost o datech tak doporucuji rychle skouknout i mtbmap:
>   http://mtbmap.cz/#zoom=15&lat=49.78256&lon=14.18019
> kde je videt ze ty znacky jsou tam dobre. A tam kde osmap.cz kresil
> cervene, tak je cyklotrasa. Takze bych to videl ze cyklotrasa prekrila
> turistickou trasu.

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

Re: [Talk-cz] Cyklostezky na taskmanovi

2016-02-23 Tema obsahu Petr Vejsada

Ahoj,

> Jedna technická - proč se v tomto tasku nezobrazuje jako výchozí nějaká
> mapa s cyklotyrasami?
> Mám tam turistickou a nevidím, jak to změnit...

protoze jsme se jeste nedomluvili, jake vrstvy tam maji byt :-).

Nelze menit mapy pro jednotlive projekty. Da se to udelat jen globalne
a na zacatku prace si vybrat, s jakou mapou dale pracovat. Dejte vedet,
jake vrstvy/mapy maji na Taskmanu byt k dispozici a hned je tam nandam.

--
Petr

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

Re: [Talk-cz] Jak mapovat turistickou znacku pres parkoviste

2016-02-21 Tema obsahu Petr Vejsada

Ahoj,

určitě highway-virtual. Je to nutné k tomu, aby se cesta vůbec dostala do 
tabulky Mapniku, aby ji tam osm21pgsql dal. Když v tabulce nebude, nebude se 
mít jak vykreslit. Už se řešily lyžařské trasy, které v létě neexistují, 
prostě tam není žádná cesta a toto je řešení i pro ty lyžařské trasy.

--
Petr


Dne Ne 21. února 2016 14:32:58, Pavel Machek napsal(a):

> highway=virtual zni jako dobry reseni.
> 
> Pripadne... ta vyznacena cesta nemusi mit zadny highway tag, ze?
> Proste dat do relace cestu bez tagu.
> 
> (Ale highway=virtual je asi lepsi.)

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

Re: [Talk-cz] Vojenské újezdy

2016-01-20 Tema obsahu Petr Vejsada

Ahoj,

super, díky moc. Mně to vlastně nevadilo, aktualizace adres (zda leží na území 
obce) se checkuje vůči RÚIAN a tam je to už po novu. Zdá se, že se adresy 
zaktualizovaly, jak měly.

Pěkné :-)

No a nešťastníci mají posledních pár dnů na podání přiznání k dani z 
nemovitostí.

--
Petr

Dne St 20. ledna 2016 21:49:34, Petr Morávek [Xificurk] napsal(a):

> Právě jsem překontroloval/doplnil úpravy Libavé, Březiny, Hradiště a
> Boletic.
> 
> Zbývá dořešit Brdy

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

Re: [Talk-cz] co s traceristy?

2016-01-19 Tema obsahu Petr Vejsada

Ahoj,

Dne St 20. ledna 2016 07:04:48, Vladimír Domes napsal(a):

> K tomuto tématu bych přidal otázku, jestli je možné někam hlásit chybné
> building:levels při importu z Traceru? Tento typ chyby na
> http://ruian.poloha.net/building.php nyní není.

už je. Prosím o vyplňování poznámky, pokud je to jen trochu možné. Napsat 
reálný počet podlaží a pokud možno zjistit a napsat sem, co ČÚZK rozumí 
podlažím - zda jde o nadzemní podlaží nebo třeba i podzemní ... abychom 
negenerovali falešná chybová hlášení.

--
Petr


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

Re: [Talk-cz] zobrazení turististických stezek ve výřezu na old.openstreetmap.cz

http://poloha.net:8080/vector/z/x/y.json

př. http://poloha.net:8080/vector/14/8847/5549.json

- jsou tam teď jen shopy, shop= a jsou to POI
- beží to jen na ipv4

ale na pokusy to může teď stačit.

samozřejmě časem to poběží na normálním portu pod něčím výkonnějším než 
builtin web server.

Mám ale 100 chutí tu TileStache vyhodit a dát tam něco malého třeba v PHP. Ono 
vlastně stačí přepočítat adresu dlaždice na koordináty a pak z toho vyprsknout 
json. Ten Python je ...

uvidíme.

Dnes končím.

--
Petr

Dne Ne 10. ledna 2016 17:35:16, Marián Kyral napsal(a):

> Jako je mi jasné jak to funguje pro jednotlivé body. Ale jak to má
> fungovat pro vektory, které přesahují do vedlejších dlaždic, budu muset
> zjistit.

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

Re: [Talk-cz] zobrazení turististických stezek ve výřezu na old.openstreetmap.cz

Ahoj,

Dne Ne 10. ledna 2016 16:03:08, Marián Kyral napsal(a):

> Takže nemáš nic proti tomu, kdybych udělal nějaké nové servisy, které by
> se využívaly na nových openstreetmap.cz?

Naopak, budu rád, když bude další využití.

> 
> Kromě toho seznamu turistických tras ve výřezu bych ještě chtěl vrstvu
> aktivních bodů (rozcestníky, restaurace, obchody - cokoli co má smysl).
> Viz: https://github.com/osmcz/osmcz/issues/4

Jj, http://openstreetbrowser.org - dávný projekt, který, bohužel, funguje čím 
dál tím hůř :-(. Dnes tedy IMO nefunguje vůbec. Jinak ve chvílích, kdy 
částečně funguje, dělá přesně to, o čem je tato issue. Vybereš si kategorie 
zájmu, zobrazí se ve sloupci, co je v okolí, klikací pointy, otevírací doba 
restaurací atd. Zkoušel jsem to několikrát zprovoznit, ale byla to jen ztráta 
času :-(

> Hlavně bych to chtěl udělat jako dlaždice - tedy x/y/z.json
> 
> Akorát jsem se momentálně zasekl - už druhý den hledám nějaký prográmek,
> který by mi jeden velký geojson soubor rozsekal na dlaždice. Ovšem buď
> je to tak primitivní, že si to každý udělá sám nebo si to generují
> rovnou z PG:
> http://tilestache.org/doc/TileStache.Goodies.Providers.PostGeoJSON.html
> 
> Nemáš nějakou zkušenost nebo radu?

Okrajově jsem se tím zabýval, ale nikam jsem to moc nedotáhl. Upřímně moc 
nechápu, jak vektorové dlaždice fungují - co když mám třeba veliký polygon 
lesa, tak co bude na té vektorové dlaždici, když mám zobrazen jen malý kousek 
toho lesa? Jen kousek lesa? Jak? Vždyť je to veliký polygon. Nebo celý 
polygon, i když zobrazuji na mapě jen 50 metrů? Bude na té dlaždici třeba celá 
hranice světadílu?

Potřeboval bych trochu edukaci taky :-).

Dál asi na githubu.

--
Petr


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

Re: [Talk-cz] zobrazení turististických stezek ve výřezu na old.openstreetmap.cz

Dne Ne 10. ledna 2016 14:35:21, Petr Vejsada napsal(a):

> Pokud by ti toto či něco podobného k něčemu bylo, dej vědět.
> 
> Třeba http://postgis.net/docs/ST_AsGeoJSON.html

Ostatně geojson nám tu funguje už hodně dlouho pro Josm tracer a Pointinfo - 
například si zkus:

http://josm.poloha.net/ruian-buildings/?req=full&lat=49.1439&lon=15.0385

--
Petr


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

Re: [Talk-cz] zobrazení turististických stezek ve výřezu na old.openstreetmap.cz

Dne St 30. prosince 2015 13:45:03, Michal Grézl napsal(a):

> Mozna kdyby nekdo vymyslel query, ktera bude vracet kml, tak bych to
> tam mohl priplacnout.

Ahoj,

no já se tu pořád nabízím, ale bud si to nikdo nepamatuje nebo není zájem?

http://postgis.net/docs/ST_AsKML.html

Příklad:

select st_askml(2,way,3,'route=' || route) from gis.cz_kct limit 1;

 13.801,49.592 13.801,49.592 
13.803,49.593 13.805,49.593 13.806,49.593

(1 řádka)

Pokud by ti toto či něco podobného k něčemu bylo, dej vědět.

Třeba http://postgis.net/docs/ST_AsGeoJSON.html

--
Petr




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

Re: [Talk-cz] Aktualnost dat - poloha.net a old.osm.cz

Ahoj,

DATA jsou OK, vždy ráno z geofabrik. Info o aktuálnosti dat je na hlavní 
stránce http://poloha.net v levém sloupci hned nahoře.

Problém asi bude s dlaždicemi - každý den, po přijetí nových dat z geofabrik 
se mažou dlaždice zoomu 16-20. Ty se pak překreslí v snad přijatelném čase cca 
2 vteřin. Dlaždice do zoomu 15 včetně jsou na disku nakešované a samy o sobě 
se nepřekreslují; jen na spuštění kreslení z příkazového řádku. Funguje 
/dirty .

Mod_tile umí něco jako "autodirty". Je soubor planet-import-complete, jehož 
timestamp se porovnává s timestampem dlaždice. Pokud někdo požaduje dlaždici, 
která je starší než planet-import-complete, spustí se renderování. Uživatel 
ovšem dostane starou verzi dlaždice a novou verzi dostane až při dalším 
požadavku, bude-li do té doby dlaždice vykreslena. Metadlaždice zoomu 11 se 
vykresluje asi půl minuty a když jich bude ve frontě 10, tak holt 5 minut. 
Zkusil jsem to teď zapnout na dlaždice zoomu 11-15.

Tedy aktuální stav je:
- dlaždice 0-10 se překreslují jen z commandline
- dlaždice 11-15 autodirty
- dlaždice 16-20 jsou stále aktuální (mažou se z cache po zpracování nových 
dat)

Jinak když mluvím o dlaždicích v cache, tak mám na mysli meta-dlaždice 8x8=64 
normálních dlaždic. Používám Tirex http://wiki.openstreetmap.org/wiki/Tirex .

Osm2pgsql má funkci na exspirování dlaždic. Funguje tak, že při importu změn 
vygeneruje seznam bboxů, které se mají překreslit. Tuto funkci jsem použival, 
je to mnoho měsíců (let) zpět. Funkce jednak dosti zdržovala import a její 
spolehlivost byla nevalná - často exspirovala kusy území zbytečně a naopak - 
nechala být území, kde došlo k podstatným změnám. Možná se v osm2pgsql něco v 
tomto směru zlepšilo, ale moc tomu nevěřím.

Poslední variantou je dlaždice například 14-15 každý den překreslovat. Můžu se 
zkusit zeptat TransIP, co oni na to :-), docela pěkně a svižně to tu funguje, 
tak si nechci hledat další hosting.

--
Petr


Dne Ne 10. ledna 2016 11:37:16, Tom Ka napsal(a):

> Jeste jednu vec jse ted narazil. Chtel jsem zkontrolovat nejake sve
> zmeny (napr. vytvoreni http://www.openstreetmap.org/way/389382702), na
> osm.org je v pohode, ale na ruian.poloha.net (podle webu data z
> 9-1-2016) neni. Krome toho jsem nikde nenasel info o aktualnosti dat z
> old.osm.cz (zde pri nahravani casto kontroluju stav dat i kdyz vim, ze
> nebyva uplne cerstve).
> 
> Muzu tedy poprosit Petra Vejsadu o kontrolu aktualnosti dat a Michala
> Grezla o info o aktualizacich dat pro old.osm.cz (idealne s infem o
> verzi dat primo na webu).
> 
> Diky moc.
> 
> ___
> 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] polder vykreslený jako vodní plocha

2016-01-09 Tema obsahu Petr Vejsada

Ahoj,

do kódu jsem hleděl:


 [landuse] = 'basin'
 


tedy vykresluje se basin bez ohledu na další vlastnosti. Sušiny v datech jsou, 
jenže nejsou v relaci k tomu basin. Basin by měl být outer a ty spousty sušin, 
co jsou v datech, jako inner.

Plus upravit filter.

--
Petr


Dne So 9. ledna 2016 16:22:17, Pavel Pilát napsal(a):

> Ahojte,
> 
> narazili jsme na zajímavý jev: kousek od Ostravy v Polsku je jezero, ve
> kterém jsou polní cesty a lesíky. :-D
> 
> http://www.openstreetmap.org/#map=14/49.9794/18.2909
> 
> Na fotomapě je ovšem vidět, že ve skutečnosti je tam mnoho samostatných
> jezírek a mezi nimi ty cesty:
> 
> https://www.google.com/maps/@49.9835285,18.3034242,5288m/data=!3m1!1e3
> 
> 
> No, je evidentní, že za to může vykreslování tagu landuse=basin - celá
> oblast slouží jako polder pro potřebu zachycení vodního přívalu a je tedy
> vlastně korektně otagovaná. Zde wiki pro tento tag:
> 
> http://wiki.openstreetmap.org/wiki/Cs:Tag:landuse%3Dbasin
> 
> Chyba je tedy v Mapniku, který suchou oblast, která je zaplavená jen
> vyjímečně, vykresluje jako vodní plochu a tím vzniká nesmysl s cestama ve
> vodě. Dá se s tím něco dělat? :)
> 
> 
> Pavel

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

Re: [Talk-cz] Multipolygony lesů - převod starého tagování na nové

2015-12-07 Tema obsahu Petr Vejsada

Dne Po 7. prosince 2015 21:55:56, Marián Kyral napsal(a):

> Kurde. Já mám dneska den. Samý kostlivec

:-), ta fce v Postgre je hotová a stále funguje. Stačí jí jen pustit a na 
výstupu z ní je changeset a ten stačí jen uploadnout. To uploadnutí si ale 
nikdo nedovolil. Nebo jen 2-3 lesy, už nevím. import.relforests()

--
Petr


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

Re: [Talk-cz] Multipolygony lesů - převod starého tagování na nové

2015-12-07 Tema obsahu Petr Vejsada

Ahoj,

už zase? :-)

thread začíná 
https://lists.openstreetmap.org/pipermail/talk-cz/2014-September/010728.html

Ale třeba nová aktivita bude úspěšnější. Odkazuji dle pravidla, že před každou 
vědeckou prací je nutné prostudovat dostupnou literaturu :)

--
Petr

Dne Po 7. prosince 2015 20:41:42, Marián Kyral napsal(a):

> Ahoj,
> jak se díváte na hromadnou opravu tagování multipolygonů. Z varianty
> landuse=forest na outer hranici(ích) na variantu landuse=forest na relaci?
> Zdá se, že některé rendery mají problém v případě, že outer roli má více
> cest:
> http://www.geocaching.cz/topic/25018-offline-turistick%C3%A1-mapa-pro-androi
> d/page-31#entry516431 Sice bychom mohli říci, že tohle je problém těch
> rendererů, ale vzhledem k tomu, že je to tagování zastaralé, bylo by asi
> lepší to opravit.
> 
> A dokáže někdo sestavit overpass query, která by našla všechny lesní
> multipolygony , které na relaci nemají tag landuse, ale mají jej na
> outer cestě? Mně se to nějak nedaří.
> 
> Marián


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

Re: [Talk-cz] Geofabrik

2015-12-07 Tema obsahu Petr Vejsada

Ahoj,

jj, také to vidím opravené. Co se dělo, nevím.

--
Petr

Dne Po 7. prosince 2015 08:11:23, Janda Martin napsal(a):

> Dorby den,
> 
>   u me se to tvari normalne 998.osm.gz ma 824kB. Asi uz je to opravene.
> 
>   M
> 
> - Original Message -
> From: "Petr Vejsada" 
> To: talk-cz@openstreetmap.org
> Sent: Sunday, December 6, 2015 12:40:16 PM
> Subject: [Talk-cz] Geofabrik
> 
> Ahoj všem,
> 
> něco se asi rozbilo na Geofabrik. Dnešní změnový soubor má 1 GB, normálně má
> 1000x méně, tedy necelý 1 MB. Kompletní data mají normálně skoro 600 MB,
> dnešní kompletní data mají 91 MB. Namátkou jsem se podíval na Ukrajinu a
> tam je to obdobné. U Polska taky.
> 
> Název dnešního změnového souboru je 998, přičemž názvy jsou 001, 002 atd.
> Možná to souvisí s nadcházejícím "přetečením" toho číslování změnových
> souborů, neb přetečení je za dveřmi.
> 
> Jelikož $TMP mám 512 MB, tak se to nenahrálo, což je jen dobře.
> 
> Nečetli jste někdo někde o tomto problému?
> 
> http://download.geofabrik.de/europe/czech-republic-updates/000/000/
> 
> 998.osc.gz má 1 GB.


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

[Talk-cz] Geofabrik

2015-12-06 Tema obsahu Petr Vejsada

Ahoj všem,

něco se asi rozbilo na Geofabrik. Dnešní změnový soubor má 1 GB, normálně má 
1000x méně, tedy necelý 1 MB. Kompletní data mají normálně skoro 600 MB, 
dnešní kompletní data mají 91 MB. Namátkou jsem se podíval na Ukrajinu a tam 
je to obdobné. U Polska taky.

Název dnešního změnového souboru je 998, přičemž názvy jsou 001, 002 atd. 
Možná to souvisí s nadcházejícím "přetečením" toho číslování změnových 
souborů, neb přetečení je za dveřmi.

Jelikož $TMP mám 512 MB, tak se to nenahrálo, což je jen dobře.

Nečetli jste někdo někde o tomto problému?

http://download.geofabrik.de/europe/czech-republic-updates/000/000/

998.osc.gz má 1 GB.

--
>p<


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

Re: [Talk-cz] Fwd: Hromadná reklamace stavebních objektů

2015-12-01 Tema obsahu Petr Vejsada

Ahoj,

Dne Út 1. prosince 2015 10:16:54, jzvc napsal(a):

> Jinak co takhle adresni bod vs ulice ... opakovane narazim na takove,
> ktere jsou kilometry od nejblizsi ulice toho jmena.

nj, teoreticky to jde, jenže kde vezmeme tu vědomost, že ulice má existovat a 
že to není jen zapomenutá neexistující ulice v adrese? Šlo by třeba spočítat 
adresy s danou ulicí a když > 10, doplnit ulici. Na to tam mají možnost:


 
  Národní
  549240
  Doplnění chybějící ulice v obci Písek.
 


Za velmi vtipné ovšem považuji toto:




to je přeci jeden SQL dotaz, respektive jeden update ... na to není třeba 
vymýšlet reklamační formulář...

> BTW: sme v tech reportovanych schopny detekovat, ze se v RUIAN neco
> pripadne zmenilo?

No, jo i ne. Kdybych se nestěhoval k TransIP nebo byl moudřejší, tak jo, ale 
teď těžko. U každého záznamu v DB je sloupec item_timestamp, což je čas 
poslední modifikace záznamu v DB. U adres jsem byl moudrý a tento sloupec mám 
schovaný v extra tabulce. U domů jsem to schované bohužel neměl, takže při 
reimportu RÚIANu se samozřejmě tyto hodnoty přepsaly na aktuální datum a tedy 
v okamžiku importu byly všechny SO v RÚIAN "novější" než ty naše záznamy. 
Ostatně je to vidět na http://ruian.poloha.net/neplatne-budovy/ , kde je skoro 
všude v prvním sloupci vykřičník v trojúhelníku, což znamená, že došlo ke 
změně od našeho zápisu. Ke "změně" ovšem došlo protože jsem nahrával znova 
RÚIAN :(. Mohl bych to vyhodnocovat podle sloupce plati_od, ale ten není 
spolehlivý.

Někdy od července v okamžiku zapsání do chybných budov ukládám do DB i původní 
geometrii s vizí mít možnost porovnat, jak budova vypadala v okamžiku zápisu a 
jak vypadá aktuálně. To by ovšem musel někdo nakódovat to zobrazování, já fakt 
časově nemůžu. A aby nebylo smůly málo, tak ty uložené geometrie se nejspíš 
všechny liší od geometrií uložených v tabulkách RÚIAN. Nejspíš to bude proto, 
protože při stěhování jsem trochu upgradoval, takže je nový Proj, GDAL, GEOS 
atd. a nejspíš při transformaci z Křováka se to vypočítalo o nějaké miliontiny 
jinak.

Jediným spolehlivým indikátorem, že se něco změnilo, by tedy byla situace, kdy 
plati_od je novější než datum zápisu do naší tabulky nebo se podívat, jestli 
by se našla v Postgisu nějaká pěkná funkce, že geometrie se od sebe liší o 
více než X procent. To by mělo zahrnout jak posun na jiné místo tak změnu 
tvaru.

Takže takováto je situace.

Jo, těch baráku, co mají novější plati_od než je datum zápisu je 21:

   kod|   datum|  plati_od
--++
 45445354 | 20.06.2015 | 26.06.2015
 21000280 | 01.12.2014 | 09.02.2015
 39296091 | 02.12.2014 | 08.02.2015
  8379009 | 07.12.2014 | 03.04.2015
 46833251 | 10.12.2014 | 28.04.2015
 39581187 | 19.12.2014 | 12.06.2015
 50163779 | 21.12.2014 | 07.02.2015
 46575065 | 01.12.2014 | 19.11.2015
 14350173 | 25.12.2014 | 07.02.2015
 18930379 | 26.12.2014 | 04.05.2015
 39599019 | 16.02.2015 | 02.03.2015
  6999549 | 02.06.2015 | 25.09.2015
 21812101 | 11.12.2014 | 25.05.2015
 27279812 | 12.12.2014 | 22.06.2015
 44142455 | 16.05.2015 | 16.06.2015
 46088563 | 25.12.2014 | 15.09.2015
 44045298 | 25.12.2014 | 08.02.2015
 44409109 | 29.12.2014 | 03.07.2015
 38370468 | 16.05.2015 | 17.06.2015
 43999671 | 16.05.2015 | 11.11.2015
 45166374 | 29.09.2015 | 27.10.2015
(21 řádek)

takže na ty se můžeme podívat a eventuálně ze seznamu smazat, pokud jsou 
doopravdy opravené.

--
Petr


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

[Talk-cz] Fwd: Hromadná reklamace stavebních objektů

2015-11-30 Tema obsahu Petr Vejsada

Ahoj,

tento vtipný článek

http://zpravy.idnes.cz/aktiviste-softwarem-odhalili-tisice-chyb-uradu-f5c-/domaci.aspx?c=A151130_145927_domaci_zt

mi připomněl, že ČÚZK si nejspíš také zaslouží zahltit a nejspíš poslat
reklamaci do datovky, aby se "neztratila" ;-)

Můj mail s dotazem samozřejmě bez jakékoli reakce, nepočítám-li reakci robota,
ujišťujícího mě, že se mému podání budou ihned věnovat.

Pane Součku, neporadil byste, s kým se domluvit?

-- Přeposlaná zpráva --

Předmět: Hromadná reklamace stavebních objektů
Datum: Út 17. listopadu 2015, 10:26:31
Od: Petr Vejsada
Komu: c...@cuzk.cz

Dobrý den,

jsem členem komunity OpenStreetMap, zabýváme se mimo jiné mapováním budov.
Jedním ze zdrojů je i registr RÚIAN. Již více než rok vedeme databáze s
chybnými stavebními objekty, do které tyto objekty zapisujeme. Momentálně čítá
vice než 2000 chybných stavebních objektů. Seznam můžete vidět na
http://ruian.poloha.net/neplatne-budovy/ .

Všiml jsem si, že už je možné podat hromadnou reklamaci přes XML soubor na
http://reklamace.cuzk.cz/formular/index.php?source=R%C3%9AIAN&presenter=Advanced

. Rád bych této možnosti využil a chci se s Vámi domluvit, co by bylo
nejvýhodnější. Mám tím na mysli, zda zda zaslat jeden soubor či soubor
rozdělit podle území (například podle okresů či krajů).

Mimo výše uvedený seznam evidujeme tisíce stavebních objektů, u kterých je
definiční bod daleko od vlastního polygonu - největší vzdálenost definičního
bodu od polygonu budovy je přes 6 kilometrů. Tyto případy si jistě můžete
zjistit sami vhodným dotazem do Vaší databáze. Měl bych toto zahrnout do
reklamace?

Další věcí jsou případy, kdy uvnitř polygonu budovy se nachází definiční bod
jiného stavebního objektu. Tento jiný stavební objekt nemá hranice, jen
definiční bod a často je k němu vázané adresní místo, které ve skutečnosti
patří k objektu s hranicemi. Těchto budov je cca 12000 párů. Zahrnout do
reklamace či ne?

Děkuji za odpověď a těším se na spolupráci.

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

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

Re: [Talk-cz] Vandalismus (?) v Celakovicich

2015-11-17 Tema obsahu Petr Vejsada

To není vandalizmus, Petr Dlouhý, changeset 35079371, nejspíš chytil pár 
samotných uzlů a přetáhl je kam neměl.

--
Petr


Dne Út 17. listopadu 2015 12:22:49, Pavel Machek napsal(a):

> Ahoj!
> 
> Zda-se ze nekdo posunul par bodu z Celakovic kamsi daleko na
> jiho-vychod. Je to jasne videt, protoze tam natahnul i modrou
> znacku...
> 
>   Pavel

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

Re: [Talk-cz] WeeklyOSM CZ 273

2015-11-01 Tema obsahu Petr Vejsada

Díky za WeeklyOSM

Dne Ne 1. listopadu 2015 09:30:39, Tom Ka napsal(a):

> Data 1-SRTM dostupná pro celý svět.

jo, to je super, jenže teď potrvá roky, než to bude vyčištěno od těch 
stokilometrových jam :-( - tím myslím hluboké "jámy" v oblastech vodních 
ploch.

Děkuji za propagaci fundraisingu :)

Snad se zadařilo rozumě přidat Weekly OSM na poloha.net - na titulce je blok, 
zobrazující vydání 20 dnů zpět. To datum na RSS je, bohužel, datum vydání 
anglické verze a nejsem si jistý, zda to bude fungovat. Po vydání české se 
totiž nejspíš nezmění GUUID ani datum, tak uvidíme, jestli Drupal pochopí a 
zaktualizuje, ale je dost možné, že ne.

Filtrem se podařilo eliminovat RSS reklamy Not available yet.

--
Petr


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

Re: [Talk-cz] problém se čtvercem 8257 na task manageru

2015-10-29 Tema obsahu Petr Vejsada

Pardon, to URL na google, co jsem z komentare smazal, bylo
https://www.google.cz/maps/@49.4782713,15.9091371,3a,75y,324.63h,61.47t/data=!3m6!1e1!3m4!1sA4NdIN_2hRjpVitoPUkpOA!2e0!7i13312!8i6656!6m1!1e1

On Thu, Oct 29, 2015 at 09:06:04AM +0100, Zdeněk Pražák wrote:
> Dobrý den,
> označil jsem čtverec 8257 jako hotový s tím, že tam nejsou turistické značky
> a až po odeslání done jsem si všiml že do levého dolního rohu zasahuje 
> nezmapovaná žlutá značka z Pokojova do Starého Telečkova.
> Když chci čtverec invalidovat, tak mi task manager píše chybu an error 
> ocured
> Jak to mám opravit
> 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] problém se čtvercem 8257 na task manageru

2015-10-29 Tema obsahu Petr Vejsada

Invalidovano, viz comment u tasku (python)

--
Petr

On Thu, Oct 29, 2015 at 09:06:04AM +0100, Zdeněk Pražák wrote:
> Dobrý den,
> označil jsem čtverec 8257 jako hotový s tím, že tam nejsou turistické značky
> a až po odeslání done jsem si všiml že do levého dolního rohu zasahuje 
> nezmapovaná žlutá značka z Pokojova do Starého Telečkova.
> Když chci čtverec invalidovat, tak mi task manager píše chybu an error 
> ocured
> Jak to mám opravit
> 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] Mapovani turistickych tras

2015-10-23 Tema obsahu Petr Vejsada

Barevné čáry KČT se aktualizují každý den hned po zpracování dat z Geofabrik. 
Je to rychlé.

DNES je to trochu zmatené, protože turistické trasy jsou i na podkladové mapě 
a ta se každý den maže od zoomu 16 výše, zoomy 14-15 překresluji tak cca za 
1-2 týdny a větší ještě řidčeji. Až se dohodneme, jak přesně má vypadat 
overlay pro současný projekt, upravil bych overlay a jako podklad bych dal 
základní dlaždice z osm.org, kde turistické trasy nejsou a nebude se to plést.
--
Petr


Dne Čt 22. října 2015 11:14:59, Miroslav Suchy napsal(a):

> Dne 14.10.2015 v 22:16 Petr Vejsada napsal(a):
> > Ta KČT vrstva (čáry) se kreslí ze speciální tabulky, která se poskládá z
> > relací a čar. Zjednodušeně, je tam pak všechno, co je not NULL v kct_{red|
> > green|yellow|blue}
> 
> A jak casto tuhle vrstvu (ty barevne cary KCT) aktualizujes?
> 
> 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] Mapovani turistickych tras

2015-10-23 Tema obsahu Petr Vejsada

neumí per projekt, ale umí na požádání (kliknutí), takže si holt každý klikne 
a vybere si vrstvu dle svého vkusu.

--
Petr

Dne Čt 22. října 2015 11:12:48, Miroslav Suchy napsal(a):

> Dne 22.10.2015 v 10:20 Jan Breuer napsal(a):
> > Nebo spíš cyklotrasy nerenderovat vůbec a založit rovnou další projekt
> > "Cyklotrasy"?
> Na popisu projektu Cyklotrasy pracuji, ale problem je ze taskman neumi
> overlay per project. Je to pro vsechny dohromady.
> 
> 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] Mapovani turistickych tras

2015-10-23 Tema obsahu Petr Vejsada

Ahoj,

s těmi cyklistickými trasami to bylo, pravda, takové nejasné. Od zítra budou 
na mapě všechny KČT cyklistické trasy (kct_barva='bicycle'). Všechny také není 
úplně přesné. Když je trasa zařazená do několika relací, tak si musím vybrat, 
jak bude čára udělaná. Dávám tam to, co je IMO nejvýznamnější podle 
následující tabulky:

90;wheelchair
80;peak
70;spring
60;ruin
50;interesting_object
40;horse
30;ski
25;bicycle
20;learning
10;local

Wheelchair tedy přebije všechno a pokud bude cesta v relaci horse, major a 
wheelchair, vyhraje wheelchair a bude označkována invalidními vozíky.

Mám sice hotové řešení, jak označkovat na trase všechny její atributy, třeba 
ski+wheelchair+horse+learning najednou, jenže Mapnik (2.2) to neumí - nezvládá 
více shieldsymbolizérů na jedné čáře. Mapnik 3 nevím, při přesunu k TransIP 
jsem ho zkoušel a opět jsem došel k závěru, že není moudré ho ještě nasazovat. 
Možná by to šlo po interních vrstvách Mapniku, ale bylo by jich celkem 48, 
haha.

Výše uvedené se táká natrvalo podkladové mapy a MOMENTÁLNĚ i overlaye.

A teď co s tím Taskmanem. Různé vrstvy pro různé projekty, pravda, neumí, ale 
naučil jsem ho ty overlaye, takže by šlo dát jako podklad základní vrstvu z 
osm.org a overlay by se musel kliknout obdobně, jako teď se dá kliknout 
ortofoto (coby ukázka funkčnosti).

A teď si pojďme říci, co tedy dát do overlaye pro mapování turistických cest. 
Jaké cesty tam mají být? Jen hiking a foot? Nebo kct_barva is not NULL? Nebo?

A rozcestníky - kdy je tedy rozcestník OK? Když má název a ref? Takže když 
nebude mít název, tak ná být červený? A když nebude mít ref tak modrý? A když 
nebude mít nic?

A co rozcestníky, které nesouvisí s turistickými trasami? Někdo nandal spoustu 
rozcestníků na Olšanské hřbitovy v Praze a ty opravdu nejsou na turistické 
stezce ;-).

Další overlaye pro Taskmana bude možné vyrobit dle dohody, volného času a 
chuti ;-).

--
Petr


Dne Čt 22. října 2015 10:02:20, Petr Vozdecký napsal(a):

> Tak tomu uz teda super nerozumim... copak Petr renderuje do overlay i
> cyklotrasy? Zadne jsem si nevsimnul, jsou tam jen KCT turisticke, ne?
> 
> Stejne tak me mate, ze o par set metru na sever je podle overlay cervena
> turisticka prerusena (alespon u me) a ctverec dostal Done - v OSM je to ale
> OK. Podobnych "der" v overlay jsem nasel vic...
> 
> vop
> 
> 
> -- Původní zpráva --
> Od: Miroslav Suchy 
> Komu: talk-cz@openstreetmap.org
> Datum: 22. 10. 2015 9:36:12
> Předmět: Re: [Talk-cz] Mapovani turistickych tras
> 
> "Dne 22.10.2015 v 07:21 Petr Vejsada napsal(a):
> > ad ocásek - ve skutečnosti to není ocásek, ale samostatná relace
> > http://www.openstreetmap.org/relation/2367146#map=15/49.2038/16.3609
> > (kct_red=bicycle). Další relace v místě jsou:
> > http://www.openstreetmap.org/relation/223319#map=16/49.2042/16.3585
> > (kct_red=major) a
> > http://www.openstreetmap.org/relation/1539025#map=15/49.2045/16.3600
> > (kct_red=bicycle)
> 
> Presne tak, ten ocasek je cyklotrasa, ktera neni dokoncena.
> 
> Slo by ty cyklotrasy renderovat jinak? Treba prerusovane? Aby se to nepletlo
> s pesimi trasami?
> 
> 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] Mapování tras KČT na taskmanu

jj, podívám se na to, snad dnes večer. Dal bych tam základní vrstvu z osm.org 
+ overlay s barevnými rozcestníky, stávající tloušťkou tur. tras a výraznější 
názvy a ref.

--
Petr

Dne Čt 22. října 2015 02:35:12, Petr Vozdecký napsal(a):

> ano, pridavam se s prosbou, at je drive patrne, ze ten udaj u rozcestniku
> mame nebo ne. A dosahnes na udaj, zda je u rozcestniku fotka? Asi tezko, to
> by chtelo jeste krapet povysit obsah sbiranych informaci o fotkach o #REF
> toho uploadovaneho rozcestniku, ze?
> 
> a jeste poznatek - zda se mi, ze udaje pod rozcestnikem, se nachazeji:
> - nazev rozcestniku "pod" vrstvou tras (barevnych linii)
> - ref rozcestniku "nad" vrstvou tras - a navic s outline, takze narozdil od
> nazvu citelnejsi
> 
> slo by dat oboji "nad" a s outline?
> 
> diky
> 
> vop
> 
> 
> -- Původní zpráva --
> Od: Jan Breuer 
> Komu: OpenStreetMap Czech Republic 
> Datum: 21. 10. 2015 16:12:33
> Předmět: Re: [Talk-cz] Mapování tras KČT na taskmanu
> 
> "
> 
> 
> 
> 
> Dne 21. října 2015 15:56 Petr Vejsada  (mailto:o...@propsychology.cz)> napsal(a):
> "Ahoj,
> 
> jmena rozcestniku i REF se na Taskmanu zobrazuji, ale oboje az ve velkych
> zoomech. Ma nasetovat mensi zoomy? Taky by slo udelat rozcestniky ruznou
> barvou,
> podle toho, zda maji/nemaji REF ci maji/nemaji nazev. ?
> 
> "
> 
> 
> 
> Kdyby byl nějaký hint o tom, jestli má všechny náležitosti i na zoomu, kdy
> se začne poprvé zobrazovat, tak by to bylo fajn. Stačil by i jen název a ref
> už na těch menších zoomech a klidně menší ikona/kolečko/křížek.
> 
> 
> 
> 
> Honza 
> 
> 
> 
> 
> ___
> 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] Mapovani turistickych tras

Ahoj,

ad ocásek - ve skutečnosti to není ocásek, ale samostatná relace 
http://www.openstreetmap.org/relation/2367146#map=15/49.2038/16.3609 
(kct_red=bicycle). Další relace v místě jsou:
http://www.openstreetmap.org/relation/223319#map=16/49.2042/16.3585 
(kct_red=major) a
http://www.openstreetmap.org/relation/1539025#map=15/49.2045/16.3600 
(kct_red=bicycle)

Překreslí se na vyžádání znamená, že obrázky nejsou na disku, ale vyrobí se z 
dat v databázi ve chvíli, kdy se na ně někdo chce podívat. Do databáze se 
dostanou až poté, co denní porci dat pro ČR zpracuje Geofabrik. Pak trvá asi 
hodinu, než data z Geofabrik zpracuji a data se ocitnou v databázi. K jakému 
dni data v databázi mám je vidět v levém sloupci na http://poloha.net/

Věta "zoomy 14-20 se vykresli na vyzadani" ovšem platí pro overlay KČT; pro 
základní mapu platí, že na vyžádání se překreslují zoomy 16-20.

Ještě jednou jinak - na taskmanu je základní vrstva, obsahující turistické 
trasy a přes ní je plácnutá další vrstva s tlustšími turistickými trasami a 
velkými rozcestníky. Když nad tím přemýšlím, tak bych asi měl dát jako 
základní vrstvu tu z tile.openstreetmap.org, aby se to nepletlo.

--
Petr


Dne Čt 22. října 2015 02:30:08, Petr Vozdecký napsal(a):

> Ahoj,
> 
> prosim info, jak je to presne s tim prekreslovanim, resp. s aktualizaci dat.
> Napr. zde http://taskman.poloha.net/project/2#task/975 je na mape tasking
> manageru na cervene znacce "ocasek", ktery ale v OSM databazi neni.
> 
> a blby dotaz c. 2, co znamena "zoomy 14-20 se vykresli na vyzadani"? Pro me
> jako BFU to vypada, jako ze jsou prakticky vzdy aktualni - chapu to dobre?
> Praxe takoéva neni...
> 
> diky
> 
> vop
> 
> 
> -- Původní zpráva --
> Od: Petr Vejsada 
> Komu: OpenStreetMap Czech Republic 
> Datum: 14. 10. 2015 8:03:32
> Předmět: Re: [Talk-cz] Mapovani turistickych tras
> 
> "OK, takže technická příprava snad hotova. Overlay se překresluje ihned po
> zpracování denní porce v zoomech 7-13 (cca 3 minuty), zoomy 14-20 se mažou,
> neb se stihnou vykreslit na vyžádání. Kdyby ještě něco (zmenšit rozcestníky?
> 
> udělat je samotné černé bez toho rámečku?to budou méně výrazné).
> 
> 
> "

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

Re: [Talk-cz] Mapovani turistickych tras

Ahoj,

momentálně se nevykresluje, pokud je zájem, tak (časem) může.

--
Petr

Dne St 21. října 2015 20:23:04, Václav Kubíček napsal(a):

> Nějak jsem se v tom ztratil... Funguje vykreslování "rozbitých relací" na
> nějaké mapě nebo jde jen o seznam? 
> Vašek
>  
> ______
> 
> > Od: Petr Vejsada 
> > Komu: OpenStreetMap Czech Republic 
> > Datum: 14.10.2015 08:03
> > Předmět: Re: [Talk-cz] Mapovani turistickych tras
> 
> OK, takže technická příprava snad hotova. Overlay se překresluje ihned po
> zpracování denní porce v zoomech 7-13 (cca 3 minuty), zoomy 14-20 se mažou,
> neb se stihnou vykreslit na vyžádání. Kdyby ještě něco (zmenšit rozcestníky?
> udělat je samotné černé bez toho rámečku?to budou méně výrazné).
> 
> Stále taky běží úloha, kterou tu někdo chtěl, a to jsou "rozbité relace".
> Jsou to relace route=hiking nebo route=foot, které jsou geometricky rozbité
> - není to jedna souvislá čára. Buď tam mohou být ocásky a nebo je čára
> přerušená, například http://mapapi.poloha.net/relation/2163647
> <http://mapapi.poloha.net/relation/2163647> . Seznam je na
> http://osm.poloha.net/rozbite_relace.csv
> <http://osm.poloha.net/rozbite_relace.csv> . Nejedná se tedy pouze o cesty
> KČT, ale o všechny relace uvedeného typu.
> 
> Tak mě napadá, že by se ty rozbité čáry daly také dát do toho overlaye.
> Někdy se v tom těžko hledá, když je 100 km dlouhá cesta přerušená na půl
> metru nebo má půlmetrový ocásek ;-) ?
> 
> --
> Petr
> 
> Dne Út 13. října 2015 22:17:36, Miroslav Suchý napsal(a):
> > On 10/13/2015 07:56 PM, Petr Vejsada wrote:
> > > Jsou 3 režimy, kam se to dá přidat. Standardní, t.j. teď, ale overlay
> > > není
> > > při vytváření projektu a při zadávání prioritních oblastí. Mám to tam
> > > taky přidat?
> > 
> > Pri vytvareni projektu to netreba (k cemu?), jedeme celou CR.
> > 
> > Prioritni oblasti taky nemame, opet to bude cela CR.
> > 
> > Mirek
> > 
> > ___
> > Talk-cz mailing list
> > Talk-cz@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-cz
> > <https://lists.openstreetmap.org/listinfo/talk-cz>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> <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] Tagy turistických tras na cestách

Ahoj,

to bychom snad uměli, http://osm.poloha.net/kct_xxx/
--
Petr

Dne St 21. října 2015 21:23:41, Václav Kubíček napsal(a):

> Ahoj,
> občas prolézám taginfo a snažím se přetransformovat tagy turistických tras
> co jsou na cestách do relací. Co jsem dnes koukal jedná se o něco málo přes
> 1000 cest na kterých je tag kct_barva a ve většině případů nejsou v relaci.
> Chtěl bych se zeptat jestli by se nenašel někdo šikovný, kdo by nezvládl
> udělat výpis případně vrstvu do mapy těchto tagů na cestách takovýmto
> způsobem: 1. cesta (např. s tagem kct_red) už v relaci existuje. Tag
> (kct_red) se může z cesty smazat. 2. cesta v žádné relaci není nebo je, ale
> neshodují se barvy. Musí se vytvořit nová relace a do ní cestu přesunout,
> případně ji přesunout do relace stávající. Kdysi jsem se snažil udělat
> skript do overpass turba abych si stáhnul všechny cesty co jsou v relaci se
> stejným tagem (kct_barva), ale bez úspěchu. Děkuji
> Vaš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] Mapování tras KČT na taskmanu