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

[Petr Morávek [Xificurk]]

Ahoj,

udělal jsem ještě pár testů na budovách v Bukovci a výsledky jsou v
podstatě stejné jako jsem psal u těch adres, viz příloha.

- tmavě zelená je transformace 5514 -> 4326 pomocí gridu, tj. tvoje
oranžová vrstva
- tmavě červená je transformace 5514 -> 4326 pomocí sedmiprvkové
transformace, tj. tvoje tvoje růžová.
- světle červená je to, co zobrazuje ČÚZK v námi používaných WMS
podkladech... data získána dotazem na WFS v projekci 4326
- světle zelená získána dotazem na WFS v projekci 4258

Jak už jsi psal ty - je jasně vidět, že ta sedmiprvková transformace
nesedí na podklady od ČUZK úplně přesně, ale rozhodně lépe než
transformace pomocí gridu, ale...
Ty dvě zelené čáry (transformace gridem a ČUZK v EPSG:4258) jsou
prakticky identické. I když uvážíme, že EPSG:4236 != EPSG:4258, tak by
ten rozdíl neměl být tak velký, jako na obrázku.
Opravdu to vypadá, že ČUZK transformaci do EPSG:4236 dělá blbě a vzniká
tam dodatečná chyba.

Zdraví,
Petr Morávek aka Xificurk

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

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

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

[Petr Morávek [Xificurk]]

Ahoj,

mohl bys prosím poslat konkrétní příklad, kde je vidět posun, o kterém
mluvíš? Mám pocit, že se v tomhle vlákně míchá více věcí dohromady -
jeden o voze, druhý o koze ;)
Ideálně nějaký obrázek s dvěma vrstvama a popisem, z jakého zdroje a
jakými transformacemi vznikly.

S pozdravem,
Petr Morávek aka Xificurk

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


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

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

[Petr Morávek [Xificurk]]

Dne 27.12.2016 v 14:32 Marián Kyral napsal(a):
> Abych pravdu řekl, dle všech dostupných indícií vlastně nemám žádný
> problém. Pro ČÚZK je to metr a půl sem, metr a půl tam :-D

Jo, někde ale ten rozdíl asi vidět bude...

> A abych pravdu řekl, vůbec jsem nezaregistroval, že je dostupný nějaký
> nový grid, který se zřejmě už normálně používá. Já žil v domnění, že
> ještě stále potřebujeme ten algoritmus od ČÚZK, abychom jej mohli
> přepočítat.

Žádný nový grid nepoužívám... jsem stále na starém Ježek08, viz co psal
hanoj:
> *** není žádný starší méně přesný a nový přesnější. Jsou dva gridy starý 
> Ježek2008 XY a nový Seidl2014 XYZ, nic víc, o změně přesnosti nebyla řeč.

Taky jsem si doteď myslel, že potřebujem spočítat nový grid. Celé to
vycházelo z toho, že když já vezmu zdrojové souřadnice v EPSG:5514 z
RUIAN a pomocí gridu je převedu na latlon (EPSG:4326), tak dostanu jiná
čísla (občas o víc jak metr) než jaká vrací ČÚZK ve svém WMS/WFS. A
tenhle problém předpokládám nepřímo trápí i tebe.

Jenže z mého testování na adresních bodech to spíš vypadá, že chyba při
transformaci ze zdrojového EPSG:5514 nevzniká na naší straně, ale na
straně ČÚZK. A tedy starý grid Ježek08 dává stále dobré výsledky.

S pozdravem,
Petr Morávek aka Xificurk

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

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

[Petr Morávek [Xificurk]]

Dne 27.12.2016 v 11:40 Petr Morávek [Xificurk] napsal(a):
> Dne 27.12.2016 v 08:44 Marián Kyral napsal(a):
>> Dne 27.12.2016 v 08:29 Marián Kyral napsal(a):
>>> Dne 26.12.2016 v 23:55 Petr Morávek [Xificurk] napsal(a):
>>>> @Marián: Ty se snažíš vyřešit zarovnání dat, co posílá Petr z poloha.net
>>>> (hádám, že vznikají transformací ze zdrojového EPSG:5514 do latlon
>>>> pomocí gridu) s čím konkrétně? S WMS podklady? A ty teď taháš v jaké
>>>> projekci? EPSG:4326? Jestli jo, tak to zkus vyměnit za EPSG:4258.
>>>>
>>> Snažím se to napasovat na KM. Konkrétně na tuhle definici:
>>> 
>>>   
>>>   
>>>   >> value='http://services.cuzk.cz/wms/wms.asp?FORMAT=image/pngVERSION=1.1.1SERVICE=WMSREQUEST=GetMapLAYERS=DEF_PARCELY,DEF_BUDOVY,RST_PK_I,RST_KMD_I,dalsi_p_mapy_i,obrazy_parcel_i,parcelni_cisla_i,hranice_parcel_barevne,omp_iSTYLES=SRS={proj}WIDTH={width}HEIGHT={height}BBOX={bbox}TRANSPARENT=true'/>
>>>   
>>>   
>>>   
>>> 
>>>
>>> Žádnou projekci tam nemám, předpokládám, že se použije nějaká výchozí.
>>>
>>> Marián
>>
>> Tak jsem hledal v nastavení a tam mám ještě něco úplně jiného:
>>
>>
>> To je OK, nebo to mám nějak změnit?
>>
>> Marián
> 
> 
> Ahoj,
> 
> pošli mi prosím bližší info, kde je problém... teď jsem se zkoušel v
> JOSM podívat na Jablunkov s vrstvami:
> - WMS přesně podle tvé definice
> - Český RUIAN budovy (TMS z poloha.net)
> 
> A přišlo mi, že to na sebe pěkně pasuje.
> 
> S pozdravem,
> Petr

Ale jak na to koukám, tak JOSM asi stejně neumí udělat reprojekci
lokálně :/ Takže je nereálné stahovat EPSG:4258 dlaždice a do mercatora
(EPSG:3857) to převádět až u sebe.

Petr

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

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

[Petr Morávek [Xificurk]]

Dne 27.12.2016 v 08:44 Marián Kyral napsal(a):
> Dne 27.12.2016 v 08:29 Marián Kyral napsal(a):
>> Dne 26.12.2016 v 23:55 Petr Morávek [Xificurk] napsal(a):
>>> @Marián: Ty se snažíš vyřešit zarovnání dat, co posílá Petr z poloha.net
>>> (hádám, že vznikají transformací ze zdrojového EPSG:5514 do latlon
>>> pomocí gridu) s čím konkrétně? S WMS podklady? A ty teď taháš v jaké
>>> projekci? EPSG:4326? Jestli jo, tak to zkus vyměnit za EPSG:4258.
>>>
>> Snažím se to napasovat na KM. Konkrétně na tuhle definici:
>> 
>>   
>>   
>>   > value='http://services.cuzk.cz/wms/wms.asp?FORMAT=image/pngVERSION=1.1.1SERVICE=WMSREQUEST=GetMapLAYERS=DEF_PARCELY,DEF_BUDOVY,RST_PK_I,RST_KMD_I,dalsi_p_mapy_i,obrazy_parcel_i,parcelni_cisla_i,hranice_parcel_barevne,omp_iSTYLES=SRS={proj}WIDTH={width}HEIGHT={height}BBOX={bbox}TRANSPARENT=true'/>
>>   
>>   
>>   
>> 
>>
>> Žádnou projekci tam nemám, předpokládám, že se použije nějaká výchozí.
>>
>> Marián
> 
> Tak jsem hledal v nastavení a tam mám ještě něco úplně jiného:
> 
> 
> To je OK, nebo to mám nějak změnit?
> 
> Marián


Ahoj,

pošli mi prosím bližší info, kde je problém... teď jsem se zkoušel v
JOSM podívat na Jablunkov s vrstvami:
- WMS přesně podle tvé definice
- Český RUIAN budovy (TMS z poloha.net)

A přišlo mi, že to na sebe pěkně pasuje.

S pozdravem,
Petr

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

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

[Petr Morávek [Xificurk]]

Dne 24.12.2016 v 00:04 Ha Noj napsal(a):
>> 1) Dělám něco špatně já?
> *** GRID je spočítán mezi ETRS89 a JTSK, takže by tam mělo být ještě
> něco mezi ETRS89 a WGS84. Ale nepotěším tě, neboť to dělá jen cca 30 cm.
> 
> echo "18.845223 49.547998" | cs2cs +init=epsg:4326 +to +init=epsg:4258
> +towgs84="0.0473,0.0467,-0.0253,0.000891,0.00539,-0.008772,-0.00158" -f
> "%.6f" | cs2cs +init=epsg:4258 +to +init=epsg:5514
> +nadgrids=./jezek08_jtskcz.llb -f "%.3f"
> -432758.771-1136759.330 -0.009

Uff, musím říct, že tvoje zmínka o ETRS89 (a rozdílnosti oproti WGS84)
pro mne otevřela nová dvířka, která si nejsem jistý, že jsem chtěl
otevřít :-))

Zajímalo by mne odkud pochází tvoje transformační parametry towgs84?
Vůbec se mi je nepodařilo nikde vygooglit a obecně jsem ve spoustě
zdrojů narážel na doporučení považovat oba systémy za "shodné". A když
se podívám na definici v /usr/share/proj/epsg tak tam je:

> # ETRS89
> <4258> +proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs  <>


Snažil jsem se dál empiricky dopátrat, jaké transformace provádí ČÚZK.
Jako dataset jsem použil adresní místa - pro každou obec (>6000) jsem
náhodně vybral jedno adresní místo (to by snad mělo zajistit
reprezentativní vzorek).
Z WFS jsem pak stáhl souřadnice v EPSG:4258 a EPSG:4326, na ně vyzkoušel
různé transformace a výsledek porovnával s původními souřadnicemi v
EPSG:5514 z WFS.
A mám pocit, že čím víc se v tom rýpu, tím větší zmatek v tom mám :/


1) EPSG:4258 -> EPSG:5514 pomocí gridu, např.
echo "16.914199 49.148716" | cs2cs +init=epsg:4258 +to +init=epsg:5514
+nadgrids=czech -f "%.3f"
-576504.892 -1168238.275 -0.000
Výsledná odchylka na souboru adresních bodů:
4 +/- 2 cm (max. 15 cm)
HURÁ! Zdá se, že grid skutečně funguje skvěle a souhlasí s tím, co
posílá ČÚZK.


2) EPSG:4258 -> EPSG:5514 pomocí sedmiprvkové transformace, např.
echo "16.914199 49.148716" | cs2cs +init=epsg:4258 +to +init=epsg:5514
+towgs84="570.8,85.7,462.8,4.998,1.587,5.261,3.56" -f "%.3f"
-576504.701 -1168238.186 -44.382
Výsledná odchylka na souboru adresních bodů:
16 +/- 11 cm (max. 82 cm)
Podle očekávání dává sedmiprvková transformace horší výsledky.


3) EPSG:4326 -> EPSG:5514 pomocí gridu, např.
echo "16.914193 49.148715" | cs2cs +init=epsg:4326 +to +init=epsg:5514
+nadgrids=czech -f "%.3f"
-576505.338 -1168238.341 0.000
Výsledná odchylka na souboru adresních bodů:
18 +/- 16 cm (max. 116 cm)
Tohle je to, co používám teď na import administrativních hranic (AFAIK
to samé je na poloha.net) a řeším, proč se ta čísla v některých
případech rozcházejí o více jak metr.


4) EPSG:4326 -> EPSG:4258 -> EPSG:5514 pomocí gridu, např.
echo "16.914193 49.148715" | cs2cs +init=epsg:4326 +to +init=epsg:4258
+towgs84="0.0473,0.0467,-0.0253,0.000891,0.00539,-0.008772,-0.00158" -f
"%.8f" | cs2cs +init=epsg:4258 +to +init=epsg:5514 +nadgrids=czech -f "%.3f"
-576505.114 -1168238.150 -0.009
Výsledná odchylka na souboru adresních bodů:
31 +/- 10 cm (max. 86 cm)
Nápad s přidáním transformace WGS84<->ETRS89 sice stáhnul maximální
chybu o těch 30 cm, na druhou stranu průměrná chyba šla nahoru, takže
tohle asi taky nebude správná cesta (?)


5) EPSG:4326 -> EPSG:5514 pomocí sedmiprvkové transformace, např.
echo "16.914193 49.148715" | cs2cs +init=epsg:4326 +to +init=epsg:5514
+towgs84="570.8,85.7,462.8,4.998,1.587,5.261,3.56" -f "%.3f"
-576505.148 -1168238.251 -44.382
Výsledná odchylka na souboru adresních bodů:
14 +/- 7 cm (max. 36 cm)
Tohle je další překvapení - tahle cesta nejlépe reprodukuje transformaci
ČÚZK přestože víme, že rozhodně není nejpřesnější.


6) EPSG:4326 -> EPSG:4258 -> EPSG:5514 pomocí sedmiprvkové transformace,
např.
echo "16.914193 49.148715" | cs2cs +init=epsg:4326 +to +init=epsg:4258
+towgs84="0.0473,0.0467,-0.0253,0.000891,0.00539,-0.008772,-0.00158" -f
"%.8f" | cs2cs +init=epsg:4258 +to +init=epsg:5514
+towgs84="570.8,85.7,462.8,4.998,1.587,5.261,3.56" -f "%.3f"
-576504.923 -1168238.061 -44.391
Výsledná odchylka na souboru adresních bodů:
24 +/- 9 cm (max. 49 cm)
Tohle už uvádím jen pro úplnost.



Abych pravdu řekl, tak vůbec netuším, jaký z toho všeho udělat závěr.
Vypadá to, že grid, co jsme používali doteď, stále "funguje" správně. A
naopak jsou to data ČÚZK v EPSG:4326, kterým se nedá moc věřit.

@Marián: Ty se snažíš vyřešit zarovnání dat, co posílá Petr z poloha.net
(hádám, že vznikají transformací ze zdrojového EPSG:5514 do latlon
pomocí gridu) s čím konkrétně? S WMS podklady? A ty teď taháš v jaké
projekci? EPSG:4326? Jestli jo, tak to zkus vyměnit za EPSG:4258.


S pozdravem,
Petr Morávek aka Xificurk

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

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

[Petr Morávek [Xificurk]]

Dne 20.12.2016 v 16:39 Ha Noj napsal(a):
>> Aktuálně je rozdíl RUIAN vs. KM. Takže jsem předpokládal, že stačí
> napasovat RUIAN na KM. Ale jestli je KM taky
>> mimo, tak jsme v pr..li úplně. :-(
> 
> *** tak pokud nám stačí, aby to sedělo na cuzk:km v epsg:4326 pak
> použijme WFS např. Bukovec č.p.109 okres FrýdekMístek:
> http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/12381535
> 
> http://services.cuzk.cz/wfs/inspire-bu-wfs.asp?service=WFS=urn:ogc:def:crs:EPSG::4326=2.0.0=GetFeature_id=urn:ogc:def:query:OGC-WFS::GetFeatureById=BU.12847628
> 
> 
> ha
> hanoj

Ahoj,

včera večer jsem si potvrdil, že mám u sebe grid Ježek2008 -sedí mi
transfomace kontrolního bodu uváděného na wiki:

> SELECT ST_AsText(ST_Transform(ST_GeomFromText('POINT(-718583.33 
> -949224.46)',999),4326)) As wgs_geom;
> "POINT(14.5808761364013 50.9523314825017)"

A tak jsem to rovnou testnul na odkazované budově (prostě jsem vzal
první bod z geometrie budovy):

ČUZK EPSG:5514:
-432758.18 -1136758.78

ČUZK EPSG:4326:
49.547998 18.845223

ČUZK EPSG:4326 -> EPSG:5514 převedeno pomocí gridu:
-432759.004430401 -1136759.53511646

Tzn. celkový posun je cca 112cm.

Ono to není nijak tragické, ale už je to prostě poznat. Ale především je
to o dva řády vyšší odchylka než tebou udávané centrimetry.

Omlouvám se pokud přehlížím nějakou trivialitu, která je jasná každému
prvákovi na geoinformatice... v tomhle jsem prostě amatér a do vnitřních
složitostí tematiky různých projekcí vidím jen natolik, kolik bylo doteď
potřeba pro práci s RUIAN v OSM. Takže se možná budu dál ptát trochu
jako blbeček, ale...

1) Dělám něco špatně já?

2) Dělá něco špatně ČÚZK a jeho souřadnice v EPSG:4326 jsou chybné?

3) Skutečně je grid Ježek2008 přesný řádově na centimetry?

4) Jak je možné, že se transformace moje a ČÚZK rozchází v tomhle
případě víc jak o metr?

5) Pokud je transformace ČUZK správná, jak ji můžu implementovat u sebe
aniž bych se na každou souřadnici musel ptát WFS?


Předem díky za jakékoliv info,
Petr Morávek aka Xificurk

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

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

[Petr Morávek [Xificurk]]

Dne 20.12.2016 v 11:40 Ha Noj napsal(a):
> 2) Transformace gridem je znama: http://k154.fsv.cvut.cz/~seidl/
> http://freegis.fsv.cvut.cz/gwiki/S-JTSK_/_Grid

Ahoj,

tohle je třeba pro mne nové info - přiznám se, že jsem to tu poslední
dobou moc nesledoval, tak nevím jestli jsem zmínku o tomto gridu jen
přehlédl, nebo sem opravdu doputovala až teď.

Jsem si celkem jistý, že v databázi, ze které pouštím aktualizace
administrativních hranic mám nějaký starší méně přesný grid... a vůbec
bych se nedivil, kdyby to měl Petr na poloha.net taky tak.

Každopádně díky za info, aspoň si mám s čím přes vánoce hrát :-)

Zdraví,
Petr Morávek aka Xificurk

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

Re: [Talk-cz] Jak značíme střední školu?

[Petr Morávek [Xificurk]]

Dne 18.2.2016 v 14:39 jzvc napsal(a):
> Dne 18.2.2016 v 11:01 Petr Morávek [Xificurk] napsal(a):
>> Dne 18.2.2016 v 10:13 jzvc napsal(a):
>>> 1) tagy se neprekladaji ale vykladaji, prekladat je, je pitomost
>>> 2) v celem stredoevropskem prostoru, kde skolstvi vychazi ze stejnych (a
>>> diametralne jinych nez EN) zakladu, ve vseobecnosti existuje 3 stupnove
>>> vzdelavani.
>>> 3) college v tom systemu vubec neexistuje (z pohledu vzdelavaciho
>>> systemu jsou vsechny VS totez, a rozlisovat nepatrne rozdily na ukor
>>> zcela zasadniho rozdilu mezi zakladni a stredni skolou ...).
>>
>> Ahoj,
>>
>> vycházíš ze nesprávného předpokladu, že anglické tagy odpovídají
>> anglickému (britskému) systému školství. Přeti si anglickou verzi wiki.
>> Explicitně se tam píše, že ne všechno, co má v názvu College/University
>> by se mělo značit jako amenity=college/university.
>> Jak já rozumím popisu na anglické wiki, tak aplikace na naše školství je
>> následující:
>> MŠ: amenity=kindergarten
>> ZŠ+SŠ (gymnázia, SOŠ, SOU, učiliště): amenity=school
>> VŠ: amenity=university
>> VOŠ: amenity=college
>>
> 
> Ja nevychazim z predpokladu, vychazim z toho, ze se tu snazite ty tagy
> prekladat. A ZS vs SS je diametralne neco jineho, narozil od VoS, coz je
> takovej zpusob, jak se dalsi rok nebo dva poflakovat na stredni. Ale
> porad to neni college.

Na tom se shodnem, není to college... ale sedí to na definici tagu
amenity=college. To je ta "chyba" v tvé úvaze, na kterou jsem se tě
snažil upozornit - definice tagů NEodpovídá jejich významu v britském
školství.

> Vsimni si totiz, ze prave ty VoS jsou prakticky
> vzdy soucasti strednich skol.  A naopak, drtiva vetsina strednich skol
> umoznuje neco na to tema.
> 
> Zkus si predstavit pouzitelnost dat ktera je ve tvem schematu naprosto
> mizerna. Budes hledat zakladni skoly ve svem okoli ... a nemas jak.

Máš, viz zmíněný ISCED.

> Budes hledat stredni skoly/uciliste ... a opet nemas jak.

Máš, viz zmíněný ISCED.

> Jak casto - jaky % populace/uzivatelu bude resit specificky VOS?
> 
> http://www.msmt.cz/vzdelavani/skolstvi-v-cr/statistika-skolstvi/vykonova-data-o-skolach-a-skolskych-zarizenich-2003-04-2013
> 
> 
> Cca 1/2M na strednich skolach
> vs
> cca 30k na VOS
> vs
> temer 1M na ZS
> 
> => budeme davat extra tag pro 30k lidi (aby to jakoz takoz odpovidalo
> prekladu z EN) a 1,5M hodime na jednu hromadu?

Nehodíme na jednu hromadu, viz zmíněný ISCED.
Ne, aby to odpovídalo překladu, ale aby to odpovídalo definici tagu.

A když se podíváš třeba do Rakouska, tak tam to značí podobně jako
píšu... amenity=college se v podstatě nepoužívá - to málo, co jsem našel
a proklikal vypadalo všechno na VOŠ, různé akademie a další podobné
okrajové záležitosti.


S pozdravem,
Petr Morávek aka Xificurk

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

Re: [Talk-cz] Jak značíme střední školu?

[Petr Morávek [Xificurk]]

Dne 18.2.2016 v 10:13 jzvc napsal(a):
> 1) tagy se neprekladaji ale vykladaji, prekladat je, je pitomost
> 2) v celem stredoevropskem prostoru, kde skolstvi vychazi ze stejnych (a
> diametralne jinych nez EN) zakladu, ve vseobecnosti existuje 3 stupnove
> vzdelavani.
> 3) college v tom systemu vubec neexistuje (z pohledu vzdelavaciho
> systemu jsou vsechny VS totez, a rozlisovat nepatrne rozdily na ukor
> zcela zasadniho rozdilu mezi zakladni a stredni skolou ...).

Ahoj,

vycházíš ze nesprávného předpokladu, že anglické tagy odpovídají
anglickému (britskému) systému školství. Přeti si anglickou verzi wiki.
Explicitně se tam píše, že ne všechno, co má v názvu College/University
by se mělo značit jako amenity=college/university.
Jak já rozumím popisu na anglické wiki, tak aplikace na naše školství je
následující:
MŠ: amenity=kindergarten
ZŠ+SŠ (gymnázia, SOŠ, SOU, učiliště): amenity=school
VŠ: amenity=university
VOŠ: amenity=college


S pozdravem,
Petr Morávek aka Xificurk

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

Re: [Talk-cz] Jak značíme střední školu?

[Petr Morávek [Xificurk]]

Dne 16.2.2016 v 13:01 Dalibor Jelínek napsal(a):
> No, ono nejde ani tak o preklad wiki, ta definice je podle me jasna
> 
> a to na obou mistech. U amenity=college se pise, ze je jedna o
> 
> post-sekundarni vzdelavani a u amentity=school zase ze to je pro
> 
> zaky do 18ti let a zahruje to i sekundarni vzdelavani.
> 
>  
> 
> Problem byl spise v tom puvodnim prekladu, ktery je blbe jak
> 
> pro JOSM tak byl spatne i na wiki. I slovnik.seznam.cz preklada
> 
> college jako vyssi odborna skola.
> 
>  
> 
> Nemyslim si, ze je zcela vhodne, abychom si v CR kvuli spatnemu
> 
> prvotnimu prekladu znacili skoly jinak, nez je bezne ve svete.
> 
> Tim bychom, podle meho nazoru, sli hodne proti cele logice OSM.
> 
> To bych radsi hlasoval pro to preznaceni.
> 
> Co si mysli ostatni?

Ahoj,

naprosto s tebou souhlasím.

Ještě bych k tomu dodal, že podle taginfa máme v ČR:

3348 amenity=school
 464 amenity=college
 285 amenity=university

Tedy, což dost zpochybňuje obavu, že jsou všechny nebo značná část
středních škol označeny jako amenity=college a oprava by znamenala velké
přeznačování.

S pozdravem,
Petr Morávek aka Xificurk



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

Re: [Talk-cz] Vojenské újezdy

[Petr Morávek [Xificurk]]

Právě jsem překontroloval/doplnil úpravy Libavé, Březiny, Hradiště a
Boletic.

Zbývá dořešit Brdy, viz:

Dne 13.1.2016 v 11:56 Petr Morávek [Xificurk] napsal(a):
> 1. Brdy
> Vojenský újezd zanikl, jeho území je rozporcováno mezi přilehlé obce.
> 
> landuse=military: http://www.openstreetmap.org/relation/67882
> - Odpovídá staré nepřístupné oblasti, v velké části je veden pop cestách
> administrativních hranic.
> - Zatím jen proběhlo přetagování na CHKO.
> - TODO: Opravit hranici CHKO - pokud vím, tak do něj spadají i oblasti
> mimo bývalý újezd a naopak. Dokud nebude dokončena sanace celého území,
> tak by měl alespoň někde zůstat military=danger_area.

S pozdravem,
Petr Morávek aka Xificurk


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

[Talk-cz] Vojenské újezdy

[Petr Morávek [Xificurk]]

Ahoj,

dokončil jsem aktualizaci administrativních hranic včetně všech změn
vojenských újezdů.

Teď by bylo potřeba aktualizovat polygony landuse=military - ty by měly
podle mě pokrývat jen oblasti skutečně používané armádou a typicky
(částečně) uzavřené pro veřejnost. Tzn. stejně jako doteď nutně nemusí
být přesně shodné s administrativní hranicí vojenského újezdu.

Neměl jsem ještě čas hledat, jak se v jednotlivých újezdech od nového
roku změnil režim, co je/není přístupné atd. Takže pokud máte někdo k
některé z oblastí bližší vzta, napiště a klidně se pusťte do úprav.

Tady je přehled aktuální situace:

1. Brdy
Vojenský újezd zanikl, jeho území je rozporcováno mezi přilehlé obce.

landuse=military: http://www.openstreetmap.org/relation/67882
- Odpovídá staré nepřístupné oblasti, v velké části je veden pop cestách
administrativních hranic.
- Zatím jen proběhlo přetagování na CHKO.
- TODO: Opravit hranici CHKO - pokud vím, tak do něj spadají i oblasti
mimo bývalý újezd a naopak. Dokud nebude dokončena sanace celého území,
tak by měl alespoň někde zůstat military=danger_area.


2. Libavá
Došlo ke zmemnšení újezdu:
http://www.openstreetmap.org/relation/437075

landuse=military: http://www.openstreetmap.org/way/28354068
- Nepřesný polygon vojenského prostoru, nepoužívá cesty adm. hranic.
- TODO: Předělat na multipolygon užívající adm. hranic + zmenšit území
vojenského prostoru.


3. Březina
Došlo ke zmenšení újezdu:
http://www.openstreetmap.org/relation/440731

landuse=military: http://www.openstreetmap.org/relation/50875
- Multipolygon používá cesty adm. hranic.
- TODO: Zmenšit území vojenského prostoru.


4. Hradiště
Došlo ke zmenšení újezdu:
http://www.openstreetmap.org/relation/439469

landuse=military: http://www.openstreetmap.org/relation/1753105
- Multipolygon používá převážně cesty adm. hranic.
- TODO: Zmenšit území vojenského prostoru.


5. Boletice
Došlo ke zmenšení újezdu:
http://www.openstreetmap.org/relation/438525

landuse=military: http://www.openstreetmap.org/relation/3463628
- Multipolygon používá převážně cesty adm. hranic.
- TODO: Zmenšit území vojenského prostoru.



S pozdravem,
Petr Morávek aka Xificurk

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

Re: [Talk-cz] libava

[Petr Morávek [Xificurk]]

Ještě na tom pracuju... bylo toho víc něž jsem čekal. Dneska už bych
fakt chtěl dotáhnout aktualizaci administrativnich hranic a sepsat
souhrnný stav vojenských újezdů.

Zdraví,
Petr Morávek aka Xificurk

Dne 12.1.2016 v 21:15 Jan Dudík napsal(a):
> Nejen Libavá, není aktualizovaný ani Hradiště, Boletice a Březina a CHKO
> Brdy taky nemá správnou rozlohu, stejně tak hranice krajů.
> 
> ---
> Ing. Jan Dudík
> projekce dopravních staveb
> tel. 777082195
> 
> Dne 12. ledna 2016 7:52 Michal Grézl <michal.gr...@openstreetmap.cz
> <mailto:michal.gr...@openstreetmap.cz>> napsal(a):
> 
> jak to dopadlo s tim updatem? ono to uz dost hori, mapy.cz
> <http://mapy.cz> uz to maji opraveny:)
> 
> 2016-01-04 13:50 GMT+01:00 Michal Grézl
> <michal.gr...@openstreetmap.cz <mailto:michal.gr...@openstreetmap.cz>>:
> > 2016-01-04 13:34 GMT+01:00 Petr Morávek [Xificurk] <p...@pada.cz
> <mailto:p...@pada.cz>>:
> >> Dne 4.1.2016 v 13:24 Michal Grézl napsal(a):
> >>> zacal uz nekdo neco delat s libavou? Je potreba zrusit stary hnusny
> >>> polygon a predelat to na relaci nad hranicemi katastru. Jestli
> nikdo,
> >>> tak bych zacal.
> >>>
> >>
> >> Ahoj,
> >>
> >> nejpozději do konce týdne provedu update administrativních hranic
> podle
> >> aktuálních dat z RUIAN.
> >> Předpokládám, že zároveň s tím opravím i příslušný landuse=military.
> >>
> >> Zdraví,
> >> Petr Morávek aka Xificurk
> >>
> >
> > ok, tak ja na to dlabu, nezapomen zrusit ten stary landuse:).
> >
> > --
> > Michal Grézl
> > http://openstreetmap.cz
> 
> 
> 
> --
> Michal Grézl
> http://openstreetmap.cz
> 
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org <mailto:Talk-cz@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-cz
> 
> 
> 
> 
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> 


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

Re: [Talk-cz] Hospoda Praha

[Petr Morávek [Xificurk]]

Ahoj,
právě se mi uvolnil zítřejší večer, takže bych taky dorazil.
Platí tedy Kofein v šest?

Zdraví,
Petr Morávek aka Xificurk

Dne 20.10.2015 v 15:56 Jan Cibulka napsal(a):
> Ja taky pujdu, zadnej podnik nepreferuju.
> 
> From: Marián Kyral 
> Sent: ‎20. ‎10. ‎2015 15:44
> To: OpenStreetMap Czech Republic 
> Subject: Re: [Talk-cz] Hospoda Praha
> 
> Ahoj.
> jsem pro, takže už jsme dva ;-)
> 
> Marián
> 
> -- Původní zpráva --
> Od: Dalibor Jelínek 
> Komu: 'OpenStreetMap Czech Republic' 
> Datum: 20. 10. 2015 15:22:29
> Předmět: Re: [Talk-cz] Hospoda Praha
> 
> 
> Ahoj,
> tak jak s tou hospodou zitra?
> Muzete napsat, kdo jde a v kolik asi muze a kam by chtel?
> Asi by se podle toho mel zarezervovat stul.
> Za sebe navrhuju Kofein - 18:00
> 
> Dalibor
> 
> > -Original Message-
> > From: Martin Landa [mailto:landa.mar...@gmail.com]
> > Sent: Monday, October 19, 2015 8:31 PM
> > To: OpenStreetMap Czech Republic 
> > Subject: Re: [Talk-cz] Hospoda Praha
> >
> > Panove,
> >
> > Dne 19. října 2015 7:31 Dalibor Jelínek 
> napsal(a):
> > > za sebe bych navrhoval Kofein na Vinohradech. https://ikofein.cz/cz/
> > > Je to spise klidnejsi vinarna, kde maji dobre tapas.
> > > Ale U sadu se taky da.
> > > Nevim, jestli plati ta 17ta hodina, na me je to trochu brzy, dorazil
> > > bych se zpozdenim. 18ta by byla lepsi.
> >
> > necham to na Vas. Moje ucast je nejista, ale pokusim se dorazit
> (spise az
> > kolem 19h)! Martin
> >
> > >>
> > >> [1] http://www.usadu.cz/
> > >> [2] http://www.drest.cz/u-petnika
> > >>
> > >> >> Dalibor
> > >> >>
> > >> >>
> > >> >>
> > >> >> From: Petr Dlouhý [mailto:petr.dlo...@email.cz]
> > >> >> Sent: Sunday, October 4, 2015 11:00 PM
> > >> >>
> > >> >>
> > >> >> To: OpenStreetMap Czech Republic 
> > >> >> Subject: Re: [Talk-cz] Hospoda Praha
> > >> >>
> > >> >>
> > >> >>
> > >> >> Ahoj,
> > >> >>
> > >> >>
> > >> >>
> > >> >> rád bych se taky přidal. V úterý ale nebudu moct (resp. až po
> > >> >> deváté), a ve středu budu moct až po osmé.
> > >> >>
> > >> >> --
> > >> >> Petr Dlouhý
> > >> >> petr.dlo...@email.cz
> > >> >> Mob: +420 736 108 424
> > >> >>
> > >> >> -- Původní zpráva --
> > >> >> Od: Marián Kyral 
> > >> >> Komu: talk-cz@openstreetmap.org
> > >> >> Datum: 3. 10. 2015 23:07:26
> > >> >> Předmět: Re: [Talk-cz] Hospoda Praha
> > >> >>
> > >> >>
> > >> >>
> > >> >> Dne 3.10.2015 v 10:09 Jachym Cepicky napsal(a):
> > >> >>
> > >> >> někdy v týdnu od 12.10?
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >> >> Ideálně v úterý 13.10 nebo středu 14.10. To bych měl být na
> > >> >> nějakých 90% v Praze.
> > >> >> Nějaký tip na místo? Já jich v Praze moc neznám.
> > >> >>
> > >> >> Marián
> > >> >>
> > >> >> On Fri, Oct 2, 2015, 12:03 Jiří Sedláček
>  wrote:
> > >> >>
> > >> >> Taky bych přišel, lokalitou se asi přizpůsobím.
> > >> >>
> > >> >> Nicméně, přišel bych asi spíš za Wikimedia ČR a za Wikipedii
> a rád
> > >> >> bych vás osobně pozval na Wikikonferenci (wikikonference.cz).
> > >> >>
> > >> >>
> > >> >>
> > >> >> J.
> > >> >>
> > >> >>
> > >> >>
> > >> >> 2015-10-02 9:32 GMT+02:00 Marián Kyral :
> > >> >>
> > >> >> Takže fajn,
> > >> >> nějaký zájem by byl ;-)
> > >> >>
> > >> >> Nevím jak mi to vyjde příští týden, jedu na školení a ještě
> přesně
> > >> >> nevím, jaký bude program. Ale ten další týden by to mohlo vyjít.
> > >> >> Máte tip na nějaké vhodné místo? Nezakouřená hospoda nebo třeba
> > >> čajovna.
> > >> >>
> > >> >> Marián
> > >> >>
> > >> >> -- Původní zpráva --
> > >> >> Od: Dalibor Jelínek 
> > >> >> Komu: 'OpenStreetMap Czech Republic'  > c...@openstreetmap.org>
> > >> >> Datum: 30. 9. 2015 9:07:29
> > >> >> Předmět: Re: [Talk-cz] Hospoda Praha Was: Hospoda Brno - rijen
> > >> >>
> > >> >>
> > >> >>
> > >> >> Ahoj,
> > >> >>
> > >> >> i ja bych se zucastnil.
> > >> >>
> > >> >> Dalibor
> > >> >>
> > >> >>
> > >> >>
> > >> >> From: Petr Schönmann [mailto:pschonm...@gmail.com]
> > >> >> Sent: Wednesday, September 30, 2015 6:23 AM
> > >> >> To: OpenStreetMap Czech Republic 
> > >> >> Subject: Re: [Talk-cz] Hospoda Praha Was: Hospoda Brno - rijen
> > >> >>
> > 

Re: [Talk-cz] KČT (Re: WeeklyOSM CZ 257)

[Petr Morávek [Xificurk]]

Dne 7.7.2015 v 21:58 Marián Kyral napsal(a):
 Dne 7.7.2015 v 20:46 Petr Vejsada napsal(a):
 Ahoj,

 no a na závěr docela překvapení - ne, není to seznam tras ani SHP, ale pro 
 mě 
 to docela překvapení je: http://trasy.kct.cz (C) Seznam,cz, OpenStreetMap, 
 NASA  KČT.

 
 To zase není až takové překvapení. Seznam přece používá OSM databázi pro
 mapu světa. A i když pro ČR a SK mají vlastní podklady, tak v patičce
 mají pro jistotu uvedeno i OpenStreetMap a Nasa. Prostě aby nemuseli
 zjišťovat, ze kterých podkladů ten daný kousek vygenerovali.
 
 Marián
 

Největší ironií je, že v této aplikaci pro změnu používají jako podklad
mapy od Seznamu. A pokud se v poslední době něco nezměnilo, tak Seznam
si taky udržuje data o turistických trasách sám z podobných důvodů jako
my v OSM.

Petr


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

Re: [Talk-cz] Podivné relace a překryvy landuse=*

[Petr Morávek [Xificurk]]

Dne 19.11.2014 17:18, Martin Švec - OSM napsal(a):
 Dne 19.11.2014 16:29, Petr Vejsada napsal(a):
 Zobecnit to na všechny relace s landuse či na všechny relace si netroufám,
 to by potřebovalo větší průzkum. Není totiž pravda, že všechny tagy z outer
 cesty by se měly přesunout na relaci. Příklad - oplocený les, obora.
 
 Jo, určitě. To jsme probírali už v září, že přesouvat se může jen 
 landuse=forest tag. Další typy
 landuse by se musely prozkoumat.

Ohledně zobecnění na další multipolygony by asi stálo za to se podívat
na kód osm2pgsql, který tohle obstarává. Před rokem jsem se trochu
šťoural v jednom bugu [1], který s tím souvisí - tenkrát jsem docela
načetl kód, co to obstarává. Pokud se něco nezměnilo, tak to není moc
ideální, ale funguje to ve většině případů. Myslím, že pokud by se takto
přetogovalo vše na new-style, tak jedině dobře. Je možné, že občas bude
výsledek ne úplně ideálně správný, ale aspoň bude shodný s tím, jak se
to chová teď, protože většina lidí stejně nejprve importuje OSM data
přes osm2pgsql do postgisu a pak s nima pracuje dál.

S pozdravem,
Petr Morávek aka Xificurk

[1] https://github.com/openstreetmap/osm2pgsql/issues/80


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

Re: [Talk-cz] Podivné relace a překryvy landuse=*

[Petr Morávek [Xificurk]]

Dne 19.11.2014 20:19, Petr Vejsada napsal(a):
 Ahoj,
 
 Dne St 19. listopadu 2014 17:36:53, Petr Morávek [Xificurk] napsal(a):
 
 Ohledně zobecnění na další multipolygony by asi stálo za to se podívat
 na kód osm2pgsql, který tohle obstarává. Před rokem jsem se trochu
 šťoural v jednom bugu [1], který s tím souvisí - tenkrát jsem docela
 načetl kód, co to obstarává. Pokud se něco nezměnilo, tak to není moc
 ideální, ale funguje to ve většině případů. Myslím, že pokud by se takto
 přetogovalo vše na new-style, tak jedině dobře. Je možné, že občas bude
 výsledek ne úplně ideálně správný, ale aspoň bude shodný s tím, jak se
 
 no, když to máš nastudované, tak bych docela uvítal tvůj popis než abych to 
 třeba studoval od začátku.

Ono se mi toho za ten rok už dost z hlavy vypařilo :-) Zkusím se na to
podívat a sepsat nějak srozumitelně algoritmus, který se používá. Ale
neslibuju, kdy se k tomu dostanu... Bohužel jsem teď dost vytížen jinými
záležitostmi.

S pozdravem,
Petr Morávek aka Xificurk


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

Re: [Talk-cz] Ahoj,Re: Nová fíčura - kde chybí natrasovat budovy

[Petr Morávek [Xificurk]]

Dne 31.10.2014 08:44, Petr Vejsada napsal(a):
 Ahoj,
 
 tak je to hotové. Nejhorší bylo přijít na to, jak podvést Postgre, protože 
 jeho query plány jsou někdy opravdu debilní.
 
 Myslím, že požadovat 70% pokrytí je možná pořád moc. Vylezlo z toho opravdu 
 hodně posunutých budov a obávám se, že to přiláká Petra1868 a místo desítek 
 tisíc duplicitních budov jich budou stovky tisíc. ?
 
 Tak mám to takhle nechat nebo ubrat třeba na 60 či 50%?
 
 --
 Petr


Ahoj,

to, že to odchytává i výrazně posunuté budovy (== pravděpodobně chyba),
je dobrá věc, ne? Já bych méně už rozhodně nedával.

Petr


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

[Talk-cz] Značení silnic v Praze

[Petr Morávek [Xificurk]]

Ahoj,

chtěl jsem se zeptat, jestli jsou někde sepsaná pravidla pro tagování
silnic v Praze. A existuje na to nějaký rozumný zdroj, podle kterého by
to šlo ověřit?
Sice nejsem motorista, ale když vidím, jak se za posledních pár týdnů už
asi třikrát přetagoval nový Trojský most a okolí, tak mě začalo zajímat,
jak že to ja správně.

Zdraví,
Petr Morávek aka Xificurk

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

Re: [Talk-cz] Oprava relaci landuse=forest

[Petr Morávek [Xificurk]]

Dne 29.9.2014 14:00, Martin Švec - OSM napsal(a):
 Ahoj,
 
 napadl mě možný zádrhel u inner cest. Jak budou interpretované díry v 
 multipolygonech,
 pokud přesuneme landuse=forest z outer cesty na relaci, ale přitom ten tag 
 necháme na
 inner cestách?
 
 Hledal jsem přes víkend jak renderery apod. řeší old-style + new-style + 
 mixed-style
 multipolygony a tohle je zrovna šedá zóna bez jasných pravidel, co jsem 
 pochopil z diskusí.
 
 Vypadá to, že mapnik tagování v lesní relaci pochopil správně a inner cesta s
 landuse=forest je stále díra. Ale co ostatní konzumenti OSM dat?
 
 Ideální by bylo inner cesty opravit současně s outer cestami... Nebo ty 
 relace vynechat,
 ale tím update ztrácí smysl, otagovaných inner cest jsou mraky.
 
 Máte s tím někdo víc zkušenosti?
 
 Martin

Ahoj,

tohle není moc otázka rendereru, protože opravdu jen výjimečně se kreslí
ze surových OSM dat. Povětšinou se nejprve importují do databáze pomocí
osm2pgsql a ten se snaží podle tagů uhádnout, co tím asi autor myslel a
vytvořit jednotlivé (multi)polygony :-)
Bohužel to opravdu není moc exaktně definované a jediným spolehlivým
zdrojem informací je zdroják... ale něco trochu vyčíst lze i z tohodle
issue: https://github.com/openstreetmap/osm2pgsql/issues/80


Zdraví,
Petr Morávek aka Xificurk

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

Re: [Talk-cz] Kontrola a doplnění ulic

[Petr Morávek [Xificurk]]

Dne 28.8.2014 12:51, Jan Kouba napsal(a):
 Na té ceduli to stejně nejspíš bude všechno velkýma (NA STŘELNICI). Zdá se 
 mi, 
 že všechny cedule s názvy (ulice, města, názvy turistických rozcestníků, ...) 
 se schválně píší pouze velkými písmeny, aby v tom neudělali náhodou chybu, 
 nebo aby se to nemuselo předělávat, když zase provedou nějakou změnu v psaní 
 velkých písmen.

Tohle není vůbec pravda, viz např.:
https://www.dropbox.com/s/j9qpysu5qiss19d/k-visnovce.png?dl=0

Zdraví,
Petr Morávek aka Xificurk

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

Re: [Talk-cz] Kontrola a doplnění ulic

[Petr Morávek [Xificurk]]

Dne 28.8.2014 20:50, Marián Kyral napsal(a):
 Dne 28.8.2014 12:50, Jan Martinec napsal(a):
 
 Nicméně: ten problém s adresami ale je větší: velká a malá písmena bych
 považoval za ne-problém, to funguje při vyhledávání téměř všude (takže bych 
 to
 neřešil a považoval za false positive); ale co se zkratkami? Třeba celý úsek
 podél Mariánských hradeb v Praze: ulice má name=Na Baště svaté Ludmily,
 zatímco adresní body Na Baště sv. Ludmily.

 Tedy dotaz do pléna: má smysl řešit takové (významově rovnocenné) rozdíly?
 (Případně, pokud ne: lze v OSMi něco označit jako fixed: false positive?)

 Honza Piškvor Martinec

 
 Přesně tak. Co vím, je snaha v OSM mít nezkrácené názvy. Existuje
 dokonce skript, který projde seznam ulic a navrhne nezkrácené jméno -
 ul. - ulice, tř. - třída, nám. - náměstím, náb. - nábřeží...
 
 Na cedulích se to většinou zkracuje - cedule je menší a levnější. A pak
 zřejmě záleží na konkrétním úředníkovi, jak to zadá do databáze a
 následně do RUIAN.
 Takže pokud bychom to chtěli udělat dle pravidel OSM - tedy nezkracovat,
 musel by si Petr udělat nějaké mapování - RUIAN ulice - nezkrácená OSM
 ulice. A při aktualizaci k tomu přihlížet.
 
 Marián

Ona by se nějaká ta normalizace názvů asi hodila, protože jak jsem
koukal do RUIAN, tak je tam docela bordel. Jednou jsou jména pokrácena,
jindy ne. Jednou je na začátku velké písmeno, jindy ne. Často se taky
vyskytuje typografický nešvar, že za tečkou není mezera atp. A to
všechno ve všech možných kombinacích.

Petr

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

Re: [Talk-cz] Kontrola a doplnění ulic

[Petr Morávek [Xificurk]]

Dne 28.8.2014 21:23, Petr Vejsada napsal(a):
 Ahoj,
 
 Dne Čt 28. srpna 2014 21:02:34, Jan Dudík napsal(a):
 
 On je hlavní problém s ulicemi pojmenovanými po lidech.
 Dvořákova / A. Dvořáka / Ant. Dvořáka / Antonína Dvořáka - vše je
 de-facto správně.

 příklad z ČB: Rudolfovská / Rudolfovská tř. / rudolfovská třída
 
 myslím, že problém je v tom zkracování/nezkracování. A taky si myslím, že 
 ulice se buď jmenuje Dvořáka nebo Dvořákova a že tyto dvě varianty nejsou 
 zaměnitelné. A. Dvořáka X Antonína Dvořáka je IMO jedno a totéž a tedy 
 zaměnitelné.

Tady bych trochu přibrzdil... Já třeba mám kousek od bydliště ulici S.
K. Neumanna a i kdybych se na hlavu stavěl, tak z paměti ty první dvě
jména nedám. Všichni, co znám, té ulici prostě říkají takhle jak je psána.

Ale úplně jiná situace je s obvyklými zkratkami typu nám., tř..

Pak tu jsou různé tituly před jmény - myslím, že třeba ing. nebo Dr.
je trochu nesmysl rozvinout do plného znění, ale pak tu jsou takové
hraniční případy jako kpt.

A další lahůdkou jsou Čs. legií, Čsl. Legií apod. V Pardubicích je
třeba náměstí Čs. legií - to je tak obludný název, že tomu všichni
místní říkají prostě náměstí Legií :D

--

Pokud se přistoupí k nějaké normalizaci, tak jí to bude chtít pořádně
promyslet. V databázi je cca 1700 rozdílných názvů ulic, které mají v
názvu tečku (spousta toho jsou zkrácená jména, datumy atd.).

Určitě bych zachoval oficiální název přesně jak je v RUIAN v tagu
official_name, do name bych hodil ten normalizovaný, příp. do short_name
standardní pokrácenou verzi. Otázka je, kam s těmito tagy? Osobně si
myslím, že by bylo nejlepší to dát jen na ulici a na adresních bodech
používat jen normalizované jméno a už znovu neopakovat všechny varianty,
ale nevím, jak si s tím poradí různé vyhledávače.

Petr

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

Re: [Talk-cz] Kontrola a doplnění ulic

[Petr Morávek [Xificurk]]

Dne 28.8.2014 23:55, Petr Vozdecký napsal(a):
 Zdravím vespolek,
 
 
 už jsem to chtěl napsat dříve, je to tak jak píše Petr Souček - za
 oficiální název nelze v žádném případě brát nějaké slovní spojení
 odpovídající (jakýmkoliv) pravidlům. Nelze tedy postupovat cestou
 univerzálního skriptu, který sjednotí názvy do správných tvarů.
 Historický vývoj místních názvů i neuvěřitelná lidová tvořivost místních
 zastupitelstev jsou autory mnoha fantaskních názvů, které jsou přes
 svoji originalitu, zmatečnost a jazykovou nesmyslnost skutečnými
 oficiálními názvy. 
 
 
 Univerzální skript bude mít řadu dalších oříšků k řešení. Je jím třeba
 značný výskyt slova ulice v názvech ulic, přičemž mnohde je zjevně
 nesprávně nadbytečný a v rozporu s ofic názvem. 
 
 V Brně (a v celé řadě dalších měst) však lze např. nalézt i z pohledu
 uživatele map překvapivé sousloví ulice Kosmonautů, zatímco třeba
 zastávka MHD je jen Kosmonautů. Zmatečné je to třeba tím, že v papírovém
 rejstříku tuto ulic nenajdete pod K ale pod U. Různé datové zdroje
 pak obsahují mraky ulic s nesprávně uvedeným slovem ulice na začátku
 názvu - jak ale pomocí scriptu automaticky poznat, která ulice je
 správně a která nikoliv...
 
 
 vop

Ahoj,

zrovna těchto obskurních názvů s ulicí na začátku jména v RUIAN moc není:

 ulice Čoupkových| Brno
 ulice Kosmonautů| Brno
 Ulice práce | Ústí nad Labem
 ulice 1. května | Brno
 ul. Města Lwówek Śląski | Chrastava
 UL. SNP | Letohrad
 ul. 5. května   | Klatovy
 ul. 9. května   | Blučina

Problém je hlavně s náměstími, nábřežími a třídami.

Petr

PS: Pořád se nemůžu se rozhodnout, jestli u mě vyhrává cenu za
nejpodivnější název polština v oficiálním názvu, nebo UL. SNP ;-)

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

Re: [Talk-cz] Zahrady u RD jako leisure=garden

[Petr Morávek [Xificurk]]

Dne 26.8.2014 15:55, Václav Řehák napsal(a):
 Pokud použijeme leisure=garden, je potřeba akorát naklikat
 tisícovku nových objektů, kde na pozadí bude velké
 landuse=residential, kterého se ani nedotkneme. Co vám zní méně
 pracně? Pokud jde o rendering, není nic jednoduššího než se na
 renderování leisure=garden vykašlat.
 
 Mě osobně by přišlo nejlepší použít samostatný tag, třeba
 garden=residential. Každopádně to tady nevyřešíme, je to spíš otázka na
 tagging@ 

Ahoj,

ono se tohle v tagging@ dost dlouze před časem rozebíralo. Taky mně
osobně vadila nemožnost odlišit zahrady okolo RD od těch pravých
zahrad okolo zámků, klášterů, botanických zahrad, ... Access tag tohle
bohužel neřeší, protože typicky třeba zahrada okolo kláštera nemusí být
veřejně přístupná.

Závěr poměrně dlouhé diskuze byl, že prostě i trávník za RD je zahrada a
lidi to všude možně po světě tagují jako leisure=garden a nic se s tím
nenadělá.

Bohužel se zatím masově neprosadil žádný dodatečný tag pro odlišení
trávníků okolo RD od těch ostatních zahrad.

Zdraví,
Petr Morávek aka Xificurk


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

Re: [Talk-cz] Zahrady u RD jako leisure=garden

[Petr Morávek [Xificurk]]

Dne 26.8.2014 17:22, Karel Volný napsal(a):
 
 zdar,
 
 ... 
 Závěr poměrně dlouhé diskuze byl, že prostě i trávník za RD je zahrada
 
 že je to zahrada je víceméně ok, ale ...
 
 a lidi to všude možně po světě tagují jako leisure=garden
 
 ... proč se nemůže tagovat garden=něco?
 
 jestli jsi tu diskusi sledoval, mohl bys to prosím nějak stručně shrnout?

Ten hlavní problém je, že jakmile se nějaký tag dostatečně zažije pro
určitý objekt, tak je prakticky nemožné to změnit - je v presetech
editorů, kde jsou na něj lidi zvyklí, renderuje se v mapách... Je možné
snést milion naprosto racionálních argumentů, proč ten tag pro ten
konkrétní případ není úplně to pravé, ale stejně to nic nezmění, lidi
jej prostě budou dál používat (a to není jen případ zahrad okolo RD).
Prostě význam tagů je v OSM primárně definován tím, na co jej lidi
používají.

 ...
 Bohužel se zatím masově neprosadil žádný dodatečný tag pro odlišení
 trávníků okolo RD od těch ostatních zahrad.
 
 ale tož to je tak trošku začarovaný kruh, je snad potřeba s něčím přijít, 
 začít to aplikovat, pak se toho chytnou ostatní, a ne koukat, co se používá, 
 abychom se podle toho řídili, když se zatím nic nepoužívá, a nejbližší 
 aproximace co se dá potkat je pěkná blbost ('Taky mně
 osobně vadila nemožnost odlišit zahrady okolo RD od těch pravých zahrad' 
 ... 
 +1)

Momentálně existují dva aspoň trochu používané způsoby pro odlišení
soukromých zahrad okolo domků - garden:type=residential (původně můj
návrh vzniklý jako reakce na debatu v tagging listu) a
garden=residential (afaik v podobné době vzniklý tag používaný hlavně v
Německu). Podle globálního taginfo jsou oba tagy v databázi řádově na
tisícovkách objektů, vs. sta tisíce objektů s leisure=garden.

Když jsem podobné oblasti se zahrádkami editoval, tak jsem přidával i
garden:type, pokud vás toto odlišení trápí stejně jako mě, tak
doporučuju začít tento tag přidávat. Lepší radu asi teď nemám.

Zdraví,
Petr Morávek aka Xificurk

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

Re: [Talk-cz] taginfo.openstreetmap.cz

[Petr Morávek [Xificurk]]

Dne 22.8.2014 11:52, Michal Grézl napsal(a):
 nejak to spadlo, opravim to

Super, díky za údržbu skvělého nástroje.

Petr


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

[Talk-cz] taginfo.openstreetmap.cz

[Petr Morávek [Xificurk]]

Ahoj,

při nejmenším pár týdnů už nefunguje české taginfo...
Internal Server Error

Nějaké info k tomu? Bude zprovozněno?

Díky,
Petr Morávek aka Xificurk

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

Re: [Talk-cz] Relations - sousední obce (kraje, okresy) z API

[Petr Morávek [Xificurk]]

Dne 18.8.2014 09:09, hanoj napsal(a):
 jak píše xificurk, asi takto:
 
 http://overpass-api.de/api/interpreter?data=(rel[name=okres
 Brno-město][admin_level=7][boundary=administrative];way(r);rel(bw))-.c;(rel.c[admin_level=7][boundary=administrative];way(r);node(w))-.d;.d
 out meta;
 
 výklad syntaxe např. zde:
 http://geoinformatics.fsv.cvut.cz/data/2014/06-12/03-Barta-Geoinformatics-2014.pdf#page=26
 
 ha
 hanoj

Ještě doplním, že záleží, co přesně má být výstupem... uvedený odkaz
stáhne komplet relace a jejich prvky.
Pokud ti stačí jen metadata o obcích/okresech, tak stačí stáhnout jen
relace. Z nich si pak už vytáhneš všechny důležité identifikační údaje a
můžeš se podle nich dotazovat dál třeba právě RUIAN.

Petr Morávek aka Xificurk


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

Re: [Talk-cz] Změna ve vykreslování tramvají na silnici (?)

[Petr Morávek [Xificurk]]

Dne 17.8.2014 18:00, Petr Kadlec napsal(a):
 Zdravím,
 
 včera jsem si všiml „chybějících tramvajových kolejí“ na mapě Prahy a po
 chvilce pátrání mám dojem, jako by se dost zásadně změnilo vykreslování
 standardní vrstvy na OSM, což má za následek prakticky totální rozbití
 tramvajových tratí na mapě.
 
 Pokud se nepletu, odjakživa se tramvaje na silnici kreslily normálně do
 jedné cesty otagované zároveň jako highway=* a railway=tram. [1] Ale teď
 se mi zdá, že se z takové kombinace černá čára reprezentující
 tramvajovou trať vypařila. [2] V Brně jsem si na jednom místě všimnul
 nově zakreslené [3] _druhé_ cesty (se stejným průběhem), přičemž
 highway=* zůstane na jedné cestě a na novou cestu se vydělí
 railway=tram. [4] To, zdá se, způsobí správné vykreslení.
 
 Takže: Změnil se doporučovaný (tedy, jediný funkční) způsob tagování? (A
 cíleně, nebo nějakým omylem ve stylech?) Bylo o tom někde informováno
 (či dokonce diskutováno)? Ví případně Mar4s, který to v Brně
 „opravoval“, o tom něco, nebo jen metodou pokus/omyl našel způsob, jak
 to změnit, aby se to vykreslilo jako dřív? Nebo je všechno jinak?
 
 -- Petr Kadlec / Mormegil
 
 [1] Zcela namátkou: http://www.openstreetmap.org/way/131565891
 [2] Povšimněte si příšerného vzhledu křižovatky
 http://osm.org/go/0J0lH1vtQ, kde zůstaly vidět jen koleje nevedoucí po
 silnici.
 [3] http://www.openstreetmap.org/changeset/24701510
 [4] http://www.openstreetmap.org/way/297357661

Ahoj,

to je nahlášený bug ve vykreslování.

https://github.com/gravitystorm/openstreetmap-carto/issues/874

Zdraví,
Petr Morávek aka Xificurk


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

Re: [Talk-cz] Relations - sousední obce (kraje, okresy) z API

[Petr Morávek [Xificurk]]

Dne 18.8.2014 00:20, Jiří Sedláček napsal(a):
 Dobrý den, ahoj,
 mám poměrně specifický požadavek na API (či případně na jiný zdroj) a
 nevím, jak se správně zeptat API (či třeba RUIANu).
 
 Chtěl bych získat:
 Obce (či okresy, ...) tak, abych zjistil, která další obec (či okres,
 ...) s ní sousedí. 
 
 A to ideálně tak, abych si mohl vybrat obce jen z daného okresu (a to je
 pro mě největší problém a nijak jsem nedokázal donutit API, aby mi
 vrátila jen data z daného okresu dle ref nebo id relace).
 
 Pokud bych získal data dle BBOXU, tak je to sice hezký, ale nebude to
 ono - nicméně, i pak mi asi nezbyde nic jiného, než projít jednotlivý
 relace a jejich ways a dle toho, že ways jsou ve více relacích poznat,
 že spolu ty dané obce sousedí. Nebo to jde i jinak?
 
 Díky za radu či nakopnutí.
 
 J.
 
 -- 
 S pozdravem,
 Jirka Sedláček
 ---
 jirisedla...@gmail.com mailto:jirisedla...@gmail.com

Ahoj,
tohle by mělo být řešitelné pomocí Overpass API. Zkonstruování
konkrétního dotazu už nechám na tobě, ale postup by měl být zhruba takovýto:

1) Podle jména, id, nebo čehokoliv jiného najít relaci obce (okresu, ...)
2) Najít všechny cesty, které relace odkazuje.
3) Najít všechny relace, ve kterých jsou tyto cesty a vyfiltrovat je
pomocí požadovaného admin_level.
4) Příp. stáhnout všechny cesty/uzly, které jsou součástí těchto relací.


Zdraví,
Petr Morávek aka Xificurk


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

Re: [Talk-cz] RUIAN a inkrementální aktualizace

[Petr Morávek [Xificurk]]

Dne 10.8.2014 21:49, Petr Vejsada napsal(a):
 Mám schema, vzniklé z dat ke dni 30.4. plus aktualizace. Od začátku těch 
 aktualizací tam mám ten patch, co ignoruje čísla transakcí, tedy *ignoruje*, 
 není tam =, jak je asi v poslední -dev, viz debata na Githubu. To jen pro 
 pořádek. Ač není pravděpodobné, že by se čísla transakcí někdy 
 dekrementovala, 
 vyloučit to asi nemůžeme!
 
 * SO 78153263 je v červencovém dumpu (20140731_OB_554791_UKSH.xml.gz),
 ale není v dumpu z června ani žádném změnovém souboru.
 
 select deleted,id_trans_ruian,definicni_bod is not NULL as 
 definicni_bod,hranice 
 is not NULL as hranice,plati_od,item_timestamp from ruian.rn_stavebni_objekt 
 where kod=78153263;
 
  deleted | id_trans_ruian | definicni_bod | hranice |  plati_od  |   
 item_timestamp
 -++---+-++
  f   | 627026 | t | f   | 20.06.2014 | 22.06.2014 
 11:38:58.947812
 
 je tedy ve změnovém souboru z průběhu června. Nahráno 22.6., takže asi soubor 
 z 21.6., ale nevím jistě. Nenahrávám každý den, jen skoro každý den.
 
 V dumpu z června by ovšem být měl.

Tak tohle mě vážně nenapadlo... dohledal jsem to ve změnovém souboru z
20.6. a obsah do puntíku sedí s tím, co je v červencovém dumpu. Ale v
červnu fakt nebyl.

Takže chyby jsou vážně v obojím, což opravdu není dobré :/

Petr

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

[Talk-cz] RUIAN a inkrementální aktualizace

[Petr Morávek [Xificurk]]

Ahoj,

mám nemilou zprávu pro vás, co pracujete s RUIAN (přes ruian2pgsql) a
provádíte inkrementální aktualizace - nefunguje to.

Petr Vejsada tu už na jaře psal, že má podezření, že nový import úplného
dumpu RUIAN dává jiný výsledek než postupně aktualizovaná databáze přes
změnové soubory. A já to bohužel teď musím potvrdit. A je to trochu
komplikovanější.

První problém byl v ruian2pgsql [1]. Původní algoritmus počítal s tím,
že pokud dojde k nějaké změně objektu, tak se vždy zvýší id transakce,
což bohužel není pravda. Tento problém byl nedávno opraven... pokud
používáte ruian2pgsql a importujete změnové soubory, tak silně
doporučuju update na poslední dev verzi.

Jenže i tak byly indikace, že není vše úplně v pořádku - a opravdu není.
Mám tu dvě databáze:
1) Vznikla importem posledního úplného dump z konce července, konkrétně
soubory 20140731_OB_*_UKSH.xml.gz a 20140731_ST_UKSH.xml.gz.
2) Vznikla importem úplného dumpu z konce června a pak importem všech
změnových souborů z července, tj. soubory 20140630_OB_*_UKSH.xml.gz a
20140630_ST_UKSH.xml.gz a pak 26 souborů 201407*_ST_ZKSH.xml.gz.

A když porovnám výsledek obou cest, tak se dá najít opravdu velké
množství rozdílů. Konkrétně jsem se díval na stavební objekty. Některé
SO jsou jen v (1), některé jen v (2), jiné jsou sice v obou databázích,
ale jedna verze má neúplné údaje. Problematické SO jsem vystopoval do
zdrojových dat a chyba je už tam.

* SO 78153263 je v červencovém dumpu (20140731_OB_554791_UKSH.xml.gz),
ale není v dumpu z června ani žádném změnovém souboru.

* SO 78258294 je v červencovém dumpu (20140731_OB_576000_UKSH.xml.gz) -
tam má IdTransakce=648617 a IsknBudovaId=15680609010. V červnovém dumpu
není, ale je v jednom jediném změnovém souboru
(20140728_ST_ZKSH.xml.gz), ale tam nemá nastaveno IsknBudovaId a
IdTransakce=648063.

...

Na ostatní tabulky jsem nekoukal, ale je dost možné, že trpí podobným
problémem.

--

Informaci píšu primárně sem do talk-cz, protože to tu sledují jak
konzumenti dat, tak i zástupci ČÚZK. Chtěl bych poprosit pana Součka,
jestli by mě (nás) nasměroval, kam/jak/jestli tento problém reportovat,
případně jaké další detaily by bylo vhodné dodat.

--

Zdraví,
Petr Morávek aka Xificurk

[1] https://github.com/fordfrog/ruian2pgsql/issues/24

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

Re: [Talk-cz] Nominatim a české adresy

[Petr Morávek [Xificurk]]

Dne 28.5.2014 16:09, Matěj Cepl napsal(a):
 On 2014-05-27, 21:13 GMT, Petr Souček wrote:
 A dále je členěna na několik prvků:
 - na 57 městských částí 
   
 http://vdp.cuzk.cz/vdp/ruian/mestskecasti/vyhledej?ob.kod=554782search=Vyhledat
 - na 22 správních obvodů Prahy 
   http://vdp.cuzk.cz/vdp/ruian/spravniobvody/vyhledej?search=Vyhledat
 - na 10 městských obvodů Prahy 
   http://vdp.cuzk.cz/vdp/ruian/mestskeobvody/vyhledej?search=Vyhledat
 - na 112 katastrálních území 
   
 http://vdp.cuzk.cz/vdp/ruian/katastralniuzemi/vyhledej?ob.kod=554782search=Vyhledat
  
   (v rámci katastrálních území jsou v Praze číslovány stavební 
   objekty, takže se někde můžete setkat s tím, že v Praze je 
   také 112 částí obce)
 
 No právě a myslím, že by asi bylo dobré rozhodnout co z toho 
 bude obec pro účely OSM. Teď tam máme Prahu jako jednu obec což 
 mi připadne (z důvodů, které jsou snad jasné z tohoto threadu) 
 špatně. Nechtělo by to nahradit toto členění něčím jiným? Čím?
 
 Já bych hlasoval pro Prahu 1-10 (nebo 1-22), ale chtěl bych se 
 o tom spíše pobavit (a kdyby někdo navrhnul jak změnit OSM data 
 tak, aby Nominatim chápal obce jako co se dohodneme).
 
 Hezký den,
 
 Matěj

Tohle raději ne.
Vzhledem k adresám mi přijde jako nejlepší naimportovat městské obvody
Prahy jako relace hranic s admin_level=9. Jen pro úplnost uvádím, že
admin_level=8 je u nás všude hranice obcí a admin_level=10 hranice
katastrálních území (které jsou v Praze zároveň de facto částmi obce).

Správní obvody Prahy, městské části Prahy a ostatních statutárních měst
bych naopak zatím do OSM asi netahal.

Petr Morávek


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

Re: [Talk-cz] Nominatim a české adresy

[Petr Morávek [Xificurk]]

Dne 26.5.2014 19:44, Petr Souček napsal(a):
 Dobrý den,
 
 možná bude můj dotaz OOT, ale z jakého důvodu neimportujete v OSM tyto údaje 
 (Praha 3)? Chápu městské části (v členěných statutárních městech), protože ty 
 se do adresy nezapisují. Ale v Praze se do adresy vypisuje Městský obvod 
 Prahy 
 (http://vdp.cuzk.cz/vdp/ruian/mestskeobvody/vyhledej?mp.nazev=mp.kod=mpg.sort=NAZEVsearch=Vyhledat),
  tj. právě ta níže zmiňovaná Praha 3. 
 
 Adresa dle vyhlášky č. 359/2011 by se měla pro adresní místo Květná 43, 
 Praha 3  http://vdp.cuzk.cz/vdp/ruian/adresnimista/21764409 vypisovat takto:
 
 Květná 2097/43
 Vinohrady
 13000 Praha 3
 
 Petr Souček

Dobrý den,

předně velice děkujeme za odkaz na konkrétní vyhlášku - konečně tedy
víme přesně, které členění Prahy se v adrese má používat (městské obvody
Praha 1-10).

(Zatím) se tyto data neimportují především proto, že nebylo příliš
jasné, jaké členění a kde všude by se mělo do OSM importovat - jen
Praha, nebo všechna statutární města; v Praze použít městské části (54),
správní obvody (22), nebo městské obvody (10).

Osobně jsem se (zjevně mylně) domníval, že číslo městského obvodu do
adresy nepatří. Dokonce i formulář pro ověření adresy [1] obsahuje jen
políčko Obec, nikoliv Městský obvod, takže je potřeba zadat jen
Praha bez čísla, v opačném případě sice vyhledávání zafunguje, ale
objeví se upozornění:
 Nebyla nalezena adresa přesně odpovídající zadání, systém se pokusil nalézt 
 adresy přibližně splňující požadavek.


Zdraví,
Petr Morávek

[1] http://vdp.cuzk.cz/vdp/ruian/overeniadresy/vyhledej

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

Re: [Talk-cz] Geoinformatics FCE CTU 2014

[Petr Morávek [Xificurk]]

Dne 18.5.2014 19:40, Marián Kyral napsal(a):
 Myslím, že bychom mohli opravdu pozvat lidi z ČUZK a probrat to hlášení chyb
 přímo z oka do oka.

 Přišel by někdo, koho kdo by se rád o tom pobavil za OSM?
 
 Pokud nezůstanu sám ;-)

Taky bych alespoň na nějakou část dorazil... už jen proto, abych konečně
ke jménům přiřadil nějaké obličeje :-)

Petr Morávek aka Xificurk


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

Re: [Talk-cz] Aktualizace RUIAN

[Petr Morávek [Xificurk]]

Dne 2.5.2014 14:59, Petr Vejsada napsal(a):
 Zrovna jsem ti psal do mailu - pointinfo by mělo fungovat, ovšem jen na 
 místech,
 kde už jsou data nahraná. Nahrávám od rána znovu, jsem v necelé půlce. Myslím,
 že do půlnoci by mělo vše být. V Praze je vadný polygon, čeká mě ruční editace
 řádku dlouhého 888 MB :-\. Nechápu, jak může být v datech z ČÚZK vadný 
 polygon.

Nevím, co se změnilo, ale poslední cca 3 měsíce se to stává nepříjemně
často. Dřív jsem na tenhle problém nenarážel.

Petr Morávek aka Xificurk

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

Re: [Talk-cz] Aktualizace RUIAN

[Petr Morávek [Xificurk]]

Dne 2.5.2014 15:19, Marián Kyral napsal(a):
 Ad XML)
 Co takhle si jej přeformátovat? Třeba pomocí XMLStarlet (
 http://xmlstar.sourceforge.net )
 
 Marián

Na to stačí i libxml2:
xmllint --format file.xml

Ale ty soubory jsou pořád (celkově) dost velké, obzvláště v Praze :/

Petr

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

Re: [Talk-cz] Lokální Taginfo

[Petr Morávek [Xificurk]]

Dne 21.2.2014 11:34, Michal Grézl napsal(a):
 - zdroj dat je pbf z http://osm.kyblsoft.cz/archiv/
 - cetnost aktualizace by mohl byt klidne denni, podle me staci tyden

Ahoj,

jak to prosím vypadá s tou aktualizací? Web stále ukazuje:
Data from: 2014-02-13 21:49 UTC

Zdraví,
Petr Morávek aka Xificurk

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

Re: [Talk-cz] Průběh importu adres

[Petr Morávek [Xificurk]]

Dne 7.4.2014 11:49, Zdeněk Pražák napsal(a):
 Dobře pochopil jsem,
 
 Pokud se týká výběru oblasti k importu nešlo by zasílat pouze například
 data osm po jednotlivých obcích okresu ze stránky
 http://ruian.poloha.net/czaddr/
 Pražák

Ahoj,

myslím, že by bylo super, kdyby se povedlo to vyžádání zautomatizovat -
Petře, nechceš ještě k tomu seznamu přidat jeden sloupeček s ikonkou na
vygenerování a stáhnutí souboru ke kontrole, nebo to generování trvá
příliš dlouho, aby to bylo takto automaticky on-demand?

Petr Morávek aka Xificurk


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

Re: [Talk-cz] český addr:housenumber

[Petr Morávek [Xificurk]]

Dne 18.3.2014 19:04, Pavel Machek napsal(a):
 Ahoj!
 
 to ale aso nebude uplne bezny pripad, ne?
 Nemas nejaky priklad?
 
 Jak rikam, me uz se to hodilo. Hledal jsem neco na sidlisti, a tam ty
 ulice nejsou tak uplne jednoznacny.
 
 Predpokladam, ze na rohu stoji jeden dum, protoze
 dva by se na roh asi jen tezko vesly, i kdyz je to teoreticky
 mozne. Navic by musely mit stejne cislo orientacni, coz
 je jeste mene pravdepodobne.
 
 http://www.openstreetmap.org/#map=18/50.10762/14.48524
 
 Kdepak je Podvinny Mlyn 17? Nebo je to Kovanecka 17? 2308/17 uz
 mi dava slusnou jistotu, ze jsem nasel spravny misto...
   Pavel

Ahoj,

v tomhle musím dát Pavlovi zapravdu...
Dalším problémem (a řekl bych mnohem častějším) je kolize čísel
popisných a orientačních v jedné ulici.

Schválně, kdo z vás najde např. Petra Jilemnického 85, Hradec Králové?

A s hledáním přímo na místě to nebude o moc lepší - kdo z vás ví bez
googlení, jakou barvu má správně mít které číslo?
A vážně si nedělám iluze o tom, že všechny domy jsou podle této konvence
správně označeny.


Já vím, že to není to, co Jakub chce slyšet, ale... Argumentovat tím,
jak se něco (ne)vykresluje na mapě na openstreetmap.org vážně nemá
smysl. Tahle mapa nikdy nebyla nějakým kartografickým skvostem. Je to
primárně demo toho, co všechno lze nalézt v OSM datech, a tak je to
šílený slepenec všeho možného.

Těžko lze očekávat, že všechno půjde otagovat a vykreslit na mapě
univerzálně stejně na celém světě. Koneckonců i ty papírové mapy jsou v
každém regionu trochu jiné, tak aby lépe postihly místní specifika.


Zdraví,
Petr Morávek aka Xificurk

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

Re: [Talk-cz] Adresy

[Petr Morávek [Xificurk]]

Dne 15.3.2014 13:26, Dalibor Jelínek napsal(a):
 Sekeru nemam, ale navrhuju:
 
 - zapomenouta ma muj napad s borough a nechat suburb
 
 - vypustit a mazat CZ a is_in
 
 - kdyz to snese komunita a teoreticky stvrdi Xificurk,
 tak doplnit do OSM vsechny hranice, co jsou v RUIAN
 a tedy vynechat suburb i city
 
 - vynechat source:addr 
 
 Zdravi,
 Dalibor


Hehe, koukám, že jsem se nějak neplánovaně stal autoritou na admin.
hranice :-)

Radši to zkusím vzít popořadě celé... Ale rovnou říkám, že systém dělení
ČR je dost komplikovaný a na dost věcí sám nemám vyhraněný názor a
nevím, jestli nějaký takový vůbec objektivně může existovat.

Radši při čtení po očku koukejte na schema z
http://www.czso.cz/csu/rso.nsf/i/soustava_prvku

Vyšší územní celky jsou celkem jasné a máme je v OSM jako relace hranic:
* ČR (NUTS0/NUTS1, admin_level=2)
* region soudržnosti/oblast (NUTS2, admin_level=4)
* kraj (NUTS3, admin_level=6)
* okres (LAU1, admin_level=7)
* obec (LAU2, admin_level=8)

Z dat RUIAN by se ještě mohly hodit hranice obce s rozšířenou působností
a obce s pověřeným obecním úřadem.
Problém je, že tyhle dvě úrovně nahrazují okresy (které dnes v podstatě
neexistují), tj. správně by hierarchie měla být:
kraj  ORP  POU  obec
Tím pádem by se musel dost překopat současný systém hranic v OSM a
osobně si nemyslím, že to stojí za to. ORP nebo POU člověka zajímá jen v
případě, že se shání po tom, kam si má jet vyzvednout např. občanku;
oproti tomu okresy se celkem běžně používají pro přibližné určení polohy
(mrkněte na mapy.cz, idos, ), a tak mi přijdou daleko užitečnější.

--

Jsme tedy na úrovni obce a tady se věci začínají komplikovat - existuje
totiž několik paralelních způsobů dělení.

1) Osa územního členění (tj. to, které má jasně dané hranice) pokračuje
katastrálním územím, to máme jako relaci hranic s admin_level=10.
Tohle dělení je z hlediska adres irelevantní.

2) Všechny obce se dále dělí na 1 nebo více částí obce a ty nemají jasně
definované hranice.
Na venkově jsou části obce většinou to, čemu všichni říkáme vesnice -
zástavba s vlastním jménem. Ve městech se používají většinou jako názvy
čtvrtí (třeba Vinohrady).
Důležité: je zaručeno, že č.p. jsou unikátní v rámci jedné části obce
(nikoliv v rámci jedné obce, kat. území, městské části, nebo ulice!).
Jméno části obce by mělo být na všech adresních bodech jako addr:place,
jelikož polygony neexistují, tak tohle je asi jediný rozumný způsob, jak
tuto informaci do OSM dostat.
Pojmenování ulic na tomto podle mě nic nemění - schválně si zkuste
položit otázku, jak by se měla promítnout do OSM situace, kdy obec nově
zavede pojmenované ulice? Doplníme ulice na adresní body a cesty a dál?
Měl by se smazat addr:place, nebo jeho obsah přesunout do jiného tagu?
Proč? Ta část obce pořád existuje a i nadále by měly fungovat adresy ve
starém tvaru (jen už to nebude ten preferovaný).

3) Městské části/obvody existují jen ve větších městech a jen v
některých. Mrkněte radši na [1]. Problém je, že tohle dělení je v
podstatě, co město, to unikát:
- někde hranice MČ/MO odpovídají katastrálním území, někde ne
- někde MČ/MO pokrývají celé území města, někde ne
- někde mají smysluplné názvy, někde jsou to jen očíslované části
Řekl bych, že tohle do adresy nepatří, např. v Praze se sice často píše
na obálku něco jako Praha 8, ale to je podle mě na 99% název adresní
pošty, ne název MČ/MO, a stejně dobře by mělo posloužit i prosté Praha
v kombinaci s PSČ.
*Já osobně* tohle dělení nijak v OSM nepostrádám, jeho užitečnost vidím
asi tak na úrovni ORP a POU. (Já jsem měl potřebu zjistit, v jaké
městské části bydlím až ve svých 27 letech, když jsem potřeboval vyřídit
voličský průkaz :-))
Pokud to chceme do OSM přidat, tak by bylo lepší jako nějaké polygony,
než na adresní body. admin_level=9 je sice volný, ale nevím, jestli je
to ta správná volba kvůli výše zmíněným vlastnostem (ne vždy pokrývají
celé území obce a většinou nefunguje skladebnost obec  MČ/MO  k.ú.).
Praha má krom městských částí (57) ještě navíc správní obvody (22) a
městské obvody (10) - a tohle je už totální chaos, protože lehce
vznikají nedorozumění - o čem se vlastně mluví, když se řekne Praha 8?

4) Jméno ulice je unikátní v rámci jedné obce a v rámci jedné ulice by
měla být unikátní čísla orientační.

--

Úplně bokem pak stojí PSČ - domy z různých obcí můžou mít stejné PSČ, a
naopak různé domy dokonce i v jedné části obce můžou mít PSČ různé.
Vzhledem k tomu, že nemáme polygony (ale někde se asi dají sehnat -
třeba google je v mapách zobrazuje), tak jediným řešením je dávat PSČ
přímo na adresní body.

Jméno adresní pošty - to je specifikum České pošty - by mělo odpovídat
PSČ. Tenhle seznam v RUIAN nemáme, ale asi by šel vytáhnout odjinud.
Myslím si, že tohle na adresní body, nebo polygony nepatří, ale mělo by
se dávat jako name tag na POI dané pošty.
POZOR: Jméno pošty nemusí odpovídat názvu žádné administrativní jednotky
(mrkněte třeba do Prahy).

--

Pro adresní body jsou tedy nepostradatelná domovní čísla 

Re: [Talk-cz] Adresy

[Petr Morávek [Xificurk]]

Tak ještě jedna drobná oprava...

Dne 16.3.2014 19:23, Petr Morávek [Xificurk] napsal(a):
 Řekl bych, že tohle do adresy nepatří, např. v Praze se sice často píše
 na obálku něco jako Praha 8, ale to je podle mě na 99% název adresní
 pošty, ne název MČ/MO, a stejně dobře by mělo posloužit i prosté Praha
 v kombinaci s PSČ.

Koukám, že zrovna Praha je opravdu speciální případ, protože na webu
CUZK to v Adresa pro poštovní styk nějaké číslo za Praha zobrazuje:
http://vdp.cuzk.cz/vdp/ruian/adresnimista/22393439
Ale kdo ví, kde ho bere?

Název adresní pošty to NENÍ:
http://goo.gl/7S36rY
A přitom do tohoto formuláře pro ověření adresy to chce jenom Praha
bez čísla.

Co jsem se díval na pár míst v Pardubicích, Ostravě a Brně, tak tam nic
podobného není.

Petr

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

Re: [Talk-cz] Adresy

[Petr Morávek [Xificurk]]

Dne 16.3.2014 21:34, Petr Vejsada napsal(a):
 3) Městské části/obvody existují jen ve větších městech a jen v
 některých. Mrkněte radši na [1]. Problém je, že tohle dělení je v
 podstatě, co město, to unikát:
 
 [...]
 
 Není to *nezbytně* nutné a je otázkou, zda na městské části vyplýtvat 
 admin_level 9 nebo si ho nechat třeba ba ZSJ. Fakt nevím, jestli polygony 
 nebo 
 addr:suburb. Statistika - addr:suburb se týká asi 10% adresních míst.

ZSJ jsou v hierarchii daleko níže než všechny zde probírané
administrativní celky (viz odkazované schéma), tedy admin_level=9 určitě ne.

 Řekl bych, že tohle do adresy nepatří, např. v Praze se sice často píše
 na obálku něco jako Praha 8, ale to je podle mě na 99% název adresní
 pošty, ne název MČ/MO, a stejně dobře by mělo posloužit i prosté Praha
 v kombinaci s PSČ.
 
 Praha 81 - pošta Bohnice, Praha 86 - pošta Karlín. atd. Jestli existuje pošta 
 Praha 8 fakt nevím. Ještě je to komplikované tím, že ačkoli pošt může být v 
 obvodu/městské části více, ne všechny tyto pošty musí být vždy doručovací. 
 Například v té Praze 8 ty mé příklady, to jsou doručovací pošty. Naproti tomu 
 v Praze 3 je sice také více pošt, ale doručovací je jen jedna a proto na 
 Prahu 
 3 se píše pouze 130 00, nikoli 131 00, ačkoli pošta Praha 31 existuje, ale 
 není doručovací - prostě se tam nevozí dopisy. Slouží jen jako podací pošta. 
 Teď vynechávám speciální PSČ pro velké firmy, kdy třeba velký kancelářský 
 barák 
 má svoje vlastní PSČ.

Jo, ohledně Prahy jsem se už opravoval, to je vážně speciální případ.

...hm, a teď koukám, že Česká pošta má asi nový web.

Nejsem si jistý, jestli oba myslíme to samé - starý web pošty používal
adresní pošta (ta, která odpovídá PSČ z adresy), teď pro to samé asi
používají doručovací pošta.

Něco podobného, jako píšeš, znám z Pardubic. Velká část města (včetně
mě) a některé okolní obce mají PSČ 530 02 (Pardubice II). Ale přitom já
chodím vyzvedávat balíky, doporučená psaní, atd. na poštu Pardubice V
(530 05), to by asi podle nového webu pošty měla být ukládací pošta.
Ale tohle PSČ zas žádné adresní místo nemá.

(A nejvtipnější na tom je, že na současném webu ČP je to uvedeno špatně)

 V RUIAN je ještě jedna celkem zajímavá tabulka - základní sídelní
 jednotky. To je v podstatě to nejjemnější dělení, které nese nějakou
 
 Pokud něco nepřehlížím, tak neexistuje vazba na budovy či adresní body.? 
 Vazba 
 je jen prostorová. A zkoušel někdo self-join a st_contains ? Abychom se ještě 
 nedivili ;-. Všechno je možné. Mám na mysli překrývající se území.

Nepřehlížíš... viz níže.

 zajímavou informaci (název). Tyhle body a jejich názvy jsou dobrými
 adepty pro place=* body v OSM. Mám už delší dobu rozpracovaný projekt,
 pro porovnání informací v OSM a RUIAN a jejich crowd-sourcové
 doplnění/aktualizaci, ale času se nějak nedostává a stále to není v
 publikovatelné podobě.
 
 A není to spíš adept na polygony, když není v tabulkách vazba na AM ani SO 
 (ani parcelu) ?

Házet to do OSM jako polygony mi přijde jako overkill. Měly by stačit
body s rozumným tagem place. Ne všechny ZSJ je vhodné importovat do OSM
- občas má vlastní ZSJ průmyslová zóna, nákupní centrum, park nebo
náměstí... ten odpad je celkem velký.
Tohle bohužel musí většinou rozseknout někdo s místní znalostí, ale
aspoň tu je zdroj názvů (s polohou), proti kterému se dá pustit
porovnávací algoritmus.

Zdraví,
Petr Morávek aka Xificurk

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

Re: [Talk-cz] [Tagging] [osm_sk] Re: Aktualizace: Tags for Czech/Slovak address system

[Petr Morávek [Xificurk]]

Ahoj,

mixování jazyků nechám stranou. Z toho, co píšeš, to vypadá, že máš
mezery ve znalosti používaných pojmů.

Pro ČR jsou popsané tu:
http://www.czso.cz/csu/rso.nsf/i/soustava_prvku

Ještě jsem v rychlosti kouknul na Wikipedii, jak moc se liší názvosloví
u nás a u vás.
Část obce by měla být v obou státech více méně to samé.
http://sk.wikipedia.org/wiki/%C4%8Cas%C5%A5_obce
Na městské části se v ČR dělí jen několik měst a nejvíce se podobají
městským částem v Bratislavě a Košicích. Městské části v ČR nejsou
shodným pojmem s částí obce, a nejsou tomuto pojmu ani nadřazené, ani
podřízené.

Zdraví,
Petr Morávek aka Xificurk


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

Re: [Talk-cz] CzechAddress import RUIAN

[Petr Morávek [Xificurk]]

Dne 3.3.2014 08:31, Dalibor Jelínek napsal(a):
 Ahoj,
 tak ted prekladam na wiki http://wiki.openstreetmap.org/wiki/Cs:Key:place
 (Mimochodem bych byl rad, kdybyste si to precetli a napsali mi, jestli tam 
 nemam nejakou botu)

Trochu se k tomu vztahuje z části již zastaralá stránka importu míst z
ÚIR-ZSJ: http://wiki.openstreetmap.org/wiki/Import_UIR-ZSJ
Ten import vznikal v době, kdy se ještě vedly žhavé debat, jestli mají
smysl hodnoty place=neighbourhood, quarter atp. (a přiznám se, že
borough vidím teď poprvé)

place=neighbourhood (jakožto nejmenší pojmenovaná entita), by mělo v
řeči RUIAN většinou odpovídat Základní sídelní jednotce (ZSJ).

 a vyplynulo mi z toho, ze bychom asi meli pouzit pro mestkou cast/obvod
 misto navrzeneho (a imports@ zavrhovaneho) addr:suburb radsi
 addr:borough

Tenhle název je asi lepší, ale má jeden zásadní problém - nikdo to
nepoužívá. Celosvětové taginfo:
addr:suburb 429 tisíc objektů
addr:borough slovy šest bodů :-)

a zdá se, že se to moc neujalo ani jako hodnota place:
suburb 76 tisíc
borough 1 tisíc


 Podle popisu na wiki:
 depending on the country suburbs in larger cities are often grouped into 
 administrative units called boroughs or city districts;
 using the value borough avoids name confusion in countries that declare 
 districts within their states or counties.
 
 A prijde mi to i lepsi, protoze suburb, si myslim, je hlavne predmesti,
 kdezto tohle je i podle slovniku samospravna mestska cast.
 
 Co vy na to?
 
 Zdravi,
  Dalibor


Petr

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

Re: [Talk-cz] CzechAddress import RUIAN

[Petr Morávek [Xificurk]]

Dne 27.2.2014 09:29, Dalibor Jelínek napsal(a):
 Ahoj,
 OK, ale podle slovniku mi to vychazi, ze distrit je zaroven okres i mestska 
 cast.

Ano, význam district je poměrně široký, ale v ČR se používá pro okresy
[1] a začít tak označovat městské části vážně není dobrý nápad.


 A zrovna ten suburb je podle slovniku fakt premesti, i kdyz chapu, ze se 
 uz v OSM pouziva jinak, ale proc vrsit chyby?

suburb má taky poměrně široký význam a v OSM se tento pojem usadil v
podobě australského významu, což samozřejmě nevoní puristým
prosazujícím čistě britskou angličtinu. S používáním suburb v
australském významu můžeme nesouhlasit, můžeme proti tomu protestovat,
ale to je tak vše, co s tím můžeme dělat ;-)


 Ale neni Praha 9 vlastne neco jako okres?

A teď myslíš, kterou Prahu 9? Městský obvod, městskou část, nebo ještě
jiný celek? :D
Prahu bych do téhle diskuze radši netahal, to je unikátní případ.

 Jinymi slovy, pokud pouzijeme distict pro okres i pro mestkou cast velkeho 
 mesta,
 bude to necemu vadit?
 
 Dalibor


Petr

[1] http://en.wikipedia.org/wiki/District
[2] http://en.wikipedia.org/wiki/Suburb#Australia

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

Re: [Talk-cz] CzechAddress import RUIAN

[Petr Morávek [Xificurk]]

Dne 27.2.2014 11:52, Dalibor Jelínek napsal(a):
 A co teda addr:municipality?

To by zas odpovídalo našemu pojmu obce.

 Nebo mam proste trvat na addr:suburb?

Sice osobně nejsem přesvědčen, že je tento údaj na adresních bodech
potřeba, ale pokud by se měl někam dávat, tak právě do addr:suburb.

 A pro co presne pouzivame place:suburb v terminech RUIAN?

place=suburb se používalo pro části obce, které jsou uvnitř města.
Tedy např. vztah Vinohrady v Praze, Zelené Předměstí v Pardubicích, ...

 A chapu sprave, ze ta Praha 9 ani Plzeň 2-Slovany nejsou ani NUTS ani LAU?

Ano, spravně, členění na městské obvody/městské části má jen několik
měst a je to paralelní způsob k rozdělení jak územnímu (obec -
katastrální území), tak k běžnému správnímu (obec - část obce), viz [1]


Petr

[1] http://www.czso.cz/csu/rso.nsf/i/soustava_prvku

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

Re: [Talk-cz] CzechAddress import RUIAN

[Petr Morávek [Xificurk]]

Dne 27.2.2014 07:18, Dalibor Jelínek napsal(a):
 Ahoj,
 
 zacal jsem vykomunikovavat import adres z RUIAN na
 impo...@openstreetmap.org mailto:impo...@openstreetmap.org
 
 Je to trochu vice byrokracie, nez jsem cekal, ale zase se neco naucim.
 
  
 
 Nejvaznejsi pripominka (krome pochybnosti nad addr:country, ktere ovsem
 
 byly trochu podivne) byla k addr:suburb
 
  
 
 addr:suburb is a larger administrative division of a city, it contains
 
 several city quaters and it is used very often in reffering to a
 
 general directions in a city.
 
I don't think suburb makes sense, because that's not the term that's
 used in English. We have regions, or districts, or subdivisions, but
 suburb has a very specific meaning in English, which is not this.
 
  
 
 Tak bychom pouzily addr:district
 
 do tohoto klíče se dává městská část, větší než ctvrť, třeba
 
 /Praha 9/ nebo /Plzeň 2-Slovany/
 
  
 
 Myslíte, že to je OK?
 
  
 
 Zdraví,
 
 Dalibor


Ahoj,

už to psal Marián - districts rozhodně ne, to jsou okresy.

Jejich připomínka k suburb je sice platná, ale naše použití je
konzistentní s tím, jak se tento pojem v OSM používá (např. v
place=subrub). Už by se konečně lidi mohli smířit s tím, že termín
suburb v OSM znamená něco trošičku jiného než v prosté angličtině :P

Petr


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

Re: [Talk-cz] castle_type

[Petr Morávek [Xificurk]]

Dne 24.2.2014 14:19, Dalibor Jelínek napsal(a):
 To je trochu argument stranou, ne?
 Forest je proste les. Neni potreba landuse:cs=les. To nic noveho neprinasi.
 
 Jenze castle_type neumi rozlisit tvrz od hradu
 a zamek od vodniho zamku, pro slovaky nema kastiel, coz jsou terminy, ktere
 se bezne pouzivaji.
 A kdyz zamitli tagy jako castle_type=schloss, protoze to chteji mit
 anglicky,
 i kdyz pro to nemaj slova, tak jak se to ma udelat jinak,
 nez udelat vlastni lokalizovany castle_type:de nebo castle_type:cs?

Když se podívám na seznam možností na této stránce:
http://wiki.openstreetmap.org/wiki/Key:castle_type:de
tak každý řádek v tabulce (kromě castle_type:de=burg;schloss) má
jednoznačný způsob mezinárodního tagování.

Petr

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

Re: [Talk-cz] Adresy z RUIAN, 3. rekapitulace + ukázka

[Petr Morávek [Xificurk]]

Ahoj,

Dne 18.2.2014 21:48, Petr Vejsada napsal(a):
 Přidávat, nahrazovat:
 addr:country=CZ

Tohle bych vážně ještě zvážil - zatím taky nezazněl případ, kdy je ten
tag potřeba. Jak jsem psal - osobně bych preferoval nemazat, nepřidávat.
Pokud se ukáže, že to někde bezpodmínečně potřeba je, tak nebude problém
provést hromadné doplnění.

Je potřeba si uvědomit, že adresní body tvoří momentálně cca 70% všech
tagovaných bodů v ČR, po doplnění by to mělo být 75%. Takže každý
zbytečný tag bude mít ne úplně zanedbatelný dopad na celkový objem dat
a náročnost jejich zpracování.
To samo o sobě samozřejmě není důvodem pro nějaké mazání, ale je to imho
důvodem k pečlivému zvážení, jestli jsou jednotlivé tagy k něčemu užitečné.


 Mazat:

+created_by


 Mazat tyto kombinace k,v:

Ještě zhruba 50 000 bodů má:
http://taginfo.openstreetmap.cz/tags/note=Nekonzistence%20cuzk%3Akm%20a%20mvcr%3Aadresa
Vzhledem k tomu, že by se během importu měla provádět kontrola, tak by
se to mohlo taky rovnou mazat.


 Připravil jsem opět ukázku, tentokrát větší, a to pražské čtvrti Střížkov a 
 Prosek. http://pedro.poloha.net/osm/data.zip . Obsahuje dva soubory, data.osm 
 a data.csv. Co je v data.osm je snad jasné, v data.csv je tabulka varování - 
 seznam míst, kterým je třeba věnovat pozornost. Pro uživatele JOSM je tam 
 link 
 na JOSM remote control, jeho otevřením v prohlížeči nebo curl apod. JOSM 
 skočí 
 na problematické místo.Typy chyb:

Mohl bys trochu osvětlit, co znamená obsah jednotlivých sloupců v
tabulce varování?


 Píšu tady o tom proto, protože ačkoli je chyb RELATIVNĚ málo, v absolutních 
 číslech to dá desetitisíce a není reálné, abych to zvládl v rozumném čase 
 prohlédnout všechno. Proto pravděpodobně poprosím dobrovolníky, kteří by 
 chtěli dostávat .osm s jimi vybranou oblastí, prohlédnout je, opravit a 
 poslat 
 mi je zpátky. Takže je to taková příprava na lov brigádníků ;-).

Zapiš si mě ;-)


Zdraví,
Petr Morávek aka Xificurk

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

Re: [Talk-cz] Lokální Taginfo

[Petr Morávek [Xificurk]]

Dne 18.2.2014 18:18, Petr Schönmann napsal(a):
 Ahoj,
 Michal zprovoznil lokální verzi tag info pro CZ
 http://taginfo.openstreetmap.cz
 
 Směle do vylepšování kvality mapy .)
 Díky Michale.

Ahoj,

koukám, že v hlavičce je Data from: 2014-02-13 21:49 UTC.
Jak často se budou data aktualizovat?

Zdraví,
Petr Morávek aka Xificurk


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

Re: [Talk-cz] Lokální Taginfo

[Petr Morávek [Xificurk]]

Dne 18.2.2014 18:18, Petr Schönmann napsal(a):
 Ahoj,
 Michal zprovoznil lokální verzi tag info pro CZ
 http://taginfo.openstreetmap.cz
 
 Směle do vylepšování kvality mapy .)
 Díky Michale.

Wow, skvělé!

Hnedka jsem ze zvědavosti mrknul na
http://taginfo.openstreetmap.cz/keys/is_in
vs
http://taginfo.openstreetmap.org/keys/is_in

Takže z 2.8 milionu bodu s tímto tagem jsou 2 miliony v ČR?
(Podle čeho přesně se vyřezávají data pro ČR?)

Zdraví,
Petr Morávek aka Xificurk

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

Re: [Talk-cz] Ukázkový .osm Re: Adresy z RUIAN - 2. rekapitulace

[Petr Morávek [Xificurk]]

Dne 18.2.2014 19:26, Petr Vejsada napsal(a):
 Ahoj,
 
 Dne Ne 16. února 2014 13:28:20, Petr Morávek [Xificurk] napsal(a):
 
 Na tom changesetu by to podle mě nebylo potřeba rozlišovat (jestli se
 mění/doplňuje adresa, nebo i pozice je vidět přímo z jeho obsahu),
 použil bych něco jako:
 source=cuzk:ruian
 url=http://wiki.openstreetmap.org/wiki/POPIS_IMPORTU
 import=yes
 bot=yes
 comment=???

 V historii každého bodu pak bude např.:
 v1: import RUIAN
 v2: user123 změnil o pár mětrů pozici
 v3: user456 přidal shop=*
 ...

 Tím pádem na všech vytvořených nebo zkontrolovaných bodech by nebylo
 potřeba source:addr, source:loc by se nechalo jen pokud obsahuje nějakou
 jinou než s RUIANem související hodnotu, např. 'uhul:ortofoto'.
 
 můžeš ještě upřesnit, co je 'nesouvisející s RUIAN'? Resp. související s 
 RUIAN? uir_adr? cuzk:km? mvcr:adresa?  Dík.

Pro tyto účely bych za shodné považoval ruian, cuzk:ruian (příp. další
variace) a cuzk:km.
Ten zbytek bych asi radši nechal oddělený - kdo ví, co v těch
rejstříkách tenkrát bylo nebo nebylo.

 --
 Petr
 BTW: těch is_in je dnes dle mé DB 2.069.921. Hranice Geofabrik.

Je drsné, že u nás v ČR je 3x víc bodů s is_in než v celém zbytku světa.
A dalším zajímavým poznatkem z českého taginfo je, že adresní body (a to
ještě nejsou v OSM všechny) u nás tvoří cca 70% všech tagovaných bodů.

Zdraví,
Petr Morávek aka Xificurk

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

Re: [Talk-cz] Ukázkový .osm Re: Adresy z RUIAN - 2. rekapitulace

[Petr Morávek [Xificurk]]

Dne 16.2.2014 09:37, hanoj napsal(a):
  - source:position - nevím, k čemu je. Možnosti ignorovat, mazat, i nově
  přidaných AM přidat, ?
 
 source:position se nemaže, v případě přidávání nových bodů se přidává.
 
 *** spíše source:loc než source:position
 http://taginfo.openstreetmap.org/keys/source:position#combinations
 http://taginfo.openstreetmap.org/keys/source:loc#combinations
 
 hanoj

Ahoj,

nebylo by lepší ty source tagy dát přímo na changeset (což je v
současnosti doporučovaný postup pro importy)?
Obzvláště u toho source:position, resp. source:loc bych se celkem bál,
že při editaci lidi posunou bod, ale zapomenou změnit/odmazat tag.

V ČR je stejně jen jeden zdroj pro tyhle data, takže není potřeba na
každém bodu explicitně uvádět, že fakt pochází z RUIANu a ne odněkud jinud.

Zdraví,
Petr Morávek aka Xificurk

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

Re: [Talk-cz] Adresy z RUIAN

[Petr Morávek [Xificurk]]

Dne 15.2.2014 22:39, Pavel Machek napsal(a):
 Za podpasovku sorry, ale proste to dle wiki vypada, ze v addr:city ma
 byt jmeno posty, ktere se nemusi nutne shodovat s tim kde to je. Ze
 Vam to prijde reduntantni s PSC... no to asi ano, ale chudak
 zahranicni uzivatel asi nema po ruce databazi mest odpovidajicich k
 PSC... coz je duvod proc mame addr:city.
 
   Pavel
 

Ahoj,

já teda tu anglickou stránku [1] chápu tak, že tam má být to, co se píše
do kolonky město na obálku dopisu. A to může a nemusí být shodné s
městem, pod které adresní místo administrativně/územně spadá, ale zrovna
tak to může a nemusí být shodné se jménem pošty, která dané místo
obsluhuje. Problém je, že v ČR je to strašný maglajz.

Česká pošta má sice nějaké doporučené vzory psaní adres [2], ale moc
moudrý z toho nejsem. Přijde mi, že tam termín obec používají dost
volně a skutečně se tváří jako, že chtějí hlavně jméno adresní pošty.
Důsledné aplikování těch pravidel vede v mnoha případech k naprostým
kravinám.

Myslím, že bude lepší se přidržet toho tvaru, co zobrazuje RUIAN, t.j.
držet addr:city=Název obce.

Zdraví,
Petr Morávek aka Xificurk

[1] http://wiki.openstreetmap.org/wiki/Addr
[2]
http://www.ceskaposta.cz/cz/nastroje/uzitecne-informace/doporucene-vzory-postovnich-adres/doporucene-vzory-psani-postovnich-adres-id1078/

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

Re: [Talk-cz] Ukázkový .osm Re: Adresy z RUIAN - 2. rekapitulace

[Petr Morávek [Xificurk]]

Dne 16.2.2014 12:09, Petr Vejsada napsal(a):
 Ahoj,
 
 Dne Ne 16. února 2014 11:28:27, Petr Morávek [Xificurk] napsal(a):
 
 nebylo by lepší ty source tagy dát přímo na changeset (což je v
 současnosti doporučovaný postup pro importy)?
 Obzvláště u toho source:position, resp. source:loc bych se celkem bál,
 že při editaci lidi posunou bod, ale zapomenou změnit/odmazat tag.

 V ČR je stejně jen jeden zdroj pro tyhle data, takže není potřeba na
 každém bodu explicitně uvádět, že fakt pochází z RUIANu a ne odněkud jinud.
 
 Polohu neměním, tedy zdrojem polohy není RUIAN (pokud jím nebyl už v původní 
 adrese). Zdrojem polohy je RUIAN pouze u nově přidávaných bodů. To vše právě 
 proto, že s bodem mohl někdo šoupnout a posunout ho na lepší polohu - nad 
 vchod, namísto původní, méně vhodné polohy.
 
 --
 Petr

Aha, tak to jsem z té ukázky moc nepochopil - tam mají všechny body
source:position=cuzk:ruian. To by asi mít neměly, vzhledem k tomu, že
již existují a neposouváš je, ne?

Ale stále platí výše uvedená otázka... V principu by všechny adresní
body v ČR měly svým obsahem i pozicí být odvozeny od RUIAN. Jakékoliv
odchylky od stavu RUIANu budou buď opravy chyb (doufejme, že jich v
databázi moc není), malá pošoupnutí adresního místa na lepší místo
(např. blíže k vchodu/schránce), příp. doplnění nějakých POI tagů.

Otázkou tedy je, zda by nebylo vhodnější tyhle globální tagy dát přímo
na changesety importu (jak doporučují import guidelines), na
jednotlivých bodech by se pak už přidávat nemusely - co se s tím bodem
během importu přesně dělalo, se uvidí v jeho historii.

Zdraví,
Petr Morávek aka Xificurk

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

Re: [Talk-cz] Adresy z RUIAN - 2. rekapitulace

[Petr Morávek [Xificurk]]

Dne 15.2.2014 22:23, Václav Řehák napsal(a):
 
 Já taky nechci někomu zbytečně rozbíjet fungující software, a proto mě
 zajímá která konkrétní věc s is_in/addr:country tagem funguje a bez něj
 ne. Pokud jsem něco nepřehlédl, tak tu zatím nikdo takovou neuvedl.
 
 
 A nemůžeme to vzít opačně? Opravdu ti ta duplicita addr:country vadí na
 tolik, že má smysl kvůli tomu zdržovat celý import? 
 
 Obecná zásada bývá nedělat duplicity, ale proč? Aby nevznikaly rozpory
 mezi neaktualizovanými verzemi těch dat. Zrovna u RUIANu si nemyslím, že
 by to byl problém, když většina těch dat bude importována/udržována
 automaticky.
 
 Jinak řečeno, pořád chceš příklady, co se rozbije, když to odstraníme.
 Máš nějaký příklad, co se rozbije, když to tam necháme/přidáme? Těch pár
 MB opravdu není argument ve světě OSM, kde se importují jednotlivé
 stromy v parku a další (pro mě až nesmyslné) detaily.
 
 O is_in nemluvím, tam je to asi opravdu nejasné, k čemu má sloužit a i
 to rozsynchronizování si dovedu představit o dost realističtěji.
 
 V.

Ahoj,

však o addr:country už jsem psal dříve:
 Osobně jsem tedy pro: nepřidávat, ale nemazat (krom případů, kdy tam je
 nějaký nesmysl).

Asi jsem to pak zbytečně zamotal tím, že jsem začal tak nějak
addr:country a is_in házet do jednoho pytle - to proto, že se objevily
názory, že oba tagy jsou užitečné a je žádoucí je všude ponechat a
doplnit, ale zatím nikdo neukázal, kde/jak/proč jsou užitečné.

is_in má oproti addr:country jeden zásadní problém - není jasné, co by
tam mělo být, a tak není ani možné jednoduše zkontrolovat, jestli
současný obsah na existujících bodech je blábol, nebo správná hodnota. A
asi těžko vymyslíme Ten Správný Formát(TM), dokud nebude jasné k
čemu/kde se to používá.

Nepřidávání a zároveň nemazání addr:country má jeden pozitivní vedlejší
efekt - pokud na tu hodnotu něco přeci jen spoléhá, tak:
a) to bude i po importu fungovat ve stejné míře jako doteď
b) je slušná šance, že si po importu někdo všimne (a ozve se), že
software XYZ nefunguje úplně všude, protože ten tag někde chybí. Jakmile
bude na stole konkrétní problém, tak bude rozhodování řádově snažší -
buď doplníme tag na zbylé body, nebo se napíše patch, který to zvládne
vyřešit i bez addr:country.

Zdraví,
Petr Morávek aka Xificurk

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

Re: [Talk-cz] Ukázkový .osm Re: Adresy z RUIAN - 2. rekapitulace

[Petr Morávek [Xificurk]]

Dne 16.2.2014 13:00, Petr Vejsada napsal(a):
 Ahoj,
 
 Dne Ne 16. února 2014 12:29:08, Petr Morávek [Xificurk] napsal(a):
 
 Aha, tak to jsem z té ukázky moc nepochopil - tam mají všechny body
 source:position=cuzk:ruian. To by asi mít neměly, vzhledem k tomu, že
 již existují a neposouváš je, ne?
 
 Všechny mají source:addr=cuzk:ruian. source:position=cuzk:ruian mají jen nově 
 přidané. 9 se nově přidává, 111 se upravuje. Ať koukám, jak koukám, vidím to 
 tak, jak píšu. Nezaměnil jsi to se source:addr?

Aha, moje chyba - já si proklikal jen pár náhodných bodů v západní části
a naprosto špatně z toho vyvodil, že to mají všechny.


 Ale stále platí výše uvedená otázka... V principu by všechny adresní
 body v ČR měly svým obsahem i pozicí být odvozeny od RUIAN. Jakékoliv
 odchylky od stavu RUIANu budou buď opravy chyb (doufejme, že jich v
 databázi moc není), malá pošoupnutí adresního místa na lepší místo
 (např. blíže k vchodu/schránce), příp. doplnění nějakých POI tagů.
 
 Jestli to správně chápu, pak by to prakticky znamenalo zrušení informace o 
 zdroji polohy pro všechny body a zavedení předpokladu, že vše pochází od 
 CUZK, 
 není-li uvedeno jinak. V praxi to tak je (pouze ty, které jsou zastoupeny 
 více 
 než 100x):
 
  cuzk:km| 1155200
  uhul:ortofoto  | 353
  uhul:ortofoto, cuzk:km | 287
  ruian  |2900
 

 Otázkou tedy je, zda by nebylo vhodnější tyhle globální tagy dát přímo
 na changesety importu (jak doporučují import guidelines), na
 jednotlivých bodech by se pak už přidávat nemusely - co se s tím bodem
 během importu přesně dělalo, se uvidí v jeho historii.
 
 Jaká konkrétní hodnota source:loc by se tedy měla dávat na changeset? Mně to 
 vychází na cuzk:km, ovšem záeží na lokalitě. V okolí Vyškova to bude 99% 
 RUIAN, protože tam prostě skoro žádné adresy nejsou. V Praze to bude cuzk:km.
 
 --
 Petr

Na tom changesetu by to podle mě nebylo potřeba rozlišovat (jestli se
mění/doplňuje adresa, nebo i pozice je vidět přímo z jeho obsahu),
použil bych něco jako:
source=cuzk:ruian
url=http://wiki.openstreetmap.org/wiki/POPIS_IMPORTU
import=yes
bot=yes
comment=???

V historii každého bodu pak bude např.:
v1: import RUIAN
v2: user123 změnil o pár mětrů pozici
v3: user456 přidal shop=*
...

Tím pádem na všech vytvořených nebo zkontrolovaných bodech by nebylo
potřeba source:addr, source:loc by se nechalo jen pokud obsahuje nějakou
jinou než s RUIANem související hodnotu, např. 'uhul:ortofoto'.

Zdraví,
Petr Morávek aka Xificurk

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

Re: [Talk-cz] Adresy z RUIAN

[Petr Morávek [Xificurk]]

Dne 15.2.2014 11:12, Pavel Machek napsal(a):
 On Fri 2014-02-14 10:02:19, Petr Morávek [Xificurk] wrote:
 A znovu musím opakovat, že pro tyhle údaje existují spolehlivější
 zdroje, schválně si dejte hledat v nominatimu praha hlavní nádraží a
 zobrazí se vám:
 Železniční stanice Prague Main Railway Station, Legerova, Vinohrady,
 Praha, Hlavní město Praha, Praha, 12000, Česko
 (hm, asi bych se měl podívat, proč to tam je anglicky :D)
 A přitom ten uzel neobsahuje jediný addr:* nebo is_in tag.
 
 Nominatim to zvladnul. Na http://wiki.openstreetmap.org/wiki/Routing
 je seznam pouzivanych programu na hledani. Zvladnou to vsechny z nich?

Nevím. Ale je jisté, že pokud to některý z nich nezvládá, tak má celkem
problém bez ohledu na to, jak dopadne tahle naše diskuze.

Jen malá část objektů v databázi má is_in tag a z adresních bodů má jen
necelá polovina tag addr:country, pokud tedy někdo staví svoje
vyhledávání jen a pouze nad těmito daty, tak toho asi moc nenajde.


 A pokud jde o reverzní úkol, např. získat všechny adresní body třeba v
 Mikulově, tak tady jsou:
 http://overpass-turbo.eu/s/2w1
 Opět, na to není potřeba žádný addr:* nebo is_in tag.
 
 A jak to udelam v josm bez overpassu?

Čtu to už asi po desáté a pořád to nedává smysl... Já tu ukážu, jak s
určitým nástrojem (overpass api) dosáhnout určitého cíle (stažení
specifických dat z nějaké oblasti) a tvoje následná otázka je typu A
jak to můžu udělat jinak?


Zdraví,
Petr Morávek aka Xificurk

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

Re: [Talk-cz] Adresy z RUIAN

[Petr Morávek [Xificurk]]

Dne 15.2.2014 11:30, Pavel Machek napsal(a):
 Fajn. Takze je to best-practice. Od ktere se chces odchylit, a duvodem
 se zda byt je mi lito 86MB v databazi. To myslim neni dobry duvod,
 proc se od best-practice odchylit.

Zas mi podsouváš něco, co jsem nikdy ani v nejmenším nenaznačoval - 86MB
byla reakce na tvých pár bajtů a že bys radši přidával addr:country,
protože se ti nechce stahovat celé hranice ČR.

Best-practice na wiki říká, že jakmile existují spolehlivé polygony
hranic, tak tyto tagy nejsou potřeba a já s tím souhlasím a zatím
nevidím důvod, proč je nadále udržovat, nebo dokonce někde přidávat.


 Import by se v prvé řadě měl řídit zdravým rozumem, až následně nějakým
 článkem na wiki. Znění těch článků se koneckonců mění právě na základě
 diskuze a předložení racionálních argumentů.
 
 Muj zdravy rozum rika ze jinde se addr:country pouziva, tak by tam mel
 byt i nadale.

Míst, kde se používá addr:country je méně než míst, kde se nepoužívá.
Pro is_in tag je ten rozdíl ještě mnohem výraznější - je řádově víc
objektů bez něj než s ním.


 Mam tu monav, ano, obcas stahnu novy data. Ne, neumi to spolupracovat
 s relacemi hranic. Bohuzel pro to nektere ulice nevidi v Praze.
...
 Zda se ze napriklad navit potrebuje is_in tag:
 
 * Navit only works with is_in tags, can't work with boundaries.
 
 http://wiki.openstreetmap.org/wiki/Talk:Key:is_in
 
 Z osobni zkusenosti vim, ze monav neumi vyuzit hranice mest. Myslim ze
 z hranicemi zemi to bude podobne.

http://wiki.navit-project.org/index.php/OpenStreetMap
Navit (resp. maptool, který převádí osm do binárního formátu pro navit)
umí používat jak hranice států, tak i měst.

https://groups.google.com/forum/#!msg/monav-discuss/kWz7Xvao7jM/SBABYSQ4Oy0J
Podle tohoto MoNav s nějakými polygony pracovat umí, takže bude jen
problém v tom, jaké využívá. Zároveň jsem ale nikde v dokumentaci nebo
kódu nenašel zmínku o tom, že by se používala hodnota is_in nebo
addr:country, takže jejich ponechání/doplnění stejně nic nevyřeší.

Co tam máš dál? ;-)


 Z jineho mailu:
 
 #Aha. Takže Krásná, pošta Raškovice má být
 #  
 #addr:city=Raškovice
 #is_in=Krásná
 #
 #místo
 #addr:city=Krásná
 #is_in=Krásná

Omlouvám se, to jsem nějak přehlédl. Ale naprosto nesouhlasím s tímto
použitím.
* addr:city by mělo obsahovat jméno obce, kde se AM nachází (tak jak je
to i v RUIAN), v žádném případě by tam nemělo být něco jiného.
* pošta Raškovice je to samé jako PSČ 73907. Nemá smysl tu samou
informaci duplikovat v OSM. Ani není potřeba ji duplikovat v adrese na
dopisu - jediný význam je pro kontrolu, takže když napíšeš Krásná,
pošta Raškovice, PSČ 12345, tak to pravděpodobně dojde. Z vlastní
zkušenosti vím, že Česká pošta je schopná doručit i dopisy s hodně
zkomolenou adresou.


Zdraví,
Petr Morávek aka Xificurk


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

Re: [Talk-cz] Adresy z RUIAN

[Petr Morávek [Xificurk]]

Dne 15.2.2014 14:50, Petr Vejsada napsal(a):
 K tomuto tolik, že i ten Nominatim má vážný problém.
 
 Libochovany 129 - prostě to nenajde, ačkoli má dokonce hned dvě možnosti, jak 
 to udělat. Barák existuje, existují hranice obce, existují hranice čtvrti - 
 asi katastrální území, existuje addr:city, addr:housenumber i 
 addr:conscriptionnumber.

A dokonce i is_in=Libochovany, Ústecký kraj, CZ
Chtělo by to přijít na to, kde je zakopaný pes a proč to nenajde.

 Z toho víceméně vyplývá, že nebude schopen najít barák ve městě ani po 
 zavedení addr:place.

Já teda osobně nevidím, jak to z toho vyplývá (vždyť ani nevíme, proč
nenajde Libochovany 129!)
A že nenajde adresu Praha 42 je sice škoda, ale žádná tragedie.

 Dotaz bude muset být na část obce (což v případě 
 Libochovan jsou taky Libochovany), ovšem ne vždy tomu tak bude.

To by nebylo až tak katastrofální - typicky chceš hledat podle názvu
ulice, nebo části obce (protože tam nejsou pojmenované ulice).

Petr


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

Re: [Talk-cz] Adresy z RUIAN - 2. rekapitulace

[Petr Morávek [Xificurk]]

Dne 15.2.2014 18:57, Petr Vejsada napsal(a):
 Jelikož j obecnému konsensu ohledně is_in a addr:country nejspíš nedojde, 
 chci 
 poprosit, abyste se už k přidávání těchto tagů nevyjadřovali, ledaže by 
 nutkání či argumenty byly nepřekonatelně silné. Zato uvítám podněty k obsahu 
 tagu is_in.
 
 K diskusi:
 
 - obsah tagu is_in

Ahoj,

dokud nebude jasné čemu má obsah toho tagu sloužit, tak se těžko shodnem
na jeho formátu.

Já taky nechci někomu zbytečně rozbíjet fungující software, a proto mě
zajímá která konkrétní věc s is_in/addr:country tagem funguje a bez něj
ne. Pokud jsem něco nepřehlédl, tak tu zatím nikdo takovou neuvedl.

Nominatim - umí polygony hranic, addr:country/is_in tedy není potřeba.

Navit - resp. maptool, které převádí osm formát do binárního formátu pro
navit, umí polygony hranic států i měst, is_in/addr:country tedy není
potřeba.

MoNav - sice neumí polygony hranic, ale neumí ani is_in/addr:country.

OsmAnd - umí polygony hranic, is_in/addr:country tedy není potřeba.

...

Ne opravdu jsem neprocházel všechen software, ale čistě ze statistik
taginfo bych se fakt divil, kdyby na přítomnost těchto tagů něco opravdu
spoléhalo.
Zajímá mě nějaký příklad toho, kde jsou tyto tagy užitečné mj. i proto,
abysme si vyjasnili, jaký formát/obsah by is_in mělo mít.

Zdraví,
Petr Morávek aka Xificurk

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

Re: [Talk-cz] Adresy z RUIAN

[Petr Morávek [Xificurk]]

Dne 15.2.2014 16:41, Dalibor Jelínek napsal(a):
 Ahoj,
 tohle jsem nepochopil. Proc by to po zavedeni addr:place nefungovalo?
 Kdyz jsem to zkousel, tak to fungovalo vzdy na tvar addr:place cislo
 popisne. Praha 2295 to samozrejme nenajde, ale Libeň 2295 ano. U tech
 Libochovic to musi fungovat taky, kdyz si Nominatim docte addr:place do
 databaze.
 Dalibor

Ahoj,
z toho, co jsem teď testoval to vypadá, že umí najít Street 1, nebo 
Place 2, ale ne obojí - pokud je nastaveno addr:street, tak už to
nenajde kombinaci s addr:place.
Ten příklad s Libní to umí jen proto, že existuje budova, která má
addr:place, ale nemá addr:street a zároveň existují adresní body, které
mají jak addr:place=Libeň, tak addr:street=Kovanecká.
Škoda, že neumí oboje, ale asi je to celkem očekávané chování - když
jsou pojmenované ulice, tak hledám podle názvu ulice.

Zdraví,
Petr Morávek aka Xificurk


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

Re: [Talk-cz] Adresy z RUIAN

[Petr Morávek [Xificurk]]

Dne 14.2.2014 08:29, Dalibor Jelínek napsal(a):
 Ahoj,
 se nam ta debata nejak rozvasnuje. ;-)
 
 Pokud mám bod a chci získat všechny administrativní celky (KÚ až stát), ve 
 kterých leží, tak opět položím jeden jednoduchý dotaz na overpass API
 Tak ho sem napis. Ja ho neumim, vymyslet ho nechci, ale chtel bych se 
 podivat, jak se to dela.
 
 Ja bych to addr:country=CZ daval vsude, protoze to treba zjednodusi
 vyhledavani bodu zajmu v prihranici. A do te adresy to proste tak nejak patri,
 i kdyz se zda, ze je to z naseho pohledu implicitni.

Jak konkrétně to zjednoduší?

Když hledám Ulice 42, Obec, Ulice, Obec, nebo POI, Obec, tak tam
ani CZ nemám a typicky to nepotřebuji (ta obec stačí).

A znovu musím opakovat, že pro tyhle údaje existují spolehlivější
zdroje, schválně si dejte hledat v nominatimu praha hlavní nádraží a
zobrazí se vám:
Železniční stanice Prague Main Railway Station, Legerova, Vinohrady,
Praha, Hlavní město Praha, Praha, 12000, Česko
(hm, asi bych se měl podívat, proč to tam je anglicky :D)
A přitom ten uzel neobsahuje jediný addr:* nebo is_in tag.

A pokud jde o reverzní úkol, např. získat všechny adresní body třeba v
Mikulově, tak tady jsou:
http://overpass-turbo.eu/s/2w1
Opět, na to není potřeba žádný addr:* nebo is_in tag.


 Tady je dokonce nejaky naznak, ze to nekde dela problemy, kdyz to chybi
 http://wiki.openstreetmap.org/wiki/OSM_Inspector/Views/Addresses 

Uvědomuješ si, že dáváš odkaz na něco, co už víc jak pět let nefunguje?
:-) Navíc ten hlavní problém není v chybějícím addr:country, ale
jednoduše špatně navrženém algoritmu.


Zdraví,
Petr Morávek aka Xificurk

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

Re: [Talk-cz] RUIAN adresy - mezirekapitulace

[Petr Morávek [Xificurk]]

Dne 14.2.2014 08:56, Jan Dudík napsal(a):
 Já teda vím o jednom baráku 
 http://www.openstreetmap.org/#map=19/48.92397/14.50170
 který leží na území jedné obce, ale obyvatelé patří, po dohodě
 zastupitelstev, do vedlejší obce.
 Takže sice adresa Nedabyle 50, ale obec Vidov
 
 JD

Ahoj,

tohle je další dobrý důvod, proč tam to jméno obce dávat.

Je to tento stavební objekt:
http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/19774010
V RUIAN ta dohoda zanesená není - nevím, jestli to platí jen na dobré
slovo, nebo je to příliš čerstvé, nebo... Ale prostě to tam (zatím?) není.

Ale podobné přesahy obcí skutečně existují, a ještě nedávno byly dokonce
i na hranici okresů (a asi ještě pořád někde jsou). Ale z toho, co jsem
vyčetl, by se to postupně mělo opravovat nějakou dohodou a posunem hranic.

Jeden příklad za všechny:
http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/7603991
Dům leží v kú Neratov, které patří do obce Neratov.
Ale patří do části obce Dědek, která patří do obce Živanice.

Zároveň to nádherně ilustruje ty rozdílné způsoby dělení - část obce
_nemá_ narozdíl od kú žádnou přesně určenou hranici, ale je definována
právě výčtem adresních míst (resp. stavebních objektů)... a tak občas
dojde k této podivné situaci, kdy jeden dům je vlastně součástí dvou obcí.

Zdraví,
Petr Morávek aka Xificurk

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

Re: [Talk-cz] Adresy z RUIAN

[Petr Morávek [Xificurk]]

Dne 14.2.2014 13:35, Dalibor Jelínek napsal(a):
 Ahoj,
 http://wiki.openstreetmap.org/wiki/Cs:JOSM/Plugins/CzechAddress#Adresy_v_OpenStreetMap
 tak to jsem nenasel. Cekal bych, ze to najdu na ceskych Map Features nebo 
 Editing Standards.
 Neva, prilezitostne to tam dopisu.
 
 Pokud jej zachováme, tak jsem pro to, aby se to udělalo pořádně:
 [místní část], [městská část], [město], [okres], [kraj], CZ
 S tím, že minimální zápis bude:
 [město], [okres], [kraj], CZ
 
 Hmm. A nevadi nam, ze tam mame carky, kdyz tady
 http://wiki.openstreetmap.org/wiki/Key:is_in
 se zcela zjevne doporucujou stredniky?
 Mě to teda vadí hodně. Středník by byl lepší, protože to je standardní 
 oddělovátko.
 Navíc ta stránka píše, že vlastně na pořadí těch částí zas tak moc nezáleží 
 (i když je lepší
 je mít seřazené), ale my vlastně žádné části nemáme, takže zahraniční 
 programy na
 to asi koukaj dost divně.

A ještě by se tam mohl přidat NUTS2 region, katastrální území, ZSJ, PSČ,
jméno ulice, ... těch pár bajtů navíc nikoho nezabije :P

A teď vážně - dokáže někdo říct k čemu by to mělo být užitečné?

O tom, že je tento tag překonaný koneckonců svědčí i čísla z taginfo:
addr:housenumber celkem 29 mil. objektů, 2 mil. má is_in tag
addr:street celkem 26 mil. objektů, 1 mil. z nich má is_in tag
is_in celkem 4 mil. objektů


 Uvědomuješ si, že dáváš odkaz na něco, co už víc jak pět let nefunguje?
 Ee, nee, proste jsem to jen nasel. Mozna blbej algoritmus, ale chybelo jim 
 to. ;-)

Chybělo jim to tenkrát - bylo potřeba buď addr:country, rozumnější
hranice států, nebo chytřejší algoritmus. Rozhodně tuhle pět let mrtvou
věc nelze považovat za smysluplný argument pro plošné používání
addr:country ;-)

 Pokud mám bod a chci získat všechny administrativní celky (KÚ až 
 stát), ve kterých leží, tak opět položím jeden jednoduchý dotaz na 
 overpass API
 Když já jsem chtěl vědět, jak se dělá tohle.

Např. takto:
http://overpass-turbo.eu/s/2wb

 Najít adresy v nějakých hranicích už jste mě naučili.

Overpass API toho umí opravdu spoustu, na wiki je rozsáhlá dokumentace.
Hlavní výhodou je, že není potřeba vlastníma silama něco instalovat a
nastavovat.

Zdraví,
Petr Morávek


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

Re: [Talk-cz] Adresy z RUIAN

[Petr Morávek [Xificurk]]

Dne 13.2.2014 15:31, Pavel Machek napsal(a):
 On Tue 2014-02-11 23:49:11, Petr Vejsada wrote:
 Ahoj,

 Dne Út 11. února 2014 09:01:07, Dalibor Jelínek napsal(a):

 Ahoj,
 ja teda is_in tag rad nemam, protoze nevim, jak se ma spravne vyplnovat.
 Na druhou stranu se mi nezda hezke mazat neco, co nekdo do mapy
 s nejakym usilim pridal.
 Pokud opravdu dokazeme nahradit vse, co ted ten tag obsahuje, pak ano.
 Ale uz ted vim, ze zatim ten navrh PV neobsahuje vse, co je v is_in.
 V is_in jsou mestske casti (nekde) a stat, to tam zatim PV nema.

 Ja bych navrhoval, do tech adres pridavat :
 addr:country=CZ (czechaddress to tam dava a proc to vynechavat?)
 addr:suburb=Praha 14 (z městská část/obvod)

 přidat stát není problém, otázka spíš je, zda to má smysl.?
 
 Jo, ma. Wiki rika, ze to tam ma byt, a ne kazdy si chce stahovat
 hranice zemi aby mohl pracovat s adresama.
   Pavel
 

Ahoj,

Wiki není žádná norma... a nikdy nebyla.
Taginfo říká, že addr:country existuje na necelé polovině adresních bodů
- konkrétně jej má:
- 44% objektů, které mají addr:housenumber
- 46% objektů, které mají addr:street
Takže ono to až tak důsledně, jak naznačuješ, používané není.

Nevím, co si mám představit pod mohl pracovat s adresama, ale... Pokud
chci dostat skutečně všechny adresní body v ČR je to otázka jediného
jednoduchého dotazu na overpass API. Pokud mám bod a chci získat všechny
administrativní celky (KÚ až stát), ve kterých leží, tak opět položím
jeden jednoduchý dotaz na overpass API. Ani pro jedno si já nepotřebuju
stahovat hranice k sobě a zároveň to dává spolehlivější výsledky, než
hledání podle addr:country.

Zdraví,
Petr Morávek aka Xificurk

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

Re: [Talk-cz] RUIAN adresy - mezirekapitulace

[Petr Morávek [Xificurk]]

Dne 13.2.2014 15:37, Pavel Machek napsal(a):
 On Thu 2014-02-13 10:01:41, Marián Kyral wrote:
 Na základě diskuze hlasuji pro:

 1) Přidat addr:place a addr:suburb
 2) Rozlišovat ref:ruian (ref:ruian:addr, ref:ruian:building...)
 3) Mazat addr:country, uir_adr a is_in (Dle wiki je is_in přežité)
 
 A dle wiki se addr:country pouziva. Jestli si myslis, ze se
 addr:country ma mazat, oddebatuj to na anglicky wiki, at je pro to
 shoda po cely mape.

Už jsem psal komentář vedle, proč tento tag považuji za pořekonaný.
Ale je pravda, že narozdíl od is_in v tomto případě hrozí větší riziko,
že to stále ještě někdo používá.
Osobně jsem tedy pro: nepřidávat, ale nemazat (krom případů, kdy tam je
nějaký nesmysl).

 is_in mozna je prezite, ale to neni duvod ho mazat. Az bude tak
 prezite, ze bude dobre ho smazat, pujde to udelat jednou a centralne.

Ale tady se bavíme přeci o jednom konkrétním případu - adresy (v ČR), ne
globálním používání is_in. Hoď sem prosím nějaký příklad (např.
konkrétní software), kdy je tento tag na adresách skutečně užitečný. Já
o žádném nevím (a vzhledem k tomu, co je/není v is_in tagu, tak
pochybuju, že takový existuje).

 (A viz anglicka wiki, ktera vysvetluje, ze mesto v is_in muze byt jine
 nez v addr:city.)

Máš konkrétní příklad pro ČR?

   Pavel
 

Zdraví,
Petr Morávek aka Xificurk

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

Re: [Talk-cz] RUIAN adresy - mezirekapitulace

[Petr Morávek [Xificurk]]

Dne 13.2.2014 20:41, Petr Vejsada napsal(a):
 Ahoj,
 
 Dne Čt 13. února 2014 19:39:42, Petr Morávek [Xificurk] napsal(a):
 
 no to teda máš sakra pravdu, já si to ověřoval selectem na view, co tu mám 
 pro 
 zobrazování adres v lidské formě. Naivně jsem si myslel, že ve sloupci 
 'nazev' 
 bude název, a ono prd, jsou tam poznámky, ve kterém okrese se obec nacházela 
 v 
 minulosti. Tak to zase někdo něco po..., když se měnily hranice okresů, hmm.

jj, databáze takovýchle dárečků obsahuje více :-)

 Na okres máme hranice s admin_level=7, víc netřeba.
 
 nóó, a proč tam dávat obce, když na to máme admin_level 8?

Už jsem psal, že v principu tam název obce (addr:city) být nemusí právě
proto, že tahle hranice již existuje, ale zrovna nad názvem obce bych
přimhouřil oko a dával ji duplicitně i na adresní body.
Hlavním důvodem je to, že bod potom bude obsahovat kompletní adresu tak,
jak se píše na dopis.
Dalším důvodem je to, že kombinace obec, ulice a domovní číslo (č.p.
nebo č.e.) je v naprosté většině případů unikátní (a taky je to formát,
ve kterém se typicky adresa vyhledává), tj. pro většinu základních
vyhledávání skutečně stačí informace jen z adresního bodu.

 A na části obce máme admin_level 10.

Nene, admin_level=10 jsou katastrální území, to je něco jiného. Jak už
jsem psal víckrát - hranice části obce neexistuje.


Zdraví,
Petr Morávek aka Xificurk

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

Re: [Talk-cz] Adresy z RUIAN

[Petr Morávek [Xificurk]]

Ahoj,

já to radši zas sloučím do jednoho vlákna. A rovnou se omlouvám, že ty
tvoje dva maily a odpovědi na ně promíchám, ale je to jedno téma, tak ať
je to pohromadě.


Dne 13.2.2014 18:20, Pavel Machek napsal(a):
 Wiki není žádná norma... a nikdy nebyla.
 
 Ne? A co je tedy norma? talk-cz@ mailing list?

Ne, talk-cz@ skutečně taky žádná norma není. Norma pro OSM tagování
totiž jednoduše neexistuje. Jaké tagy jsou nebo nejsou požíváno určuje
jen a pouze to, jestli skutečně jsou nebo nejsou v databázi používány.
Wiki slouží jako dokumentace best-practice. Rozhodně není pravda, že
co je na wiki, tak se musí používat a žádná jiná varianta není
přípustná, nebo že co není na wiki, to neexistuje a se nesmí se používat.
A tohle není můj osobní výmysl, takto je to prezentováno, jak na wiki
samotné, tak i jednotlivých mezinárodních mailing listech.
(A příště mi prosím nepodsouvej věci, které jsem ani v nejmenším
nenaznačoval.)


 Taginfo říká, že addr:country existuje na necelé polovině adresních bodů
 - konkrétně jej má:
 - 44% objektů, které mají addr:housenumber
 - 46% objektů, které mají addr:street
 Takže ono to až tak důsledně, jak naznačuješ, používané není.
 
 Coz porad neni duvod to kazit jeste vic. Dela se hromadna uprava,
 hromadna uprava by mela byt spravne. Pokud nesouhlasis s wiki, fajn,
 oprav wiki. Ale import by se mel ridit tim co je na wiki.

Import by se v prvé řadě měl řídit zdravým rozumem, až následně nějakým
článkem na wiki. Znění těch článků se koneckonců mění právě na základě
diskuze a předložení racionálních argumentů.


 Už jsem psal komentář vedle, proč tento tag považuji za
 pořekonaný.
 
 Wiki si to nemysli. Jestli s tebou zbytek sveta souhlasi, tak nebude
 problem problem problem opravit na wiki, ze?

Wiki není potřeba opravovat, ono to tam už totiž je. Jen jsi to asi
přehlédl:
  The keys addr:housenumber=* und addr:street=* in principle are the only 
 necessary ones if there are valid border polygons.
(http://wiki.openstreetmap.org/wiki/Addr)


 (A ne, nemyslim ze by pro import bylo vic prace pridat addr:country, a
 nemyslim ze tech par bajtu navic neco zmeni.)

Těmi pár bajty se tu ohání lidi nějak často...

Celá státní hranice ČR (relace, všechny cesty a body a jejich tagy) má
11 MB v nekomprimovaném formátu.

'tag k=addr:country v=CZ/\n'
31 B * 2917732 adresních míst = 86 MB

Těch par bajtu navic je ve skutečnosti mnohonásobně víc než má
kompletní hranice ČR (jejímuž stahování se těmi par bajty navic snažíš
vyhnout).


 Nevím, co si mám představit pod mohl pracovat s adresama, ale... Pokud
 chci dostat skutečně všechny adresní body v ČR je to otázka jediného
 jednoduchého dotazu na overpass API. Pokud mám bod a chci získat
 všechny
 
 Mam tady offline navigaci na n900. Fakt chci aby zustala offline, a
 ne, nebudu si instalovat posgresql pro to, a by mi fungovalo
 vyhledavani podle adresy.

Nenapsal jsi, v čem konkrétně by nastal problém, takže neumím dát
konkrétní odpověď. Ale předpokládám, že nějak ty data aktualizuješ. A z
toho, co jsi psal hádám, že tam necpeš přímo celý dump OSM dat, ale
děláš nějaký pre-processing, nevím čím a jak ale divil bych se, kdyby to
neumělo spolupracovat z relacemi hranic a spoléhalo se jen a pouze na
addr:country, nebo is_in tag. A i kdyby neumělo, tak existuje zmíněné
overpass API.


 Ale je pravda, že narozdíl od is_in v tomto případě hrozí větší riziko,
 že to stále ještě někdo používá.
 
 Is_in se pouzival treba tady:
 
 http://code.google.com/p/osmand/issues/detail?id=391

Irelevantní po přečtení první věty:
 Convert using OsmAndMapCreator-0.5.1beta-b2, an osm map without borders to 
 delimit cities, so street ownership is determined by is_in tag in the 
 corresponding way.
My ty hranice (nejen) měst máme... a ještě k tomu máme (a nikdo se
nesnaží to změnit) i addr:place.
Já netvrdím, že se to nikde a vůbec nepoužívá... právě naopak z
historických důvodů to jako úplně poslední fallback používá celá řada
softwaru, ale je to skutečně až ten nejposlednější fallback. Jednoduše
tenhle tag je deprecated a nemá smysl ho dále udržovat, protože existují
spolehlivější cesty, jak se k daným informacím dostat.


 Opravdu si chces projit vsechen existujici software, a overit, ze uz
 to nikdo nepouziva?

Nechci, chtěl jsem po tobě alespoň jeden konkrétní příklad, k čemu/kde
je to užitečné - myslel jsem, že jsem to napsal dost jasně, ne? A myslím
opravdu užitečné, tzn. S is_in/addr:country tagem 'tohle' funguje, bez
něj ne.


 Osobně jsem tedy pro: nepřidávat, ale nemazat (krom případů, kdy tam je
 nějaký nesmysl).
 
 Na wiki ten tag stale jeste je, tak by to tam byt melo.

Na wiki je napsáno, že tam být nemusí, tak tam taky být nemusí :P


 (A viz anglicka wiki, ktera vysvetluje, ze mesto v is_in muze byt jine
 nez v addr:city.)

 Máš konkrétní příklad pro ČR?
 
 Proc bych mel mit priklad pro CR?

Eh, to jako vážně? Nu, dobrá... Tématem této diskuze je Adresy z
RUIAN, to jsou adresy v ČR. Tvoji výše uvedenou poznámku jsem si
vyložil tak, že is_in tag by se 

Re: [Talk-cz] Adresy z RUIAN

[Petr Morávek [Xificurk]]

Dne 12.2.2014 02:05, Petr Vejsada napsal(a):
 Dne Út 11. února 2014 08:39:22, Petr Morávek [Xificurk] napsal(a):
 
 Zásadní otázka č.1 - co s tagy addr:country a is_in? Možnosti jsou
 ponechat, mazat či nahrazovat. Jaký máte názor?

 Asi by bylo dobré udělat nějakou základní analýzu obsahu is_in tagu -
 pokud obsahuje jen část obce, obec, stát... (nebo čárkami oddelenou
 kombinaci), tak smazat. Pokud jsou všechna data is_in tagu obsažena ve
 strukturované podobě v addr:*, tak si myslím, že nemá cenu, aby nám tu
 nadále strašil.
 
 Zběžná analýza provedena, 
 - is_in obsahuje navíc kraj
 - is_in je u cca 90 procent všech entit, kde se vyskytují adresní tagy.
 
 Tak co s tím krajem? 
 
 --
 Petr

Obecně si myslím, že dávat na adresní informaci o jakémkoliv
administrativním celku od obce výše je nesmysl (a do toho zahrnuji i
stát) - na adresu se to typicky nepíše a pokud to někdo potřebuje z
jiných důvodů, tak od toho máme udržované administrativní hranice a
overpass API a i ten Nominatim tyto hranice umí používat.

Zdraví,
Petr Morávek aka Xificurk

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

Re: [Talk-cz] Adresy z RUIAN

[Petr Morávek [Xificurk]]

Dne 12.2.2014 21:00, Marián Kyral napsal(a):
 Dne 12.2.2014 18:06, Petr Morávek [Xificurk] napsal:
 Dne 12.2.2014 02:05, Petr Vejsada napsal(a):
 Dne Út 11. února 2014 08:39:22, Petr Morávek [Xificurk] napsal(a):

 Zásadní otázka č.1 - co s tagy addr:country a is_in? Možnosti jsou
 ponechat, mazat či nahrazovat. Jaký máte názor?

 Asi by bylo dobré udělat nějakou základní analýzu obsahu is_in tagu -
 pokud obsahuje jen část obce, obec, stát... (nebo čárkami oddelenou
 kombinaci), tak smazat. Pokud jsou všechna data is_in tagu obsažena ve
 strukturované podobě v addr:*, tak si myslím, že nemá cenu, aby nám tu
 nadále strašil.

 Zběžná analýza provedena,
 - is_in obsahuje navíc kraj
 - is_in je u cca 90 procent všech entit, kde se vyskytují adresní tagy.

 Tak co s tím krajem?

 -- 
 Petr

 Obecně si myslím, že dávat na adresní informaci o jakémkoliv
 administrativním celku od obce výše je nesmysl (a do toho zahrnuji i
 stát) - na adresu se to typicky nepíše a pokud to někdo potřebuje z
 jiných důvodů, tak od toho máme udržované administrativní hranice a
 overpass API a i ten Nominatim tyto hranice umí používat.

 
 A máme jistotu, že to někdo třeba nepoužívá?
 Marián

Naprostá jistota samozřejmě nikdy nebude, ale vzhledem k rozmanitosti
formátu i obsahu tagu is_in (a zároveň dostupnosti té samé informace na
lepších místech), bych se docela divil, kdyby to někde bylo ve větší
míře bylo používáno.

Petr

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

Re: [Talk-cz] PointInfo - nová (testovací) verze

[Petr Morávek [Xificurk]]

Ahoj,

Dne 11.2.2014 23:44, Marián Kyral napsal(a):
 Dne 11.2.2014 09:37, Dalibor Jelínek napsal:
 - jeste bych pridaval tu mestkou cast, obvod
 podle me se na to hodi tehle tag, pokud nechceme zavadet novy
 addr:suburb=Praha 14

 Asi by bylo třeba to doplnit do wiki. O addr:suburb tam není ani slovo.
 Ještě si nejsem jistý, že tam něco jako Praha 14 je. Co vím, tak je tam
 přímo název městké části - Dejvice, Vinohrady...

To nejsou návzvy městské části, ale části obce. Dělení na městské části
je paralelní způsob rozdělení města a mají ho jen statutární města (a
ještě myslím ne všechna). Názvy městských částí jsou v rn_mommc
(navázány pres momc_kod na stavební objekt). Aby toho nebylo málo, Praha
má ještě jedno své speciální dělení (Praha 1-10), které je v tabulce
rn_momp.

 Akorát tu správnou Wiki stránku teď ne a ne najít.
 
 BTW: Co jsem tak koukal na addr: schéma, platí tedy, že addr:place se
 dává jen v případě, že v dané obci nejsou pojmenované ulice? V případě,
 že ulice jsou, tak se místo addr:place dává addr:suburb?

Už jsem to tu psal - držel bych důsledně addr:place všude s tím, že by
to mělo obsahovat název části obce. Ona totiž část obce nemá vlastní
hranici, ale je definována právě výčtem AM.

Zdraví,
Petr Morávek aka Xificurk

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

Re: [Talk-cz] Tracer plugin - ruian update

[Petr Morávek [Xificurk]]

Ahoj,

Dne 10.2.2014 14:24, Marián Kyral napsal(a):
 Dne 10.2.2014 13:56, jzvc napsal:
 2) v RUIANu nejsou ty pristavky co sou v KM? Pripadne odkud se v KM
 berou? Protoze ty to rozhodne netrasuje. Pokud by trasovalo, byl by asi
 vyresen problem vejs.
 
 Nejsou, nejsou. Když si zapneš tu vrstvu budov od Petra Vejsady a přes to
 si dáš vrstvu KM, tak uvidíš, že ty přístavky jsou dělány tenčí čarou a
 třeba původní tracer server je nevidí = je to v jiné vrstvě KM. (ale záleží
 na konfiguraci Tracer Serveru)

Většinou jsou uvedeny v tabulce parcela jako zastavěná plocha
(druh_pozemku_kod = 13).

Problém je, že do téhle kategorie spadá všechno možné - od parkovací
plochy po normální dům.

Např. toto:
http://vdp.cuzk.cz/vdp/ruian/parcely/2430440606
zahrnuje na východní straně i venkovní schody k zadnímu vchodu do sklepa

a přitom odpovídající stavební objekt:
http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/7666926
má hranice odpovídající jen jednomu vchodu z pěti


Zdraví,
Petr Morávek aka Xificurk

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

Re: [Talk-cz] Tracer plugin - ruian update

[Petr Morávek [Xificurk]]

Dne 7.2.2014 09:39, Dalibor Jelínek napsal(a):
 Ne, takhle ne (alespon podle struktury databaze). V databazi je jen
 sloupecek domovni_cislo, jestli se jedná o č.p. nebo č.e. určuje
 hodnota ve
 sloupci typ_kod (možnosti jsou tři: č.p., č.e., nic) v tabulce SO. A z
 tohodle
 tedy plyne, že by neměl existovat SO s oběma druhy čísel, resp. nevím jak
 by
 byl značen v databázi.
 Petr
 
 Ahoj,
 no, jo, ale to se na to jaksi divas jen z jednoho smeru, kde mas teda
 pravdu.
 Ale jak vis, ze neexistuje (nebo nebude existovat)
 1. vice AM v rn_adresni_misto
 2. vice samostatnych vchodu v TEA 
 ktere budou privazany ke stejnemu SO a budou mit jina c.p. ci c.e. (u c.o.
 je to bezne)?
 
 Oboji je myslim v tom databazovem modelu mozne, byt by to nabouravalo
 prirazeni domovni_cislo, jak pises.

Já reagoval na:
 - vice c.p./c.e.
 muzou existovat SO, ktere maji c.p. i c.e. a pritom nemaji vice vchodu.
 Nevim, jak to vypada uvnitr databaze RUIAN, ale realne to je. Proste je dum, 
 co ma nejdrive c.e.
 a pak dostane c.p. (asi vetsinou stejne), ale AM existuji obe

A databázová struktura prostě neumí SO s oběma typy čísel - popisným i
evidenčním. Neumí to ani přímo v tabulce SO, ani přes tabulku AM. Nic
víc, nic míň netvrdím ;-)

Petr



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

Re: [Talk-cz] Tracer plugin - ruian update

[Petr Morávek [Xificurk]]

Dne 6.2.2014 13:46, Dalibor Jelínek napsal(a):
 - vice c.p./c.e.
 muzou existovat SO, ktere maji c.p. i c.e. a pritom nemaji vice vchodu.
 Nevim, jak to vypada uvnitr databaze RUIAN, ale realne to je. Proste je dum, 
 co ma nejdrive c.e.
 a pak dostane c.p. (asi vetsinou stejne), ale AM existuji obe

Ne, takhle ne (alespon podle struktury databaze). V databazi je jen
sloupecek domovni_cislo, jestli se jedná o č.p. nebo č.e. určuje
hodnota ve sloupci typ_kod (možnosti jsou tři: č.p., č.e., nic) v
tabulce SO. A z tohodle tedy plyne, že by neměl existovat SO s oběma
druhy čísel, resp. nevím jak by byl značen v databázi.

Petr


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

Re: [Talk-cz] Tracer plugin - ruian update

[Petr Morávek [Xificurk]]

Dne 5.2.2014 08:53, Dalibor Jelínek napsal(a):
 No prave tady mi to prijde uplne jasne, jak jsem psal drive:
 
 cesta budovy:
 addr:place=Dejvice
 addr:city=Praha 6 (nebo Praha, tady nevim)
 addr:country=CZ 
 addr:housenumber=2710
 addr:conscriptionnumber=2710
 ref:ruian=cislo stavebniho objektu
 bez ulice
 bez c.o.
 bez PSC
 
 
 4x body nad vchody (ale soucasty cesy domu) 
 to same, co je vyse, ovsem s addr:housenumber  ve tvaru c.p./c.o. 
 entrance=yes
 addr:street 
 addr:streetnumber 
 addr:postcode
 ref:ruian=cislo adresniho mista
 
 Tohle mi prijde, jako ze presne kopiruje maximum informaci, ktere z RUIAN mame
 a dava to nejvetsi smysl. Jedine, co tam takhle neni, je ta vazba mezi SO a AM
 (resp. je zakreslena v mape, ale to nekdy nemusi tak byt, a bude-li AM lezet
 mimo SO, pak tam zadna vazba neni, ovsem sla-by pridat, ale myslim, ze vlastne
 k nicemu neni)

Přiznám se, že mně to teda moc smysl nedává... Ani jeden objekt
neobsahuje celou adresu (to co bych psal na obálku). Pokud tedy
přistoupíme na to, že si to každý dopočítá sám, tak nemá smysl uvádět
addr:city=Praha
addr:country=CZ
protože tyhle ǘdaje jsou v mapě jako hranice s admin_level=8, resp.
admin_level=2.

Ad dopočítávání:
Celkem je v databázi ~ 3 miliony adresních míst, z toho 2 miliony mají
geometrii definičního bodu a zároveň odkazovaný stavební objekt má
geometrii hranice.
Z těch 2M míst cca 6% NEleží uvnitř geometrie stavebního objektu. To by
se mohlo zdát jako celkem vysoké číslo, ale ono to bude souviset s
dalšíma buguma v RUIANu (chybějící budovy, zakreslena jen část, ...)
Když jsem se díval na vzdálenosti, tak sice existují rekordmani s
hodnotou ve stovkách kilometrů :-) ale moc toho není.
Z těch 2M míst jen 0.9% má vzdálenost SO a AM větší jak 10 metrů.


 Jedina drobna chyba je, ze to v nekterych (ale podle me velmi ridkych) 
 pripadech
 bude vest ke dvojimu zobrazeni cisla v mape. Ale jen pri velkem zvetseni, 
 jinak
 je videt jen jedno cislo. Zkousel jsem to.
 
 Druha vetsi chybka je, ze to nejde aplikovat na to jedno procento
 s.o., ktere fakt maji vice c.p. nebo c.e.
 Sice by to slo v housenumber a consriptionnumber oddelovat strednikem, ale to 
 je velka prasarna.
 Spise bych si myslel, ze by Trace v tohmle miste zobrazit informaci,
 ze SO ma vice c.p. nebo c.e. a rekl, ze je tudiz nenatagoval a doporucil
 uzivateli, aby dum rozdelil na adekvatni mensi casti, nebo tak neco.
 
 Treba tak (protoze ty priklady domu, ktere jsem zatim videl, tomu odpovidaly),
 ze celou cestu SO nakreslenou dle RUIAN oznaci jako building=terrace ci 
 building=garages,
 a pak ji rozdelit na podbudovy building=house nebo building=garage 
 a ty uz otagovat spravne i s housenumber a conscription number.

A třetí chyba je to, že není pravda, že 1 stavební objekt = 1 OSM cesta.
Jedna budova je v OSM občas nakreslena pomocí více cest, např. pro
zmapování rozdílného počtu podlaží (výšky, ...) nějaké části budovy.

Zdraví,
Petr Morávek aka Xificurk

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

Re: [Talk-cz] Tracer plugin - ruian update

[Petr Morávek [Xificurk]]

Dne 5.2.2014 10:33, Dalibor Jelínek napsal(a):
 Přiznám se, že mně to teda moc smysl nedává... Ani jeden objekt
 neobsahuje celou adresu (to co bych psal na obálku).
 Jak to? Vsechny ctyri vchody obsahuji uplnou adresu.
 Vzdyt tam pisu  to same, co je vyse, ovsem s addr:housenumber  ve tvaru 
 c.p./c.o.

Aha, to jsem nějak pro změnu přehlídl já :/
Ale obecně se mi ta duplikace dat stejně nelíbí.

Petr

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

Re: [Talk-cz] Posuny - pokus o zpřesnění

[Petr Morávek [Xificurk]]

Ahoj,

Dne 5.2.2014 19:33, Petr Vejsada napsal(a):
 (st_transform(st_setsrid(st_transform(hranice,5514),999),900913))
 Je to podle mých očí jen horší. Proč?
 
 Já teda do těch transformací moc nevidím, ale není možné, že se tam
 kumuluje nějaká chyba tím převodem tam a zpátky?
 
 Asi ne. Vytvořil jsem nové schema a naimportovat Aš, Šluknov, Vyšší Brod, 
 Třinec a Jablunkov a podle oka mi to přijde úplně stejné a úplně stejně 
 špatně, jako v předchozím případě. To je opravdu zvláštní. Definici projekce 
 5514 mám od tebe, grid mám od tebe a s výsledkem nejsem spokojen, kdežto ty 
 se 
 svými daty ano. Je to horší než bez gridu. A mám stejný pocit, jako Marián, 
 že 
 grid to koriguje v podstatě správně, správným směrem, jen s opačnou orientací.

Ahaaa! Teď mi to teprve došlo - on byl RUIAN zpočátku (a v té době jsem
zkoumal přesnost) v jiné projekci. Původně to bylo EPSG:2065 a nyní
EPSG:5514, která se pokud vím liší právě v prohození souřadnic a změně
znamének. Já blbec ten grid slepě bez kontroly převzal... takže ten grid
je teď úplně mimo... chtělo by to najít zdrojová data a přegenerovat pro
5514.

 Já si teď u sebe pustím nový čerstvý import RUIANu a pak můžem porovnat
 výstup na nějakém konkrétním stavebním objektu, což?
 
 Tož to bychom měli. V jakém souřadnicovém systému máš RUIAN? Já v 900913 
 kvůli 
 vykreslování dlaždic. Mohu ti někde vystavit nějakou část, asi stačí kod a 
 hranice a nechat si třeba v qgisu ukázat st_diff

Já to nechávám v originále a transformuji až on-demand, podle toho na co
to používám. (Pokud chci počítat vzdálenosti dvou objektů, tak je lepší
to dělat v 5514.)

Zdraví,
Petr Morávek aka Xificurk

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

Re: [Talk-cz] Tracer plugin - ruian update

[Petr Morávek [Xificurk]]

Dne 4.2.2014 08:51, hanoj napsal(a):
 http://www.kma.zcu.cz/main.php?KMAfile=./STRUCTURE/05_ebooks/04_Zaverecne_prace/zav_prace.phpDRC=./STRUCTURE/05_ebooks/04_Zaverecne_prace/DRL=CZDROF=0osCislo=52920
 
 cituji Honzy Ježka:
 - Diplomka otestovala postup a výsledek byl, že metoda lze aplikovat  s
 dostatečnou přesností, ale odovzení a finální výpočet gridu byl
 - vytvořen jen pro malé území. S odvozením pro celou CR jsme měli nějaké
 technické problémy s R, ktere se nepodarilo vcas vyresit a ted
 - nemam paky jak to dotahnout, ale zkouším to. Na podzim taky probehla
 komunikace s CUZK o odvozeni 'oficialni' verze gridu, ale v
 - poslední době to usnulo.
 
 
 ha
 hanoj

Jestli to byly jen technické problémy, tak to bysme to tu mohli
komunitně dotáhnout :-)

Ale zatím se mi podařilo proklikat jen k textu diplomky. A bohužel během
té chvilky, co jsem tomu věnoval, tak jsem úplně nevykoukal, kde vzít
data a co s nima krok po kroku udělat, aby nakonci vypadl grid pro celou
republiku.

Petr


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

Re: [Talk-cz] Posuny - pokus o zpřesnění

[Petr Morávek [Xificurk]]

Ahoj,

Dne 4.2.2014 18:31, Petr Vejsada napsal(a):
 Ahoj,
 
 udělal jsem experimentální vrstvu s budovami, která, pokud jsem něco 
 nezvoral, 
 by měla být podle Xificurka s použitím gridu, ale možná jsem fakt něco 
 nedomyslel, pže to dopadlo nic moc.
 
 http://pedro.poloha.net/mapa , url vrstvy je 
 http://tile.poloha.net/temp_budovy/z/x/y.png
 
 Jak jsem postupoval:
 
 - zavedl jsem fiktivní SRID 999 do spatial_ref_sys, kde jsem změnil proj4text 
 tak, jak to má Xificurk
 - stáhnul jsem si grid podle Petrova odkazu (btw: Petře, pokud to čteš, ta 
 zdrojová forma by nebyla?)

bohužel git.zcu.cz se zdá opravdu mrtvý... a já bohužel ten zdrojový
soubor nikde na disku nemám, ale podařilo se mi ho dohledat v archivu:
http://web.archive.org/web/20091003020944/http://git.zcu.cz/grid/czech.lla
Nicméně je to z roku 2009, tak nevím jestli to je stejná verze.


 - zkopíroval tabulku s geometriemi budov
 - updatnul geometrii takto:
 
 update temp_budovy set hranice= 
 (st_transform(st_setsrid(st_transform(hranice,5514),999),900913))
 
 
 což by mělo dělat, že se z 900913 geometrie přepočítá zpět na 5514 a podle 
 gridu se zase přepočítá zpátky do 900913.
 
 Je to podle mých očí jen horší. Proč?

Já teda do těch transformací moc nevidím, ale není možné, že se tam
kumuluje nějaká chyba tím převodem tam a zpátky?

Já si teď u sebe pustím nový čerstvý import RUIANu a pak můžem porovnat
výstup na nějakém konkrétním stavebním objektu, což?

Zdraví,
Petr Morávek aka Xificurk

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

Re: [Talk-cz] Tracer plugin - ruian update

[Petr Morávek [Xificurk]]

Ahoj,

Dne 5.2.2014 07:43, Dalibor Jelínek napsal(a):
 A jaky teda mas stavebni objekt prirazen tady?
 http://vdp.cuzk.cz/vdp/ruian/adresnimista/40037649
 O tomhle adresnim bode jsem ti psal drive psal v mailu.
 Mel jsem dojem, ze tohle misto ve sve databazi nemas.

Odkazuje na http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/30119138
Ale je zajímavé, že přímo adresní bod nemá žádnou pozici (definicni_bod
= NULL), a stejně na tom je celkem cca 6% adresních bodů. A podle webu
RUIAN je tohle asi bug, na jehož odstranění se pracuje.

Zdraví,
Petr Morávek aka Xificurk

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

Re: [Talk-cz] Tracer plugin - ruian update

[Petr Morávek [Xificurk]]

Dne 5.2.2014 07:41,  JV napsal(a):
 Zdravím,
 omlouvám se, ale opravdu se bavíme o číslech popisných? Zrovna u
 Technické knihovny v Dejvicích vidím jen jedno číslo popisné a 4 čísla
 orientační:
 http://vdp.cuzk.cz/vdp/ruian/adresnimista/vyhledej?ob.kod=554782ul.kod=co.kod=400459mc.kod=500178so.kod=27239781vo.kod=search=Vyhledat
 Více čísel popisných by bylo vidět jak v grafice VDP
 (http://vdp.cuzk.cz/marushka/?themeid=1MarUid=DDB04061%206EAC62F2MarUidi=0D3E163B%2076073BA4%20DDB04061%20E4699646%206EAC62F2MarMiddlePoint=-744741.2141709006%20-1040895.0606261094MarScale=857),
 tak v Nahlížení do KN
 (http://sgi.nahlizenidokn.cuzk.cz/marushka/default.aspx?themeid=3MarUid=7E6595D2%20A5AD9D88%208244EA23MarUidi=8244EA23MarMiddlePoint=-744781.5201761102%20-1040865.3080245024MarScale=1996).
 
 Raději ještě jednou:
 - číslo popisné / evidenční je unikátní v rámci části obce a nesmí se
 používat opakovaně (tedy číslo po zrušené budově nelze přidělit jinému
 objektu). Popisná a evidenční čísla tvoří dvě samostatné řady.
 - číslo orientační by mělo určovat pořadí budovy v rámci ulice nebo
 náměstí, nejsou povinná
 Viz http://cs.wikipedia.org/wiki/Ozna%C4%8Dov%C3%A1n%C3%AD_dom%C5%AF
 
 J. Veselý
 

Ano, v případě NTK jde o 1 č.p. a 4 čísla orientační.

Ona ta struktura dat není vůbec jednoduchá... uvedu na příkladu NTK:

Co nám říká stavební objekt 27239781:
- kód městské části (Praha 6)
- kód části obce (Dejvice)
- čísla domovní (2710)
- jedná se o budovu s č.p.

K tomuto objektu se váží 4 adresní místa, která nesou informaci o:
- kód stavebního objektu (27239781)
- číslo domovní (2710)
- kód ulice (4 různé hodnoty - Flemingovo nám., Studentská, Technická,
Thákurova)
- číslo orientační (4 různé hodnoty - 6, 1, 20, 13)
- PSČ (16000)

A teď zkuste někdo popsat, jakým způsobem z těchto dat dostat adresu,
která by se měla umístit přímo na budovu v OSM.

Zdraví,
Petr Morávek aka Xificurk

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

Re: [Talk-cz] Tracer plugin - ruian update

[Petr Morávek [Xificurk]]

Dne 3.2.2014 16:08, Dalibor Jelínek napsal(a):
 - a dokonce, možná pro někoho kontroverzně, bych přidal i adresní tagy 
 (addr:country, addr:city, addr:place, addr:*number )
 
 Tady bych to asi měl odůvodnit. Původně jsem byl skalním zastáncem teorie,
 že adresní body by měly být jen v bodech. Vycházel jsem z toho, že jsem byl 
 přesvědčen, že jejich hlavní zdroj, tedy KM a RUIAN, je jako body mají 
 a proto budoucnost je v bodech.
 Teď ale vidím, že číslo popisné/evidenční je vlastnost domu, tedy té cesty.
 Je to koneckonců logické, protože to číslo je přidělováno domu, ne bodu.
 A taky je vedeno v RUIAN jako vlastnost stavebního objektu.
 Adresní bod z RUIAN je pak opravdu bod, který navíc obsahuje PSČ
 a číslo orientační (je-li přiděleno).
 Takže by se mi zdálo vhodné i logické, aby se ta informace vlastně zadávala
 dvakrát. Jednou k cestě domu jen číslo popisné/evidenční a to k celému domu.
 A pak, jsou-li definované adresní body, tak znovu na body, které by bylo 
 ideálně
 mít ručně posunuté nad vchody, které jsou těmi čísly orientační označené.
 Je mi jasné, že je se tím vnáší do OSM nějaká data navíc, ale nemyslím, že by
 to mělo nějak zásadně vadit. Navíc se může stát, a stává se, že existuje
 adresní bod s jiným číslem popisným, než má v RUIAN budova. Pak nevím,
 co mám vlastně tagovat a takhle bych tam otagovat oboje i s příslušným
 odkazem ref na RUIAN databázi.
 Co myslíte? Něco jsem přehlédl?

Ahoj,

úplně mi není jasné, kde jsi to vykoukal.

Já teda v tabulce stavebního objektu vidím
cisla_domovni| integer[]

tj. výčet čísel popisných vztahujících se k danému objektu. Osobně mi
není moc jasné, proč tam tento sloupec je, protože stejná data by mělo
vrátit:
SELECT stavobj_kod, array_agg(cislo_domovni) FROM rn_adresni_misto GROUP
BY stavobj_kod;

Vztah stav. obj. : adresní místo je typu 1:N, resp. existují objekty,
bez adresního místa.

Zdraví,
Petr Morávek aka Xificurk

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

Re: [Talk-cz] Tracer plugin - ruian update

[Petr Morávek [Xificurk]]

Dne 26.1.2014 22:48, Marián Kyral napsal(a):
 *) Přidal jsem konfiguraci. Dá se nastavit vlastní adresa serveru a
 případně i posunout polohu natrasované budovy. Třeba tady u nás v
 Beskydech je RUIAN oproti KM mírně posunutý (asi přepočet, ale je to
 mnohem lepší než KM). Pro RUIAN to funguje, u KM moc ne. Ten mi každou
 budovu vrátí s trochu jiným posunem :-(

Ahoj,

jen k tomu posunu - určitě je na serveru správně nastavena projekce?

Používám následující nastavení už celkem dlouho a co jsem koukal, tak sedí:
binárka gridu:
https://dl.dropboxusercontent.com/u/75839328/proj/czech
sql pro postgis:
https://dl.dropboxusercontent.com/u/75839328/proj/krovak.sql

Původní (ascii) zdroj gridu http://git.zcu.cz/grid/czech.lla se zdá
momentálně mrtvý...

Zdraví,
Petr Morávek aka Xificurk


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

Re: [Talk-cz] RUIAN nad OSM

[Petr Morávek [Xificurk]]

Dne 11.1.2014 09:27, Marián Kyral napsal(a):
 Ad import budov)
 Kromě toho, že některé budovy v RUIAN chybí, jsou i takové, které
 přebývají.
 Třeba ulice Na Poříčí, mezi vlakovým a autobusovým nádražím. Tam je
 obrovská
 parcela, kde sice byly budovy, ale před několika lety je srovnali se zemí
 a teď tam roste jen tráva. Pokud by jsi provedl automatický import, budovy
 by se opět objevily. Asi bych se prvně zaměřil na místa, kde zatím není
 vůbec nic. Tam to pak stejně musí někdo znalý revidovat.
 
 Případně, bylo by možné udělat něco na způsob traceru? Tedy, že kliknu do
 mapy v místě, kde je nějaká budova, plugin se spojí s nějakým serverem a
 vrátí
 tvar budovy z RUIAN. Taky by tam mohla být volba Importuj vše v okolí pro
 místa, kde ještě vůbec nic není. Ať to není třeba dělat po jedné.

Ahoj,

bohužel kvalita budov v RUIAN není nijak dobrá. Já jsem narazil na to,
že některá (části) budov jsou označeny jen jako zastavěná plocha a
naopak zastavěné plochy jsou označeny jako budova. Navíc se občas objeví
docela hnusné artefakty přímo v geometriích.

http://maps.fordfrog.com/?zoom=17lat=50.02363lon=15.77651layers=B00FFF
http://mapy.cz/#!x=15.774797y=50.023553z=15l=15

Pokud tedy bude opravdu nějaký import budov probíhat, tak rozhodně
nemůže být automatický, spíš opravdu něco na styl traceru.

Zdraví,
Petr Morávek aka Xificurk

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

Re: [Talk-cz] RUIAN nad OSM

[Petr Morávek [Xificurk]]

Dne 6.1.2014 13:39, Petr Vejsada napsal(a):
 Ahoj,
 
 Dne Po 6. ledna 2014 12:20:01, Dalibor Jelínek napsal(a):
 
 Cau,
 tady je pro porovnani neco obdobneho
 http://maps.fordfrog.com/

 Nektere budovy skutecne chybi, zejmena venkovske stodoly a tak.
 Nekdo tu snad pro to mel i nejake vysvetleni, tak zkus prohledat archiv.
 
 problem znacne casti chybejicich budov jsem, zda se, objevil a vyresil. Slo o 
 pouziti geometrie kruhu a kruhovych vyseci, ktere Mapnik (a ani Qgis) neumi. 
 Postgis nastesti umi kruhove vysece aproximovat na cary ci polygony, ostatne 
 jak se kresli kruhy v OSM? ;-), takze:

Lepší je požít přepínač --linearize-ewkt v ruian2pgsql, takhle se
převedou oblouky rovnou při importu. Navíc to řeší jeden problém, kterým
trpí st_curvetoline - výsledná aproximace oblouku v st_curvetoline
závisí na orientaci tohoto oblouku, což je problém pokud máte dva
polygonu se sdílenou obloukovou hranicí, tak po projetí přes
st_curvetoline se tento sdílený kus hranice ztratí (hranice se v tom
místě budou nepatrně lišit).

 alter table rn_stavebni_objekt add column hranice_original geometry;
 update rn_stavebni_objekt set hranice_original = hranice, hranice = 
 st_curvetoline(hranice) where st_hasarc(hranice);
 
 Totez pro parcely. U ulic jsem zadny oblouk nenasel.
 
 Objevila se tak treba nova budova technicke knihovny (ktera ma pekne rohy do 
 oblouku).
 
 Ono take plati, ze ne vsechny budovy jsou katastrem evidovane, coz bude dalsi 
 duvod, proc neco chybi.
 
 Take obcas maji barak misto dvora a nic misto baraku, to bych jim asi mel 
 napsat, pokud nenajdu chybu u sebe. Priklad - velky rohovy dum, je to roh 
 Slezske a Hradecke v Praze na Vinohradech smerem jihovychod od Palace Flora. 
 Uprostred vnitrobloku je bar Infinity,  v tom dotycnem rohovem dome je 
 prodejna 
 Albert, c.p. 2526. V katastru je ten dum nakresleny na miste, kde je ve 
 skutecnosti vnitroblok a dum jako takoby chybi. V OSM je to spravne. Dum ma v 
 RUIAN ID 24704873.

Jo, takových problémů tam je bohužel spousta. Já jich u nás v
Pardubicích našel opravdu hodně.

 Jeden blok na vychod, hned pres ulici, jsou v tom bloku hned 2 domy spatne 
 zakreslene, a to vcetne adresnich bodu. Je to divne.
 

 Vsiml jsem si, ze ty adresy nejsou uplne dokonale.
 U nekterych domu, ktere maji jedno c.p., ale vice c.o.
 tam mas nakresleno jen jednu adresu c.p./c.o., ale zbyla c.o. chybi uplne.
 Pocitam, ze vsechna c.o. v RUIANu asi nejsou?
 
 Tohle jeste presne nevim. Na mape zobrazuji adresni mista, nikoli cisla domu. 
 Cisla domu jsou v tabulce stavebnich objektu jako pole, takze ano, dum muze 
 mit vice cisel, ale v tomto pripade jde o cisla popisna. Presneji jeden 
 stavebni objekt muze mit vice adresnich mist i cisel popisnych. Cisla 
 oriantacni jsou tak trochu mimo a mohou, ale nemusi byt soucasti adresniho 
 bodu. Zrovna ten rohovy dum, o kterem pisu v predchozim textu, tak je sice 
 spatne zakresleny v katastru, ale ma dve adresni mista - 2526/113 (Slezska 
 ulice) a 2526/3 (Hradecka ulice). Adresni body jsou pritom v katastri i v OSM 
 spravne.
 
 
 Objevily se ted po uprave ty stodoly, ktere ti chybely?


Zdraví,
Petr Morávek aka Xificurk


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

Re: [Talk-cz] Adresy a is_in, RUIAN

[Petr Morávek [Xificurk]]

Dne 1.1.2014 20:54, Petr Vejsada napsal(a):
 Ahoj,
 
 díky moc za info, to je skvělá zpráva. addr:place by se dalo doplnit a zdá 
 se, 
 že automaticky..
 
 Existuje 213.959 adresních míst bez ulice a bez addr:place, přičemž 211.534 z 
 nich má tag is_in a tedy 2.425 adresních míst tento tag nemá.
 
 Adresní tagy se vyskytují ve všech třech typech, tedy uzlech (209.852), 
 cestách (4.375) i relacích (2).
 
 Mapnik vykresluje adresy jen u bodů. Podle pravidel na 
 http://wiki.openstreetmap.org/wiki/Key:addr je povoleno používat tyto tagy na 
 cestách, takže vlastně jde o (chybnou) konfiguraci Mapniku.
 
 Z is_in by se tedy dalo vytáhnout adresní místo (zdá se, že to je to první), 
 které by se použilo jako addr:place. U těch 2.425 by šlo použít addr:city 
 jako 
 addr:place, případně to nechat být, případně těch 2-425 míst zkouknout očima 
 a 
 rozhodnout, co s tím.
 
 Prosím tedy komunitu o vyjádření, zda se to zdá jako dobrý nápad a mohu se do 
 toho pustit. Je to docela rozsáhlý zásah do dat. Myslím, že udělat cca 
 200.000 
 adres dohledatelnými by nebylo špatné.
 
 --
 Petr

Ahoj,

(polo)automaticky ano, ale přijde mi jako hodně špatný nápad to dělat
parsování is_in tagu, protože tam opravdu může být cokoliv. Správně by
bylo matchnout jednotlivé body na údaje z RUIAN a doplnit addr:place z
této databáze.

Zdraví,
Petr Morávek aka Xificurk


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

Re: [Talk-cz] Adresy a is_in, RUIAN

[Petr Morávek [Xificurk]]

Dne 2.1.2014 00:10, Petr Vejsada napsal(a):
 Ahoj,
 
 díky za názor. Ono to nebude tak hrozné. Ano, může tam v ojedinělých 
 případech 
 být cokoli.
 
 Pohleďme na tabulku četností výskytu tagu %source% v předmětných adresních 
 místech:
 
  count  |k|  v
 +-+--
   1 | source  | http://www.autolibra.cz/
   1 | source  | http://www.pension-libra.cz/
   1 | source  | ruian
   1 | source:addr | mvcr:adresa;ruian
   1 | source:name | wikipedia
   2 | source  | local knowledge
   3 | source:position | cuzk:km
  45 | source  | cuzk:kn
  46 | source  | cuzk:km
 309 | source  | mvcr:adresa
 684 | source:loc  | cuzk:km
1091 | source:addr | mvcr:adresa
  202194 | source:addr | ruian
 
 S drtivou převahou vede právě RUIAN. Ano, i tyto položky mohl někdo editovat 
 a 
 napsat do is_in nějaký nesmysl. Kolik jich bude?

Nemám tušení... ona to totiž není jen otázka toho, jestli to někdo od
importu zeditoval nebo ne. Já totiž vůbec nemám přehled, co, kdo, při
jakém importu do tohodle tagu házel, ty ano, je to někde rozumně
zdokumentováno? Myslím si, že pokud se něco opravuje, tak by se to mělo
opravit pořádně.

 Proč se vlastně při importu těchto míst z RUIAN nepřidával tag addr:place? 
 (víceméně řečnické otázky).

To je dobrá otázka, před nedávnem jsme se o tom v jednom vlákně bavili...

 To vyvolává další otázky, jako třeba:
 
 Importovat z RUIAN addr:place jen tam, kde není ulice, nebo úplně všude?

Taky už jsem psal ve vedlejším vlákně (včetně odůvodnění) - já jsem pro
to všude a obsahem by měl být název části obce.

 číslo 
 popisné je jedinečné v katastrálním území, tedy mělo by být možné nalézt dům 
 v 
 katastrálním území i bez znalosti ulice.

Tady se pleteš, č.p. není jedinečné v katastrálním území, ale v části
obce.

 To dnes v Nominatimu nelze. Pak je tu 
 další věc, která souvisí jen okrajově, ale je to věc, která se mi honí 
 hlavou. 
 V OSM vůbec nejsou městské části (nebo jsem slepý).  Nemělo by se uvažovat o 
 zavedení městských částí? (Praha 1, Praha 2 atd.)

Otázkou je v jaké formě a k čemu by to mělo být vlastně dobré. Mě osobně
jejich absence moc netrápí. Mám zkušenosti z Prahy, kde sice vím kde
jsou Vinohrady, Smíchov, atd., ale fakt netuším, jestli to je Praha 1,
2, 3, 4, 5... A podobně jsem na tom doma v Pardubicích.

 Zpět k původnímu tématu - srovnat to s RUIAN momentálně nezvládnu, protože 
 nejsem schopen importovat RUIAN do Postgisu. Skončím na hlášce:
 
 Exception in thread main org.postgresql.util.PSQLException: ERROR: geometry 
 contains non-closed rings
   Hint: ... -1058212.19,-746762.81 -1058118.93)) -- parse error at 
 position 
 3490 within geometry

Co přesně pouštíš za příkaz? Já jsem RUIAN importoval před pár dny bez
problémů.

 a přitom mám switch --ignore-invalid-gml, takže by to mělo běžet dál. Verze 
 ruian2pgsql je aktuální kompilovaná z gitu, do spatial_ref_sys jsem také 
 přidal projekci 5514, takže nevím. Jdu spát _)
 


Zdraví,
Petr Morávek aka Xificurk

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

Re: [Talk-cz] Ruian jako zdroj dat

[Petr Morávek [Xificurk]]

Dne 6.12.2013 12:15, Pavel Machek napsal(a):
 Ahoj!
 
 a co je to to?
 addr:city?
 nebo myslis i addr:country? 
 
 Oboji.
 
 Nastavit to podle obrysu zeme / mesta je relativne jednoduchy, ale
 dava smysl mit to v databazi -- at to nemusi kazdy delat znovu.
 
 Vsimnete si, ze treba navigacni software (navit, monav) ma problem s
 urcenim ve kterym meste je ulice. Ano, na velkym PC je to asi nejaky
 jednoduchy dotaz na spatiallite, ale databaze pro navigaci ma vyrazne
 jinou strukturu (a v navigaci neni dost RAM/disku na spatiallite).
 
 K tomu melo byt is_in... ale to je nestastne bez struktury. Davalo by
 smysl mit addr:city / addr:country na ulicich?
 
   Pavel

Ahoj,

přiznám se, že konkrétní zkušenosti s těmito prográmky nemám, ale přijde
mi, že není problém ten index vytvořit ve chvíli, kdy exportuju data z
OSM pro navigaci, ne?

Osobně mi přijde jako nesmysl mnohokrát duplikovat ta samá data v OSM,
jen aby to trochu usnadnilo všechny myslitelné i nemyslitelné způsoby
jejich použití...

Petr


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

Re: [Talk-cz] Fwd: rozdělení multipolygonu

[Petr Morávek [Xificurk]]

Dne 4.12.2013 09:30, Zdeněk Pražák napsal(a):
 Dobrý den, při kreslení budov zároveň upřesnuji zakreslení lesů.
 Při tom jsem narazil na les (cesta č. 26016351) po jehož úpravách mi
 JOSM píše, že počet uzlů v této cestě přesahuje maximální povolený počet
 uzlů 2000 a nechce provedené změny nahrát.
 Jak mám rozdělit tento multipolygon?
 Pražák

Cesty rozdělit (na dva, příp. více částí), vytvořit multipolygon relaci
a přidat do ní tyto cesty, viz

http://wiki.openstreetmap.org/wiki/Multipolygon

Zdraví,
Petr Morávek aka Xificurk

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

Re: [Talk-cz] Fwd: rozdělení multipolygonu

[Petr Morávek [Xificurk]]

Dne 4.12.2013 09:34, Zdeněk Pražák napsal(a):
 opravuji číslo cesty 26019351
 Pražák

A tady dokonce už ta multipolygon relace existuje (24038)...
Jen teda všechny tagy, které patří celému území vymezenému
multipolygonem (landuse=forest), by měly být na relaci a už ne na
jednotlivých cestách.

Zdraví,
Petr Morávek aka Xificurk

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

Re: [Talk-cz] Ruian jako zdroj dat

[Petr Morávek [Xificurk]]

Ahoj,

Dne 3.12.2013 16:38, Dalibor Jelínek napsal(a):
 U části obce bez pojmenovaných ulic to jde a žádná informace se neztratí. 
 Tedy jsem pro.
 addr:city = obec
 addr:place = část obce
 Tohle se mi asi nelíbí, ale nejsem si jist. Máš nějaký příklad?
 Pointa addr:place je, že se pak dá najít adresa v obci bez ulic.
 A co budou uživatelé hledat více obec nnn nebo část obce nnn?
 Jestli to první, pak je potřeba do addr:place dávat obec
 a část obce dát někam jinam (třeba addr:is_in?).

Obecně čemukoliv, co obsahuje is_in bych se snažil vyhnout. Název tagu
by měl lépe popisovat, co to vlastně obsahuje za data - is_in (příp.
addr:is_in) je strašně obecné. To je ostatně taky jeden z důvodů, proč
je is_in v současné době naprosto nepoužitelný - každý si tam cpe, co
chce.

Myslím, že by bylo dobré nějakým způsobem do všech adresních bodů dostat
jméno části obce, a to protože:
1) č.p. je unikátní jen a právě v rámci tohoto administrativním celku
2) část obce není vymezena geografickou hranicí, ale právě výčtem
adresních bodů
Osobně mi přijde addr:place jako celkem rozumná volba.


 addr:city = obec
 Tady si nejsem jist, páč naše wiki říká, že je to název vesnice za PSČ
 Skutečně je to vždy stejné jako hranice obce a dá se to odvodit z mapy?

Tady pozor! Ta skladebnost funguje trochu jinak.

Obec je tvořena 1 a více částí obce.
Část obce je vymezena výčtem adresních bodů, které do ní patří.

Vedle toho stojí PSČ, které je AFAIK více méně číselným identifikátorem
pošty. Vztah pošty (potažmo tedy PSČ) a části obce je N:M.

Zdraví,
Petr Morávek aka Xificurk

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

Re: [Talk-cz] Opravdu nen? ??dn? shoda o adresn?ch bodech?

[Petr Morávek [Xificurk]]

Dne 12.10.2013 17:21, Pavel Machek napsal(a):
 Hi!
 
 Pokud se nepletu, hanoj tady pred nedavnem psal, jak se tyhle veci
 resi efektivne pomoci databaze - je to jeden dotaz nad
 geoprostorovou databazi, ktera se z OSM dat da naplnit skriptem za
 par sekund. Pokud to samozrejme chces resit algorimticky bez
 databaze, je to slozitejsi. Je to tedy spis diskuze o prostredcich a
 pripadne o jejich znalosti a neznalosti. Ale urcite neni geodatabaze
 nejake scifi, co by neumel nikdo pouzit - s navodem na wiki jsem si
 ji sam rozbehl a co rict - funguje to.
 
 Uz se tesim jak budu na telefonu rozbihat postgresql, nebo cim se to zrovna
 dneska dela...
 
 Ja nerikam ze to nejde, ja rikam ze je to blbe a ze kazdy kdo to bude 
 delat v tom bude mit jiny chyby... a ze by davalo smysl projet to skriptem
 (jednou, referencne) a ulozit to v databazi explicitne.

Ahoj,

tenhle problém podle mě nemá jednoduché řešení přímo v datovém modelu OSM.

Problémy jsou následující:
1) vazba adresa - OSM budova je typu N:M
2) více POI může sdílet jednu adresu
3) více POI často nemůže mít tagy na jednom OSM objektu kvůli jejich kolizím
4) vazba OSM budova - reálná budova je typu N:M

Duplikovat adresní tagy na více místech je imho fuj, fuj.

Řešením podle mě je, jak ostatně píše i ty, nějaký pre-processing
surových OSM dat do podoby, která bude vyhovovat konkrétním požadavkům.
Data OSM jsou různorodé kvality a mixují různé druhy tagování - snažit
se všechny donutit k nějaké konformitě v tagování je bohužel dost nereálné.

Ano, je tu šance, že tu bude více nástrojů snažících se o to samé a
každý bude dávat trochu jiné výsledky... no a?

Zdraví,
Petr Morávek aka Xificurk

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

Re: [Talk-cz] Opravdu nen? ??dn? shoda o adresn?ch bodech?

[Petr Morávek [Xificurk]]

Dne 10.10.2013 09:53, Petr Holub napsal(a):
 Ahoj,
 
 Doufám, že jsem ten dotaz na overpass pochopil správně:

 ten dotaz zněl: vypiš všechny body typu cykloshop v areaXY, kde areaXY
 byla area města Brna.

 Když bychom řekli, že chceme adresní body uvnitř jiné area, je to stejné.
 
 doplnujici dotaz :) - dokazal bych pres Overpass API udelat query,
 ktere by mi vratili v dane oblasti (napr. Brno) vsechny cykloobchody
 a jejich adresy? To mi prijde jako zajimavejsi - protoze to znamena,
 ze v dane oblasti musim najit vsechny body typu cykloshop a pro
 kazdy z nich najit adresni bod, ktery je umisten ve stejne budove
 (za predpokladu, ze tedy cykloshop je umisten uvnitr budovy).
 V pripade, ze dana budova ma vice jak jednu adresu, tak vypsat
 vsechny adresy.
 
 Docela by mne zajimalo, jak na to. :)
 
 Diky,
 Petr

Ahoj,

na tohle úplně Overpass API není určené... jeho primární účel je výběr
dat z databáze podle zadaných kritérií. Můžeš tedy vybrat vsechny cyklo
obchody + vsechny adresní body, které jsou max. X metrů vzdálené od
nějakého obchodu.
Napárování obchod č. 42 - adresa č. 6, si už musíš udělat sám...

Zdraví,
Petr Morávek aka Xificurk


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

Re: [Talk-cz] číslo evidenční v addr:housenumber

[Petr Morávek [Xificurk]]

Dne 2.10.2013 10:34, Dalibor Jelínek napsal(a):
 byly tu vášnivé diskuse na téma jak máme dodržovat každou pikatchovinu co
 si zrovna ÚJČ vycucá z palce, 
 ale toto flagrantní porušení pravidel najednou nevadí?
 Většině lidí zjevně nevadí, mně se to zdá hezčí bez mezery a i pravidla
 říkají,
 že výjimečně se tam mezera nepíše, tak se na to můžeme dívat jako na další
 výjimku. ;-)

Cože?!? A to prosím kde?

(Ale jinak chápu argument se změnou několika desítek nodů vs. několika
stovek tisíc... škoda že převažuje ta špatná verze)


Zdraví,
Petr Morávek aka Xificurk


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

Re: [Talk-cz] číslo evidenční v addr:housenumber

[Petr Morávek [Xificurk]]

Dne 27.9.2013 14:05, Dalibor Jelínek napsal(a):
 Umíte někdo vytáhnout z Overpass API sestavu všech bodů s
 addr:provisionalnumber?
 Když zvolím takový obdélník, že je v něm celá ČR, tak mi to browser
 nezvládne.

Na http://www.overpass-api.de/query_form.html zadej tohle:

query type=node
  area-query ref=3600051684/
  has-kv k=addr:provisionalnumber/
/query
print mode=meta order=quadtile/

Zdraví,
Petr Morávek aka Xificurk

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

Re: [OSM-talk] osm2pgsql multipolygon parsing

[Petr Morávek [Xificurk]]

Dne 23.9.2013 11:59, Paul Norman napsal(a):
 Unless the closed way is a member of a multipolygon relation with no other
 tags on the relation - then you'll have a resulting area with a hole. This
 is a very well established means of tagging areas with holes (~22% of
 type=multipolygon relations have no other tags).

Yes, but if the relation has any[*] additional tags, you can't reliably
decide what was the intended purpose of this tagging. Imho the only
logical thing is to treat the relation and ways separately.
[*] Maybe some internal keys could be ignored, e.g. odbl, fixme, ...

 The issues raised originally in the ticket are best explored through
 examples
 
 The first case is a way with natural=water and a MP relation with no other
 tags. Both old osm2pgsql (0.82) and latest master version from git create an
 area with a hole with natural=water on the area. There are no suggestions of
 changing this.

Agreed.

 The second is a way with natural=water and a MP relation with name=foo (with
 the way as a member). Old osm2pgsql created an area with a hole with
 natural=water, name=foo, latest master does too.

Is this really correct?
In case of the name=foo it is probably safe assumption, but how about
multipolygon relation with only access=* tag (or something similar)? How
do you decide, if it means the area with holes is
natural=water+access=*, or that the whole area (with no holes) is
natural=water and only some parts have access=*?

 The fourth is a way with natural=water and a MP relation with foo=bar. In
 old osm2pgsql this created an area without a hole, in latest master it
 depends on the .style file used for import.

The dependence on on the .style file bothers me, I think it's a mistake
and will ultimately come back to haunt us. If you don't care about some
features and delete the lines from your .style file, the multipolygon
parsing should not change.

--

I propose that:
1) By default the relation and ways are treated separately
 - relation creates polygon with tags from the relation and ways are
processed on their own.
2) If and only if the relation has only type=multipolygon tag go to
backward compatibility mode. Copy over tags from outer ways that are
present on all of them and create polygon. Go over all member ways and
if all their tags are present on the created polygon, then mark them as
done, otherwise process them separately.

--

I have looked at all the multipolygon relations that do not have any of
the well-known polygon tags (the ones defined in default.style), this is
less than 27% of all the multipolygon relations. 85% of these relations
have type=multipolygon tag only, so the proposed change in fact affects
less than 4% of all the multipolygons.

More detailed breakdown of tags on multipolygons without well-known
polygon tags:
percentage  keys
85.5%   type
3.7%ref,type,id_ob,adr_les
1.7%type,name
1.5%area,type,highway


Best regards,
Petr Morávek aka Xificurk


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