from:"Miroslav Šulc"

Dne 6.8.2012 04:54, Mirek Dlask napsal(a):
 Je otázka, zda nejsou v RÚIAN adresní body domů bez č.p. , asi tam
 budou adresní body rozestavěných domů. Ty v OSM předpokládám nejsou.
 Nebo by se asi zobrazovaly tečky bez čísel!?

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

adresní body bez čísla v rúian neexistují (jsou tam pouze 4, ale ty mají
příznak smazání), protože to z podstaty věci není adresa :-) za adresní
body bez čísla lze ale považovat stavební objekty (na nich je právě
definovaný ten typ čísla bez čísla). podle mě ale nemá smysl je
zobrazovat jako body, budovy (které mají definovanou geometrii) se do
osm z rúian dřív nebo později také dostanou.


 150 je fakt nějak moc

 Mirek

ff


smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

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

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

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

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

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

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


smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

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

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

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

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

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

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

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

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

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

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

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

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

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

Mirek

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

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

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

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

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

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

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

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

smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http

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

Dne 6.8.2012 16:04, Jan Bilak napsal(a):
Ahoj,

jak ten bot rychlý? Aneb za jak dlouho by zpracoval (pokusně) celou ČR
- tedy vygeneroval log?
no, chvíli by mu to asi trvalo, ale v tom nevidím problém. až budu mít
aspoň trochu jistotu, že z toho nepolezou bláboly, tak to můžu zkusit na
celé čr. akorát mám trochu obavy z toho, že ten log bude až moc velký.
Můžeš udělat histogram vzdáleností spárovaných bodů?

nad tímhle už jsem přemýšlel. zkusím to rozdělit po nějakých rozumných
intervalech a přidám to do těch výstupních statistik.

Honza
ff

Dne 6. srpna 2012 4:54 Mirek Dlask dlas...@gmail.com napsal(a):
Je otázka, zda nejsou v RÚIAN adresní body domů bez č.p. , asi tam budou
adresní body rozestavěných domů. Ty v OSM předpokládám nejsou.
Nebo by se asi zobrazovaly tečky bez čísel!?

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

150 je fakt nějak moc

Mirek

Dne 5. srpna 2012 23:30 Miroslav Šulc fordf...@fordfrog.com napsal(a):
tak jsem dodělal bota do stádia, že načte body z osm api a z rúian db,
pokusí se je spárovat a vygeneruje nějaké statistiky. pokud se někdo chce
podívat do kódu, tak je k dispozici na https://github.com/fordfrog/ruian2osm

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

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

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

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

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

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

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

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

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

smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

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

tak jsem přidal do statistik bota ještě ten histogram vzdáleností
spárovaných bodů a informace o změně názvu obce/ulice adresního bodu.

tady jsou doksy: http://pastebin.com/M5AwaeFNhttp://pastebin.com/jtbpMzdX
tady je část mladé boleslavi a kosmonos: http://pastebin.com/jtbpMzdX

ff

Dne 6.8.2012 19:27, Miroslav Šulc napsal(a):
 v příloze posílám log z bota. tady pak ještě výtah z logy pro ty,
 kterým se nebude chtít zip otevírat:
 ...



smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

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

2012-08-05 Tema obsahu Miroslav Šulc

tak jsem ještě narazil na tabulku rn_vusc (vyšší územně samosprávné
celky), což by asi měla být obdoba krajů (aspoň podle obsahu):

ruian_new=# select nazev from rn_vusc order by nazev;
nazev
--
 Hlavní město Praha
 Jihočeský kraj
 Jihomoravský kraj
 Karlovarský kraj
 Kraj Vysočina
 Královéhradecký kraj
 Liberecký kraj
 Moravskoslezský kraj
 Olomoucký kraj
 Pardubický kraj
 Plzeňský kraj
 Středočeský kraj
 Ústecký kraj
 Zlínský kraj
(14 rows)

tím by teda měl být třetí body vyřešený.

ff

Dne 5.8.2012 18:10, Miroslav Šulc napsal(a):
 ahoj,

 pustil jsem se do toho bota nad rúian daty. z analýzy rúian dat mi
 vyplývá, že sestavení adresy lze udělat následovně:
 - adresní místa s vazbou na ulici mají definovanou ulici
 - adresní místa bez vazby na ulici nemají asociovanou žádnou ulici
 - určení obce adresního místa vazbou na stavební objekt a u něj přes
 vazbu na část obce až na samotnou obec (a následně na nějaký vyšší
 územní celek - okres, region)

 k tomu připojuju ilustrační tabulku (typ_kod 1 = má číslo domovní, 2 =
 má číslo evidenční; has_ulice f = nemá definovanou vazbu na ulici, t =
 má definovanou vazbu na ulici; count = počet adresních míst; has_cobce
 = má vazbu na část obce; has_momc = má vazbu na městský obvod/městskou
 část; has_parcela = má vabzu na parcelu):

 ruian_new=# select so.typ_kod, am.ulice_kod is not null has_ulice,
 count(*), count(cobce_kod) has_cobce, count(momc_kod) has_momc,
 count(identifikacni_parcela_id) has_parcela from rn_adresni_misto am
 left join rn_stavebni_objekt so on am.stavobj_kod = so.kod group by
 typ_kod, has_ulice order by typ_kod, has_ulice;
  typ_kod | has_ulice |  count  | has_cobce | has_momc | has_parcela
 -+---+-+---+--+-
1 | f | 1098413 |   1098413 | 2190 | 1048078
1 | t | 1350292 |   1350292 |   266197 | 1310712
2 | f |  353978 |353978 |31947 |  273816
2 | t |  112828 |112828 |16215 |   81166
3 | f |   3 | 0 |0 |   3
3 | t |   1 | 0 |0 |   1
 (6 rows)

 z ní vyplývá, že všechny adresní body typu 1 (má číslo domovní) a 2
 (má číslo evidenční) mají v tabulce stavebních objektů vazbu na část
 obce. problematika určení parametrů adresního bodu by tedy měla být až
 potud jasná. (možná se lze ještě pozastavit nad otázkou, zda do
 informací o adresních bodech zahrnout i městský obvod/městskou část).



 další oblastí je tagování adresních bodů. když se podívám třeba tady u
 nás na adresní body, tak jejich otagování se dost různí (nevím, jestli
 jsem postihnul všechny případy, ale asi ne):

 1) číslo domovní bez tagu addr:city
 addr:conscriptionnumber=666
 addr:country=CZ
 addr:housenumber=666
 addr:street=Lesní
 is_in=Doksy, Liberecký kraj, CZ
 source:addr=mvcr:adresa
 source:loc=cuzk:km

 2) evidenční číslo bez tagu addr:city a addr:street
 addr:country=CZ
 addr:housenumber=ev.479
 addr:provisionalnumber=479
 is_in=Staré Splavy, Doksy, Liberecký kraj, CZ
 note=Nekonzistence cuzk:km a mvcr:adresa
 source=cuzk:km

 3) evidenční číslo s tagem addr:street, ale bez addr:city
 addr:country=CZ
 addr:housenumber=ev.399
 addr:provisionalnumber=399
 addr:street=Klůček
 is_in=Doksy, Liberecký kraj, CZ
 source:addr=mvcr:adresa
 source:loc=cuzk:km

 4) očekával bych adresní body typu 1) včetně tagu addr:city, ale u nás
 jsem je nenašel

 takže otázkou je, jaké tagy má mít adresní bod s číslem domovním a s
 číslem evidenčním (v obci a mimo obec). osobně bych očekával u všech
 adresních bodů následující tagy:
 addr:city=Litovel
 addr:conscriptionnumber=678
 addr:country=CZ
 addr:housenumber=678/1
 addr:postcode=78401
 addr:street=Mlýnská
 addr:streetnumber=1
 is_in=Litovel, Olomoucký kraj, CZ
 source:addr=ruian
 ref:ruian=123456789

 případně lze ještě přidat tag s částí obce. tady je odkaz na addr tag
 na osm: http://wiki.openstreetmap.org/wiki/Key:addr



 poslední věc, na kterou jsem narazil, je, že kraje, které jsou použité
 v osm datech, dnes již neexistují. co jsem pochopil z dokumentace
 rúian, tak se nyní používají tzv regiony soudržnosti, jejichž názvy
 jsou víceméně totožné s kraji (nicméně ne s těmi v osm). tady je
 seznam regionů:

 ruian_new=# select nazev from rn_region_soudrznosti;
   nazev 
 -
  Praha
  Střední Čechy
  Jihozápad
  Severozápad
  Severovýchod
  Jihovýchod
  Střední Morava
  Moravskoslezsko
 (8 rows)

 takže např liberecký kraj zmíněný v příkladech nahoře neexistuje,
 stejně tak olomoucký. tady je pak otázka, jakou identifikaci použít v
 is_in, zda použít regiony soudržnosti (jako náhradu krajů), nebo pro
 lepší identifikaci použít raději okresy.


 takže když to shrnu, tak:
 - identifikace adresních bodů je asi jasná (co s momc?)
 - je potřeba domluvit se, jaké tagy budou adresní body obsahovat
 - je potřeba najít náhradu za kraje

 dotazy

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

2012-08-05 Tema obsahu Miroslav Šulc

nejsou ale součástí údajů o adresních bodech (je otázka, jestli by vůbec
měly být).

ff

Dne 5.8.2012 18:19, LM_1 napsal(a):
 Námět: Regiony soudržnosti se zobrazují na hlavní stránce při zoomu 7,
 takže v OSM zcela jistě jsou.
 LM_1

 Dne 5. srpna 2012 18:10 Miroslav Šulc fordf...@fordfrog.com napsal(a):
 ahoj,

 pustil jsem se do toho bota nad rúian daty. z analýzy rúian dat mi vyplývá,
 že sestavení adresy lze udělat následovně:
 - adresní místa s vazbou na ulici mají definovanou ulici
 - adresní místa bez vazby na ulici nemají asociovanou žádnou ulici
 - určení obce adresního místa vazbou na stavební objekt a u něj přes vazbu
 na část obce až na samotnou obec (a následně na nějaký vyšší územní celek -
 okres, region)

 k tomu připojuju ilustrační tabulku (typ_kod 1 = má číslo domovní, 2 = má
 číslo evidenční; has_ulice f = nemá definovanou vazbu na ulici, t = má
 definovanou vazbu na ulici; count = počet adresních míst; has_cobce = má
 vazbu na část obce; has_momc = má vazbu na městský obvod/městskou část;
 has_parcela = má vabzu na parcelu):

 ruian_new=# select so.typ_kod, am.ulice_kod is not null has_ulice, count(*),
 count(cobce_kod) has_cobce, count(momc_kod) has_momc,
 count(identifikacni_parcela_id) has_parcela from rn_adresni_misto am left
 join rn_stavebni_objekt so on am.stavobj_kod = so.kod group by typ_kod,
 has_ulice order by typ_kod, has_ulice;
  typ_kod | has_ulice |  count  | has_cobce | has_momc | has_parcela
 -+---+-+---+--+-
1 | f | 1098413 |   1098413 | 2190 | 1048078
1 | t | 1350292 |   1350292 |   266197 | 1310712
2 | f |  353978 |353978 |31947 |  273816
2 | t |  112828 |112828 |16215 |   81166
3 | f |   3 | 0 |0 |   3
3 | t |   1 | 0 |0 |   1
 (6 rows)

 z ní vyplývá, že všechny adresní body typu 1 (má číslo domovní) a 2 (má
 číslo evidenční) mají v tabulce stavebních objektů vazbu na část obce.
 problematika určení parametrů adresního bodu by tedy měla být až potud
 jasná. (možná se lze ještě pozastavit nad otázkou, zda do informací o
 adresních bodech zahrnout i městský obvod/městskou část).



 další oblastí je tagování adresních bodů. když se podívám třeba tady u nás
 na adresní body, tak jejich otagování se dost různí (nevím, jestli jsem
 postihnul všechny případy, ale asi ne):

 1) číslo domovní bez tagu addr:city
 addr:conscriptionnumber=666
 addr:country=CZ
 addr:housenumber=666
 addr:street=Lesní
 is_in=Doksy, Liberecký kraj, CZ
 source:addr=mvcr:adresa
 source:loc=cuzk:km

 2) evidenční číslo bez tagu addr:city a addr:street
 addr:country=CZ
 addr:housenumber=ev.479
 addr:provisionalnumber=479
 is_in=Staré Splavy, Doksy, Liberecký kraj, CZ
 note=Nekonzistence cuzk:km a mvcr:adresa
 source=cuzk:km

 3) evidenční číslo s tagem addr:street, ale bez addr:city
 addr:country=CZ
 addr:housenumber=ev.399
 addr:provisionalnumber=399
 addr:street=Klůček
 is_in=Doksy, Liberecký kraj, CZ
 source:addr=mvcr:adresa
 source:loc=cuzk:km

 4) očekával bych adresní body typu 1) včetně tagu addr:city, ale u nás jsem
 je nenašel

 takže otázkou je, jaké tagy má mít adresní bod s číslem domovním a s číslem
 evidenčním (v obci a mimo obec). osobně bych očekával u všech adresních bodů
 následující tagy:
 addr:city=Litovel
 addr:conscriptionnumber=678
 addr:country=CZ
 addr:housenumber=678/1
 addr:postcode=78401
 addr:street=Mlýnská
 addr:streetnumber=1
 is_in=Litovel, Olomoucký kraj, CZ
 source:addr=ruian
 ref:ruian=123456789

 případně lze ještě přidat tag s částí obce. tady je odkaz na addr tag na
 osm: http://wiki.openstreetmap.org/wiki/Key:addr



 poslední věc, na kterou jsem narazil, je, že kraje, které jsou použité v osm
 datech, dnes již neexistují. co jsem pochopil z dokumentace rúian, tak se
 nyní používají tzv regiony soudržnosti, jejichž názvy jsou víceméně totožné
 s kraji (nicméně ne s těmi v osm). tady je seznam regionů:

 ruian_new=# select nazev from rn_region_soudrznosti;
   nazev
 -
  Praha
  Střední Čechy
  Jihozápad
  Severozápad
  Severovýchod
  Jihovýchod
  Střední Morava
  Moravskoslezsko
 (8 rows)

 takže např liberecký kraj zmíněný v příkladech nahoře neexistuje, stejně tak
 olomoucký. tady je pak otázka, jakou identifikaci použít v is_in, zda použít
 regiony soudržnosti (jako náhradu krajů), nebo pro lepší identifikaci použít
 raději okresy.


 takže když to shrnu, tak:
 - identifikace adresních bodů je asi jasná (co s momc?)
 - je potřeba domluvit se, jaké tagy budou adresní body obsahovat
 - je potřeba najít náhradu za kraje

 dotazy/připomínky/náměty?

 ff

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

 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 http

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

2012-08-05 Tema obsahu Miroslav Šulc

v rúian jsou mj dvě tabulky, rn_vusc (to jsou aktuální kraje) a
rn_kraj_1960 (tyhle co jsem pochopil už neplatí). pro is_in každopádně
použiju rn_vusc.

ff

Dne 5.8.2012 19:45, Petr Morávek napsal(a):
 Já myslím, že neměly... Vy jste je někdy v adrese viděli? K čemu by
 tam byly... Navíc tohle už se dá celkem spolehlivě vytáhnout z polohy
 bodu.
 Jinak kraje stále existují ;) my je máme v osm jako admin_level=6.
 Regiony soudržnosti jsou v osm taky, jako admin_level=4.
 Petr

 05.08.12, Miroslav Šulc fordf...@fordfrog.com:
 nejsou ale součástí údajů o adresních bodech (je otázka, jestli by vůbec
 měly být).

 ff

 Dne 5.8.2012 18:19, LM_1 napsal(a):
 Námět: Regiony soudržnosti se zobrazují na hlavní stránce při zoomu 7,
 takže v OSM zcela jistě jsou.
 LM_1

 Dne 5. srpna 2012 18:10 Miroslav Šulc fordf...@fordfrog.com napsal(a):
 ahoj,

 pustil jsem se do toho bota nad rúian daty. z analýzy rúian dat mi
 vyplývá,
 že sestavení adresy lze udělat následovně:
 - adresní místa s vazbou na ulici mají definovanou ulici
 - adresní místa bez vazby na ulici nemají asociovanou žádnou ulici
 - určení obce adresního místa vazbou na stavební objekt a u něj přes
 vazbu
 na část obce až na samotnou obec (a následně na nějaký vyšší územní celek
 -
 okres, region)

 k tomu připojuju ilustrační tabulku (typ_kod 1 = má číslo domovní, 2 =
 má
 číslo evidenční; has_ulice f = nemá definovanou vazbu na ulici, t = má
 definovanou vazbu na ulici; count = počet adresních míst; has_cobce = má
 vazbu na část obce; has_momc = má vazbu na městský obvod/městskou část;
 has_parcela = má vabzu na parcelu):

 ruian_new=# select so.typ_kod, am.ulice_kod is not null has_ulice,
 count(*),
 count(cobce_kod) has_cobce, count(momc_kod) has_momc,
 count(identifikacni_parcela_id) has_parcela from rn_adresni_misto am
 left
 join rn_stavebni_objekt so on am.stavobj_kod = so.kod group by typ_kod,
 has_ulice order by typ_kod, has_ulice;
  typ_kod | has_ulice |  count  | has_cobce | has_momc | has_parcela
 -+---+-+---+--+-
1 | f | 1098413 |   1098413 | 2190 | 1048078
1 | t | 1350292 |   1350292 |   266197 | 1310712
2 | f |  353978 |353978 |31947 |  273816
2 | t |  112828 |112828 |16215 |   81166
3 | f |   3 | 0 |0 |   3
3 | t |   1 | 0 |0 |   1
 (6 rows)

 z ní vyplývá, že všechny adresní body typu 1 (má číslo domovní) a 2 (má
 číslo evidenční) mají v tabulce stavebních objektů vazbu na část obce.
 problematika určení parametrů adresního bodu by tedy měla být až potud
 jasná. (možná se lze ještě pozastavit nad otázkou, zda do informací o
 adresních bodech zahrnout i městský obvod/městskou část).



 další oblastí je tagování adresních bodů. když se podívám třeba tady u
 nás
 na adresní body, tak jejich otagování se dost různí (nevím, jestli jsem
 postihnul všechny případy, ale asi ne):

 1) číslo domovní bez tagu addr:city
 addr:conscriptionnumber=666
 addr:country=CZ
 addr:housenumber=666
 addr:street=Lesní
 is_in=Doksy, Liberecký kraj, CZ
 source:addr=mvcr:adresa
 source:loc=cuzk:km

 2) evidenční číslo bez tagu addr:city a addr:street
 addr:country=CZ
 addr:housenumber=ev.479
 addr:provisionalnumber=479
 is_in=Staré Splavy, Doksy, Liberecký kraj, CZ
 note=Nekonzistence cuzk:km a mvcr:adresa
 source=cuzk:km

 3) evidenční číslo s tagem addr:street, ale bez addr:city
 addr:country=CZ
 addr:housenumber=ev.399
 addr:provisionalnumber=399
 addr:street=Klůček
 is_in=Doksy, Liberecký kraj, CZ
 source:addr=mvcr:adresa
 source:loc=cuzk:km

 4) očekával bych adresní body typu 1) včetně tagu addr:city, ale u nás
 jsem
 je nenašel

 takže otázkou je, jaké tagy má mít adresní bod s číslem domovním a s
 číslem
 evidenčním (v obci a mimo obec). osobně bych očekával u všech adresních
 bodů
 následující tagy:
 addr:city=Litovel
 addr:conscriptionnumber=678
 addr:country=CZ
 addr:housenumber=678/1
 addr:postcode=78401
 addr:street=Mlýnská
 addr:streetnumber=1
 is_in=Litovel, Olomoucký kraj, CZ
 source:addr=ruian
 ref:ruian=123456789

 případně lze ještě přidat tag s částí obce. tady je odkaz na addr tag na
 osm: http://wiki.openstreetmap.org/wiki/Key:addr



 poslední věc, na kterou jsem narazil, je, že kraje, které jsou použité v
 osm
 datech, dnes již neexistují. co jsem pochopil z dokumentace rúian, tak
 se
 nyní používají tzv regiony soudržnosti, jejichž názvy jsou víceméně
 totožné
 s kraji (nicméně ne s těmi v osm). tady je seznam regionů:

 ruian_new=# select nazev from rn_region_soudrznosti;
   nazev
 -
  Praha
  Střední Čechy
  Jihozápad
  Severozápad
  Severovýchod
  Jihovýchod
  Střední Morava
  Moravskoslezsko
 (8 rows)

 takže např liberecký kraj zmíněný v příkladech nahoře neexistuje, stejně
 tak
 olomoucký. tady je pak otázka, jakou identifikaci použít v is_in, zda
 použít
 regiony soudržnosti

Re: [Talk-cz] import budov

2012-08-01 Tema obsahu Miroslav Šulc

Dne 1.8.2012 01:08, LM_1 napsal(a):
 Vlastní tagy obecně nejsou problém, ale měly by být popsané. Určitě
 bych byl pro zachování nějaké jednoznačné identifikace ruian:id nebo
 ref:ruian, to je jedno.
 Ty tagy pro bota se mi moc nelíbí proto, že nevypovídají nic o objektu
 na kterém jsou a není to ani dočasné řešení jako bylo odbl=clean.
 Srozumitelnost existujícího tagu pro neseznámené by asi byla jasná,
 ale způsob způsob jak dojít od bodu který se mi občas někam chybně
 přesune k tomu, že mám použít zvláštní tag už tak jasná není. Možá
 bych volil kompromis, že by bot hlídal posledního autora (to by
 nemuselo být tak složité) a nebo svůj bot=yes tag, který by při
 editaci odstranil - stal by se posledním autorem a nebyl by už
 potřeba. Nikomu by neutíkaly body.

jestli jsem to dobře pochopil, tak navrhuješ, že pro bota by znamenalo,
že se o bod má starat v případě, že buď je posledním editorem nebo je na
bodu tag ruian:bot=yes. takže jakákoliv editace bodu by znamenala, že
se o něj bot přestane starat. pro navrácení bodu botovi by pak bylo
nutné přidat ruian:bot=yes. to podle mě zní rozumně. sice to postrádá
tu úplnou jednoduchost, letmým pohledem není zřejmé, jestli se bot o ten
bod stará nebo ne (člověk musí znát pravidlo o posledním editorovi, což
většina mapperů asi vědět nebude), ale na druhou stranu mapper o botovi
nemusí vůbec vědět a i tak by vše mělo fungovat správně, tj pokud je bod
umístěný špatně, tak ho mapper zedituje a tím ho vyjme z kontroly bota.
jak ho vrátit botovi už vědět nebude, ale to se dá někde popsat (třeba v
tom mailu, který bude bot generovat). výhoda je určitě ta, že se u
většiny bodů nebudou osm data zanášet dalším tagem. akorát při prvotním
importu bude muset bot tohle pravidlo ignorovat, jinak by nic neudělal.
a před importem bude potřeba ručně otagovat body, které jsou v rúian
špatně umístěné, tagem ruian:bot=no.

ff

 LM

 Dne 1. srpna 2012 0:56 Miroslav Šulc fordf...@fordfrog.com napsal(a):
 ono by se to třeba i dalo nějak vymyslet, aby to fungovalo bez tagu, ale
 postrádalo by to jednu důležitou vlastnost - jednoduchost. jednak bot by
 se musel rozhodovat na základě složitějších pravidel než jen bot=yes
 = můžu měnit, bot=no = nesahat, což by mohlo způsobovat
 chyby/nedorozumnění/mylné předpoklady. a to samé by se týkalo i mapperů.
 nikdo si nebude pamatovat složitá pravidla, na základě jakých se bot o
 body stará. ale jednoduché pravidlo bot=yes = bot se o bod stará,
 bot=no = bot na bod sahat nebude, pouze pošle info pro případný ruční
 zásah, to si myslím z toho tagu vyplývá samo a i nový mapper bota
 neznající by měl bez problému tenhle závěr z toho tagu vyvodit.

 píšu tu o tagu bot, ale v praxi by to možná mohl být spíš tag
 ruian:bot=yes|no. z toho by bylo zřejmé, že tag se týká jen a pouze
 bota, který pracuje nad rúian daty. stejně tak by asi mohl existovat tag
 ruian:id=kod z ruian (jeho asi jediný přínos ale vidím v tom, že v
 případě přejmenování ulice/změny čísla by se zachovala historie, jinak
 pro fungování bota asi není nezbytný). nicméně zatím nevím, jak je to
 přesně s custom tagy, sice jsem něco na osm wiki našel, ale nevyplynulo
 mi z toho nějaké pravidlo nebo předepsaný postup.

 ff

 Dne 31.7.2012 23:00, LM_1 napsal(a):
 Dalo by se uvažovat o posuzování jednotlivých argumentů (tagů, pozice)
 individuálně (člověk posune - bot už hýbat nebude, ale klidně změní
 číslo při přečíslování ulice nebo název při změně názvu)

 Změna ve zdrojových datech by mohla sloužit pro navrácení dané hodnoty
 do správy botovi - když se změní hodnota ve zdrojových datech,
 předpokládáme i změnu v realitě a tím zneplatnění původní lidské
 úpravy. To by mělo vyloučit většinu soubojů mezi člověkem a strojem.

 Lukáš Matějka (LM_1)

 Dne 31. července 2012 14:44 Miroslav Šulc fordf...@fordfrog.com napsal(a):
 o tomhle jsem taky uvažoval, má to ale jednu nevýhodu. neumožňuje to bod
 vrátit do správy botovi. stejně tak pokud by někdo jen přidal nějaký
 další tag k adresnímu bodu, tak by se bot taky přestal o ten bod starat,
 i když by se o něj měl starat dál.

 ff

 Dne 31.7.2012 14:15, LM_1 napsal(a):
 Nejsou systémy s tagováním bot/nobot moc komplikované? Co kdyby se bot
 podíval na autora poslední změny daného bodu a pokud by to byl on sám
 tak by ho upravil podle potřeby, pokud by to byl někdo jiný tak by jen
 vygeneroval upozornění.
 LM_1
 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-cz

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

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

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



smime.p7s
Description: Elektronicky podpis S/MIME

Re: [Talk-cz] import budov

2012-08-01 Tema obsahu Miroslav Šulc

no, tady u nás je editorem bodů účet lpechacek, tak nevím, jestli to
importoval tenhle uživatel.

ff

Dne 1.8.2012 14:48, LM_1 napsal(a):
 Uvažoval jsem přesně takto.
 Není i dnes většina adresních bodů z importů? Ty ručně dělané budou
 pravděpodobně správně...
 LM



smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] import budov

2012-07-31 Tema obsahu Miroslav Šulc

o tomhle jsem taky uvažoval, má to ale jednu nevýhodu. neumožňuje to bod
vrátit do správy botovi. stejně tak pokud by někdo jen přidal nějaký
další tag k adresnímu bodu, tak by se bot taky přestal o ten bod starat,
i když by se o něj měl starat dál.

ff

Dne 31.7.2012 14:15, LM_1 napsal(a):
 Nejsou systémy s tagováním bot/nobot moc komplikované? Co kdyby se bot
 podíval na autora poslední změny daného bodu a pokud by to byl on sám
 tak by ho upravil podle potřeby, pokud by to byl někdo jiný tak by jen
 vygeneroval upozornění.
 LM_1


smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] import budov

2012-07-31 Tema obsahu Miroslav Šulc

ono by se to třeba i dalo nějak vymyslet, aby to fungovalo bez tagu, ale
postrádalo by to jednu důležitou vlastnost - jednoduchost. jednak bot by
se musel rozhodovat na základě složitějších pravidel než jen bot=yes
= můžu měnit, bot=no = nesahat, což by mohlo způsobovat
chyby/nedorozumnění/mylné předpoklady. a to samé by se týkalo i mapperů.
nikdo si nebude pamatovat složitá pravidla, na základě jakých se bot o
body stará. ale jednoduché pravidlo bot=yes = bot se o bod stará,
bot=no = bot na bod sahat nebude, pouze pošle info pro případný ruční
zásah, to si myslím z toho tagu vyplývá samo a i nový mapper bota
neznající by měl bez problému tenhle závěr z toho tagu vyvodit.

píšu tu o tagu bot, ale v praxi by to možná mohl být spíš tag
ruian:bot=yes|no. z toho by bylo zřejmé, že tag se týká jen a pouze
bota, který pracuje nad rúian daty. stejně tak by asi mohl existovat tag
ruian:id=kod z ruian (jeho asi jediný přínos ale vidím v tom, že v
případě přejmenování ulice/změny čísla by se zachovala historie, jinak
pro fungování bota asi není nezbytný). nicméně zatím nevím, jak je to
přesně s custom tagy, sice jsem něco na osm wiki našel, ale nevyplynulo
mi z toho nějaké pravidlo nebo předepsaný postup.

ff

Dne 31.7.2012 23:00, LM_1 napsal(a):
 Dalo by se uvažovat o posuzování jednotlivých argumentů (tagů, pozice)
 individuálně (člověk posune - bot už hýbat nebude, ale klidně změní
 číslo při přečíslování ulice nebo název při změně názvu)

 Změna ve zdrojových datech by mohla sloužit pro navrácení dané hodnoty
 do správy botovi - když se změní hodnota ve zdrojových datech,
 předpokládáme i změnu v realitě a tím zneplatnění původní lidské
 úpravy. To by mělo vyloučit většinu soubojů mezi člověkem a strojem.

 Lukáš Matějka (LM_1)

 Dne 31. července 2012 14:44 Miroslav Šulc fordf...@fordfrog.com napsal(a):
 o tomhle jsem taky uvažoval, má to ale jednu nevýhodu. neumožňuje to bod
 vrátit do správy botovi. stejně tak pokud by někdo jen přidal nějaký
 další tag k adresnímu bodu, tak by se bot taky přestal o ten bod starat,
 i když by se o něj měl starat dál.

 ff

 Dne 31.7.2012 14:15, LM_1 napsal(a):
 Nejsou systémy s tagováním bot/nobot moc komplikované? Co kdyby se bot
 podíval na autora poslední změny daného bodu a pokud by to byl on sám
 tak by ho upravil podle potřeby, pokud by to byl někdo jiný tak by jen
 vygeneroval upozornění.
 LM_1
 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-cz

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



smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] import budov

2012-07-30 Tema obsahu Miroslav Šulc

Dne 30.7.2012 03:02, Lukas Kohout napsal(a):
 On 30.7.2012 2:20, Miroslav Šulc wrote:
 Dne 30.7.2012 00:59, Lukas Kohout napsal(a):
  On 28.7.2012 23:15, Miroslav Šulc wrote:
 možná nejlepší r(ešení by bylo adresní body naimportovat/zaktualizovat
 automaticky, akorát pr(ípady, kdy už adresní bod existuje a je od toho v
 rúian vzdálený víc než x jednotek by se r(ešily poloautomaticky. možná by
 nebylo špatné napsat si ne(jaký testovací skript, který by zjistil, jak
 moc se aktuální data v osm liší od rúian. z toho by se pak dalo ledaco
 vyc(íst. až se mi doimportují osm data do db, tak to mu*žu zkusit napsat a
 uvidíme, co tu vlastne( r(ešíme.
 Zdravím, navrhuji ude(lat možnost vyr(adit oblast z automatického
 importu/aktualizace. V naší vesnici jsou ne(které adresní body chybne(
 umíste(né, ne(které chybí úplne(. Asi bych nebyl nadšený, kdyby mi je
 ne(jaký bot stále dokola automaticky pr(esouval/mazal (zrovna dnes jsem
 dopln(oval jedno c(.p. podle nálepky na popelnici, což je možné jen v
 nede(li vec(er :) )
 chybne( umíste(né znamená co pr(esne(? posunuté o kolik metru*? podle my be(
 skript neme(l me(nit body, které jsou od sebe vzdáleny víc jak x metru* (tj
 rúian vs osm), ale me(l by je ne(kam vypsat. tyhle by se pak museli
 zkontrolovat ruc(ne(. kolik jich bude, by me(lo vyplynout z analýzy rozdílu*
 mezi rúian a osm, kterou mám v plánu ude(lat.

 k te(m chybe(jícím bodu*m? znamená to, že tam máte ne(jaká c(p, o kterých
 rúian neví?
 Materiály ke zkoumání:
 http://maps.fordfrog.com/?lat=50.05843lon=15.19497zoom=18layers=0B0FTF
 (nástroj špatne( zpracovává permalink...

ten permalink jsem opravil. vc(era jsem pr(ede(lával zobrazení
sour(adnic, aby bylo v epsg:4326 (tj stejné jako osm) a rozbil jsem tím
permalink.

 Do pozornosti doporuc(uji c(ísla 125, 126, 127, 133, 162 (ty 3
 rozestave(né domy u hlavní jsou již minimálne( rok obydlené, zítra
 je obejdu se psem) a ve str(ední c(ásti vesnice pak 16, 7, 9, 10 - tam
 rúian oznac(uje c(ísla (zbor(ených) stodol.

ty posuny jsou dost znatelné, to by se me(lo dát odchytit. co se týká
te(ch c(ísel nezanesených do rúian, tam bych asi volil ne(jaký tag typu
nobot, který by bod chránil pr(ed botem. body tohohle typu by navíc
me(ly vyjet z toho porovnávacího skriptu, takže by se daly pr(ed
importem ruc(ne( odkontrolovat (pokud jich nebude moc) a otagovat tagem
nobot, aby na ne( bot nesahal.


 Naopak ve vedlejší obci je pr(edchozí import ne(jak rozházený, ne(co
 tam i chybí a tam by zme(na podle rúian znamenala znac(né zlepšení:
 http://maps.fordfrog.com/?lat=50.05772lon=15.21386zoom=18layers=0B0FTF

koukám, že ta tvoje oblast je ideální na pr(íklady nesrovnalostí :-)

 jinak ne(kde na osm wiki jsem c(etl o tagu bot nebo tak ne(jak (ted( to
 nemu*žu najít). podle me( automaticky spravované adresní body by me(ly
 tenhle tag mít. pokud by pak ne(kdo bod pr(esunul, protože je umíste(ný
 špatne(, tak by mu ten tag smazal a tím pádem by skript ten bod pr(estal
 aktualizovat, max by ne(kam vypsal zme(ny pro daný bod, pokud k nim dojde.
 takových bodu* bude v porovnání s te(mi cca tr(emi miliony minimum, takže
 pr(ípadné zme(ny (kterých taky asi bude minimum) by se daly zvládat ruc(ne(,
 pokud bude potr(eba je do osm zanést.

 LuKo
ff


smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] import budov

2012-07-29 Tema obsahu Miroslav Šulc

Dne 30.7.2012 00:59, Lukas Kohout napsal(a):
  On 28.7.2012 23:15, Miroslav Šulc wrote:
 možná nejlepší řešení by bylo adresní body naimportovat/zaktualizovat
 automaticky, akorát případy, kdy už adresní bod existuje a je od toho v
 rúian vzdálený víc než x jednotek by se řešily poloautomaticky. možná by
 nebylo špatné napsat si nějaký testovací skript, který by zjistil, jak
 moc se aktuální data v osm liší od rúian. z toho by se pak dalo ledaco
 vyčíst. až se mi doimportují osm data do db, tak to můžu zkusit napsat a
 uvidíme, co tu vlastně řešíme.
 Zdravím, navrhuji udělat možnost vyřadit oblast z automatického
 importu/aktualizace. V naší vesnici jsou některé adresní body chybně
 umístěné, některé chybí úplně. Asi bych nebyl nadšený, kdyby mi je
 nějaký bot stále dokola automaticky přesouval/mazal (zrovna dnes jsem
 doplňoval jedno č.p. podle nálepky na popelnici, což je možné jen v
 neděli večer :) )

chybně umístěné znamená co přesně? posunuté o kolik metrů? podle my bě
skript neměl měnit body, které jsou od sebe vzdáleny víc jak x metrů (tj
rúian vs osm), ale měl by je někam vypsat. tyhle by se pak museli
zkontrolovat ručně. kolik jich bude, by mělo vyplynout z analýzy rozdílů
mezi rúian a osm, kterou mám v plánu udělat.

k těm chybějícím bodům? znamená to, že tam máte nějaká čp, o kterých
rúian neví?

jinak někde na osm wiki jsem četl o tagu bot nebo tak nějak (teď to
nemůžu najít). podle mě automaticky spravované adresní body by měly
tenhle tag mít. pokud by pak někdo bod přesunul, protože je umístěný
špatně, tak by mu ten tag smazal a tím pádem by skript ten bod přestal
aktualizovat, max by někam vypsal změny pro daný bod, pokud k nim dojde.
takových bodů bude v porovnání s těmi cca třemi miliony minimum, takže
případné změny (kterých taky asi bude minimum) by se daly zvládat ručně,
pokud bude potřeba je do osm zanést.


 LuKo

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



smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] import budov

2012-07-28 Tema obsahu Miroslav Šulc

Dne 28.7.2012 22:35, hanoj napsal(a):
 Ja bych nadhodil nekolik otazek treba pro adresni body:

 * Kolik je adresnich bodu? 2.500.000
2915347 (z toho 2709859 má definované souřadnice), když bychom to brali
po kú, tak těch je 13026.
 * Kolik mapperu se bude ucastnit takove prace? Prvni desitky.
při tom množství práce (viz níž) asi nikdo :-)
 * Jak dlouho to bude trvat? ...
no, když mapper stráví na jednom kú 5 pouhých minut, tak to je jenom
cca 1085 hodin práce :-)
 * Jaka cast dat by mela byt mappery pridavana tam kde nikdy nebyla? Vetsina.
tak ono se dá něco okontrolovat třeba podle bingu, ale i to má svoje
problémy. co jsem četl někde na osm wiki, tak jim občas mapa nesedí a je
posunutá. další věc je ta, že rúian data jsou aktuální kdežto bing mapa
zastarává. takže ruční úpravy můžou mít naopak i negativní dopad, pokud
by se někdo striktně držel bingu. nehledě na to, že asi většina
adresních bodů z předchozího importu zůstala rukou živého mappera
netknutá, ať už jsou umístěné správně nebo jsou posunuté.
 * Jak budou uzivatele hodnotit (ne)kvalitu dat jiz v OSM? Na zaklade
 dat CUZK a u par stovek bodu ze znalosti z terenu kde bydli.Tezko ale
 suplovat:
 http://www.cuzk.cz/GenerujSoubor.ashx?NAZEV=10-POROVNANIADRES

 Opravdu je individualni prace na vetsine uzemi republiky cesta, jak
 data RUIAN dostat do OSM?
je fakt, že ten efekt za těch cca 1085 hodin (samozřejmě je to pouze
odhad) práce ve srovnání s plnou automatizací by byl asi minimální. už
jenom proto, že by se to ručně nikdy nedodělalo.

možná nejlepší řešení by bylo adresní body naimportovat/zaktualizovat
automaticky, akorát případy, kdy už adresní bod existuje a je od toho v
rúian vzdálený víc než x jednotek by se řešily poloautomaticky. možná by
nebylo špatné napsat si nějaký testovací skript, který by zjistil, jak
moc se aktuální data v osm liší od rúian. z toho by se pak dalo ledaco
vyčíst. až se mi doimportují osm data do db, tak to můžu zkusit napsat a
uvidíme, co tu vlastně řešíme.
 h.anoj
ff


smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] import budov

2012-07-27 Tema obsahu Miroslav Šulc

já jsem nad tím ješte( vc(era pr(emýšlel, a dospe(l jsem k tomuhle:

* aplikace by me(la umožn(ovat nejen jednorázový import, ale i následné
aktualizace podle zme(n v rúian
* evidence prováde(ní importu* by me(la být souc(ástí aplikace tak, aby
se na ní nezapomínalo, souc(asne( by me(la být co nejjednodušší
* z aplikace by me(lo být zr(ejmé, co už je hotové a co ješte( ne,
pr(ípadne( kde jsou ne(jaké zme(ny v rúian
* aplikace by me(la fungovat naprosto samostatne(, bez nutnosti ne(jaké
obsluhy

takhle ne(jak by ta aplikace mohla vypadat:

* byla by webová aplikace, kde by se podle katastrálních území daly
stahovat osm soubory s obrysy budov (a pr(ípadne( i s adresními body)
* aplikace by zobrazovala u každého kú, zda je naimportovaný nebo ne a
jestli v rúian došlo k ne(jakým zme(nám + možnost filtrování (okres,
stav importu, název kú) - v pr(ípade( budov by aplikace zobrazovala jen
kú, kde je definovaný obrys alespon( jedné budovy
* v aplikaci by se evidovalo, kdo a kdy jaký soubor naimportoval do osm
+ poznámky k importu
* aplikace by umožn(ovala sledovat zme(ny v rúian (tj. pokud ne(kdo
stáhne a naimportuje ne(jaké budovy do osm, tak info zanese do aplikace,
aplikace pak bude ve(de(t, že k danému datu jsou budovy naimportované a
umožní pr(íšte( vyexportovat pouze rozdíl mezi posledním naimportovaným
stavem a souc(asným stavem v rúian) a exportovat pouze zme(ny (vc(etne(
informace o odstrane(ných objektech)
* z aplikace také bude zr(ejmé, kdo zrovna na c(em de(lá
* aplikace by mohla také zobrazovat historii importu* (tj. kdo, kdy a
co), kdo má co rozde(lané a jak dlouho, kolik toho zbývá naimportovat apod.

pr(emýšlel jsem o tom, jak por(ešit, aby nebylo nutné se do aplikace
registrovat a souc(asne( zajistit urc(itou míru autorizace pr(i zadávání
informací o provedení importu a napadlo me( následující:

1) když si budu chtít stáhnout data z urc(itého kú, tak si to kú
vyhledám, zadám svu*j mail a jestli chci komplet soubor nebo rozdílový
soubor a aplikace mi soubor pošle na mail, vc(etne( linku pro zanesení
informace o provedení importu do aplikace
2) naimportuju budovy do osm (vizuální kontrola, opravy apod.)
3) když mám naimportováno, kliknu na link z mailu, zobrazí se mi webový
formulár(, já tam zadám poznámky k importu a odešlu
4) systém si informace spáruje s pr(edchozím exportem a bude ve(de(t, že
až po urc(ité datum jsou budovy naimportované, takže bude moct jednoduše
sledovat rozdíly

máte k tomu ne(kdo ne(jaké pr(ipomínky nebo podne(ty?

pak mám ješte( jeden technický dotaz. tušíte ne(kdo, jak pr(evést data z
postgis geometry do osm formátu? s body pr(edpokládám problém nebude,
ale netuším, jak s polygony. rúian se neomezuje jen na c(áry, takže tam
asi bude nutné provést ne(jakou konverzi. ideální by byla ne(jaká
knihovna, která vezme postgis geometry a ude(lá z ní osm xml. zkoušel
jsem ne(co vygooglovat, ale asi jsem zadával špatná klíc(ová slova.

ff

Dne 26.7.2012 08:50, Zdene(k Pražák napsal(a):
 no kdyby se pr(ipravily stránky se zdrojovými údaji pro budovy pro
 jednotlivá katastrální území, pak by bylo možné vytvor(it stránky na
 wiki s odkazy na stažení jednotlivých souboru*. zájemce by si stáhl
 data pro požadované katastrální území, provedl kontrolu napr( vu*c(i
 bingu (odstranil ru*zné chyby - napr(íklad neexistující budovy, budovy
 s jiným tvarem, doplnil by budovy ve skutec(nosti existující a
 neobsažené v datech RUIAN) a poté opravená data odeslal na OSM.
 V tabulce na wiki by zaznamenal provedení exportu a pr(ípadné problémy
 Pražák

 Dne 25. c(ervence 2012 19:34 Miroslav Šulc fordf...@fordfrog.com
 mailto:fordf...@fordfrog.com napsal(a):

 no, tak to by rozhodne( me(lo ušetr(it c(as, protože jestli se
 nepletu, tak
 když je budova v digitální mape( kú, tak bude i v rúian a dala by
 se snad
 jednoduše naimportovat. podle me( by to ale chte(lo ude(lat ne(jak
 systematicky. samozr(ejme( mu*žu ude(lat ne(jakou webovou stránku,
 odkud si
 kdokoliv bude moct stáhnout osm soubor s budovama pro daný výbe(r
 (tr(eba
 ten katastr) a nechat tomu volný pru*be(h, ale pokud bychom tomu dali
 ne(jaký r(ád, tak by to asi bylo lepší.

 máte ne(kdo ne(jaké návrhy?

 ff

 Dne 25.7.2012 19:28, Zdene(k Pražák napsal(a):
  no já zatím pomocí pluginu tracer kreslím v katastrálních
 územích s digitální mapou budovy, tak jsem si myslel jestli bych
 nemohl využít uvedených dat
 
   Pu*vodní zpráva 
  Od: Miroslav Šulc fordf...@fordfrog.com
 mailto:fordf...@fordfrog.com
  Pr(edme(t: Re: [Talk-cz] rúian mapy - vylepšení
  Datum: 25.7.2012 19:10:59
  
  Dne 25.7.2012 18:58, Zdene(k Pražák napsal(a):
  dají se ne(jak data z RUIAN dostat po jednotlivých katastrech
 do JOSM a
  následne( po kontrole napr( vu*c(i Bingu poslat do OSM
  jaká data konkrétne(? adresní body? budovy? nebo ne(jaká jiná?
 samozr(ejme(
  není problém

Re: [Talk-cz] import budov

2012-07-27 Tema obsahu Miroslav Šulc

Dne 27.7.2012 13:20, Jan Bilak napsal(a):
 Ahoj,

 teď z toho nechápu, zda si aplikaci představuješ jen jako evidenční
 nebo zda aplikace má provádět vlastní import (resp. s ním výrazně
 pomáhat).

aplikace pouze připraví data z rúian, samotný import provede mapper.
tj. aplikace pro import připraví data, ale nebude import provádět, ten
se bude dělat ručně. i kdybychom (pokud vůbec, to vyplyne z ručních
importů) v budoucnu uvažovali o nějaké automatizaci, tak v prvním kroku
se to stejně musí udělat ručně, abychom věděli, nakolik je rúian
spolehlivý zdroj, jaké problémy lze očekávat apod. pro kontinuální práci
s daty z rúian je pak potřeba ta evidenční část.

 Tedy za zásadní považuji porovnání současných OSM dat s daty RUIAN a
 následné provedení změn (posuny stávajících bodů, opravy tagů,
 zachování stávajících tagů, doplnění chybějících tagů, ...).
 Samozřejmě s tím, že proces bude pod manuální kontrolou člověka, který
 bude import provádět (tedy nikoli plně automatický, ale
 poloautomatický). O těchto funkcích se v popisu nezmiňuješ.
vycházel jsem hlavně z importu budov tam, kde je nemáme, to je asi ta
nejjednodušší varianta. co se týče importu budov do míst, kde už nějaké
jsou, nebo importu adresních bodů, tak se přiznám, že nevím, jestli v
josm existují nástroje na zobrazení rozdílů ve vrstvách, na slučování
objektů (a tagů) z různých vrstev apod. s tím zkušenosti nemám. ale
určitě se tu najde někdo, kdo to vědět bude nebo aspoň bude vědět, kde
hledat.

ten můj nástřel je v podstatě (podle mě) asi to nejnutnější minimum pro
to, aby se dala data z rúian využít pro manuální importy. nad tím potom
lze dělat další nadstavby, které práci zjednoduší a zrychlí. něco určitě
vyplyne i ze zkušeností se samotnými importy.
 Honza
ff



smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] import budov

2012-07-27 Tema obsahu Miroslav Šulc

v souvislosti s tím co píšeš mě napadlo udělat to komplet jako josm
plugin. tj. serverová část by zůstala tak jak jsem psal, ale všechno
ostatní by se dělalo přímo z josm pluginu. ten by si stáhl data přes api
ode mě ze serveru z aktuální databáze rúian, provedl by porovnání s
datovou vrstvou z osm a vyhodil by nějaké info o rozdílech v osm a v
rúian s tím, že mapper by si vybíral varianty a potvrzoval je, případně
by sáhnul přímo do osm vrstvy a udělal úpravy tam. při uploadu změn do
osm by se pak zapsalo i info ke mně na server o provedení importu. do
pluginu by se pak dala přidávat funkcionalita dle potřeby.

ff

Dne 27.7.2012 14:18, Jan Bilak napsal(a):
 Otázka je, jak by měla vypadat ta připravená data. V případě importu
 nových věcí tak, kde žádné nebyly, je to celkem primitivní. Ale mnohem
 náročnější bude import do míst, kde již nějaká data jsou. Tam bude
 třeba něco starého odstranit, něco modifikovat, něco přidat... Lze v
 OSM formátu postihnout nějak všechny tyto typy změn (odstranění,
 modifikace, přidání nových objektů)? A pokud lze, je možné to pak
 nějak rozumně vizualizovat, aby to člověk mohl projít a rozhodovat
 tohle je ok, tohle zamítnu a zůstane při starém, tohle bude ještě
 trochu jinak... pomocí stávajících nástrojů? Nevím, jaké jsou
 možnosti.

 Pokud nic vhodné stávajícího není, tak bych to viděl spíše na
 interaktivní aplikaci, která zobrazí ty rozdíly ve vhodné podobě, u
 každé umožní se rozhodnout, zda ponechat stará data, nová data,
 automaticky zmergovat nebo ručně upravit. Ruční úpravu by ta aplikace
 přímo nepodporovala, protože by to bylo příliš náročné (vlastně by
 bylo třeba vytvořit obdobu editoru jako JOSM), ale poznačilo by to
 nutnost ruční editace do dat nějakými tagy, aby výsledek, který z
 aplikace vypadne, bylo možné otevřít např. v JOSM a ručně provést
 potřebné úpravy.

 Např. u adresních bodů by bylo podle mě vhodné, aplikace provedla
 nějaké inteligentní matchování adresních bodů v OSM a RUIAN,
 zobrazovala původní a nový bod vizuálně propojený šipkou, jinak
 vyznačené body, které jsou pouze v OSM a naopak jinak vyznačené body,
 které jsou pouze v RUIAN. Uživatel by mohl vždy zvolit, zda ponechat
 novou nebo starou polohu bodu (zde by bylo možné i volit vlastní
 polohu - jde o primitivní úkon) atd. Nakonec by aplikace vytvořila OSM
 patch, který by obsahoval požadované úpravy včetně vhodně zmergovaných
 tagů (ty by možná bylo třeba také kontrolovat v aplikaci) atd.

 U budov to bude samozřejmě výrazně složitější.

 Obecně čistě ručního importu se celkem obávám. Dat je vetší než malé množství.

 Honza


 Dne 27. července 2012 13:41 Miroslav Šulc fordf...@fordfrog.com napsal(a):
 Dne 27.7.2012 13:20, Jan Bilak napsal(a):
 Ahoj,

 teď z toho nechápu, zda si aplikaci představuješ jen jako evidenční
 nebo zda aplikace má provádět vlastní import (resp. s ním výrazně
 pomáhat).
 aplikace pouze připraví data z rúian, samotný import provede mapper.
 tj. aplikace pro import připraví data, ale nebude import provádět, ten
 se bude dělat ručně. i kdybychom (pokud vůbec, to vyplyne z ručních
 importů) v budoucnu uvažovali o nějaké automatizaci, tak v prvním kroku
 se to stejně musí udělat ručně, abychom věděli, nakolik je rúian
 spolehlivý zdroj, jaké problémy lze očekávat apod. pro kontinuální práci
 s daty z rúian je pak potřeba ta evidenční část.

 Tedy za zásadní považuji porovnání současných OSM dat s daty RUIAN a
 následné provedení změn (posuny stávajících bodů, opravy tagů,
 zachování stávajících tagů, doplnění chybějících tagů, ...).
 Samozřejmě s tím, že proces bude pod manuální kontrolou člověka, který
 bude import provádět (tedy nikoli plně automatický, ale
 poloautomatický). O těchto funkcích se v popisu nezmiňuješ.
 vycházel jsem hlavně z importu budov tam, kde je nemáme, to je asi ta
 nejjednodušší varianta. co se týče importu budov do míst, kde už nějaké
 jsou, nebo importu adresních bodů, tak se přiznám, že nevím, jestli v
 josm existují nástroje na zobrazení rozdílů ve vrstvách, na slučování
 objektů (a tagů) z různých vrstev apod. s tím zkušenosti nemám. ale
 určitě se tu najde někdo, kdo to vědět bude nebo aspoň bude vědět, kde
 hledat.

 ten můj nástřel je v podstatě (podle mě) asi to nejnutnější minimum pro
 to, aby se dala data z rúian využít pro manuální importy. nad tím potom
 lze dělat další nadstavby, které práci zjednoduší a zrychlí. něco určitě
 vyplyne i ze zkušeností se samotnými importy.
 Honza
 ff


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

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




smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] dotaz - zjednodušení dat pro renderování mapy

2012-07-26 Tema obsahu Miroslav Šulc

Dne 26.7.2012 08:46, hanoj napsal(a):
 chtěl jsem se zeptat, jestli někdo netušíte, jak bych mohl zjednodušit
 data v postgis db tak, aby renderování netrvalo tak dlouho. jde mi
 hlavně o parcely. moje představa je taková, že bych např. pro každou
 obec sloučil všechny parcely stejného typu do jedné geometrie a z toho
 bych pak generoval mapu, místo tak jako teď ze všech parcel. máte s tím
 někdo zkušenosti?
 *** v GIS se tomu rika dissolve
 *** v PostGIS udajne staci nad tabulkou sql s GROUP BY druh pozemku kod
 http://gis.stackexchange.com/questions/1387/is-there-a-dissolve-function-in-postgis-other-than-st-union

zkusil jsem ten st_union a dělá to přesně to co potřebuju, díky.
 h.

ff



smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] rúian mapy - vylepšení

2012-07-26 Tema obsahu Miroslav Šulc

tak jsem ješte( trochu upravil generování map z rúian dat. provedl jsem
ne(jaké optimalizace, takže vykreslování by me(lo být rychlejší. trochu
jsem to i vylepšil graficky. pr(edpokládám, že už do toho šahat nebudu,
takže tohle by me(l být víceméne( konec(ný stav. data se samozr(ejme(
budou pru*be(žne( aktualizovat z rúian. aktuálne( je ale problém s
aktualizacema, od updatu z 23.7.2012 import gml polygonu* shazuje
databázi (crash postgisu), takže dokud se to nevyr(eší, tak aktualizace
nebudou (bug je tady: http://trac.osgeo.org/postgis/ticket/1936).

pro shrnutí:
mapa vygenerovaná z rúian dat je k prohlížení na
http://maps.fordfrog.com http://maps.fordfrog.com/
wms vrstvy jsou na http://wms.fordfrog.com/gwc/service/wms

dal jsem tam i ty kr(ováky, ale mám pocit, že por(ád nefungují jak mají
a já netuším, kde by mohl být problém.

ff

Dne 24.7.2012 13:40, Miroslav Šulc napsal(a):
 ahoj,

 pr(idal jsem do map na http://maps.fordfrog.com/ ješte( mapy z osm a z
 katastru a taky overlay vrstvu adresních bodu* z rúian, takže lze napr(. v
 mape( porovnávat polohu adresních bodu* oproti osm. opravil jsem taky
 funkcionalitu permalinku, takže už by me(l fungovat.

 mapy ted( jsou (a ješte( chvíli budou) pomalejší, protože tam importuju
 osm planet data a znovu (opravené) multipointy do databáze rúian.

 ff



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



smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] import budov (was: rúian mapy - vylepšení)

2012-07-25 Tema obsahu Miroslav Šulc

no, tak to by rozhodně mělo ušetřit čas, protože jestli se nepletu, tak
když je budova v digitální mapě kú, tak bude i v rúian a dala by se snad
jednoduše naimportovat. podle mě by to ale chtělo udělat nějak
systematicky. samozřejmě můžu udělat nějakou webovou stránku, odkud si
kdokoliv bude moct stáhnout osm soubor s budovama pro daný výběr (třeba
ten katastr) a nechat tomu volný průběh, ale pokud bychom tomu dali
nějaký řád, tak by to asi bylo lepší.

máte někdo nějaké návrhy?

ff

Dne 25.7.2012 19:28, Zdeněk Pražák napsal(a):
 no já zatím pomocí pluginu tracer kreslím v katastrálních územích s digitální 
 mapou budovy, tak jsem si myslel jestli bych nemohl využít uvedených dat

  Původní zpráva 
 Od: Miroslav Šulc fordf...@fordfrog.com
 Předmět: Re: [Talk-cz] rúian mapy - vylepšení
 Datum: 25.7.2012 19:10:59
 
 Dne 25.7.2012 18:58, Zdeněk Pražák napsal(a):
 dají se nějak data z RUIAN dostat po jednotlivých katastrech do JOSM a
 následně po kontrole např vůči Bingu poslat do OSM
 jaká data konkrétně? adresní body? budovy? nebo nějaká jiná? samozřejmě
 není problém vyexportovat data z databáze s určitým filtrem (obec,
 extent apod) do osm formátu, ale pokud už data jsou i v osm, tak by se
 musely duplicity odstranit. a to moc netuším jak.

 a pak je tu ještě druhá věc. pokud bychom něco takového dělali, tak by
 to podle mě chtělo jednak udržovat přehled, co už je naimportováno a co
 ne, a za druhé by bylo fajn zachovat nějakou referenční vazbu na
 originální data (rúian), abychom případně v budoucnu mohli data v rúian
 a v osm porovnávat (co je nového apod).

 a pak je tu ještě třetí věc, a to posoudit, na čem má smysl trávit svůj
 čas a co automatizovat (a čas využít na něco lepšího).

 Pražák
 ff



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



smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

[Talk-cz] dotaz - zjednodušení dat pro renderování mapy

2012-07-25 Tema obsahu Miroslav Šulc

ahoj,

chtěl jsem se zeptat, jestli někdo netušíte, jak bych mohl zjednodušit
data v postgis db tak, aby renderování netrvalo tak dlouho. jde mi
hlavně o parcely. moje představa je taková, že bych např. pro každou
obec sloučil všechny parcely stejného typu do jedné geometrie a z toho
bych pak generoval mapu, místo tak jako teď ze všech parcel. máte s tím
někdo zkušenosti?

ff



smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

[Talk-cz] rúian mapy - vylepšení

ahoj,

přidal jsem do map na http://maps.fordfrog.com/ ještě mapy z osm a z
katastru a taky overlay vrstvu adresních bodů z rúian, takže lze např. v
mapě porovnávat polohu adresních bodů oproti osm. opravil jsem taky
funkcionalitu permalinku, takže už by měl fungovat.

mapy teď jsou (a ještě chvíli budou) pomalejší, protože tam importuju
osm planet data a znovu (opravené) multipointy do databáze rúian.

ff



smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] rúian mapy, geoserver a křovák

zkusil jsem, ale bohužel se nic nezměnilo. má ještě někdo nějaký nápad?

ff

Dne 24.7.2012 11:03, hanoj napsal(a):
 Definice 5514 i 102067 se mi z experimentu v GDAL se mi jevi jako OK.
 Nainstaloval jsem aktualni stable geoserver 2.1.4. a zda se mi ze ma
 nejak divne definovana 2065. Zkus ji primo odtud, je jina:
 http://spatialreference.org/ref/epsg/2065/

 h.
 h.

 Dne 24. července 2012 1:20 Miroslav Šulc fordf...@fordfrog.com napsal(a):
 ahoj,

 tak jsem zase chvíli zkoušel zprovoznit toho křováka na geoserveru a narazil
 jsem na jednu věc. když si dám preview vrstev, tak se mi při 5514 a 102067
 zobrazuje čr celá převrácená:
 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-cz




smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] rúian mapy - vylepšení

Dne 24.7.2012 15:22, jzvc napsal(a):
 Cus,

 nemel by nahodou katastr vychazet ze stejnych dat? Ja ze v RUIAN sou
 nejaky adresni body navrch (ony tam baraky fakt sou), a nektery sou
 ruzne lehce posunuty ...

no, rúian vychází z katastru, jenže jednak v osm to nemusí být nutne(
úplne( aktuální, a pak taky ten import adresních bodu* asi me(l své
mouchy, tr(eba du*m, kde ted( bydlím, má c(íslo už asi tak 50 let, ale v
osm není :-)


 BTW: Chtelo by to trebas nejak barevne rozlisit cislo popisny/evidencni.

provedeno. c(ervená = c(p, modrá = ev, žlutá = bez c(ísla, olivová =
všechny ostatní ... platí do té doby, než to náhodou v rámci zme(ny
nálady zme(ním :-P

ff


smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] rúian mapy - vylepaení

Dne 24.7.2012 17:13, Jakub napsal(a):
 Vypadá to velmi pěkně, jen dotaz - v RUIAN jsou jen čísla popisná,
 nebo i orientační? Adresu v terénu většinou hledám podle orientačního
 a to uvedeno i na většině map ...

udělal jsem tam tři overlay vrstvy, jedna jen bod, druhá jen čp, třetí
čp/čo ... takže si můžete vybírat dle libosti :-)

 Jakub
ff


smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] rúian mapy - vylepšení

Dne 24.7.2012 21:23, jzvc napsal(a):
 Dne 24.7.2012 20:43, Miroslav Šulc napsal(a):
 Dne 24.7.2012 15:22, jzvc napsal(a):
 Cus,

 nemel by nahodou katastr vychazet ze stejnych dat? Ja ze v RUIAN sou
 nejaky adresni body navrch (ony tam baraky fakt sou), a nektery sou
 ruzne lehce posunuty ...

 no, rúian vychází z katastru, jenže jednak v osm to nemusí být nutne(
 úplne( aktuální, a pak taky ten import adresních bodu* asi me(l své
 mouchy, tr(eba du*m, kde ted( bydlím, má c(íslo už asi tak 50 let,
 ale v osm není :-)

 OSM neresim, porovnaval sem ten overlay (predpokladam z RUIAN) a KM -
 rozdily byly prave tam.

aha, tak to netuším. já si urc(ite( nové adresní body v db nevymyslel,
takže se asi pr(ecejen ty katastrální mapy s rúian rozcházejí. možná to
souvisí se zpu*sobem aktualizace map, nevím, tr(eba ne(co vyc(teš tady:
http://www.cuzk.cz/Dokument.aspx?AKCE=DOC:10-WMS_PRO_KM

ff


smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] vizualizace dat z rúian

2012-07-22 Tema obsahu Miroslav Šulc

to co jsem nastavoval ve wms je i v tom wms xml:

CRSEPSG:102067/CRS
CRSEPSG:2065/CRS
CRSEPSG:4326/CRS
CRSEPSG:5514/CRS
CRSEPSG:900913/CRS
CRSCRS:84/CRS

pokud máš na mysli zobrazení mapy na tom webu v křovákovi místo toho
4326, tak to jsem zkoušel v openlayers nastavit a nefungovalo mi to, tj.
některé tily se nenačítaly a docházelo k divným posunům. pokud někdo ví,
jak to vyřešit, tak bych to uvítal, přecejen v tom 4326 to vypadá trochu
divně.

ff


Dne 22.7.2012 22:19, Jachym Cepicky napsal(a):
 Byl by problém do té WMS přihodit toho křováka?

 dík

 J

 Dne 22.7.2012 18:13, Miroslav Šulc napsal(a):
 ahoj,

 na adrese http://maps.fordfrog.com/ jsem zprovoznil mapu založenou na
 datech z rúian (je to ta samá kompletní vrstva, která se dá načíst přes
 wms). je to zatím udělané tak nějak narychlo, navíc vzhledem k bugu v
 postgisu nejsou v databázi správně naimportované definiční body u
 některých objektů (obce apod., adresní body jsou ale ok, ty nejsou
 definované jako multipoint) a tím pádem je nemůžu použít pro zobrazení
 bodu v místě obce apod. nemluvě o tom, že nemám cit pro barvy a ani
 zkušenosti z kartografie :-)

 pokud byste k tomu měii nějaké připomínky nebo návrhy, tak dejte vědět.

 ff



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




smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] vizualizace dat z rúian

2012-07-22 Tema obsahu Miroslav Šulc

Dne 22.7.2012 23:02, Jachym Cepicky napsal(a):
 Mea culpa, použil jsem špatnou URL té služby
 http://wms.fordfrog.com/gwc/service/wms?service=wmsrequest=getcapabilities

 je tam jenom 4326 a  900913 (doporučil bych použít oficiální 3857)

tak to už jsem v obraze. tohle je odkaz přes cache a tam jsem opravdu
křováky nenastavil, to jsem opravil. akorát mi to teď začalo házet chyby
typu:

  * GridSubset bounds are either null or invalid
  * Grid Subset bounds do not intersect the GridSet bounds


asi tam mám něco špatně :-P

budu muset projít boudning boxy pro jednotlivé vrstvy a jednotlivé
projekce a zjistit, jestli jsem někde něco nezadal špatně.

ff


 ale zpátky k tématu - neukazuje mi to žádná data při žádném měřítku
 (vrstva ruian_vse) - co asi tak dělám špatně? Něco v logu serveru? Moc
 velký obrázek? Souřadnice by měly být OK. Možná problém s tím Křovákem
 (achjo)?

 http://wms.fordfrog.com/ows?SERVICE=WMSLAYERS=ruian_vseTRANSPARENT=TRUEFORMAT=image%2FpngEXCEPTIONS=XMLVERSION=1.3.0INFO_FORMAT=application%2Fvnd.ogc.gmlCRS=EPSG%3A102067REQUEST=GetMapSTYLES=BBOX=-944192.07723628,-1255824.9906655,-449538.5203492,-920935.3155059WIDTH=966HEIGHT=654

 dík

 Jáchym

 Dne 22.7.2012 22:30, Miroslav Šulc napsal(a):
 to co jsem nastavoval ve wms je i v tom wms xml:

 CRSEPSG:102067/CRS
 CRSEPSG:2065/CRS
 CRSEPSG:4326/CRS
 CRSEPSG:5514/CRS
 CRSEPSG:900913/CRS
 CRSCRS:84/CRS

 pokud máš na mysli zobrazení mapy na tom webu v křovákovi místo toho
 4326, tak to jsem zkoušel v openlayers nastavit a nefungovalo mi to, tj.
 některé tily se nenačítaly a docházelo k divným posunům. pokud někdo ví,
 jak to vyřešit, tak bych to uvítal, přecejen v tom 4326 to vypadá trochu
 divně.

 ff


 Dne 22.7.2012 22:19, Jachym Cepicky napsal(a):
 Byl by problém do té WMS přihodit toho křováka?

 dík

 J

 Dne 22.7.2012 18:13, Miroslav Šulc napsal(a):
 ahoj,

 na adrese http://maps.fordfrog.com/ jsem zprovoznil mapu založenou na
 datech z rúian (je to ta samá kompletní vrstva, která se dá načíst přes
 wms). je to zatím udělané tak nějak narychlo, navíc vzhledem k bugu v
 postgisu nejsou v databázi správně naimportované definiční body u
 některých objektů (obce apod., adresní body jsou ale ok, ty nejsou
 definované jako multipoint) a tím pádem je nemůžu použít pro zobrazení
 bodu v místě obce apod. nemluvě o tom, že nemám cit pro barvy a ani
 zkušenosti z kartografie :-)

 pokud byste k tomu měii nějaké připomínky nebo návrhy, tak dejte vědět.

 ff



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




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




smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] vizualizace dat z rúian

2012-07-22 Tema obsahu Miroslav Šulc

tak nevím, nějak si s tím nedokážu poradit. 2065 se mi chová divně a
5514 i 1021067 mi vyhazují tu chybu co jsem psal. možná jestli hanoj
nebude vědět, ten mi geoserver doporučoval, tak třeba ví, jak tyhle
projekce nastavit. mně už docházejí nápady.

Dne 22.7.2012 23:02, Jachym Cepicky napsal(a):
Mea culpa, použil jsem špatnou URL té služby
http://wms.fordfrog.com/gwc/service/wms?service=wmsrequest=getcapabilities

je tam jenom 4326 a 900913 (doporučil bych použít oficiální 3857)

ale zpátky k tématu - neukazuje mi to žádná data při žádném měřítku
(vrstva ruian_vse) - co asi tak dělám špatně? Něco v logu serveru? Moc
velký obrázek? Souřadnice by měly být OK. Možná problém s tím Křovákem
(achjo)?

http://wms.fordfrog.com/ows?SERVICE=WMSLAYERS=ruian_vseTRANSPARENT=TRUEFORMAT=image%2FpngEXCEPTIONS=XMLVERSION=1.3.0INFO_FORMAT=application%2Fvnd.ogc.gmlCRS=EPSG%3A102067REQUEST=GetMapSTYLES=BBOX=-944192.07723628,-1255824.9906655,-449538.5203492,-920935.3155059WIDTH=966HEIGHT=654

dík

Jáchym

Dne 22.7.2012 22:30, Miroslav Šulc napsal(a):
to co jsem nastavoval ve wms je i v tom wms xml:

CRSEPSG:102067/CRS
CRSEPSG:2065/CRS
CRSEPSG:4326/CRS
CRSEPSG:5514/CRS
CRSEPSG:900913/CRS
CRSCRS:84/CRS

pokud máš na mysli zobrazení mapy na tom webu v křovákovi místo toho
4326, tak to jsem zkoušel v openlayers nastavit a nefungovalo mi to, tj.
některé tily se nenačítaly a docházelo k divným posunům. pokud někdo ví,
jak to vyřešit, tak bych to uvítal, přecejen v tom 4326 to vypadá trochu
divně.

Dne 22.7.2012 22:19, Jachym Cepicky napsal(a):
Byl by problém do té WMS přihodit toho křováka?

dík

Dne 22.7.2012 18:13, Miroslav Šulc napsal(a):
ahoj,

na adrese http://maps.fordfrog.com/ jsem zprovoznil mapu založenou na
datech z rúian (je to ta samá kompletní vrstva, která se dá načíst přes
wms). je to zatím udělané tak nějak narychlo, navíc vzhledem k bugu v
postgisu nejsou v databázi správně naimportované definiční body u
některých objektů (obce apod., adresní body jsou ale ok, ty nejsou
definované jako multipoint) a tím pádem je nemůžu použít pro zobrazení
bodu v místě obce apod. nemluvě o tom, že nemám cit pro barvy a ani
zkušenosti z kartografie :-)

pokud byste k tomu měii nějaké připomínky nebo návrhy, tak dejte vědět.

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

smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

[Talk-cz] rúian wms vrstvy přejmenovány!

2012-07-21 Tema obsahu Miroslav Šulc

zdravím,

zjistil jsem, že ne každý prográmek si poradí s diakritikou, tak jsem
přejmenoval wms vstvy, tak kdo je používáte, tak si ty názvy zaktualizute.

ff



smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

[Talk-cz] rúian, postgis a multipoint

2012-07-21 Tema obsahu Miroslav Šulc

ahoj,

narazil jsem na jednu zajímavou věc. multipoint geometrie se sice při
importu z rúian do db uloží, nicméně jsou zřejmě chybné a nefungují, např:

ruian_new=# create table test (geom geometry);
CREATE TABLE
ruian_new=# insert into test values (st_geomfromgml('gml:MultiPoint
xmlns:gml=http://www.opengis.net/gml/3.2; gml:id=DOB.545058.X
srsName=urn:ogc:def:crs:EPSG::2065
gml:srsDimension=2gml:pointMembersgml:Point
gml:id=DOB.545058.1gml:pos496547.00
1139895.00/gml:pos/gml:Point/gml:pointMembers/gml:MultiPoint'));
INSERT 0 1
ruian_new=# select * from test;
geom   

 0104A01108
(1 row)

ruian_new=# select st_asgml(geom) from test;
 st_asgml
--
 
(1 row)

ruian_new=# select st_astext(geom) from test;
 st_astext 

 MULTIPOINT Z EMPTY
(1 row)

netušíte někdo, kde je problém? mám tu postgresql 9.1.4 a postgis 2.0.1.

ff



smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

[Talk-cz] import rúian dat + wms vrstvy

ahoj,

tak právě doběhnul import dat. nahrál jsem tam i aktualizace do
19.7.2012 včetně, takže databáze je teď kompletní. tím pádem to co je
vidět ve wms vrstvách by měl být aktuální stav dle rúian (včetně chyb,
které plánují opravit, jako nekompletní ulice apod.)

ff



smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

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

nastavil jsem tam teda jen ty čtyři srs. pokud by tam někdo chtěl ještě
ještě nějaký přidat, tak dejte vědět.

ff

Dne 20.7.2012 10:01, Jachym Cepicky napsal(a):
 V naší WMS prohlížečce se projevila (typická) chybka při konfiguraci
 Geoserveru. Geoserver ve výchozím nastavení publikuje *všechny*
 podporované souř. systémy, i ty které nemají na daném území smysl.

 Prosil bych, v nastavení WMS dát do pole Limited SRS list hodnoty

 4326, 2065, 5514, 102067 (případně další).

 Bude potřeba do souboru data_dir/user_projection/epsg.properties doplnit
 následující řádky (tedy, dělám to poprvé, snad to bude ok):

 5514=PROJCS[S-JTSK_Krovak_East_North,GEOGCS[GCS_S_JTSK,DATUM[Jednotne_Trigonometricke_Site_Katastralni,SPHEROID[Bessel_1841,6377397.155,299.1528128],TOWGS84[498.17,136.89,510.08,6.007,4.343,3.831,3.38]],PRIMEM[Greenwich,0],UNIT[Degree,0.017453292519943295]],PROJECTION[Krovak],PARAMETER[False_Easting,0],PARAMETER[False_Northing,0],PARAMETER[Pseudo_Standard_Parallel_1,78.5],PARAMETER[Scale_Factor,0.],PARAMETER[Azimuth,30.2881397528],PARAMETER[Longitude_Of_Center,24.83],PARAMETER[Latitude_Of_Center,49.5],PARAMETER[X_Scale,-1],PARAMETER[Y_Scale,1],PARAMETER[XY_Plane_Rotation,90],UNIT[Meter,1],AUTHORITY[EPSG,5514]]
 102067=PROJCS[S-JTSK_Krovak_East_North,GEOGCS[GCS_S_JTSK,DATUM[Jednotne_Trigonometricke_Site_Katastralni,SPHEROID[Bessel_1841,6377397.155,299.1528128],TOWGS84[498.17,136.89,510.08,6.007,4.343,3.831,3.38]],PRIMEM[Greenwich,0],UNIT[Degree,0.017453292519943295]],PROJECTION[Krovak],PARAMETER[False_Easting,0],PARAMETER[False_Northing,0],PARAMETER[Pseudo_Standard_Parallel_1,78.5],PARAMETER[Scale_Factor,0.],PARAMETER[Azimuth,30.2881397528],PARAMETER[Longitude_Of_Center,24.83],PARAMETER[Latitude_Of_Center,49.5],PARAMETER[X_Scale,-1],PARAMETER[Y_Scale,1],PARAMETER[XY_Plane_Rotation,90],UNIT[Meter,1],AUTHORITY[EPSG,102067]]


 Dík

 Jáchym

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

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

 jsou tam celkem 4 vrstvy plus jedna složená: adresní body, ulice,
 stavební objekty, zastavěné parcely a vše (složená). pokud byste tam
 chtěli ještě nějaké vrsvty přidat, tak dejte vědět.

 grafická kvalita toho výstupu zatím není nic moc. pokud by mi někdo byl
 schopný poradit, jak to zobrazení vylepšit, tak bych to uvítal. běží to
 na geoserveru 2.1.4.

 ff



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






smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

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

no, to se dohodněte, pro mě je tohle čínština :-)

ff

Dne 20.7.2012 11:04, Martin Kokeš napsal(a):
 102067,PROJCS[S-JTSK_Krovak_East_North,GEOGCS[GCS_S_JTSK,DATUM[Jednotne_Trigonometricke_Site_Katastralni,SPHEROID[Bessel_1841,6377397.155,299.1528128]],PRIMEM[Greenwich,0],UNIT[Degree,0.017453292519943295]],PROJECTION[Krovak],PARAMETER[False_Easting,0],PARAMETER[False_Northing,0],PARAMETER[Pseudo_Standard_Parallel_1,78.5],PARAMETER[Scale_Factor,0.],PARAMETER[Azimuth,30.2881397528],PARAMETER[Longitude_Of_Center,24.83],PARAMETER[Latitude_Of_Center,49.5],PARAMETER[X_Scale,-1],PARAMETER[Y_Scale,1],PARAMETER[XY_Plane_Rotation,90],UNIT[Meter,1],EXTENSION[PROJ4,+proj=krovak
  +lat_0=49.5 +lon_0=24.83 +alpha=30.2881397222 +k=0. 
 +x_0=0 +y_0=0 +ellps=bessel +nadgrids=czech +pm=greenwich +units=m 
 +no_defs],AUTHORITY[EPSG,102067]]

 Možná lépe v případě použití PROJ4 a S-JTSK nadgridu? Aby někdo nepanikařil, 
 že to má ve 4326 posunuté... ;-)

 - Original Message -
 From: Miroslav Šulc
 [mailto:fordf...@fordfrog.com]
 To: 
 Cc: OpenStreetMap Czech Republic
 [mailto:talk-cz@openstreetmap.org]
 Sent: Fri, 20 Jul 2012 10:56:29
 +0200
 Subject: Re: [Talk-cz] (skoro) funkční rúian wms vrstvy


 nastavil jsem tam teda jen ty čtyři srs. pokud by tam někdo chtěl
 ještě
 ještě nějaký přidat, tak dejte vědět.

 ff

 Dne 20.7.2012 10:01, Jachym Cepicky napsal(a):
 V naší WMS prohlížečce se projevila (typická) chybka při
 konfiguraci
 Geoserveru. Geoserver ve výchozím nastavení publikuje *všechny*
 podporované souř. systémy, i ty které nemají na daném území smysl.

 Prosil bych, v nastavení WMS dát do pole Limited SRS list hodnoty

 4326, 2065, 5514, 102067 (případně další).

 Bude potřeba do souboru data_dir/user_projection/epsg.properties doplnit
 následující řádky (tedy, dělám to poprvé, snad to bude ok):


 5514=PROJCS[S-JTSK_Krovak_East_North,GEOGCS[GCS_S_JTSK,DATUM[Jednotne_Trigonometricke_Site_Katastralni,SPHEROID[Bessel_1841,6377397.155,299.1528128],TOWGS84[498.17,136.89,510.08,6.007,4.343,3.831,3.38]],PRIMEM[Greenwich,0],UNIT[Degree,0.017453292519943295]],PROJECTION[Krovak],PARAMETER[False_Easting,0],PARAMETER[False_Northing,0],PARAMETER[Pseudo_Standard_Parallel_1,78.5],PARAMETER[Scale_Factor,0.],PARAMETER[Azimuth,30.2881397528],PARAMETER[Longitude_Of_Center,24.83],PARAMETER[Latitude_Of_Center,49.5],PARAMETER[X_Scale,-1],PARAMETER[Y_Scale,1],PARAMETER[XY_Plane_Rotation,90],UNIT[Meter,1],AUTHORITY[EPSG,5514]]
 102067=PROJCS[S-JTSK_Krovak_East_North,GEOGCS[GCS_S_JTSK,DATUM[Jednotne_Trigonometricke_Site_Katastralni,SPHEROID[Bessel_1841,6377397.155,299.1528128],TOWGS84[498.17,136.89,510.08,6.007,4.343,3.831,3.38]],PRIMEM[Greenwich,0],UNIT[Degree,0.017453292519943295]],PROJECTION[Krovak],PARAMETER[False_Easting,0],PARAMETER[False_Northing,0],PARAMETER[Pseudo_Standard_Parallel_1,78.5],PARAMETER[Scale_Factor,0.],PARAMETER[Azimuth,30.2881397528],PARAMETER[Longitude_Of_Center,24.83],PARAMETER[Latitude_Of_Center,49.5],PARAMETER[X_Scale,-1],PARAMETER[Y_Scale,1],PARAMETER[XY_Plane_Rotation,90],UNIT[Meter,1],AUTHORITY[EPSG,102067]]

 Dík

 Jáchym

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

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

 jsou tam celkem 4 vrstvy plus jedna složená: adresní body, ulice,
 stavební objekty, zastavěné parcely a vše (složená). pokud byste
 tam
 chtěli ještě nějaké vrsvty přidat, tak dejte vědět.

 grafická kvalita toho výstupu zatím není nic moc. pokud by mi někdo
 byl
 schopný poradit, jak to zobrazení vylepšit, tak bych to uvítal.
 běží to
 na geoserveru 2.1.4.

 ff



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




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




smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] import rúian dat + wms vrstvy

tak jsem tam ješte( nastavil automatické aktualizace, takže by se to
me(lo samo udržovat aktuální (pokud jsem v tom skriptu neude(lal
ne(jakou chybku).

jinak (asi) v pru*be(hu dneška ješte( budu na serveru de(lat ne(jaké
úpravy kvu*li tomu geoserveru, takže tam možná bude pár krátkodobých
výpadku*.

ff

Dne 20.7.2012 09:22, Miroslav Šulc napsal(a):
 ahoj,

 tak práve( dobe(hnul import dat. nahrál jsem tam i aktualizace do
 19.7.2012 vc(etne(, takže databáze je ted( kompletní. tím pádem to co je
 vide(t ve wms vrstvách by me(l být aktuální stav dle rúian (vc(etne( chyb,
 které plánují opravit, jako nekompletní ulice apod.)

 ff



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



smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] rúian - statistiky geo dat

takže ty souřadnice ve vfr jsou správně kladné?

ff

Dne 19.7.2012 09:55, JV napsal(a):
 Ahoj,
 protože http://www.epsg-registry.org/ :-) Ale vážně - EPSG::2065 má 
 geodetické souřadnice (kladné, jih-západ). Docela dobrý přehled je na 
 http://geoportal.cuzk.cz/%28S%28uvpzlp45agmqymyeg4u25diq%29%29/Default.aspx?lng=CZmode=TextMetatext=souradsystemyside=WMS.neverejnemenu=312head_tab=sekce-03-gp
 Vzhledem k tomu, že to psal člověk, který ty kódy pro Křováka s epsg-registry 
 vyjednával, tak bych tomu i věřil.
 Cílový stav VFR je použití EPSG::5514 - ale momentálně nedovedu říct, kdy to 
 bude.

 Jirka V.

  Původní zpráva 
 Od: hanoj eha...@gmail.com
 Předmět: Re: [Talk-cz] rúian - statistiky geo dat
 Datum: 19.7.2012 09:34:54
 
 Jirko,
 a proc jsou na WMS i VDP/VFR CUZK pod EPSG:2065 souradnice kladne na
 misto ocekavanych S-JTSK zapornych?

 srovnej
 http://geoportal2.uhul.cz/wms_oprl/?SERVICE=WMSVERSION=1.1.1REQUEST=GetMapSRS=EPSG:2065LAYERS=Ortofoto_cbSTYLES=defaultFORMAT=image/jpegBBOX=-603900,-1161900,-603800,-1161800WIDTH=300HEIGHT=300

 nebo
 http://heis.vuv.cz/data/webmap/isapi.dll?SERVICE=WMSREQUEST=GetCapabilities

 nebo
 $ echo -868208.53 -1095793.57 512.30 | cs2cs +init=esri:102067 +to
 +init=epsg:2065
 -868208.53   -1095793.57 512.30

 ale CUZK
 http://wms.cuzk.cz/wms.asp?service=WMSVERSION=1.1.1REQUEST=GetMapSRS=EPSG:2065LAYERS=DEF_BUDOVY,RST_KN,RST_KMD,RST_PK,obrazy_parcel,hranice_parcel,dalsi_p_mapy,omp,prehledka_kat_uz,prehledka_kraju-linieFORMAT=image/pngtransparent=FALSEBBOX=1161800,603800,1161900,603900WIDTH=300HEIGHT=300



 hanoj

 Dne 19. července 2012 8:56 JV j@seznam.cz napsal(a):
 Zdravím všechny,
 pro jistotu - na adrese
 http://www.cuzk.cz/Dokument.aspx?PRARESKOD=998MENUID=10769AKCE=DOC:10-VDP_NOVINKY
 je popis současných známých chyb ve VFR. Navíc byl ve VFR zjištěn další 
 problém
 - neúplné definiční čáry ulic (pouze u některých ulic) - to v tom dokumentu
 ještě není doplněné.
 J. Veselý

  Původní zpráva 
 Od: Miroslav Šulc fordf...@fordfrog.com
 Předmět: [Talk-cz] rúian - statistiky geo dat
 Datum: 18.7.2012 13:27:52
 
 ahoj,

 mám naimportováno cca 20% dat a takhle zatím vypadají statistiky
 existence geo dat:

   table_name   |  total  |   bod   |  cary   | p_bod | p_cary
 ---+-+-+-+---+
  rm_momc   |   9 |   9 |   0 |   100 |  0
  rn_adresni_misto  |  732548 |  684389 |   0 |93 |  0
  rn_cast_obce  |3951 |3951 |   0 |   100 |  0
  rn_katastralni_uzemi  |3179 |3179 |2414 |   100 | 75
  rn_kraj_1960  |   8 |   0 |   0 | 0 |  0
  rn_obec   |1661 |1661 |1069 |   100 | 64
  rn_okres  |  77 |  77 |   0 |   100 |  0
  rn_orp| 206 | 206 |   0 |   100 |  0
  rn_parcela| 4628830 | 4628809 | 2948168 |99 | 63
  rn_pou| 394 | 394 |   3 |   100 |  0
  rn_region_soudrznosti |   8 |   0 |   0 | 0 |  0
  rn_stat   |   1 |   1 |   0 |   100 |  0
  rn_stavebni_objekt| 1001481 |  971883 |  589827 |97 | 58
  rn_ulice  |   22926 |   0 |   22531 | 0 | 98
  rn_vusc   |  14 |  14 |   0 |   100 |  0
  rn_zsj|5440 |5440 |4846 |   100 | 89

 p_* jsou procenta k celkovému počtu.

 ff




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



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





smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] rúian - statistiky geo dat

zde jsou statistiky kompletních dat (poslední update z 18.7.2012):

  table_name   |  total   |   bod|   cary   | p_bod | p_cary
---+--+--+--+---+
 rm_momc   |  142 |  142 |0 |   100 |  0
 rn_adresni_misto  |  2915342 |  2710043 |0 |92 |  0
 rn_cast_obce  |15068 |15064 |0 |99 |  0
 rn_katastralni_uzemi  |13026 |13026 | 9484 |   100 | 72
 rn_kraj_1960  |8 |0 |0 | 0 |  0
 rn_mop|   10 |   10 |0 |   100 |  0
 rn_obec   | 6251 | 6251 | 3549 |   100 | 56
 rn_okres  |   77 |   77 |0 |   100 |  0
 rn_orp|  206 |  206 |0 |   100 |  0
 rn_parcela| 19974362 | 19974237 | 13130238 |99 | 65
 rn_pou|  394 |  394 |3 |   100 |  0
 rn_region_soudrznosti |8 |0 |0 | 0 |  0
 rn_spravni_obvod  |   22 |   22 |0 |   100 |  0
 rn_stat   |1 |1 |0 |   100 |  0
 rn_stavebni_objekt|  4081125 |  3914316 |  2480013 |95 | 60
 rn_ulice  |79225 |0 |78248 | 0 | 98
 rn_vusc   |   14 |   14 |0 |   100 |  0
 rn_zsj|22427 |22415 |19532 |99 | 87

ff

Dne 18.7.2012 13:27, Miroslav Šulc napsal(a):
 ahoj,

 mám naimportováno cca 20% dat a takhle zatím vypadají statistiky
 existence geo dat:

   table_name   |  total  |   bod   |  cary   | p_bod | p_cary
 ---+-+-+-+---+
  rm_momc   |   9 |   9 |   0 |   100 |  0
  rn_adresni_misto  |  732548 |  684389 |   0 |93 |  0
  rn_cast_obce  |3951 |3951 |   0 |   100 |  0
  rn_katastralni_uzemi  |3179 |3179 |2414 |   100 | 75
  rn_kraj_1960  |   8 |   0 |   0 | 0 |  0
  rn_obec   |1661 |1661 |1069 |   100 | 64
  rn_okres  |  77 |  77 |   0 |   100 |  0
  rn_orp| 206 | 206 |   0 |   100 |  0
  rn_parcela| 4628830 | 4628809 | 2948168 |99 | 63
  rn_pou| 394 | 394 |   3 |   100 |  0
  rn_region_soudrznosti |   8 |   0 |   0 | 0 |  0
  rn_stat   |   1 |   1 |   0 |   100 |  0
  rn_stavebni_objekt| 1001481 |  971883 |  589827 |97 | 58
  rn_ulice  |   22926 |   0 |   22531 | 0 | 98
  rn_vusc   |  14 |  14 |   0 |   100 |  0
  rn_zsj|5440 |5440 |4846 |   100 | 89

 p_* jsou procenta k celkovému poc(tu.

 ff



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




smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] rúian a epsg:2065

Dne 19.7.2012 12:12, hanoj napsal(a):
 Dne 19. července 2012 12:08 Miroslav Šulc fordf...@gmail.com napsal(a):
 takže jen pro jistotu, mám to teda zase vrátit na kladné souřadnice?
 *** ano kladne. posleze pak pouzivat jiz uspesne transformace
 2065-5514. omlouvam se.
v pohodě :-)
 h.
ff



smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

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

ahoj,

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

jsou tam celkem 4 vrstvy plus jedna složená: adresní body, ulice,
stavební objekty, zastavěné parcely a vše (složená). pokud byste tam
chtěli ještě nějaké vrsvty přidat, tak dejte vědět.

grafická kvalita toho výstupu zatím není nic moc. pokud by mi někdo byl
schopný poradit, jak to zobrazení vylepšit, tak bych to uvítal. běží to
na geoserveru 2.1.4.

ff



smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

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

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

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

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

46.4.118.148wms.fordfrog.com

ff


smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

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

Dne 19.7.2012 17:24, jzvc napsal(a):
 Dne 19.7.2012 17:07, jzvc napsal(a):
 Dne 19.7.2012 17:03, Miroslav Šulc napsal(a):
 Dne 19.7.2012 16:54, jzvc napsal(a):
 Dne 19.7.2012 16:22, Miroslav Šulc napsal(a):
 ahoj,

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

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

 46.4.118.148wms.fordfrog.com

 Uz to tam mas, du se mrknout.

 Tak jeste jedna pripominka, nejak ti nefunguje vrstva vse, ta hlasi
 chyby, ostatni vrstvy se tvari fukncne, ac sem zatim videl jen adresni
 body. Mas nejakej typ na nejaky kousek digitalizovanyho a zaroven
 naimportovanyho uzemi? Abych se moh podivat i na nejaky ty domecky,
 ulice... ;D
v příloze posílám, co je zatím naimportováno. snad to proleze.

jinak vrstva vše mi fungovala, ale nezobrazovala se čísla adresních
bodů. co mi nefungovalo je, že když jsem si v josm přiblížil mapu, tak
bych čekal, že si josm stáhne nové obrázky, ale buď se tak nestalo, nebo
mu je můj server nedal, každopádně ta grafika pak vypadala dost děsně, a
rozhodně by na větším přiblížení mohla být detailnější. netušíte někdo,
kde by mohl být problém?

ff
 nazev 
---
 Adamov
 Adamov
 Adršpach
 Albrechtice
 Albrechtice nad Vltavou
 Alojzov
 Andělská Hora
 Andělská Hora
 Arneštovice
 Babice
 Babice
 Babice
 Babylon
 Bačalky
 Bačkov
 Bačkovice
 Bakov nad Jizerou
 Barchovice
 Bartoušov
 Bašť
 Bavorov
 Bavoryně
 Bečice
 Bečváry
 Běhařov
 Bechyně
 Bělá
 Bělá nad Radbuzou
 Bělá pod Bezdězem
 Bělá pod Pradědem
 Bělá u Jevíčka
 Bělčice
 Běleč
 Bělkovice-Lašťany
 Běloky
 Bělotín
 Bělušice
 Benátky nad Jizerou
 Benešov
 Benešov nad Černou
 Beňov
 Bernardov
 Bernartice
 Bernartice
 Bernartice
 Beroun
 Běrunice
 Beřovice
 Besednice
 Běstovice
 Běštín
 Bezděkov
 Bezděkov
 Bezděkov pod Třemšínem
 Bezno
 Bezuchov
 Bílá Lhota
 Bílá Voda
 Bílé Podolí
 Bílichov
 Bílkovice
 Bílov
 Bílov
 Bílsko
 Bílsko
 Bílsko u Hořic
 Bílý Potok
 Bítouchov
 Bítovany
 Blatec
 Blatná
 Blazice
 Blažejovice
 Blevice
 Blížejov
 Blšany u Loun
 Bludov
 Bludov
 Bobnice
 Bocanovice
 Bohdalín
 Bohdalovice
 Bohdaneč
 Bohdíkov
 Bohumilice
 Bohunice
 Bohuňovice
 Bohuslavice
 Bohuslavice
 Bohušice
 Bohutín
 Bohutín
 Bochoř
 Bojanovice
 Bolatice
 Boletice
 Bolkov
 Boreč
 Borek
 Borek
 Borek
 Borkovice
 Borotice
 Borotín
 Borová Lada
 Borovany
 Borovnice
 Borovnice
 Borovnička
 Borovy
 Boršov nad Vltavou
 Bor u Skutče
 Bořanovice
 Bořenovice
 Bořetín
 Boseň
 Bošice
 Bošilec
 Bošín
 Bouzov
 Božejov
 Božetice
 Boží Dar
 Bradáčov
 Brada-Rybníček
 Brambory
 Brandýsek
 Brandýs nad Labem-Stará Boleslav
 Branice
 Branišov
 Branky
 Branná
 Branov
 Braškov
 Bratčice
 Bratkovice
 Bratronice
 Bratronice
 Bratřice
 Bratříkovice
 Brázdim
 Brdy
 Brloh
 Brníčko
 Brodce
 Brodec
 Brodek u Přerova
 Brod nad Tichou
 Broumov
 Broumy
 Brumovice
 Brzánky
 Břehov
 Břevnice
 Březí
 Březina
 Březina
 Březina
 Březnice
 Březnice
 Březnice
 Březno
 Březová
 Březová
 Březová
 Březová nad Svitavou
 Břežany
 Břežany I
 Břežany II
 Bříství
 Bříšťany
 Bubovice
 Budčeves
 Budeč
 Budíkov
 Budiměřice
 Budislav
 Budíškovice
 Budišov nad Budišovkou
 Bujanov
 Buk
 Buk
 Buková
 Bukovany
 Bukovany
 Buková u Příbramě
 Bukovec
 Bukovec
 Bukovice
 Bukovník
 Bukovno
 Buš
 Bušanovice
 Bušín
 Buštěhrad
 Butoves
 Buzice
 Býčkovice
 Býchory
 Býkev
 Bykoš
 Bynovec
 Bystročice
 Bystrovany
 Bystřice
 Bystřička
 Byšice
 Býškovice
 Bzová
 Cehnice
 Cep
 Cerhenice
 Cerhonice
 Cerhovice
 Cetoraz
 Církvice
 Cítoliby
 Citov
 Cítov
 Cizkrajov
 Ctiboř
 Cvrčovice
 Cvrčovice
 Čachovice
 Čakov
 Čakov
 Čaková
 Čáslav
 Čáslavsko
 Častrov
 Čečelice
 Čečelovice
 Čečkovice
 Čechtice
 Čechy
 Čejetice
 Čejkovice
 Čejkovice
 Čejov
 Čelákovice
 Čelechovice
 Čelistná
 Čenkov
 Čepřovice
 Čeradice
 Čerčany
 Čermná
 Černava
 Černá Voda
 Černá v Pošumaví
 Černčice
 Černěves
 Černé Voděrady
 Černíkov
 Černíny
 Černolice
 Černošice
 Černotín
 Černouček
 Černousy
 Černovice
 Čerňovice
 Černuc
 Červená Hora
 Červená Řečice
 Červená Třemešná
 Červené Janovice
 Červené Pečky
 Červené Poříčí
 Červenka
 Červený Hrádek
 Červený Újezd
 Červený Újezd
 Česká Kubice
 České Budějovice
 České Velenice
 Český Brod
 Český Krumlov
 Český Rudolec
 Český Šternberk
 Čestice
 Čestín
 Čestlice
 Číčenice
 Číčovice
 Číhaň
 Čichalov
 Čilá
 Čím
 Čimelice
 Číměř
 Činěves
 Čisovice
 Čistá
 Čistá
 Čížkrajice
 Čížová
 Čkyně
 Čtveřín
 Čtyřkoly
 Dačice
 Daleké Dušníky
 Dalešice
 Dalovice
 Daskabát
 Dasný
 Davle
 Děkanovice
 Děpoltovice
 Dešná
 Deštná
 Dětřichov
 Dílce
 Díly
 Dírná
 Dívčice
 Dívčí Hrad
 Dívčí Kopy

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

Dne 19.7.2012 17:52, Mirek Dlask napsal(a):
 Ahoj, 
 tak mně funguje taky nějaká vrstva. Vidím ulice v Bělé pod Bezdězem.

 Posun proti OSM je u ulic cca 3metry (křižovatka Máchova - Husova -
 Elišky Krásnohorské.Tyršova ulice je posunutá proti OSM o celý jeden
 blok (asi).
 Ve wms ještě nějaké ulice nejsou natažené (Kuřivodská, část Jateční)

je otázka, jestli se natáhnou, importuje se to po obcích, takže pokud
tam nejsou, tak je možné, že ani nebudou.

 Vidět jsou i červené adresní body. Ty jsou naprosto přesně.

na nich je dobře vidět, kde nám chybí budovy. pokud v červeném bodě není
světlý bod, tak nám ta budova chybí.

 Stavby jsem nerozchodil - možná ještě nejsou data.

stavby (stavební objekty a parcely) mají grafiku jen asi v 60%.

tady posílám pár katastrálních území, kde je nejvíc budov podle pozemků:

 katuz_kod |nazev | count
---+--+---
668150 | Kolín|  8748
711578 | Opava-Předměstí  |  6995
692816 | Mělník   |  6871
720755 | Písek|  6791
602868 | Beroun   |  6114
734713 | Přerov   |  5933
696293 | Mladá Boleslav   |  5894
764701 | Tábor|  5770
764264 | Šumperk  |  5762
660523 | Jindřichův Hradec|  5573
735426 | Příbram  |  5523
786764 | Vsetín   |  5286
718912 | Pelhřimov|  5168
739081 | Rakovník |  5110
622052 | České Budějovice 3   |  5105
677710 | Kutná Hora   |  5021

a tady pár obcí, kde je nejvíc definovaných hranic stavebních objektů:

 nazev | count
---+---
 Olomouc   | 11739
 České Budějovice  | 11163
 Kladno|  8440
 Opava |  7269
 Tábor |  6764
 Přerov|  5279
 Kolín |  4362
 Písek |  4046
 Říčany|  4029
 Příbram   |  4007



 Napoprvé to vypadá docela nadějně ;-)

 Mirek

ff



smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

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

tak jsem opravil tu vrstvu vše. v geoserveru mi nebylo jasné, v jakém
pořadí se vrstvy vykreslují a měl jsem to opačně.

pěkný obrázek je například vidět v mělníku. ty světlejší plochy jsou
zastavěné pozemky, ty tmavší obdélníky na nich jsou pak skutečné stavby.

jinak jsem zjistil, že pokud si přiblížím mapu a až pak si načtu tu wms
vrstvu, tak se mi načte detailnější. bohužel ale při zoomování se
podklad neaktualizuje. netušíte někdo, kde by mohl být problém?

ff


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

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

 jsou tam celkem 4 vrstvy plus jedna složená: adresní body, ulice,
 stavební objekty, zastavěné parcely a vše (složená). pokud byste tam
 chtěli ještě nějaké vrsvty přidat, tak dejte vědět.

 grafická kvalita toho výstupu zatím není nic moc. pokud by mi někdo byl
 schopný poradit, jak to zobrazení vylepšit, tak bych to uvítal. běží to
 na geoserveru 2.1.4.

 ff






smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

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

aha, tak to jsem netušil. já obvykle dělám jen s bing vrstvou a ta se
při zoomu aktualizuje.

ff

Dne 19.7.2012 20:13, Jan Bilak napsal(a):
 Tohle je podle mě vlastnost JOSM, takto se mi to chovalo vždy u všech zdrojů.

 Honza

 Dne 19. července 2012 20:09 Miroslav Šulc fordf...@fordfrog.com napsal(a):
 jinak jsem zjistil, že pokud si přiblížím mapu a až pak si načtu tu wms
 vrstvu, tak se mi načte detailnější. bohužel ale při zoomování se
 podklad neaktualizuje. netušíte někdo, kde by mohl být problém?

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





smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

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

ta chyba co to háže je asi Operation on mixed SRID geometries. ale
nenašel jsem nikde, že by data byla v něčem jiném než v epgs:2065.

ff

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

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

 jsou tam celkem 4 vrstvy plus jedna složená: adresní body, ulice,
 stavební objekty, zastavěné parcely a vše (složená). pokud byste tam
 chtěli ještě nějaké vrsvty přidat, tak dejte vědět.

 grafická kvalita toho výstupu zatím není nic moc. pokud by mi někdo byl
 schopný poradit, jak to zobrazení vylepšit, tak bych to uvítal. běží to
 na geoserveru 2.1.4.

 ff





smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

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

Dne 19.7.2012 22:27, jzvc napsal(a):
 Dne 19.7.2012 19:05, Miroslav Šulc napsal(a):
 Dne 19.7.2012 17:24, jzvc napsal(a):
 Dne 19.7.2012 17:07, jzvc napsal(a):
 Dne 19.7.2012 17:03, Miroslav Šulc napsal(a):
 Dne 19.7.2012 16:54, jzvc napsal(a):
 Dne 19.7.2012 16:22, Miroslav Šulc napsal(a):
 ahoj,

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

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

 46.4.118.148wms.fordfrog.com

 Uz to tam mas, du se mrknout.

 Tak jeste jedna pripominka, nejak ti nefunguje vrstva vse, ta
 hlasi chyby, ostatni vrstvy se tvari fukncne, ac sem zatim videl jen
 adresni body. Mas nejakej typ na nejaky kousek digitalizovanyho a
 zaroven naimportovanyho uzemi? Abych se moh podivat i na nejaky ty
 domecky, ulice... ;D
 v příloze posílám, co je zatím naimportováno. snad to proleze.

 jinak vrstva vše mi fungovala, ale nezobrazovala se čísla adresních
 bodů. co mi nefungovalo je, že když jsem si v josm přiblížil mapu,
 tak bych čekal, že si josm stáhne nové obrázky, ale buď se tak
 nestalo, nebo mu je můj server nedal, každopádně ta grafika pak
 vypadala dost děsně, a rozhodně by na větším přiblížení mohla být
 detailnější. netušíte někdo, kde by mohl být problém?

 Cus, JOSM si pokud vim WMS nezoomuje - jednoduse si sosne dlazdice v
 rozliseni pro zoom v jakym vrstvu pridas. Muzes na ni kliknout pravym
 a pouzit zmenit rozliseni. Jinak to by default nabiz jpeg, proto je
 to tak desny. Kdyz to ruco prehodis na png, bude vysledek o dost lepsi.

o té volbě změnit rozlišení jsem nevěděl, dělá to přesně to co jsem
chtěl, díky. jinak v nastavení geowebcache jsem změnil ty formáty a
vypadá to, že už to sosá to png. díky.

 Jinak dle nahodneho nastrelu konstatuji, ze data v JOSM jsou minimalne
 na stejne urovni, misty vyznamne lepsi ... coz je tedy (dle meho
 nazoru) celkem vostuda (statni spravy samo). Hodnotim samo vysledek,
 kterej ti z toho leze - je mozny ze je nekde nejaka chybka, ale pokud
 to odpovida datum, tak to teda potes. Ulice na sebe nenavazujou, jsou
 to jen takovy halabala cary, budovy odpovidaji stavu pred sto lety
 mozna takto ... a na toto se vynakladaji stovky milionu...

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

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

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

ff


smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

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

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

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

o jaké konkrétní místo vlastně jde?

ff


smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

[Talk-cz] rúian - statistiky geo dat

2012-07-18 Tema obsahu Miroslav Šulc

ahoj,

mám naimportováno cca 20% dat a takhle zatím vypadají statistiky
existence geo dat:

  table_name   |  total  |   bod   |  cary   | p_bod | p_cary
---+-+-+-+---+
 rm_momc   |   9 |   9 |   0 |   100 |  0
 rn_adresni_misto  |  732548 |  684389 |   0 |93 |  0
 rn_cast_obce  |3951 |3951 |   0 |   100 |  0
 rn_katastralni_uzemi  |3179 |3179 |2414 |   100 | 75
 rn_kraj_1960  |   8 |   0 |   0 | 0 |  0
 rn_obec   |1661 |1661 |1069 |   100 | 64
 rn_okres  |  77 |  77 |   0 |   100 |  0
 rn_orp| 206 | 206 |   0 |   100 |  0
 rn_parcela| 4628830 | 4628809 | 2948168 |99 | 63
 rn_pou| 394 | 394 |   3 |   100 |  0
 rn_region_soudrznosti |   8 |   0 |   0 | 0 |  0
 rn_stat   |   1 |   1 |   0 |   100 |  0
 rn_stavebni_objekt| 1001481 |  971883 |  589827 |97 | 58
 rn_ulice  |   22926 |   0 |   22531 | 0 | 98
 rn_vusc   |  14 |  14 |   0 |   100 |  0
 rn_zsj|5440 |5440 |4846 |   100 | 89

p_* jsou procenta k celkovému počtu.

ff



smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] rúian - wms vrstvy

2012-07-18 Tema obsahu Miroslav Šulc

odpověď pro hanoj (jelikož mi zase chodí maily z listu tři a půl hodiny,
odpověď jsem si přečetl v archivu):

 mi se osvedcil java Geoserver. Ma to GUI rozhrani, takze to ale neni
pro geeky.

díky, to vypadá zajímavě, jdu si přečíst dokumentaci.

ff

Dne 18.7.2012 22:43, Miroslav Šulc napsal(a):
 ahoj,

 poradil by mi někdo, jak nad rúian datama zprovoznit wms? chtěl bych
 udělat vrstvy tak, aby se daly natáhnout do josm, abychom se mohli
 podívat, co lze od těch dat očekávat.

 data jsou v postgresql, datový typ geometry. mám linuxový server s
 veřejnou ip, apache atd., znalosti na úrovni admina. dokonce jsem si
 kdysi (asi před osmi lety) hrál s mapserverem, ale to už jsem víceméně
 zapomněl.

 uvítal bych, kdyby mi někdo poradil, jak to wms zprovoznit, případně i
 dodal templaty konfiguračních souborů těch vrstev. chtěl bych udělat
 vrstvu pro adresní body (včetně čísel), ulice (včetně názvů), budovy
 (plochy) z pozemků a budovy ze stavebních objektů. je mi jedno, jestli
 to bude na mapserveru nebo na mapniku nebo na něčem jiném, jen to musí
 běhat na linuxu (gentoo).

 díky.

 ff





smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] rúian - wms vrstvy

2012-07-18 Tema obsahu Miroslav Šulc

mě ta rychlost doručování zpráv ke mně deptá :-/

jinak zkusil jsem qgis a podařilo se mi normálně načíst adresní body.
ulice jsou jen fragmenty, tak ty nevypadají použitelně (snad jen jako
hodně hrubá nápověda, kde by měla být nějaká ulice). parcely se mi
načíst nepovedlo, protože qgis nepodporuje int8 klíče. ještě jsem
zkoušel stavební objekty, ale v lokalitě, kterou jsem si vybral, jich
bylo jen 5. každopádně je to vykreslilo. tady je demo, jak to vypadá:
http://postimage.org/image/vpzblxyy7/ (jde o obec doksy).

ff

Dne 19.7.2012 00:17, hanoj napsal(a):
 zkousel jsem tvuj skript ruain2pgsql

 vytvori mi tabulky, ale podle QGis nemaji geometrii, respektive maji
 sloupce podobne vetam WKT, ale zrejme (?) nejsou formalne spravne
 napr: tab: rn_adresni_misto,  sloupec: definicni_bod, hodnota:
 SRID=2056;POINT(-607747.22 -1162253.03)

 tobe to v Qgis jede? (pg 9.1/ubuntu12.04)

 h.

 Dne 18. července 2012 23:03 Miroslav Šulc fordf...@fordfrog.com napsal(a):
 odpověď pro hanoj (jelikož mi zase chodí maily z listu tři a půl hodiny,
 odpověď jsem si přečetl v archivu):


 mi se osvedcil java Geoserver. Ma to GUI rozhrani, takze to ale neni pro
 geeky.
 díky, to vypadá zajímavě, jdu si přečíst dokumentaci.

 ff

 Dne 18.7.2012 22:43, Miroslav Šulc napsal(a):

 ahoj,

 poradil by mi někdo, jak nad rúian datama zprovoznit wms? chtěl bych
 udělat vrstvy tak, aby se daly natáhnout do josm, abychom se mohli
 podívat, co lze od těch dat očekávat.

 data jsou v postgresql, datový typ geometry. mám linuxový server s
 veřejnou ip, apache atd., znalosti na úrovni admina. dokonce jsem si
 kdysi (asi před osmi lety) hrál s mapserverem, ale to už jsem víceméně
 zapomněl.

 uvítal bych, kdyby mi někdo poradil, jak to wms zprovoznit, případně i
 dodal templaty konfiguračních souborů těch vrstev. chtěl bych udělat
 vrstvu pro adresní body (včetně čísel), ulice (včetně názvů), budovy
 (plochy) z pozemků a budovy ze stavebních objektů. je mi jedno, jestli
 to bude na mapserveru nebo na mapniku nebo na něčem jiném, jen to musí
 běhat na linuxu (gentoo).

 díky.

 ff




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

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




smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] problém s gml řetězcem

2012-07-17 Tema obsahu Miroslav Šulc

Dne 17.7.2012 00:06, hanoj napsal(a):
 PS: dival jsem se, ze ulice ve VFR nemaji geometrii, tudiz nas vlastne
 zajimaji jen:
 * parcely zastavene (druh pozemku kod= myslim 13 )
 * adresni body
 a budovy?
 *** budovy jsou...
 a) bud zastavene parcely (dnes delane tracerem v JOSM)
 b) nebo bod stavebniho objektu a s tim toho mnoho neudelame.
 Importovat body s tagem building=yes, mi neprijde dobre. Slo by z toho
 generovat neco jako landuse=residential. Vic mne nenapada.
stavební objekty mají v datech i hranice, proto se na to ptám.
 hanoj
ff



smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] problém s gml řetězcem

2012-07-17 Tema obsahu Miroslav Šulc

Dne 17.7.2012 21:40, hanoj napsal(a):
 Dne 17. července 2012 11:01 Miroslav Šulc fordf...@fordfrog.com napsal(a):
 Dne 17.7.2012 00:06, hanoj napsal(a):
 PS: dival jsem se, ze ulice ve VFR nemaji geometrii, tudiz nas vlastne
 zajimaji jen:
 * parcely zastavene (druh pozemku kod= myslim 13 )
 * adresni body
 a budovy?
 *** budovy jsou...
 a) bud zastavene parcely (dnes delane tracerem v JOSM)
 b) nebo bod stavebniho objektu a s tim toho mnoho neudelame.
 Importovat body s tagem building=yes, mi neprijde dobre. Slo by z toho
 generovat neco jako landuse=residential. Vic mne nenapada.
 stavební objekty mají v datech i hranice, proto se na to ptám.
 *** kdyz koukam na obec s DKM
 http://vdp.cuzk.cz/vymenny_format/soucasna/20120630_OB_584029_UZSZ.xml.gz

 tak v
 /vf:VymennyFormat/vf:Data/vf:StavebniObjekty/vf:StavebniObjekt

 vidim
 soi:Geometriesoi:DefinicniBodgml:Point ...

 rikam to spravne?
uzsz jsou jen základní data bez originálních hranic, obsahují jen
definiční body. musíš v tom formuláři nastavit kompletní datovou sadu,
pak se ti ve výběru z údajů zaškrtnou i originální hranice. tyhle
soubory pak mají v názvu uksh a obsahují právě i ty hranice objektů.
např se můžeš podívat do souboru 20120630_OB_500291_UKSH.xml.gz, tam
jsou 100%ně.

já se pomalu pustím do importu kompletní sady dat, takže pak budeme
vědět, u čeho všeho jsou ty geometrie (např. jestli jsou někde i u ulic
apod.).
 hanoj
ff



smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] problém s gml řetězcem

2012-07-16 Tema obsahu Miroslav Šulc

Dne 15.7.2012 23:44, hanoj napsal(a):
 Nemuze to souviset s timto?
 http://www.cuzk.cz/Dokument.aspx?PRARESKOD=998MENUID=10769AKCE=DOC:10-VDP_NOVINKY

 Ve výměnném formátu VFR je chybně ukládána geometrie parcel a
 stavebních objektů, které jsou tvořeny kružnicí (případně se kružnice
 vyskytuje jako jeden z vnitřních polygonů parcely). Problém se
 vyskytuje v souborech mmdd_OB_cc_UKSH.xml.

 Ve výměnném formátu VFR je chybně ukládána geometrie parcel, které
 obsahují vnitřní polygon, který je tvořen částí oblouku. Problém se
 vyskytuje v souborech mmdd_OB_cc_UKSH.xml.
to bude asi ono. akorát mi není jasné, jestli lze z toho řetězce
vytvořit správný řetězec jeho přepsáním, nebo je chyba jiného rázu a
opravit ji nelze, protože v něm některá data chybí. hledal jsem na netu
gml validátor pro verzi 3, ale asi zatím nic neexistuje. nebo mám
invalidní data prostě ignorovat s tím, že to bude (nebo už i je?) v
nějakém aktualizačním souboru správně a při updatu se to přepíše?
 PS: jak resis, ze jsou souradnice kladne a maji byt zaporne?
to zatím neřeším, netušil jsem, že to co je v datech není správně, a
nějak mě to netrklo :-) stačí, když před všechny souřadnice dám mínus
nebo to vyžaduje ještě něco dalšího?
 ha
 hanoj
ff

 Dne 15. července 2012 23:18 Miroslav Šulc fordf...@fordfrog.com napsal(a):
 ahoj,

 netušíte někdo, co je za problém s tímhle gml řetězcem při převodu
 postgis funkcí st_geomfromgml?

 ruian-test=# insert into test values (st_geomfromgml('gml:Polygon
 xmlns:gml=http://www.opengis.net/gml/3.2; gml:id=HPA.13631950010
 srsName=urn:ogc:def:crs:EPSG::2065
 srsDimension=2gml:exteriorgml:Ringgml:curveMembergml:LineString 
 gml:id=HPA.13631950010.1gml:posList481595.25
 1102177.50 481594.26 1102173.81 481595.20 1102173.14 481595.73
 1102172.20 481595.87 1102171.13 481599.33 1102170.22 481599.01
 1102169.00 481606.76 1102166.97 481605.22 1102161.03 481600.78
 1102162.15 481599.03 1102154.97 481591.89 1102156.87 481589.28
 1102157.56 481590.24 1102161.70 481590.97 1102164.88 481589.46
 1102165.28/gml:posList/gml:LineString/gml:curveMembergml:curveMembergml:Curve
 gml:id=HPA.13631950010.2.3gml:segmentsgml:ArcStringgml:posList481589.46
 1102165.28 481588.41 1102165.67 481587.72 1102166.19 481587.07
 1102166.85 481586.30 1102168.29 481585.96 1102169.71 481586.03
 1102171.13/gml:posList/gml:ArcString/gml:segments/gml:Curve/gml:curveMembergml:curveMembergml:LineString
 gml:id=HPA.13631950010.3gml:posList481586.03 1102171.13 481588.39
 1102179.94 481588.85 1102179.86 481590.37 1102185.72 481594.17
 1102184.79 481594.52
 1102186.07/gml:posList/gml:LineString/gml:curveMembergml:curveMembergml:Curve
 gml:id=HPA.13631950010.4.5gml:segmentsgml:ArcStringgml:posList481594.52
 1102186.07 481595.95 1102185.59 481597.56 1102183.98 481598.13
 1102181.79 481597.87
 1102180.21/gml:posList/gml:ArcString/gml:segments/gml:Curve/gml:curveMembergml:curveMembergml:LineString
 gml:id=HPA.13631950010.5gml:posList481597.87 1102180.21 481596.54
 1102180.56 481595.68 1102177.39 481595.25
 1102177.50/gml:posList/gml:LineString/gml:curveMember/gml:Ring/gml:exterior/gml:Polygon'));
 ERROR:  invalid GML representation
 KONTEXT:  SQL function st_geomfromgml statement 1

 ten xml string se zdá být validní. háže mi to postgresql 9.2 beta2 +
 postgis 2.0.1. na jiné verzi jsem to nezkoušel. v postgresql logu je to
 samé co mi to píše v pgsql, není tam žádné doplňující info. je to při
 importu souboru 20120630_OB_500291_UKSH.xml.gz.
 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-cz





smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] problém s gml řetězcem

2012-07-16 Tema obsahu Miroslav Šulc

Dne 16.7.2012 23:29, hanoj napsal(a):
 hledal jsem na netu
 gml validátor pro verzi 3, ale asi zatím nic neexistuje. nebo mám
 invalidní data prostě ignorovat s tím, že to bude (nebo už i je?) v
 nějakém aktualizačním souboru správně a při updatu se to přepíše?
 *** Myslim, ze to opravi v nejakem pristim mesicnim celkovem vydani,
 validovat to neumim.

já jsem to nakonec vyřešil tak, že jsem do aplikace přidal parametr
--ingore-invalid-gml. při importu to s tímhle parametrem kontroluje
každou gml definici, takže je to pomalejší, ale zase to na chybné gml
definici nespadne. pokud st_geomfromgml definici odmítne, tak se záznam
uloží, jako by tam žádná definice nebyla. taky právě počítám s tím, že v
nějakém updatu se to pak přehraje. otázka ovšem je, jestli se změní i
údaj platné od (podle něj filtruju, jestli se má záznam zaktualizovat
nebo ne, starší platné od nepřepíše novější platné od). asi by to bylo
lepší navázat na id transakce, ale nikde jsem k tomu id transakce
neviděl popis, jestli jdou ty transakce vzestupně nebo jsou id náhodná.

 PS: jak resis, ze jsou souradnice kladne a maji byt zaporne?
 to zatím neřeším, netušil jsem, že to co je v datech není správně, a
 nějak mě to netrklo :-) stačí, když před všechny souřadnice dám mínus
 nebo to vyžaduje ještě něco dalšího?
 *** Ano, zda se ze jen zaporne znamenko. (Někdy byva třeba v jinych
 datech prohodit X za Y...)
ok, takhle jsem to udělal.
 PS: dival jsem se, ze ulice ve VFR nemaji geometrii, tudiz nas vlastne
 zajimaji jen:
 * parcely zastavene (druh pozemku kod= myslim 13 )
 * adresni body
a budovy?
 hanoj
ff


smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] problém s gml řetězcem

2012-07-16 Tema obsahu Miroslav Šulc


Dne 16.7.2012 23:48, Miroslav Šulc napsal(a):
 PS: dival jsem se, ze ulice ve VFR nemaji geometrii, tudiz nas vlastne
 zajimaji jen:
 * parcely zastavene (druh pozemku kod= myslim 13 )
 * adresni body
 a budovy?
resp. stavební objekty. jaký je rozdíl mezi stavebními objekty a parcelami?

ty ulice by se daly aktuálně použít aspoň ke kontrole, jestli nám na
mapě nechybí.
 hanoj
 ff
ff



smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] převod dat z rúian do postgresql

ahoj,

díky za tip. vypadal slibně do té doby, než jsem zjistil, že mi postgis
nefunguje jak má. instaloval jsem ho poprvé, takže chyba může být i na
mé straně, ale netuším, kde jsem jakou mohl udělat.

st_geomfromgml mi vrací chybu ERROR:  invalid GML representation,
dokonce i když použiju příklad z té referenční stránky:

ruian-test=# SELECT ST_GeomFromGML('
gml:LineString srsName=EPSG:4269
gml:coordinates
-71.16028,42.258729 -71.160837,42.259112 -71.161143,42.25932
/gml:coordinates
/gml:LineString');
ERROR:  invalid GML representation
KONTEXT:  SQL function st_geomfromgml statement 1

z té referenční stránky http://www.postgis.org/docs/ST_GeomFromGML.html
mi funguje jen ten  Examples - XLink usage, ostatní vrací tu samou chybu.

ještě jsem zkoušel tenhle příklad a ten mi taky funguje:

ruian-test=# SELECT ST_GeomFromGML(ST_AsGML(ST_GeomFromText('POINT
EMPTY',4326)));
 st_geomfromgml

 
(1 row)

zkoušel jsem postgis 2.0.1 s postgresql 9.2_beta2 a postgis 2.0.0 s
postgresql 9.1.4, ale nefunguje ani jedno. do databáze jsem nainstaloval
vždy postgis.sql, postgis_comments.sql a spatial_ref_sys.sql.

netušíte někdo, v čem by mohl být problém?

ff

Dne 14.7.2012 21:26, Petr Morávek [Xificurk] napsal(a):
 Ahoj,
 kód jsem nezkoumal, takže jen pár rychlých poznámek...

 Miroslav Šulc wrote:
 myslím, že by se ten prográmek mohl hodit (nejenom) k testování
 použitelnosti rúian dat pro aktualizace map. momentálně to importuje
 všechny informace ze základní datové sady. ještě to neumí importovat
 hranice a definiční čáry ulic. gml mi nic neříká a neměl jsem čas se do
 toho nějak víc ponořit
 Pokud máš v postgresql i postgis, tak by to mělo být velice jednoduché,
 viz http://www.postgis.org/docs/ST_GeomFromGML.html

 v souvislosti s tím jsem se chtěl zeptat, jestli se dá nějak jednoduše z
 těch dat vygenerovat mapová vrstva (například s adresními body, ale až
 to bude umět importovat i hranice a ulice, tak i s těmi), která by se
 dala načíst třeba do josm. myslím, že pro vizuální kontrolu rúian dat vs
 osm by to bylo fajn.
 Jednoduše je v tomto případě relativní... o hotovém skriptu nevím, ale
 v případě bodů by to mělo být poměrně triviální. Stačí načíst z databáze
 latlon souřadnice bodu a připojené atributy převést na tagy, pak už jen
 vypsat v osm formátu.
 Trochu komplikovanější by to bylo v případě exportu cest.

 Petr Morávek aka Xificurk




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




smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] převod dat z rúian do postgresql

tak odpověď jsem našel v logu postgresql ... problém byl v chybějící
definici gml namespace ... takže ty jejich dva příklady ani fungovat
nemůžou.

ff

Dne 15.7.2012 16:51, Miroslav Šulc napsal(a):
 ahoj,

 díky za tip. vypadal slibně do té doby, než jsem zjistil, že mi
 postgis nefunguje jak má. instaloval jsem ho poprvé, takže chyba může
 být i na mé straně, ale netuším, kde jsem jakou mohl udělat.

 st_geomfromgml mi vrací chybu ERROR:  invalid GML representation,
 dokonce i když použiju příklad z té referenční stránky:

 ruian-test=# SELECT ST_GeomFromGML('
 gml:LineString srsName=EPSG:4269
 gml:coordinates
 -71.16028,42.258729 -71.160837,42.259112 -71.161143,42.25932
 /gml:coordinates
 /gml:LineString');
 ERROR:  invalid GML representation
 KONTEXT:  SQL function st_geomfromgml statement 1

 z té referenční stránky
 http://www.postgis.org/docs/ST_GeomFromGML.html mi funguje jen ten 
 Examples - XLink usage, ostatní vrací tu samou chybu.

 ještě jsem zkoušel tenhle příklad a ten mi taky funguje:

 ruian-test=# SELECT ST_GeomFromGML(ST_AsGML(ST_GeomFromText('POINT
 EMPTY',4326)));
  st_geomfromgml
 
  
 (1 row)

 zkoušel jsem postgis 2.0.1 s postgresql 9.2_beta2 a postgis 2.0.0 s
 postgresql 9.1.4, ale nefunguje ani jedno. do databáze jsem
 nainstaloval vždy postgis.sql, postgis_comments.sql a spatial_ref_sys.sql.

 netušíte někdo, v čem by mohl být problém?

 ff

 Dne 14.7.2012 21:26, Petr Morávek [Xificurk] napsal(a):
 Ahoj,
 kód jsem nezkoumal, takže jen pár rychlých poznámek...

 Miroslav Šulc wrote:
 myslím, že by se ten prográmek mohl hodit (nejenom) k testování
 použitelnosti rúian dat pro aktualizace map. momentálně to importuje
 všechny informace ze základní datové sady. ještě to neumí importovat
 hranice a definiční čáry ulic. gml mi nic neříká a neměl jsem čas se do
 toho nějak víc ponořit
 Pokud máš v postgresql i postgis, tak by to mělo být velice jednoduché,
 viz http://www.postgis.org/docs/ST_GeomFromGML.html

 v souvislosti s tím jsem se chtěl zeptat, jestli se dá nějak jednoduše z
 těch dat vygenerovat mapová vrstva (například s adresními body, ale až
 to bude umět importovat i hranice a ulice, tak i s těmi), která by se
 dala načíst třeba do josm. myslím, že pro vizuální kontrolu rúian dat vs
 osm by to bylo fajn.
 Jednoduše je v tomto případě relativní... o hotovém skriptu nevím, ale
 v případě bodů by to mělo být poměrně triviální. Stačí načíst z databáze
 latlon souřadnice bodu a připojené atributy převést na tagy, pak už jen
 vypsat v osm formátu.
 Trochu komplikovanější by to bylo v případě exportu cest.

 Petr Morávek aka Xificurk




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






smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] převod dat z rúian do postgresql

takže program už importuje i hranice a cesty (do postgis datového typu
geometry). diky xificurkovi za radu.

ff

Dne 14.7.2012 21:13, Miroslav Šulc napsal(a):
 ahoj,

 napsal jsem prográmek na převod dat z rúian do postgresql (potřeboval
 jsem to částečně pro jednu svojí aplikaci, ale psal jsem to i s
 ohledem na osm). bližší info k programu je tady:
 https://github.com/fordfrog/ruian2pgsql/blob/next_release/README.cs.md

 myslím, že by se ten prográmek mohl hodit (nejenom) k testování
 použitelnosti rúian dat pro aktualizace map. momentálně to importuje
 všechny informace ze základní datové sady. ještě to neumí importovat
 hranice a definiční čáry ulic. gml mi nic neříká a neměl jsem čas se
 do toho nějak víc ponořit, ale pokud by mě někdo chtěl stručně
 vysvětlit, jak ta data nejlíp převést do db, tak budu rád, ušetřilo by
 mi to nějaký čas. nebo to může někdo do toho prográmku dopsat,
 zdrojáky jsou na
 https://github.com/fordfrog/ruian2pgsql/tree/next_release (je to v javě).

 v souvislosti s tím jsem se chtěl zeptat, jestli se dá nějak jednoduše
 z těch dat vygenerovat mapová vrstva (například s adresními body, ale
 až to bude umět importovat i hranice a ulice, tak i s těmi), která by
 se dala načíst třeba do josm. myslím, že pro vizuální kontrolu rúian
 dat vs osm by to bylo fajn.

 fordfrog


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




smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] převod dat z rúian do postgresql

díky za odpověď, bohužel mi zprávy z mailing listu obvykle chodí s
několikahodinovým zpožděním, takže se mi občas stane, že mi přijde
odpověď na něco na co jsem se ptal, ale já to mezi tím nějak vyřeším.
předpokládám, že ostatním to asi chodí normálně, protože jinak by ty
odpovědi neměly čas odeslání třeba hodinu a půl před mojí následnou
zprávou, při které mi předchozí odpověď ještě nedorazila. pak to vypadá,
že ty odpovědi vůbec nečtu :-/

ff

Dne 15.7.2012 17:18, Petr Morávek [Xificurk] napsal(a):
 Miroslav Šulc wrote:
 ahoj,

 díky za tip. vypadal slibně do té doby, než jsem zjistil, že mi postgis
 nefunguje jak má. instaloval jsem ho poprvé, takže chyba může být i na
 mé straně, ale netuším, kde jsem jakou mohl udělat.

 st_geomfromgml mi vrací chybu ERROR:  invalid GML representation,
 dokonce i když použiju příklad z té referenční stránky:

 ruian-test=# SELECT ST_GeomFromGML('
 gml:LineString srsName=EPSG:4269
 gml:coordinates
 -71.16028,42.258729 -71.160837,42.259112 -71.161143,42.25932
 /gml:coordinates
 /gml:LineString');
 ERROR:  invalid GML representation
 KONTEXT:  SQL function st_geomfromgml statement 1
 Tohle bude asi chyba v dokumentaci. Testnul jsem to u sebe a přišel na
 to, že musíš uvést namespace, tj.

 osm= SELECT ST_GeomFromGML('
 gml:LineString xmlns:gml=http://www.opengis.net/gml; srsName=EPSG:4269
 gml:coordinates
 -71.16028,42.258729 -71.160837,42.259112 -71.161143,42.25932
 /gml:coordinates
 /gml:LineString');

 nebo ho poctivě odstranit na všech elementech:

 osm= SELECT ST_GeomFromGML('
 LineString srsName=EPSG:4269
 coordinates
 -71.16028,42.258729 -71.160837,42.259112 -71.161143,42.25932
 /coordinates
 /LineString');

 Petr Morávek aka Xificurk



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




smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] převod dat z rúian do postgresql

tak jsem se ještě díval do logu mailserveru a vypadá to, že mi zpráva
dorazila cca tři a půl hodiny potom, co jsi ji psal :-/

Jul 15 20:54:21 thia postfix/smtpd[23483]: connect from
shenron.openstreetmap.org[89.16.179.150]
Jul 15 20:54:22 thia postfix/smtpd[23483]: 03861F50:
client=shenron.openstreetmap.org[89.16.179.150]
Jul 15 20:54:22 thia postfix/cleanup[23489]: 03861F50:
message-id=5002df2f.8090...@gmail.com
Jul 15 20:54:22 thia postfix/qmgr[30228]: 03861F50:
from=talk-cz-boun...@openstreetmap.org, size=6157, nrcpt=1 (queue active)
Jul 15 20:54:22 thia postfix/virtual[23492]: 03861F50:
to=fordf...@fordfrog.com, relay=virtual, delay=0.24,
delays=0.13/0/0/0.11, dsn=2.0.0, status=sent (delivered to maildir)
Jul 15 20:54:22 thia postfix/qmgr[30228]: 03861F50: removed

ff


Dne 15.7.2012 17:18, Petr Morávek [Xificurk] napsal(a):
 Miroslav Šulc wrote:
 ahoj,

 díky za tip. vypadal slibně do té doby, než jsem zjistil, že mi postgis
 nefunguje jak má. instaloval jsem ho poprvé, takže chyba může být i na
 mé straně, ale netuším, kde jsem jakou mohl udělat.

 st_geomfromgml mi vrací chybu ERROR:  invalid GML representation,
 dokonce i když použiju příklad z té referenční stránky:

 ruian-test=# SELECT ST_GeomFromGML('
 gml:LineString srsName=EPSG:4269
 gml:coordinates
 -71.16028,42.258729 -71.160837,42.259112 -71.161143,42.25932
 /gml:coordinates
 /gml:LineString');
 ERROR:  invalid GML representation
 KONTEXT:  SQL function st_geomfromgml statement 1
 Tohle bude asi chyba v dokumentaci. Testnul jsem to u sebe a přišel na
 to, že musíš uvést namespace, tj.

 osm= SELECT ST_GeomFromGML('
 gml:LineString xmlns:gml=http://www.opengis.net/gml; srsName=EPSG:4269
 gml:coordinates
 -71.16028,42.258729 -71.160837,42.259112 -71.161143,42.25932
 /gml:coordinates
 /gml:LineString');

 nebo ho poctivě odstranit na všech elementech:

 osm= SELECT ST_GeomFromGML('
 LineString srsName=EPSG:4269
 coordinates
 -71.16028,42.258729 -71.160837,42.259112 -71.161143,42.25932
 /coordinates
 /LineString');

 Petr Morávek aka Xificurk



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




smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

[Talk-cz] problém s gml řetězcem

ahoj,

netušíte někdo, co je za problém s tímhle gml řetězcem při převodu
postgis funkcí st_geomfromgml?

ruian-test=# insert into test values (st_geomfromgml('gml:Polygon
xmlns:gml=http://www.opengis.net/gml/3.2; gml:id=HPA.13631950010
srsName=urn:ogc:def:crs:EPSG::2065
srsDimension=2gml:exteriorgml:Ringgml:curveMembergml:LineString 
gml:id=HPA.13631950010.1gml:posList481595.25
1102177.50 481594.26 1102173.81 481595.20 1102173.14 481595.73
1102172.20 481595.87 1102171.13 481599.33 1102170.22 481599.01
1102169.00 481606.76 1102166.97 481605.22 1102161.03 481600.78
1102162.15 481599.03 1102154.97 481591.89 1102156.87 481589.28
1102157.56 481590.24 1102161.70 481590.97 1102164.88 481589.46
1102165.28/gml:posList/gml:LineString/gml:curveMembergml:curveMembergml:Curve
gml:id=HPA.13631950010.2.3gml:segmentsgml:ArcStringgml:posList481589.46
1102165.28 481588.41 1102165.67 481587.72 1102166.19 481587.07
1102166.85 481586.30 1102168.29 481585.96 1102169.71 481586.03
1102171.13/gml:posList/gml:ArcString/gml:segments/gml:Curve/gml:curveMembergml:curveMembergml:LineString
gml:id=HPA.13631950010.3gml:posList481586.03 1102171.13 481588.39
1102179.94 481588.85 1102179.86 481590.37 1102185.72 481594.17
1102184.79 481594.52
1102186.07/gml:posList/gml:LineString/gml:curveMembergml:curveMembergml:Curve
gml:id=HPA.13631950010.4.5gml:segmentsgml:ArcStringgml:posList481594.52
1102186.07 481595.95 1102185.59 481597.56 1102183.98 481598.13
1102181.79 481597.87
1102180.21/gml:posList/gml:ArcString/gml:segments/gml:Curve/gml:curveMembergml:curveMembergml:LineString
gml:id=HPA.13631950010.5gml:posList481597.87 1102180.21 481596.54
1102180.56 481595.68 1102177.39 481595.25
1102177.50/gml:posList/gml:LineString/gml:curveMember/gml:Ring/gml:exterior/gml:Polygon'));
ERROR:  invalid GML representation
KONTEXT:  SQL function st_geomfromgml statement 1

ten xml string se zdá být validní. háže mi to postgresql 9.2 beta2 +
postgis 2.0.1. na jiné verzi jsem to nezkoušel. v postgresql logu je to
samé co mi to píše v pgsql, není tam žádné doplňující info. je to při
importu souboru 20120630_OB_500291_UKSH.xml.gz.

ff



smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

[Talk-cz] převod dat z rúian do postgresql

2012-07-14 Tema obsahu Miroslav Šulc

ahoj,

napsal jsem prográmek na převod dat z rúian do postgresql (potřeboval
jsem to částečně pro jednu svojí aplikaci, ale psal jsem to i s ohledem
na osm). bližší info k programu je tady:
https://github.com/fordfrog/ruian2pgsql/blob/next_release/README.cs.md

myslím, že by se ten prográmek mohl hodit (nejenom) k testování
použitelnosti rúian dat pro aktualizace map. momentálně to importuje
všechny informace ze základní datové sady. ještě to neumí importovat
hranice a definiční čáry ulic. gml mi nic neříká a neměl jsem čas se do
toho nějak víc ponořit, ale pokud by mě někdo chtěl stručně vysvětlit,
jak ta data nejlíp převést do db, tak budu rád, ušetřilo by mi to nějaký
čas. nebo to může někdo do toho prográmku dopsat, zdrojáky jsou na
https://github.com/fordfrog/ruian2pgsql/tree/next_release (je to v javě).

v souvislosti s tím jsem se chtěl zeptat, jestli se dá nějak jednoduše z
těch dat vygenerovat mapová vrstva (například s adresními body, ale až
to bude umět importovat i hranice a ulice, tak i s těmi), která by se
dala načíst třeba do josm. myslím, že pro vizuální kontrolu rúian dat vs
osm by to bylo fajn.

fordfrog


smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

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

Dne 10.7.2012 18:53, Václav Řehák napsal(a):
 a ještě jsem se chtěl zeptat na jednu věc. na mobilu a na tabletu
 používám osmand+ a tak by mě zajímalo, kdy, kde a kdo generuje obf
 soubory pro čr, které si pak osmand stahuje. jinak řečeno, zajímá mě,
 kdy si budu moct svoje editace stáhnout do mobilu a do tabletu :-)
 S osmand+ ti neporadím, ale zkus se podívat na Locus, buď zdarma Locus
 Free nebo za cca stovku Locus Pro. Je to asi nejlepší mapový program
 pro Android a lze do něj stáhnout cca 140 MB vektorovou mapu ČR z
 http://www.openandromaps.org/en/download.html
já jsem na ten locus koukal, ale nějak mě nezaujal, na osmand+ už jsem
zvyklý. navíc osmand je dělaný přímo na osm mapy, což mi vyhovuje. mapa
čr, kterou využívá osmand, má v jejich formátu aktuálně cca 328mb
(používá obf formát). výhodou (pro mě) je i to, že si můžu stáhnout z
http://osm.kyblsoft.cz/archiv/ aktuální mapu čr a překonvertovat si ji
prográmkem z osmand repozitáře do obf formátu a mapu si rovnou nahrát do
aplikace, takže můžu mít aktuální data podle potřeby.
 Aktuálně je ke stažení cca měsíc stará verze a většinou to tak jednou
 za měsíc aktualizují.
autor osmand dělal aktualizace čr map cca jednou týdně, akorát teď o
prázdninách zatím aktualizaci nedělal. ale tím, že si mapy můžu
připravit sám, tak mě to netrápí. samotná konverze čr z osm do obf mi
trvá na notebooku (core i7, 8gb ram, ssd disk) cca 2 hodiny.
 V.
fordfrog


smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

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

Dne 10.7.2012 20:07, Tomáš Kratina napsal(a):
 nekde misto uhul jde pouzit uz Bing, ale ne cela CR je jeste v tom
 novem rozliseni
mně to v josm z bingu načetlo půlku obrazovky mapu a a půlku chyba
null, a to se mi stalo několikrát. nicméně teď jsem to zkoušel znova a
když mapu přesunu jinam a pak nazpátek, tak mi to načte i zbytek. nevím
jak je to jinde v republice, ale tady u nás (doksy) je ta mapa dost
nekontranstní, takže se tam špatně identifikují ulice apod., ale je
určitě detailnější než uhul, takže díky za tip.

fordfrog


smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

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

Dne 11.7.2012 20:41, Libor Pechacek napsal(a):
Ahoj Mirku,

On Tue 10-07-12 18:22:17, Miroslav Šulc wrote:
jsem tu nový a tak se chci zeptat, kde a s čím případně můžu pomoct, na
čem má smysl pracovat a na čem ne. co jsem třeba tak nějak pochopil, tak
adresní body asi aktuálně nemá smysl ručně v mapách řešit. přijde mi, že
aktuálně asi hlavním uživatelsky kvalitativním nedostatkem čr map jsou
ulice bez názvů, ale nemám přehled, v jakém rozsahu chybí názvy ulic a
jestli se na tom nějak pracuje. další problém, na který jsem narazil, je
že některé ulice na mapě vůbec nejsou. to se ale asi špatně hledá, pokud
člověk danou oblast nezná nebo ji nezpracovává globálně. chybějící ulice
by se asi daly najít porovnáním osm dat s nějakou db ulic. další věc,
která mě napadá, je malování budov, ale to si myslím, že je v tuhle
chvíli spíš bonus a v současnosti to nemá takovou prioritu.

včera jsem si pročítal českou wiki k osm, ale nějak jsem z ní
nepochopil, jestli jsou práce na českých mapách nějak koordinované nebo
každý dělá to, co ho zrovna baví. stránka o progresu je asi dva roky
stará, takže z ní jsem se toho moc nedozvěděl.

jinak včera jsem zkoušel něco editovat v josm, nakonec jsem přidal názvy
ulic ve třech městečkách, v jednom bylo dokonce potřeba i přidat nějaké
ulice, takže základní mapování už asi trochu ovládám. mapy mě momentálně
baví, ale je to jen hobby, není to moje práce.
Prima. Mluvíc sám za sebe a podle toho jak OSM používám bych Ti doporučil
kreslení ulic. Ulice samotné lze obtáhnout z ortofota nebo Bingu (případně i
z
KM) a pojmenovat podle okolo ležících adresních bodů tam kde už proběhl
import.
Například na českolipsku a mladoboleslavsku jsou adresní body hotové, lze z
nich snadno číst jména ulic tam kde jsou.
takhle přesně jsem to dělal. zjistil jsem ale například, že adresní bod
domu, kde bydlím, na mapě vůbec není, a to se týká i některých dalších
tady okolo. v praze jsem taky v některých případech neuspěl.
Nakonec pak obtáhni hranice obce jako residential area, případně kde to
poznáš, označ průmyslové a zemědělské plochy. Výsledkem bude mapa použitelná
pro navigace.

Dál se pak, pokud se rád touláš v přírodě, můžeš zapojit do mapování
turistických tras. Na to je třeba vyrazit s GPSkou a foťákem do lesů a
posbírat potřebné informace. Kdybys chtěl vědět víc, můžu vysvětlit.
na tohle používám osmand+ a mám stažený i osmtracker. nějak jsem ale
nepochopil, jak dostanu track do josm. četl jsem něco, že mám track
nahrát na osm a pak si ho stáhnout, ale nikde v josm jsem nenašel, jak
se tracky stahují.
normálně programuju v javě (už moc dlouho).
Skvěle, můžeš přispět k vývoji nástrojů. :)
kde a jakých? :-) já teď aktuálně dělám na prográmku pro převod dat z
výměnného formátu rúian do pgsql databáze (potřebuju z toho dostat adresy).
s editací souvisí jedna věc, na kterou jsem včera narazil. v bělé pod
bezdězem jsem zjistil, že některé ulice na mapě vůbec nejsou. mapy z
katastru se mi ale nenačetly, takže předpokládám, že ta vrstva používá
nové digitální mapy, které ovšem pro danou oblast ještě neexistují.
nakonec jsem ulice maloval podle uhul ortofoto mapy (podle vyježděných
polních cest a s pomocí jiných webových map, abych vůbec věděl, kde na
orto mapě mám ty polní cesty), ale ta asi není úplně nejnovější.
existuje nějaký lepší způsob pro malování ulic než ten uhul?
Nic lepšího, než ortofoto a satelitní snímky neznám. Je zajímavé, že
katastrální mapa v Bělé chybí, měla by být všude. Kde není nová digitální, je
ta stará ručně kreslená.
tak už vím v čem byl problém. já jsem měl v josm zapnuté vykreslování
potlach 2 a ty mapy se vykreslují bílou barvou, takže to splynulo s
pozadím a stalo se neviditelným.
HTH,
Libor
fordfrog

smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

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

Dne 11.7.2012 23:22, Michal Pustějovský napsal(a):
 Miroslav Šulc fordfrog@... writes:

 zdravím,

 jsem tu nový a tak se chci zeptat, kde a s čím případně můžu pomoct, na
 čem má smysl pracovat a na čem ne. co jsem třeba tak nějak pochopil, tak
 adresní body asi aktuálně nemá smysl ručně v mapách řešit. přijde mi, že
 aktuálně asi hlavním uživatelsky kvalitativním nedostatkem čr map jsou
 ulice bez názvů, ale nemám přehled, v jakém rozsahu chybí názvy ulic a
 jestli se na tom nějak pracuje. další problém, na který jsem narazil, je
 že některé ulice na mapě vůbec nejsou. to se ale asi špatně hledá, pokud
 člověk danou oblast nezná nebo ji nezpracovává globálně. chybějící ulice
 by se asi daly najít porovnáním osm dat s nějakou db ulic. další věc,
 která mě napadá, je malování budov, ale to si myslím, že je v tuhle
 chvíli spíš bonus a v současnosti to nemá takovou prioritu.
 Na doplňování názvů ulic ve městech může skvěle posloužit OSM Inspector
 (http://tools.geofabrik.de/osmi/?view=wtfe ; vrstva highways zobrazuje silnice
 bez ref. čísla nebo názvu - ale i u vesnic). Dalším dobrým nástrojem pro
 mapování je KeepRight (http://www.keepright.at/).
oba nástroje vypadají dost dobře, díky za tip.

fordfrog


smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

[Talk-cz] rúian a automatizace?

zdravím,

chtěl jsem se zeptat, jak je to s možností využití dat rúian pro nějakou
formu automatizace? jednak je tu samozřejmě úvaha o importu adresních
bodů a budov, ale co třeba vyhledávání chybějících ulic, využití import
hranic území apod.? a jak je to s kvalitou dat rúian? nedalo by se
využít víc těch dat z rúian pro automatizaci aktualizací map? nebo
řekněme poloautomatizaci? že by se například data z rúian zobrazovala v
nějaké vrstvě a dalo by se například potvrdit určitý objekt, nebo naopak
odmítnout, nebo upravit?

možná jsou ty úvahy naprosto zcestné, ale zeptat jsem se prostě musel :-)

fordfrog



smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

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

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

 Mirek

tak tohle je přesně to, co jsem potřeboval vědět, díky. zkusil jsem a
funguje to :-)

fordfrog


smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

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

Dne 12.7.2012 08:59, hanoj napsal(a):
 Ahoj,

 jsem tu nový a tak se chci zeptat, kde a s čím případně můžu pomoct, na
 čem má smysl pracovat a na čem ne. co jsem třeba tak nějak pochopil, tak
 adresní body asi aktuálně nemá smysl ručně v mapách řešit. přijde mi, že
 aktuálně asi hlavním uživatelsky kvalitativním nedostatkem čr map jsou
 ulice bez názvů, ale nemám přehled, v jakém rozsahu chybí názvy ulic a
 jestli se na tom nějak pracuje. další problém, na který jsem narazil, je
 že některé ulice na mapě vůbec nejsou. to se ale asi špatně hledá, pokud
 člověk danou oblast nezná nebo ji nezpracovává globálně. chybějící ulice
 by se asi daly najít porovnáním osm dat s nějakou db ulic. další věc,
 která mě napadá, je malování budov, ale to si myslím, že je v tuhle
 chvíli spíš bonus a v současnosti to nemá takovou prioritu.
 *** Aktualne neni spravne slovo, importy do OSM trvaji mesice az roky...
tohle samozřejmě chápu. asi ale bude lepší trávit hodiny nad řešením
importu než nad manuální úpravou dat.
 *** Predmetem importu by mohli byt i ulice (v obcich kde ulicni sit
 absentuje uplne), budovy (na casti uzemi) a adresni body
tohle si moc nedovedu představit. myslím ty částečné importy. ale to je
asi na samostatný topic.
 včera jsem si pročítal českou wiki k osm, ale nějak jsem z ní
 nepochopil, jestli jsou práce na českých mapách nějak koordinované nebo
 každý dělá to, co ho zrovna baví. stránka o progresu je asi dva roky
 stará, takže z ní jsem se toho moc nedozvěděl.
 *** Ano stranky wiki pisou zpravidla novacci, kdy pochopi jak to
 funguje. Stari matadori to maji v hlave (derave).


 s editací souvisí jedna věc, na kterou jsem včera narazil. v bělé pod
 bezdězem jsem zjistil, že některé ulice na mapě vůbec nejsou. mapy z
 katastru se mi ale nenačetly, takže předpokládám, že ta vrstva používá
 nové digitální mapy, které ovšem pro danou oblast ještě neexistují.
 *** Katastralni mapa existuje  pro celou CR. V Bele pod Bezdezem se
 skenuje analogova mapa. Je treba tusit co se skrze WMS stahuje.
jak jsem psal jinde, měl jsem v josm zapnuté vykreslování potlach 2,
takže v tom byl asi problém, protože mi ty bílé čáry z katastrální mapy
splynuly s pozadím.


 ha
 hanoj
fordfrog


smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] ruian a automatizace?

Dne 12.7.2012 10:15, Jakub napsal(a):
 S s plnou a dokonce i částečnou automatizací je to složité, resp. je
 složité to udělat dobře. Navíc když se to udělá špatně, tak to může
 věci i zhoršit - například přepsat zdánlivě chybnou informaci, která
 se ale zakládá na osobním pozorování na místě namotném a je naopak
 správně. OSM je založeno na tom, že se v něm mixují různí zdroje
 informací, takže dlouhodobě jednosměrná synchronizace z nějakého
 jediného zdroje je proti smyslu projektu. Pokud by ovšem onen projekt
 byl schopen a ochoten i zpětné synchronizace informací doplněných OSM
 tak to je jiná, ale i tohle bude spíš spousta práce, než nějaký
 automatický proces. K té práci se samozřejmě mohou hodit různé
 nástroje, ale žádný nástroj ti nevyřeší jednoduchý problém typu:
 naimportuješ odněkud budouvu a za rok při snaze o synchronizaci
 zjistíš že jak v OSM tak v prvotním zdroji došlo ke úpravám polohy. Co
 s tím? Pokud se nevydáš do terénu, pravdu nezjistíš.

 Čili udělátka typu automatické generovátka chyb ano, ale stejně na
 konci bude ruční práce.
proto jsem psal o té poloautomatice. je mi jasné, že nelze prostě vzít
data z rúian a přepsat s tím data v osm. ale asi by se na základě
určitých pravidel daly ty importy aspoň zpoloautomatizovat, tj. něco by
se naimportovalo rovnou (třeba proto, že to v osm chybí), u něčeho třeba
bude možné určit, že to lze taky automaticky přepsat (needitovaný
záznam, rozdíl v souřadnicích pouze v rámci nějaké malé odchylky, atd.),
a zbytek by se musel při prvotním importu odkontrolovat ručně. pak už by
ale mělo být možné jen sledovat změny a podle toho případně upravovat
údaje v mapě.

v praxi by to samozřejmě znamenalo spoustu testování a ověřování, než by
se takovému systému povolilo něco zapisovat, ale do budoucna by v tom
podle mě byl rozhodně velký přínos. samozřejmě ale základní otázka je,
nakolik kvalitní data rúian obsahuje.

 Jakub
fordfrog


smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] ruian a automatizace?