Re: [Talk-cz] Tracer plugin - ruian update
Ahoj, k te presnosti: zkousel jsem to v Praze Vysocanech a v osade Libiv. Ale znova upozornuji, ze ten rozdil je v centimetrech, takze to asi nema cenu resit. Jestli to teda spravne chapu, tak ten Tracer nebere data primo z RUIAN, ale trasuje bitmapy vytvorene Petrem? Jestli jo, tak ta nepresnost, o ktere mluvim, je asi zpusobena jen tim, prevodem vektor-bitmapa-vektor. Alespon mi to tak pripada, kdyz to hodne zvetsim. Zdravi, Dalibor ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
[Talk-cz] Vytváření ploch
Ahoj, hledal jsem nějaký plugin pro jednodušší vytváření ploch v JOSM. Plugin, který by při kliknutí do volného místa na mapě ohraničeného jinými plochami nebo cestami vytvořil plochu a já bych jí už jen přidal atributy. Nic jsem ale nenašl. Nevíte o něčem? Teď musím při vytváření ploch, pokud na sebe navazují, klikat na každý bod nejméně dvakrát (pro každou ze sousedících ploch), takovýto plugin by zredukoval počet kliknutí na jedno. Díky, Jindra ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Vytváření ploch
Dne 4.2.2014 09:33, Jindřich Houska napsal: Ahoj, hledal jsem nějaký plugin pro jednodušší vytváření ploch v JOSM. Plugin, který by při kliknutí do volného místa na mapě ohraničeného jinými plochami nebo cestami vytvořil plochu a já bych jí už jen přidal atributy. Nic jsem ale nenašl. Nevíte o něčem? Teď musím při vytváření ploch, pokud na sebe navazují, klikat na každý bod nejméně dvakrát (pro každou ze sousedících ploch), takovýto plugin by zredukoval počet kliknutí na jedno. Díky, Jindra Ahoj, myslíš, plochy ohraničené jinými OSM objekty? To by možná mohlo někdy fungovat. Ale třeba cesta nemusí automaticky znamenat hranici. Spíše uvažuji o rozšíření Tracer pluginu o tracování ploch. Aktuálně funguje jen na budovy a to tak, že vrátí hranice aktuální budovy. Tracování ploch bych si představoval tak, že kliknu do prázdné plochy a Tracer mi z RUIAN databáze vrátí polygon, ohraničující oblast stejného typu jaký má parcela na kterou jsem klikl. Tedy, kliknu na parcelu, která je označena jako orná půda a tracer mi vrátí hranici oblasti všech parcel typu orná půda v okolí bodu na který jsem klik. Ohromně by to zjednodušilo mapování těchto velkých ploch. Má to dvě chybičky: 1) Musím se nejprve naučit PostGis 2) Data z RUIAN nejsou dostupná všude. Marián ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer plugin - ruian update
Dne 4.2.2014 09:25, Dalibor Jelínek napsal: Ahoj, k te presnosti: zkousel jsem to v Praze Vysocanech a v osade Libiv. Ale znova upozornuji, ze ten rozdil je v centimetrech, takze to asi nema cenu resit. OK. Kouknu na to, jestli si večer vzpomenu ;-) Jestli to teda spravne chapu, tak ten Tracer nebere data primo z RUIAN, ale trasuje bitmapy vytvorene Petrem? Jestli jo, tak ta nepresnost, o ktere mluvim, je asi zpusobena jen tim, prevodem vektor-bitmapa-vektor. Alespon mi to tak pripada, kdyz to hodne zvetsim. Ne. Tak to není. Petr tu bitmapovou vrstvu vytváří z RUIAN databáze a upravený tracer plugin si data bere ze stejné databáze. Takže ve skutečnosti tam k žádnému tracování bitmapy nedochází. Při každém kliknutí dostaneš vždy stejnou sadu bodů tvořící danou budovu rovnou z databáze. Technicky by se to už vlastně nemělo nazývat Tracování :-) Marián Zdravi, Dalibor ___ 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] Vytváření ploch
Ahoj, ano, myslel jsem plochy ohraničené jinými OSM objekty. Ne vždy plochy vytvořené na mapě (podle orto foto mapy) odpovídají parcelám (zejména různé remízky, křoví podél cesty apod., např. viz http://www.openstreetmap.org/#map=16/49.9077/14.3063 ). Určitě ne každá cesta znamená hranici plochy. Na druhou stranu je potřeba při vytváření nových ploch mít možnost ze stran, kde plochy ještě neexistují, je nějak ohraničit (v místech, jako je toto http://www.openstreetmap.org/#map=15/49.7246/14.6080 ). Jak tedy dnes kreslíte plochy, aby to bylo efektivní a neuklikali jste se k smrti? Jindra Dne 4. února 2014 10:04 Marián Kyral mky...@email.cz napsal(a): Dne 4.2.2014 09:33, Jindřich Houska napsal: Ahoj, hledal jsem nějaký plugin pro jednodušší vytváření ploch v JOSM. Plugin, který by při kliknutí do volného místa na mapě ohraničeného jinými plochami nebo cestami vytvořil plochu a já bych jí už jen přidal atributy. Nic jsem ale nenašl. Nevíte o něčem? Teď musím při vytváření ploch, pokud na sebe navazují, klikat na každý bod nejméně dvakrát (pro každou ze sousedících ploch), takovýto plugin by zredukoval počet kliknutí na jedno. Díky, Jindra Ahoj, myslíš, plochy ohraničené jinými OSM objekty? To by možná mohlo někdy fungovat. Ale třeba cesta nemusí automaticky znamenat hranici. Spíše uvažuji o rozšíření Tracer pluginu o tracování ploch. Aktuálně funguje jen na budovy a to tak, že vrátí hranice aktuální budovy. Tracování ploch bych si představoval tak, že kliknu do prázdné plochy a Tracer mi z RUIAN databáze vrátí polygon, ohraničující oblast stejného typu jaký má parcela na kterou jsem klikl. Tedy, kliknu na parcelu, která je označena jako orná půda a tracer mi vrátí hranici oblasti všech parcel typu orná půda v okolí bodu na který jsem klik. Ohromně by to zjednodušilo mapování těchto velkých ploch. Má to dvě chybičky: 1) Musím se nejprve naučit PostGis 2) Data z RUIAN nejsou dostupná všude. Marián ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Vytváření ploch
Dne 4.2.2014 12:08, Jindřich Houska napsal: Ahoj, ano, myslel jsem plochy ohraničené jinými OSM objekty. Ne vždy plochy vytvořené na mapě (podle orto foto mapy) odpovídají parcelám (zejména různé remízky, křoví podél cesty apod., např. viz http://www.openstreetmap.org/#map=16/49.9077/14.3063 ). Moc pěkné. To si uložím jako inspiraci :-) Určitě ne každá cesta znamená hranici plochy. Na druhou stranu je potřeba při vytváření nových ploch mít možnost ze stran, kde plochy ještě neexistují, je nějak ohraničit (v místech, jako je toto http://www.openstreetmap.org/#map=15/49.7246/14.6080 ). No to je právě ten problém. Aby to nějak rozumně fungovalo, musel by jsi nejprve tu plochu něčím uzavřít (naklikat hranu) a pak bych si dovedl představit, že po kliknutí do středu by se automaticky vytvořila nová plocha, která by měla společnou hranici se sousedními plochami typu landuse/natural. Takže by jsi naklikal jen tu jednu čáru, a společné hranice by naklikal plugin. I když správně, by se to asi mělo dělat tak, že si naklikáš společné hranice a pro tu plochu je združíš do relace. Když pak chceš přidat další plochu, jen naklikáš novou hranici, vybereš již existující hranice a uděláš z nich relaci. Takhle: http://wiki.openstreetmap.org/wiki/Cs:Relation:multipolygon Nicméně by to pak zase chtělo plugin, který ti označenou plochu pěkně převede na relaci. Dělat to ručně taky není žádná sranda. Jak tedy dnes kreslíte plochy, aby to bylo efektivní a neuklikali jste se k smrti? Klikáme, klikáme. Ale když se podíváš na mapu, jak moc jsou zmapované plochy, tak spíše neklikáme :-D Marián Jindra Dne 4. února 2014 10:04 Marián Kyral mky...@email.cz napsal(a): Dne 4.2.2014 09:33, Jindřich Houska napsal: Ahoj, hledal jsem nějaký plugin pro jednodušší vytváření ploch v JOSM. Plugin, který by při kliknutí do volného místa na mapě ohraničeného jinými plochami nebo cestami vytvořil plochu a já bych jí už jen přidal atributy. Nic jsem ale nenašl. Nevíte o něčem? Teď musím při vytváření ploch, pokud na sebe navazují, klikat na každý bod nejméně dvakrát (pro každou ze sousedících ploch), takovýto plugin by zredukoval počet kliknutí na jedno. Díky, Jindra Ahoj, myslíš, plochy ohraničené jinými OSM objekty? To by možná mohlo někdy fungovat. Ale třeba cesta nemusí automaticky znamenat hranici. Spíše uvažuji o rozšíření Tracer pluginu o tracování ploch. Aktuálně funguje jen na budovy a to tak, že vrátí hranice aktuální budovy. Tracování ploch bych si představoval tak, že kliknu do prázdné plochy a Tracer mi z RUIAN databáze vrátí polygon, ohraničující oblast stejného typu jaký má parcela na kterou jsem klikl. Tedy, kliknu na parcelu, která je označena jako orná půda a tracer mi vrátí hranici oblasti všech parcel typu orná půda v okolí bodu na který jsem klik. Ohromně by to zjednodušilo mapování těchto velkých ploch. Má to dvě chybičky: 1) Musím se nejprve naučit PostGis 2) Data z RUIAN nejsou dostupná všude. Marián ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Vytváření ploch
Jo, taky jsem neco takoveho hledal, kdyz jsem zacal delat plochy. Ale nenasel, tak se uklikavam k smrti. Ale je fakt, ze me nenapadlo to delat relacema a ty hranicni cesty vkladat do relaci. To to asi zjednodussi. Ale zase jsou ty relace narocnejsi na vypocetni vykon a hrozi, ze je nekdo rozbije. Ale zkusim to tak. Dalibor -Original Message- From: Jindřich Houska [mailto:jindrich.hou...@seznam.cz] Sent: Tuesday, February 4, 2014 12:09 PM To: OpenStreetMap Czech Republic Subject: Re: [Talk-cz] Vytváření ploch Ahoj, ano, myslel jsem plochy ohraničené jinými OSM objekty. Ne vždy plochy vytvořené na mapě (podle orto foto mapy) odpovídají parcelám (zejména různé remízky, křoví podél cesty apod., např. viz http://www.openstreetmap.org/#map=16/49.9077/14.3063 ). Určitě ne každá cesta znamená hranici plochy. Na druhou stranu je potřeba při vytváření nových ploch mít možnost ze stran, kde plochy ještě neexistují, je nějak ohraničit (v místech, jako je toto http://www.openstreetmap.org/#map=15/49.7246/14.6080 ). Jak tedy dnes kreslíte plochy, aby to bylo efektivní a neuklikali jste se k smrti? Jindra Dne 4. února 2014 10:04 Marián Kyral mky...@email.cz napsal(a): Dne 4.2.2014 09:33, Jindřich Houska napsal: Ahoj, hledal jsem nějaký plugin pro jednodušší vytváření ploch v JOSM. Plugin, který by při kliknutí do volného místa na mapě ohraničeného jinými plochami nebo cestami vytvořil plochu a já bych jí už jen přidal atributy. Nic jsem ale nenašl. Nevíte o něčem? Teď musím při vytváření ploch, pokud na sebe navazují, klikat na každý bod nejméně dvakrát (pro každou ze sousedících ploch), takovýto plugin by zredukoval počet kliknutí na jedno. Díky, Jindra Ahoj, myslíš, plochy ohraničené jinými OSM objekty? To by možná mohlo někdy fungovat. Ale třeba cesta nemusí automaticky znamenat hranici. Spíše uvažuji o rozšíření Tracer pluginu o tracování ploch. Aktuálně funguje jen na budovy a to tak, že vrátí hranice aktuální budovy. Tracování ploch bych si představoval tak, že kliknu do prázdné plochy a Tracer mi z RUIAN databáze vrátí polygon, ohraničující oblast stejného typu jaký má parcela na kterou jsem klikl. Tedy, kliknu na parcelu, která je označena jako orná půda a tracer mi vrátí hranici oblasti všech parcel typu orná půda v okolí bodu na který jsem klik. Ohromně by to zjednodušilo mapování těchto velkých ploch. Má to dvě chybičky: 1) Musím se nejprve naučit PostGis 2) Data z RUIAN nejsou dostupná všude. Marián ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer plugin - ruian update
Cau, to jsi mi trochu rozboural hracky. :-( Asi ano ;-). Mnoho domů, možná i většina, má jedno číslo. Ovšem zdaleka ne všechny. Jde o čísla popisná, ne orientační. A dokazes se zeptat, kolik takovych budov je z celeho poctu? Nepripada mi to moc logicke, ze ma stavebni objekt vice cisel a spise mi to pripada jako nejaka vec z minulosti. Kdyz jsem hledal, jakym zpusobem to pridelovani funguje, tak jsem nabyl dojmu, ze postavis barak a pozadas o cislo. Nikde jsem nenasel, ze bys mohl pozadat o cisel vice. Ale treba je to fakt historicky. Mimochodem, dokazu se te tve databaze nejak zeptat ja? Je pristupna po netu? Ale i tak mi to porad neprijde uplne mimozni. Adresní bod v RUIAN se sice váže na budovu Tohle je opravdu presne tak, jak pises? Ja myslel, ze k budove se vaze cislo popisne nebo evidenci (ted vim, ze jich muze byt vice). Ale mel jsem za to, ze databaze adresnich bodu je zvlast a nema vazbu vubec na zadne stavebni objekty. Ze je to proste bod, ktery klidne lezi nekde, kde uz zadny dum neni. Marian: Jen poznámka, že se pak to číslo zobrazuje dvakrát. Vím, že se nemáme ohlížet na render, ale tohle by mi asi hodně vadilo. Tohle myslim, zase tak nevadi. Alespon jsem nenasel zadne misto, kde by to nejak bilo do oci. Co jsem nasel, tak bud se ty popisky cisla domu a cisla adresniho bodu prekryvaji, pac lezi hodne blizko sebe, a pak je stejne vykreslene jen jedno. Nebo je, pri dostatecnem zvetseni, cislo domu uprostred a cisla domu/orientacni nad vchody, coz mi naopak prijde docela hezke. Mohlo by se přidávat i - building:levels (počet podlaží z RUIAN) - building:flats (počet bytů, je-li v RUIAN) - klidně bych přidal i přímé URL na http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/25286358 - a dokonce, možná pro někoho kontroverzně, bych přidal i adresní tagy (addr:country, addr:city, addr:place, addr:*number ) Nestačí to RUIANID? Tedy ne že by se často přistavovalo k domu patro, ale pokud by se něco obdobného stalo, bude to aktuální spíš v RUIAN než v OSM. Podle me ne zas tak uplne, protoze malokdo vi, jak se k tem udajum o objektu dostat a proto mi prislo fajn tam dat to url, ale je fakt, ze to tam asi byt nemusi, ze to staci napsat na Wiki. Ucelem building:levels myslim bylo, aby slo odahnout vysku budovy, kdyz se dela 3D mapa, tak by to bylo fajn v OSM mit. Pro building:flats me zadne vyuziti nenapada, snad jen, ze tak trochu doplnuje informaci, zda je budova urecena k bydleni, nebo ne. Ale libi se mi do OSM davat veci, pro ktere sice ted nemame jasne uplatneni, ale kdyz je vime, tak je tam dejme. Navic, kdyz uz budes ty budovy jednou trasovat, tak je lepsi tam rovnou dat maximum informaci, protoze vracet se k tomu asi nebudes. Na druhou stranu, kdyz uz tam bude ruian ID, tak se to da pozdeji relativne snadno doplnit. Uplne nejlepsi by asi tedy bylo, tu moznost tam mit a dat uzivateli v Preferencich moznost si vybrat, ktere tagy chce pridavat. Zdravi, Dalibor ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Vytváření ploch
Multipolygony (relace) jsou velmi pohodlné, ale vyplatí se tak až od 10-20 bodů, do té doby je jednodušší klikat. Řešil jsem tak celou tuto oblast a musím říct, že po počátečním testování to bylo snadné - doporučuji! http://www.openstreetmap.org/#map=14/49.3081/16.9465 Akorát bych asi doporučil udržet si chladnou hlavu a nekonvertovat vše v okolí, ono to celkem svádí zmultipolygonovat všechno čeho se relace dotknou. S odstupem času si myslím, že někde kolem té desítky bodů je jednodušší pokusit se nevrtat zbytečně do toho co už je a některé části nechat jako dotek části multipolygonu a menší oblasti (je-li to možné). Samozřejmě jakmile je jednou potřeba díra, je to stejně multipolygon a hurá... Je to asi i námět na to, kde sousedící oblasti lepit na sebe a kde ne. Připadne mi, že relací se většina laičtějších editorů bojí (pokud je rozezná), a zůstávají raději stranou. Například tak, že plochy nepřilepí :-D Viz Vyškov na západ od mého příkladu... Vláďa On 4.2.2014 13:30, Dalibor Jelínek wrote: Jo, taky jsem neco takoveho hledal, kdyz jsem zacal delat plochy. Ale nenasel, tak se uklikavam k smrti. Ale je fakt, ze me nenapadlo to delat relacema a ty hranicni cesty vkladat do relaci. To to asi zjednodussi. Ale zase jsou ty relace narocnejsi na vypocetni vykon a hrozi, ze je nekdo rozbije. Ale zkusim to tak. Dalibor ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
[Talk-cz] Zla, zla priroda (was Re: Tracer plugin - ruian update)
Ahoj1 Pro zajímavost bych rád věděl, co je příčinou, že to tak úplně nesedí na obrázek z katastrální mapy. Rozdíly jsou, tam kde jsem to zkoušel, asi jen v centimetrech, ale proč to není úplně přesně? ... To já bych taky rád věděl, protože ty fialovo-růžové dlaždice mám na svědomí. Je dost možné, že je to chyba v transformaci, protože jsem ještě neviděl dvě stejné definice srid 5514. Co člověk, to jiná definice ;-). Také i v Zemsky desky jsou proklety potvory, a hybou se. Nehybou se moc rychle, ale trochu se prece jen hybou. Zmerim polohu snezky vuci wgs-84 referenci, a za 100 let je o par centimetru jinde... Takze mit mapu zalozenou na wgs-84 je vlastne fatalne blbe, protoze ty zakreslene veci proste plujou pryc. Resenim je mit jeden system souradnic pro kazdou zemskou desku, ktera tak nejak drzi pohromade. A pak se hold jednou za 50 let zmeni prepocet na wgs-84. Nastesti je efekt maly ale centimetrovy presnosti proste z principu nejde dosahnout, protoze ty desky se hybou na radech centimetry za rok... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
[Talk-cz] Posuny - pokus o zpřesnění
Ahoj, udělal jsem experimentální vrstvu s budovami, která, pokud jsem něco nezvoral, by měla být podle Xificurka s použitím gridu, ale možná jsem fakt něco nedomyslel, pže to dopadlo nic moc. http://pedro.poloha.net/mapa , url vrstvy je http://tile.poloha.net/temp_budovy/z/x/y.png Jak jsem postupoval: - zavedl jsem fiktivní SRID 999 do spatial_ref_sys, kde jsem změnil proj4text tak, jak to má Xificurk - stáhnul jsem si grid podle Petrova odkazu (btw: Petře, pokud to čteš, ta zdrojová forma by nebyla?) - zkopíroval tabulku s geometriemi budov - updatnul geometrii takto: update temp_budovy set hranice= (st_transform(st_setsrid(st_transform(hranice,5514),999),900913)) což by mělo dělat, že se z 900913 geometrie přepočítá zpět na 5514 a podle gridu se zase přepočítá zpátky do 900913. Je to podle mých očí jen horší. Proč? -- Petr, p...@propsychology.cz p ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Postgis tutoriál (bylo PointInfo JOSM plugin - zobrazení informací z RUIAN)
Ahoj, tak jsem se dopracoval k tomuto selectu: select u.kod, u.nazev, ST_asText(st_transform(u.definicni_cara,4326)) from ( select kod, nazev, definicni_cara from ruian.rn_ulice order by definicni_cara - st_transform(st_setsrid(st_makepoint(18.36564928953012,49.670527512403766),4326),900913) LIMIT 100) as u where st_distance( (st_transform(u.definicni_cara,4326))::geography, (st_setsrid(st_makepoint(18.3657227215035,49.66980665513853),4326))::geography ) 10 ; Jediná věc mne zarazila. Musel jsem u subselectu nastavit LIMIT 100. S nastavením LIMIT 1 mi to vrátilo výsledek jen někdy. Klikal jsme podél ulice, na jednom místě mi to ulici vypsalo a o kousek dál už zase ne. Teď to vypadá, že to funguje slušně. Jen na křižovatkách to někdy vrátí vedlejší ulici. Ale to bych neviděl jako moc velký problém. Inteligentní uživatel klikne kousek dál od křižovatky. Díky, Marián Dne 2.2.2014 20:23, Petr Vejsada napsal: Ahoj, Dne Ne 2. února 2014 19:28:12, Marián Kyral napsal(a): definiční čára, mně blbne na klávesnici F, fakt, nedělám si srandu... Geometry typ prostě obsahuje údaje o tvaru nějakého objektu. Zobrazení: třeba select st_astext(definicni_cara) Geometrie může být bod, čára, polygon, multipolygon, oblouky a též směs všeho uvedeného. SRID = identifikace projekce, ve kreré je geometrie vyjádřena. Používáme v OSM dvě - 900913 pro zobrazování a 4326, což jsou ty stupně, jak je známe z běžného života. RUIAN mám uložen v 900913, aby s tím Mapnik neměl tolik práce. select st_srid(definicni_cara) from ruian.rn_ulice limit 1; st_srid - 900913 (1 řádka) Když chceš najít nejbližší ulici k bodu, vyjádřenému v občanských souřadnicích, tedy 4326, je potřeba to převést do 900913, protože takto jsou uložena data (platí jen pro tu databázi, co mám na serveru; někdo jiný to mlže mít jinak). To se dělá transformací - select st_transform(geometrie_v_lidských_souřadnicích,do jakého systému) Bod jakožto data typu geometrie vytvoříš třeba funkcí st_makepoint(lon,lat). Tato funkce vrátí data typu geometry a je to point. Není však jasné, v jakém souřadnicovém systému to vlastně je. Proto použijeme st_setsrid(geometry,srid) Takže do PG zadáme bod třeba select st_setsrid(st_makepoint(14,50),4326) Lidsky čitelné totéž: select st_astext(st_setsrid(st_makepoint(14,50),4326)); st_astext -- POINT(14 50) (1 řádka) V jakém souřadnicovém systému to vlastně máme? select st_srid(st_setsrid(st_makepoint(14,50),4326)); st_srid - 4326 (1 řádka) Ten samý bod si zobrazíme v lidsky čitelné formě v souřadnicovém systému 900913: select st_astext(st_transform(st_setsrid(st_makepoint(14,50),4326),900913)); st_astext -- POINT(1558472.87110583 6446275.84101716) (1 řádka) A konečně se dostáváme k cíli: select nazev from ruian.rn_ulice order by definicni_cara - st_transform(st_setsrid(st_makepoint(14,50),4326),900913) limit 1; nazev -- Na Zámku (1 řádka) Jak je ta ulice daleko? Funkce st_distance(geometry,geometry) Ta ráda vrací vzdálenost v radiánech na zemském povrchu, osobně dávám přednost metrům ;-). V metrech nám to řekne, když geometrie budou geografie. Geography je podobný datový typ, vyjadřuje se v souřadnicovém systému 4326. Toho se docílí přetypováním na typ geography. Celý select pak vypadá: select nazev,st_distance( (st_transform(definicni_cara,4326))::geography, (st_setsrid(st_makepoint(14,50),4326))::geography ) from ruian.rn_ulice order by definicni_cara - st_transform(st_setsrid(st_makepoint(14,50),4326),900913) limit 1; nazev | st_distance --+-- Na Zámku | 26.405619556 (1 řádka) Nejbližší bod ulice Na Zámku je od nás vzdálen 26 metrů a 40 centimetrů. Cvičení: Jak si zobrazíme lidsky čitelné souřadnice adresního bodu z RUIAN? A: select st_astext(st_transform(definicni_bod,4326)) from ruian.rn_adresni_misto where kod=21411409; st_astext -- POINT(13.6752996130858 49.2886006596294) (1 řádka) Učebnice Postgisu: http://workshops.boundlessgeo.com/postgis-intro/ je IMO super, ale nedá se to za 10 minut -- 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] Posuny - pokus o zpřesnění
Dne 4.2.2014 18:31, Petr Vejsada napsal: Ahoj, udělal jsem experimentální vrstvu s budovami, která, pokud jsem něco nezvoral, by měla být podle Xificurka s použitím gridu, ale možná jsem fakt něco nedomyslel, pže to dopadlo nic moc. http://pedro.poloha.net/mapa , url vrstvy je http://tile.poloha.net/temp_budovy/z/x/y.png Jak jsem postupoval: - zavedl jsem fiktivní SRID 999 do spatial_ref_sys, kde jsem změnil proj4text tak, jak to má Xificurk - stáhnul jsem si grid podle Petrova odkazu (btw: Petře, pokud to čteš, ta zdrojová forma by nebyla?) - zkopíroval tabulku s geometriemi budov - updatnul geometrii takto: update temp_budovy set hranice= (st_transform(st_setsrid(st_transform(hranice,5514),999),900913)) což by mělo dělat, že se z 900913 geometrie přepočítá zpět na 5514 a podle gridu se zase přepočítá zpátky do 900913. Je to podle mých očí jen horší. Proč? -- Petr, p...@propsychology.cz p Jak na to tak koukám, tak se to posunulo na opačnou stranu. Místo dolů a vlevo je nová vrstva posunuta nahoru a vpravo. Někde tam změň znaménko :D Marián ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer plugin - ruian update
Ahoj, Dne Út 4. února 2014 13:54:30, Dalibor Jelínek napsal(a): A dokazes se zeptat, kolik takovych budov je z celeho poctu? pocet_pripadu | pocet_cisel ---+- 1 | 43 1 | 38 1 | 31 1 | 29 1 | 27 12 | 25 4 | 24 3 | 22 1 | 21 4 | 20 3 | 19 2 | 18 2 | 15 12 | 14 12 | 13 23 | 12 28 | 11 57 | 10 58 | 9 101 | 8 143 | 7 433 | 6 627 | 5 1958 | 4 5807 | 3 14684 | 2 2826562 | 1 (27 řádek) Stavební objekty s jedním číslem drtivě převažují, to ano. Nepripada mi to moc logicke, ze ma stavebni objekt vice cisel a spise mi to pripada jako nejaka vec z minulosti. Jestli z minulosti, tak z minulosti velmi nedávné. Například nová budova Technické knihovny ČVUT v Dejvicích má více čísel popisných. Mimochodem, dokazu se te tve databaze nejak zeptat ja? Je pristupna po netu? Databáze nemá port vystrčený ven, ale chceš-li, můžeme se domluvit. Buď přes openvpn nebo ssh tunel. Ale i tak mi to porad neprijde uplne mimozni. Ta Technická knihovna má více vchodů, je spousta paneláků, kdy je jedna budova navenek, ale také má více vchodů, výtahů, byty jsou v každém vchodu číslovány zvlášt, ale pořád je to jedna budova. Nemám úplně jistotu, zda stavební objekt a budova je to samé, možná ne. Adresní bod v RUIAN se sice váže na budovu Tohle je opravdu presne tak, jak pises? Ano, všechny adresní body mají kód stavebního objektu, žádný není NULL a všechny ty stavební objekty existují. Ja myslel, ze k budove se vaze cislo popisne nebo evidenci (ted vim, ze jich muze byt vice). Ale mel jsem za to, ze databaze adresnich bodu je zvlast a nema vazbu vubec na zadne stavebni objekty. Ze je to proste bod, ktery klidne lezi nekde, kde uz zadny dum neni. Tabulka adresních bodů je zvlášť, asi právě proto, protože na jednom stavebním objektu může být více adresních bodů. Jinak geometrie adresního bodu nemusí ležet uvnitř budovy; teoreticky může být na opačném konci republiky ;-) -- Petr ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Posuny - pokus o zpřesnění
Ahoj, Dne 4.2.2014 18:31, Petr Vejsada napsal(a): Ahoj, udělal jsem experimentální vrstvu s budovami, která, pokud jsem něco nezvoral, by měla být podle Xificurka s použitím gridu, ale možná jsem fakt něco nedomyslel, pže to dopadlo nic moc. http://pedro.poloha.net/mapa , url vrstvy je http://tile.poloha.net/temp_budovy/z/x/y.png Jak jsem postupoval: - zavedl jsem fiktivní SRID 999 do spatial_ref_sys, kde jsem změnil proj4text tak, jak to má Xificurk - stáhnul jsem si grid podle Petrova odkazu (btw: Petře, pokud to čteš, ta zdrojová forma by nebyla?) bohužel git.zcu.cz se zdá opravdu mrtvý... a já bohužel ten zdrojový soubor nikde na disku nemám, ale podařilo se mi ho dohledat v archivu: http://web.archive.org/web/20091003020944/http://git.zcu.cz/grid/czech.lla Nicméně je to z roku 2009, tak nevím jestli to je stejná verze. - zkopíroval tabulku s geometriemi budov - updatnul geometrii takto: update temp_budovy set hranice= (st_transform(st_setsrid(st_transform(hranice,5514),999),900913)) což by mělo dělat, že se z 900913 geometrie přepočítá zpět na 5514 a podle gridu se zase přepočítá zpátky do 900913. Je to podle mých očí jen horší. Proč? Já teda do těch transformací moc nevidím, ale není možné, že se tam kumuluje nějaká chyba tím převodem tam a zpátky? Já si teď u sebe pustím nový čerstvý import RUIANu a pak můžem porovnat výstup na nějakém konkrétním stavebním objektu, což? Zdraví, Petr Morávek aka Xificurk ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Postgis tutoriál (bylo PointInfo JOSM plugin - zobrazení informací z RUIAN)
Ahoj, Dne Út 4. února 2014 19:27:37, Marián Kyral napsal(a): Ahoj, tak jsem se dopracoval k tomuto selectu: select u.kod, u.nazev, ST_asText(st_transform(u.definicni_cara,4326)) from ( select kod, nazev, definicni_cara from ruian.rn_ulice order by definicni_cara - st_transform(st_setsrid(st_makepoint(18.36564928953012,49.670527512403766),4 326),900913) LIMIT 100) as u where st_distance( (st_transform(u.definicni_cara,4326))::geography, (st_setsrid(st_makepoint(18.3657227215035,49.66980665513853),4326))::geograp hy ) 10 ; Jediná věc mne zarazila. Musel jsem u subselectu nastavit LIMIT 100. S nastavením LIMIT 1 mi to vrátilo výsledek jen někdy. Klikal jsme podél ulice, na jednom místě mi to ulici vypsalo a o kousek dál už zase ne. Já tě tím nechtěl pro začátek zatěžovat, ale teď vidím, že jsem měl, no, alespoň sis na to přišel sám. V tom odkazu, co jsem posílal, je psáno, že třídění pomocí - je přibližné, protože geometrie (čára) se převede na bbox. Hledáš-li vzdálenost bodu od bodu, pak bbox bodu je totéž jako bod samotný, ale bbox čáry je prostě obdelník, takový, aby se do něho ta čára vešla. Tak, jak jsi to vyřešil, to řeším i já, tedy podobně. Na konec toho druhého selectu dávám order by st_distance(...) limit 1. st_distance už třídí exaktně, sice pomalu, ale u 100 položek to zase nevadí. U 20M položek (parcely) je to sakra znát. Takže ten tvůj select by v mém podání vypadal: 326),900913) LIMIT 100) as u where st_distance( (st_transform(u.definicni_cara,4326))::geography, (st_setsrid(st_makepoint(18.3657227215035,49.66980665513853),4326))::geography ) 10 order by st_distance( (st_transform(u.definicni_cara,4326))::geography, (st_setsrid(st_makepoint(18.3657227215035,49.66980665513853),4326))::geography limit 1 to vrátí s vysokou pravděpodobností tu správnou ulici, ledaže by ani těch 100 řádku, nalezených aproximovaným výběrem z bboxů, neobsahovalo ten řádek se skutečně nejbližší ulicí. Teď to vypadá, že to funguje slušně. Jen na křižovatkách to někdy vrátí vedlejší ulici. Ale to bych neviděl jako moc velký problém. Inteligentní uživatel klikne kousek dál od křižovatky. protože tam nemáš ten order_by st_distance. Vrátí ti to prostě první řádek, který vyhovuje podmínce, že st_distance 10 a to může být klidně i ta druhá ulice. -- Petr ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Zla, zla priroda (was Re: Tracer plugin - ruian update)
Tohle je vtipna pripominka, kterou je dobre mit na pameti. :-) Ale pocitam, ze zrovna v tomhle pripade KM i RUIAN maji stejny system souradnic, takze plavou na desce spolu. Mimochodem, je to fakt duvod, proc se v KM pouziva S-JTSK? Asi ne, ze? Alespon Wikipedia uvadi jine duvody. Nebo je opravdu z tohoto pohledu definovana nula na nejaky konkretni bod na povrchu? A co delaji chudaci Islandane, kdyz jim ten ostrov plave do dvou smeru zaroven? ;-) Dalibor Zemsky desky jsou proklety potvory, a hybou se. Nehybou se moc rychle, ale trochu se prece jen hybou. Zmerim polohu snezky vuci wgs-84 referenci, a za 100 let je o par centimetru jinde... Takze mit mapu zalozenou na wgs-84 je vlastne fatalne blbe, protoze ty zakreslene veci proste plujou pryc. Resenim je mit jeden system souradnic pro kazdou zemskou desku, ktera tak nejak drzi pohromade. A pak se hold jednou za 50 let zmeni prepocet na wgs- 84. Nastesti je efekt maly ale centimetrovy presnosti proste z principu nejde dosahnout, protoze ty desky se hybou na radech centimetry za rok... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer plugin - ruian update
Zdravím, omlouvám se, ale opravdu se bavíme o číslech popisných? Zrovna u Technické knihovny v Dejvicích vidím jen jedno číslo popisné a 4 čísla orientační: http://vdp.cuzk.cz/vdp/ruian/adresnimista/vyhledej?ob.kod=554782ul.kod=co. kod=400459mc.kod=500178so.kod=27239781vo.kod=search=Vyhledat Více čísel popisných by bylo vidět jak v grafice VDP (http://vdp.cuzk.cz/ marushka/?themeid=1MarUid=DDB04061%206EAC62F2MarUidi=0D3E163B%2076073BA4% 20DDB04061%20E4699646%206EAC62F2MarMiddlePoint=-744741.2141709006%20- 1040895.0606261094MarScale=857), tak v Nahlížení do KN (http://sgi. nahlizenidokn.cuzk.cz/marushka/default.aspx?themeid=3MarUid=7E6595D2%20A5AD 9D88%208244EA23MarUidi=8244EA23MarMiddlePoint=-744781.5201761102%20- 1040865.3080245024MarScale=1996). Raději ještě jednou: - číslo popisné / evidenční je unikátní v rámci části obce a nesmí se používat opakovaně (tedy číslo po zrušené budově nelze přidělit jinému objektu). Popisná a evidenční čísla tvoří dvě samostatné řady. - číslo orientační by mělo určovat pořadí budovy v rámci ulice nebo náměstí, nejsou povinná Viz http://cs.wikipedia.org/wiki/Ozna%C4%8Dov%C3%A1n%C3%AD_dom%C5%AF J. Veselý -- Původní zpráva -- Od: Petr Vejsada o...@propsychology.cz Datum: 4. 2. 2014 Předmět: Re: [Talk-cz] Tracer plugin - ruian update Jestli z minulosti, tak z minulosti velmi nedávné. Například nová budova Technické knihovny ČVUT v Dejvicích má více čísel popisných. Mimochodem, dokazu se te tve databaze nejak zeptat ja? Je pristupna po netu? Databáze nemá port vystrčený ven, ale chceš-li, můžeme se domluvit. Buď přes openvpn nebo ssh tunel. Ale i tak mi to porad neprijde uplne mimozni. Ta Technická knihovna má více vchodů, je spousta paneláků, kdy je jedna budova navenek, ale také má více vchodů, výtahů, byty jsou v každém vchodu číslovány zvlášt, ale pořád je to jedna budova. Nemám úplně jistotu, zda stavební objekt a budova je to samé, možná ne. ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer plugin - ruian update
Ahoj, Dne 5.2.2014 07:43, Dalibor Jelínek napsal(a): A jaky teda mas stavebni objekt prirazen tady? http://vdp.cuzk.cz/vdp/ruian/adresnimista/40037649 O tomhle adresnim bode jsem ti psal drive psal v mailu. Mel jsem dojem, ze tohle misto ve sve databazi nemas. Odkazuje na http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/30119138 Ale je zajímavé, že přímo adresní bod nemá žádnou pozici (definicni_bod = NULL), a stejně na tom je celkem cca 6% adresních bodů. A podle webu RUIAN je tohle asi bug, na jehož odstranění se pracuje. Zdraví, Petr Morávek aka Xificurk ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Zla, zla priroda (was Re: Tracer plugin - ruian update)
Dobrý den, závazné souřadnicové systémy v ČR jsou stanoveny nařízením vlády č. 430/2006 Sb. (portal.gov.cz/app/zakony/zakonPar.jsp?idBiblio=63017fulltext=nr=430~2 F2006part=name=rpp=15#local-content). Pro katastr i RUIAN se používá S- JTSK. Např. v rámci směrnice INSPIRE (http://www.cuzk.cz/Katastr- nemovitosti/INSPIRE.aspx) se grafika katastru vydává i v systému ETRS89 - to je mimochodem systém, který je pevně svázaný s euroasijskou deskou a tedy nezávislý na kontinentálním driftu (stejně jako S-JTSK a další lokální systémy). Pro převod do / z S-JTSK neexistuje jednoznačný matematický vztah z důvodu lokálních deformací S-JTSK. Existuje ale postup, jak dosáhnout centimetrové přesnosti transformací ETRS89 S-JTSK na území celé ČR: http://www.cuzk. cz/Zememerictvi/Geodeticke-zaklady-na-uzemi-CR/GNSS/Nova-realizace-systemu- ETRS89-v-CR.aspx - pomocí dotransformace (interpolace odchylek), doporučuji na konci odkazovaný dokument Metodika převodu. J. Veselý -- Původní zpráva -- Od: Dalibor Jelínek dali...@dalibor.cz Datum: 5. 2. 2014 Předmět: Re: [Talk-cz] Zla, zla priroda (was Re: Tracer plugin - ruian update) Tohle je vtipna pripominka, kterou je dobre mit na pameti. :-) Ale pocitam, ze zrovna v tomhle pripade KM i RUIAN maji stejny system souradnic, takze plavou na desce spolu. Mimochodem, je to fakt duvod, proc se v KM pouziva S-JTSK? Asi ne, ze? Alespon Wikipedia uvadi jine duvody. Nebo je opravdu z tohoto pohledu definovana nula na nejaky konkretni bod na povrchu? A co delaji chudaci Islandane, kdyz jim ten ostrov plave do dvou smeru zaroven? ;-) Dalibor Zemsky desky jsou proklety potvory, a hybou se. Nehybou se moc rychle, ale trochu se prece jen hybou. Zmerim polohu snezky vuci wgs-84 referenci, a za 100 let je o par centimetru jinde... Takze mit mapu zalozenou na wgs-84 je vlastne fatalne blbe, protoze ty zakreslene veci proste plujou pryc. Resenim je mit jeden system souradnic pro kazdou zemskou desku, ktera tak nejak drzi pohromade. A pak se hold jednou za 50 let zmeni prepocet na wgs - 84. Nastesti je efekt maly ale centimetrovy presnosti proste z principu nejde dosahnout, protoze ty desky se hybou na radech centimetry za rok... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz;___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Vytváření ploch
Já jsem si ještě trochu pomáhal tím, že jsem na začátku vytvořil plochu na větší části mapy a následně z ní ukrajoval. Tj. vytvářel cesty, které uvnitř ní rozdělovali skutečné plochy a dával split object. Tím jsem už nemusel uvnitř té velké plochy klikat na každý bod dvakrát, ale stále to není ideální. Jindra Dne 4. února 2014 14:07 Vladimír Slávik slavik.vladi...@seznam.cz napsal(a): Multipolygony (relace) jsou velmi pohodlné, ale vyplatí se tak až od 10-20 bodů, do té doby je jednodušší klikat. Řešil jsem tak celou tuto oblast a musím říct, že po počátečním testování to bylo snadné - doporučuji! http://www.openstreetmap.org/#map=14/49.3081/16.9465 Akorát bych asi doporučil udržet si chladnou hlavu a nekonvertovat vše v okolí, ono to celkem svádí zmultipolygonovat všechno čeho se relace dotknou. S odstupem času si myslím, že někde kolem té desítky bodů je jednodušší pokusit se nevrtat zbytečně do toho co už je a některé části nechat jako dotek části multipolygonu a menší oblasti (je-li to možné). Samozřejmě jakmile je jednou potřeba díra, je to stejně multipolygon a hurá... Je to asi i námět na to, kde sousedící oblasti lepit na sebe a kde ne. Připadne mi, že relací se většina laičtějších editorů bojí (pokud je rozezná), a zůstávají raději stranou. Například tak, že plochy nepřilepí :-D Viz Vyškov na západ od mého příkladu... Vláďa On 4.2.2014 13:30, Dalibor Jelínek wrote: Jo, taky jsem neco takoveho hledal, kdyz jsem zacal delat plochy. Ale nenasel, tak se uklikavam k smrti. Ale je fakt, ze me nenapadlo to delat relacema a ty hranicni cesty vkladat do relaci. To to asi zjednodussi. Ale zase jsou ty relace narocnejsi na vypocetni vykon a hrozi, ze je nekdo rozbije. Ale zkusim to tak. Dalibor ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer plugin - ruian update
Dne 5.2.2014 07:41, JV napsal(a): Zdravím, omlouvám se, ale opravdu se bavíme o číslech popisných? Zrovna u Technické knihovny v Dejvicích vidím jen jedno číslo popisné a 4 čísla orientační: http://vdp.cuzk.cz/vdp/ruian/adresnimista/vyhledej?ob.kod=554782ul.kod=co.kod=400459mc.kod=500178so.kod=27239781vo.kod=search=Vyhledat Více čísel popisných by bylo vidět jak v grafice VDP (http://vdp.cuzk.cz/marushka/?themeid=1MarUid=DDB04061%206EAC62F2MarUidi=0D3E163B%2076073BA4%20DDB04061%20E4699646%206EAC62F2MarMiddlePoint=-744741.2141709006%20-1040895.0606261094MarScale=857), tak v Nahlížení do KN (http://sgi.nahlizenidokn.cuzk.cz/marushka/default.aspx?themeid=3MarUid=7E6595D2%20A5AD9D88%208244EA23MarUidi=8244EA23MarMiddlePoint=-744781.5201761102%20-1040865.3080245024MarScale=1996). Raději ještě jednou: - číslo popisné / evidenční je unikátní v rámci části obce a nesmí se používat opakovaně (tedy číslo po zrušené budově nelze přidělit jinému objektu). Popisná a evidenční čísla tvoří dvě samostatné řady. - číslo orientační by mělo určovat pořadí budovy v rámci ulice nebo náměstí, nejsou povinná Viz http://cs.wikipedia.org/wiki/Ozna%C4%8Dov%C3%A1n%C3%AD_dom%C5%AF J. Veselý Ano, v případě NTK jde o 1 č.p. a 4 čísla orientační. Ona ta struktura dat není vůbec jednoduchá... uvedu na příkladu NTK: Co nám říká stavební objekt 27239781: - kód městské části (Praha 6) - kód části obce (Dejvice) - čísla domovní (2710) - jedná se o budovu s č.p. K tomuto objektu se váží 4 adresní místa, která nesou informaci o: - kód stavebního objektu (27239781) - číslo domovní (2710) - kód ulice (4 různé hodnoty - Flemingovo nám., Studentská, Technická, Thákurova) - číslo orientační (4 různé hodnoty - 6, 1, 20, 13) - PSČ (16000) A teď zkuste někdo popsat, jakým způsobem z těchto dat dostat adresu, která by se měla umístit přímo na budovu v OSM. Zdraví, Petr Morávek aka Xificurk ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer plugin - ruian update
No prave tady mi to prijde uplne jasne, jak jsem psal drive: cesta budovy: addr:place=Dejvice addr:city=Praha 6 (nebo Praha, tady nevim) addr:country=CZ addr:housenumber=2710 addr:conscriptionnumber=2710 ref:ruian=cislo stavebniho objektu bez ulice bez c.o. bez PSC 4x body nad vchody (ale soucasty cesy domu) to same, co je vyse, ovsem s addr:housenumber ve tvaru c.p./c.o. entrance=yes addr:street addr:streetnumber addr:postcode ref:ruian=cislo adresniho mista Tohle mi prijde, jako ze presne kopiruje maximum informaci, ktere z RUIAN mame a dava to nejvetsi smysl. Jedine, co tam takhle neni, je ta vazba mezi SO a AM (resp. je zakreslena v mape, ale to nekdy nemusi tak byt, a bude-li AM lezet mimo SO, pak tam zadna vazba neni, ovsem sla-by pridat, ale myslim, ze vlastne k nicemu neni) Jedina drobna chyba je, ze to v nekterych (ale podle me velmi ridkych) pripadech bude vest ke dvojimu zobrazeni cisla v mape. Ale jen pri velkem zvetseni, jinak je videt jen jedno cislo. Zkousel jsem to. Druha vetsi chybka je, ze to nejde aplikovat na to jedno procento s.o., ktere fakt maji vice c.p. nebo c.e. Sice by to slo v housenumber a consriptionnumber oddelovat strednikem, ale to je velka prasarna. Spise bych si myslel, ze by Trace v tohmle miste zobrazit informaci, ze SO ma vice c.p. nebo c.e. a rekl, ze je tudiz nenatagoval a doporucil uzivateli, aby dum rozdelil na adekvatni mensi casti, nebo tak neco. Treba tak (protoze ty priklady domu, ktere jsem zatim videl, tomu odpovidaly), ze celou cestu SO nakreslenou dle RUIAN oznaci jako building=terrace ci building=garages, a pak ji rozdelit na podbudovy building=house nebo building=garage a ty uz otagovat spravne i s housenumber a conscription number. Co jsem prehledl tentokrat? ;-) Zdravi, Dalibor Ano, v případě NTK jde o 1 č.p. a 4 čísla orientační. Ona ta struktura dat není vůbec jednoduchá... uvedu na příkladu NTK: Co nám říká stavební objekt 27239781: - kód městské části (Praha 6) - kód části obce (Dejvice) - čísla domovní (2710) - jedná se o budovu s č.p. K tomuto objektu se váží 4 adresní místa, která nesou informaci o: - kód stavebního objektu (27239781) - číslo domovní (2710) - kód ulice (4 různé hodnoty - Flemingovo nám., Studentská, Technická, Thákurova) - číslo orientační (4 různé hodnoty - 6, 1, 20, 13) - PSČ (16000) A teď zkuste někdo popsat, jakým způsobem z těchto dat dostat adresu, která by se měla umístit přímo na budovu v OSM. Zdraví, Petr Morávek aka Xificurk ___ 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
