Re: [Talk-cz] import budov

[Jan Dudík]

Postup  - rozdělit podle katastrů, velké katastry klidně ještě na pár
částí a ty pak postupně ručně importovat je určitě lepší, než hromadný
import. Když budou data někde k dispozici + stránka na wiki, za pár
měsíců uživatelé naimportují své okolí a pak se ukáže, co zbývá a
uvidí se, co s tím zbytkem.

J&D

Dne 2. srpna 2012 20:14 Michal Pustějovský
 napsal(a):
> Dne 2.8.2012 13:19, jzvc napsal(a):
>
> Ja vam tady do toho lehce vstoupim - moje predstava, jak by to mohlo
> docela pekne fungovat = upravit soucasny tracer plugin, a to tak, ze
> nebude trasovat z bitmapy, ale veme vektor/body.
>
> => zdroj zi zobrazim jako podklad, a pokud klipnu "do budovy", tak ji to
> bafne a vlozi do aktivniho layeru. Melo by to samo mit funkci "merge" =>
> pokud chci slucovat, melo by jit nastavit zda poloha bude stavajici nebo
> ze zdroje + to drapne vsechny stavajici tagy + to samo prida IDcko ze
> zdroje a omarkuje pokud je poloha z OSM (aby se to v pripade zmeny ve
> zdroji nemenilo). Tohle by melo fungovat tak, ze klipnu (vyberu) dva
> objekty stejnyho typu a on je automaticky podle danych pravidel slouci.
>
> Zjistovani rozdilu = vemu objekty danyho typu v danym boxu a podivam se,
> zda mam v OSM vsechny objekty danyho typu s danym ID. Ty co tam nejsou
> vyrenderuju jako rozdil.
> Dale u tech co tam jsou overim, zda maji stejne souradnice (a pripadne
> dalsi parametry) jako ve zdroji (pokud ne = rozdil), pripadne zda sou
> oznaceny (= v RUIAN je blbost).
> Pokud to bude v podobe podkladu (trebas vrstva toho WMS generovanyho z
> RUIAN), tak se da velmi snadno a rychle najit kde co chybi.  Melo by to
> mit nejakou moznost zpetne prohlasit ze v RUIAN je blbost, a takovej
> objekt by se neresil, dokud nebude v RUIAN zmenen (pripadne by to mohla
> byt dalsi vrstva).
>
> Ad adresni body - me osobne se nelibi, protoze jak uz sem psal vejs,
> pokud ma budova definovany vchody, da se navigovat ke vchodu i z jiny
> ulice nez te, kde ma adresu. Pokud je tam bod, tak kazda navigace povede
> do ulice, kam ta adresa patri. Dovedu si to predstavit prave pro
> oznaceni mist, kde z nejakyho duvodu budova neni, neni tam digitalini
> km, ... protoze tam budovy neni moc jak vykreslit.
>
> V takovym pripade bych si asi doved predstavit, ze (v ramci upraveneho
> pluginu) vyberu trebas nejaky box a prohlasim ze do nej chci vlozit
> vsechny adresni body ze zdroje. S matchovanim to asi bude vselijaky, neb
> sem svyho casu podobny veci delal, uspesnost asi nepreleze 80 - 85%. Ale
> opet, lze renederovat nejaky rozdil, a postupne se to da dokupy. Hlavne
> musi byt nekde videt co kde chybi.
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>
>
>
>
> Dobrý nápad, jenže pokud budu chtít zmapovat budovy v celém městě/vesnici,
> kde zatím vůbec žádné nejsou, bude to stále ještě hodně pracné. Nebylo by
> pro tyto případy lepší provést tento import podobně jako import UIR-ZSJ?
> Pomocí skriptu by se vytvořil .osm soubor obsahující budovy z RÚIAN z daného
> katastru. Otevřel by se v JOSM jako nová vrstva. Tato vrstva by se porovnala
> s jinými zdroji a nesrovnalosti by se ručně opravily. Soubor by se uložil a
> dalším skriptem (který by doplnil source=ruian apod.) poslal do databáze
> OSM.
> O programování toho ale moc nevím, takže možná navrhuju něco, co není
> prakticky proveditelné.
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>



-- 
--
Ing. Jan Dudík

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

Re: [Talk-cz] import budov

[hanoj]

> Blbost to je, i když snadno přehlédnutelná, diffni si tyhle dva řetězce:
>
> Krupá u Kostelce nad Černýni Lesy
> Krupá u Kostelce nad Černými lesy
*** aha, to je pod mou okoschopnost ;)

h.
hanoj

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

Re: [Talk-cz] import budov

[hanoj]

Dne 3. srpna 2012 1:07 Martin Kokeš  napsal(a):
> S tou sedmiprvkovou transformací je to samozřejmě přesnější. Jde o to, jestli 
> byla při
> importu UIR-ADR použita... :-)

Druhy transformací podle přesnosti (WGS84/ERTS89->S-JTSK) 2D:

*100-110 metrů na severozápad - základní sedmiprvková transformace
bez transformačního klíče; nepoužívá se
*< 1 metr - základní navíc s parametry transformačního klíče
"towgs"; viz níže globální transformační klíč pro ČR/SR
*< 0,1 metr - pomocí gridu (ČR); zvláštní článek


hanoj

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

Re: [Talk-cz] import budov

[Martin Kokeš]

S tou sedmiprvkovou transformací je to samozřejmě přesnější. Jde o to, jestli 
byla při importu UIR-ADR použita... :-)

MK

- Original Message -
From: "Petr Morávek [Xificurk]"
[mailto:xific...@gmail.com]
To: OpenStreetMap Czech Republic
[mailto:talk-cz@openstreetmap.org]
Sent: Thu, 02 Aug 2012 22:29:45
+0200
Subject: Re: [Talk-cz] import budov


> Martin Kokeš wrote:
> > Bohužel v metrech. :-) Např. Pardubice cca 20 metrů SV-JZ.
> > 
> > MK
> 
> Určitě? V porovnání s čím?
> Sice mám v tomhle směru fakt limitované znalosti, ale když jsem stáhnul
> grid [1] a zkusil transformovat pár bodů z Ostravska, tak se výsledek
> oproti definici [2] lišil cca o 0.5m (plus opačná znaménka).
> 
> Petr
> 
> [1] http://grass.fsv.cvut.cz/wiki/index.php/S-JTSK-Grid
> [2] http://spatialreference.org/ref/sr-org/czech-s-jtsk-epsg2065/proj4/
> 
> 

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

Re: [Talk-cz] import budov

[Petr Morávek [Xificurk]]

Martin Kokeš wrote:
> Bohužel v metrech. :-) Např. Pardubice cca 20 metrů SV-JZ.
> 
> MK

Určitě? V porovnání s čím?
Sice mám v tomhle směru fakt limitované znalosti, ale když jsem stáhnul
grid [1] a zkusil transformovat pár bodů z Ostravska, tak se výsledek
oproti definici [2] lišil cca o 0.5m (plus opačná znaménka).

Petr

[1] http://grass.fsv.cvut.cz/wiki/index.php/S-JTSK-Grid
[2] http://spatialreference.org/ref/sr-org/czech-s-jtsk-epsg2065/proj4/



signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] import budov

[Martin Kokeš]

Bohužel v metrech. :-) Např. Pardubice cca 20 metrů SV-JZ.

MK
- Original Message -
From: "Petr Morávek [Xificurk]"
[mailto:xific...@gmail.com]
To: OpenStreetMap Czech Republic
[mailto:talk-cz@openstreetmap.org]
Sent: Thu, 02 Aug 2012 18:49:28
+0200
Subject: Re: [Talk-cz] import budov


> Martin Kokeš wrote:
> > Předpokládám, že tehdy při importu UIR-ADR nikdo chybu při převodu
> JTSK>WGS84 neřešil. :-)
> > 
> > http://grass.fsv.cvut.cz/wiki/images/c/c6/Dopnul_wgs84_jtsk_xyerr.png
> > 
> > MK
> 
> Ahoj,
> 
> to jsou odchykly v centimetrech, ne? To je/bylo pro import adresních
> bodů celkem irrelevantní.
> U importu budov už by možná mělo smysl přemýšlet nad přesnější
> transformací s nadgrids=czech. Na některých místech by ten necelý metr
> už mohl být znát, ale i tak by to asi nebyla žádná velká tragédie.
> 
> Petr
> 

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

Re: [Talk-cz] Zásahy BOTa - nutné a provedené opravy

[Libor Pechacek]

Ahoj,

Když vidím ten objem oprav, mám výzvu.  Dělejme opravy ve stejné či lepší
kvalitě jako byla původní data.  Data z mapy zmizela rychle, to ale neznamená,
že se zase stejně rychle mají vrátit.  Sám jsem cítil jistou hořkost při
opravování již jednou dobře zmapovaných oblastí a měl jsem tendenci opravu
odbýt.  Nicméně jsem se zamyslel a pozvolna mapuji vyčištěná místa jako by to
bylo poprvé - budovy z KM, ulice a lesy z ortofota, názvy ulic a adresy z
importu KM+MVČR.

Libor

On Thu 02-08-12 07:00:50, Michal Tauchman wrote:
>  - Vidochov (oprava silnice)
>  - Mostek (oprava využití krajin, kompletní předělání zničeného lesa okolo 
> obce)
>  - Železnice (oprava drobných detailů smazaných BOTem)
>  - Jičín (drobné opravy)
>  - Pustějov - Nový Jičín (oprava roztržených silnic)
>  - oprava silnice 46421, 46423, 191, 27 (E 53), 190, 145, 14516, 185, 1422, 
> 141 
> (obec Bavorov), 271, 501, 46420, 441, 3024, 2904, 27246
>  - Bílov (opravy rozpojených silnic)
>  - Litochovice/Marčovice (spojovací silnice)
>  - Předslavice/Všechlapy (spojovací silnice)
>  - koleje č. 1435
>  - Vodňany (vodní nádrže)
>  - Vodňanské Svobodné Hory (drobné opravy okolních cest)
>  - Horní Jiřetín (rebuild smazaných cest)
>  - Litvínov (opravy a doplnění roztržených a umazaných silnic)
>  - Chomutov (drobné doplnění smazaných uliček)
>  - Pecka a okolí (opravy cest), Pecka/Borovnice (tracks)
>  - Fulnek (malá silnice obnovena)
>  - Boseň (rekonstrukce okolního lesa)
>  - Dvorský les (nad Trutnovem) (opraveno přerušení a nevykreslení v mapě)
>  - Bobr u Žacléře (opraveny spoje a smazané cesty)
>  - Stárkov (opravená spojení)
>  - Dobruška (opravená spojení, doplněny silnice)
>  - Kostelec nad Orlicí (opravená spojení, doplněny silnice)
>  - Pardubice (drobné chyby)
>  - Litomyšl (drobné opravy)
>  - Loučky (obnova všech městských silnic)
>  - Jablonec nad Nisou (smazané budovy)
>  - Andělka (doplnění smazaných silnic)
>  - Grabštejn (nápravy uliček)
>  - Hrádek nad Nisou (drobné opravy)
>  - Liberec (opravy silnic)
>  - Mařenice (znovuzakreslení místní uličky)
>  - Česká Lípa (ulice už byly opraveny, tak jen drobné detaily k doladění)
> 
> Další hotové opravy:
> 
>  - Turnov
>  - Česká Lípa 
> 
> 
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz

-- 

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

Re: [Talk-cz] import budov

[Libor Pechacek]

On Thu 02-08-12 19:45:49, jzvc wrote:
> Dne 2.8.2012 16:34, LM_1 napsal(a):
> > O jakých chybách se tady bavíme? V Brně bylo spostu adresních bodů
> > pěkně vyplněných, ale posunutých o třy čtyři domy vedle. Pro navigaci
> > lepší než nic, ale pro opravy celkem peklo (navíc oproti prázdnotě
> > hledání původního bodu).
> > LM
> 
> To je presne o cem se bavime, ze se tam naimportuje hromada dat, ktery
> nikdy nikdo neopravi - naprosto totez jako aktualne zmena licence, to
> nikdy nikdo neopravi, protoze se to nijak rozumne opravit neda. je totiz
> daleko jednodussi mapovat prazdny misto nez opravovat ho. A neni to samo
> jen posun, chyb tam bude IMO celkem hromada (sak je to registr ala CR).
> 
> Takze ja sem radsi pro poloprazdnou, ale spravnou mapu, nez pro mapu
> stejne blbou, jako vsechny ostatni.

Tady mluvíme o importu z RÚIAN, jestli dávám správně pozor.  Ten je na úrovni
dat z KM a databáze adres MVČR.  Pokud vím, nic lepšího aktuálně není.
Importujme tedy, a to způsobem, který umožní budoucí úpravy, což tu právě
diskutujeme.

Libor

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

Re: [Talk-cz] import budov

[LM_1]

Pokud jde o srovnávání importované vrstvy a stávajího stavu, toto je
cílem pluginu conflation. Jak moc to funguje nevím, naposledy když
jsem to zkoušel tak nic moc.
LM

> Dobrý nápad, jenže pokud budu chtít zmapovat budovy v celém městě/vesnici,
> kde zatím vůbec žádné nejsou, bude to stále ještě hodně pracné. Nebylo by
> pro tyto případy lepší provést tento import podobně jako import UIR-ZSJ?
> Pomocí skriptu by se vytvořil .osm soubor obsahující budovy z RÚIAN z daného
> katastru. Otevřel by se v JOSM jako nová vrstva. Tato vrstva by se porovnala
> s jinými zdroji a nesrovnalosti by se ručně opravily. Soubor by se uložil a
> dalším skriptem (který by doplnil source=ruian apod.) poslal do databáze
> OSM.
> O programování toho ale moc nevím, takže možná navrhuju něco, co není
> prakticky proveditelné.
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz
>

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

Re: [Talk-cz] import budov

[Michal Pustějovský]

Dne 2.8.2012 13:19, jzvc napsal(a):

Ja vam tady do toho lehce vstoupim - moje predstava, jak by to mohlo
docela pekne fungovat = upravit soucasny tracer plugin, a to tak, ze
nebude trasovat z bitmapy, ale veme vektor/body.

=> zdroj zi zobrazim jako podklad, a pokud klipnu "do budovy", tak ji to
bafne a vlozi do aktivniho layeru. Melo by to samo mit funkci "merge" =>
pokud chci slucovat, melo by jit nastavit zda poloha bude stavajici nebo
ze zdroje + to drapne vsechny stavajici tagy + to samo prida IDcko ze
zdroje a omarkuje pokud je poloha z OSM (aby se to v pripade zmeny ve
zdroji nemenilo). Tohle by melo fungovat tak, ze klipnu (vyberu) dva
objekty stejnyho typu a on je automaticky podle danych pravidel slouci.

Zjistovani rozdilu = vemu objekty danyho typu v danym boxu a podivam se,
zda mam v OSM vsechny objekty danyho typu s danym ID. Ty co tam nejsou
vyrenderuju jako rozdil.
Dale u tech co tam jsou overim, zda maji stejne souradnice (a pripadne
dalsi parametry) jako ve zdroji (pokud ne = rozdil), pripadne zda sou
oznaceny (= v RUIAN je blbost).
Pokud to bude v podobe podkladu (trebas vrstva toho WMS generovanyho z
RUIAN), tak se da velmi snadno a rychle najit kde co chybi.  Melo by to
mit nejakou moznost zpetne prohlasit ze v RUIAN je blbost, a takovej
objekt by se neresil, dokud nebude v RUIAN zmenen (pripadne by to mohla
byt dalsi vrstva).

Ad adresni body - me osobne se nelibi, protoze jak uz sem psal vejs,
pokud ma budova definovany vchody, da se navigovat ke vchodu i z jiny
ulice nez te, kde ma adresu. Pokud je tam bod, tak kazda navigace povede
do ulice, kam ta adresa patri. Dovedu si to predstavit prave pro
oznaceni mist, kde z nejakyho duvodu budova neni, neni tam digitalini
km, ... protoze tam budovy neni moc jak vykreslit.

V takovym pripade bych si asi doved predstavit, ze (v ramci upraveneho
pluginu) vyberu trebas nejaky box a prohlasim ze do nej chci vlozit
vsechny adresni body ze zdroje. S matchovanim to asi bude vselijaky, neb
sem svyho casu podobny veci delal, uspesnost asi nepreleze 80 - 85%. Ale
opet, lze renederovat nejaky rozdil, a postupne se to da dokupy. Hlavne
musi byt nekde videt co kde chybi.

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





Dobrý nápad, jenže pokud budu chtít zmapovat budovy v celém 
městě/vesnici, kde zatím vůbec žádné nejsou, bude to stále ještě hodně 
pracné. Nebylo by pro tyto případy lepší provést tento import podobně 
jako import UIR-ZSJ ? 
Pomocí skriptu by se vytvořil .osm soubor obsahující budovy z RÚIAN z 
daného katastru. Otevřel by se v JOSM jako nová vrstva. Tato vrstva by 
se porovnala s jinými zdroji a nesrovnalosti by se ručně opravily. 
Soubor by se uložil a dalším skriptem (který by doplnil source=ruian 
apod.) poslal do databáze OSM.
O programování toho ale moc nevím, takže možná navrhuju něco, co není 
prakticky proveditelné.


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

Re: [Talk-cz] import budov

[jzvc]

Dne 2.8.2012 16:34, LM_1 napsal(a):
> O jakých chybách se tady bavíme? V Brně bylo spostu adresních bodů
> pěkně vyplněných, ale posunutých o třy čtyři domy vedle. Pro navigaci
> lepší než nic, ale pro opravy celkem peklo (navíc oproti prázdnotě
> hledání původního bodu).
> LM

To je presne o cem se bavime, ze se tam naimportuje hromada dat, ktery
nikdy nikdo neopravi - naprosto totez jako aktualne zmena licence, to
nikdy nikdo neopravi, protoze se to nijak rozumne opravit neda. je totiz
daleko jednodussi mapovat prazdny misto nez opravovat ho. A neni to samo
jen posun, chyb tam bude IMO celkem hromada (sak je to registr ala CR).

Takze ja sem radsi pro poloprazdnou, ale spravnou mapu, nez pro mapu
stejne blbou, jako vsechny ostatni.

> Dne 2. srpna 2012 16:20 Jakub Sykora  napsal(a):
>> Ja si myslim, ze se automatizovanemu importu nevyhneme. Tohle fakt rucne
>> delat asi nejde :)
>>
>> K
>>
>> Dne 2.8.2012 15:18, hanoj napsal(a):
>>
> Já jsem pro hromadný import, případně následně pro vytvoření robota na
> údržbu. Minimálně u adresních bodů.
>
> MK

 A dopadne to jako potoky, ktery nejsou spraveny doted.
>>> *** Jestli si mam vybrat mezi:
>>> * rucne s chybami=nikdy
>>> * import s chybami=letos
>>>
>>> tak vyber je jasnej
>>>
>>> h.
>>> hanoj
>>>
>>> ___
>>> Talk-cz mailing list
>>> Talk-cz@openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-cz
>>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz


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

Re: [Talk-cz] import budov

[Petr Morávek [Xificurk]]

Martin Kokeš wrote:
> Předpokládám, že tehdy při importu UIR-ADR nikdo chybu při převodu JTSK>WGS84 
> neřešil. :-)
> 
> http://grass.fsv.cvut.cz/wiki/images/c/c6/Dopnul_wgs84_jtsk_xyerr.png
> 
> MK

Ahoj,

to jsou odchykly v centimetrech, ne? To je/bylo pro import adresních
bodů celkem irrelevantní.
U importu budov už by možná mělo smysl přemýšlet nad přesnější
transformací s nadgrids=czech. Na některých místech by ten necelý metr
už mohl být znát, ale i tak by to asi nebyla žádná velká tragédie.

Petr
<>

signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] import budov

[Martin Kokeš]

Předpokládám, že tehdy při importu UIR-ADR nikdo chybu při převodu JTSK>WGS84 
neřešil. :-)

http://grass.fsv.cvut.cz/wiki/images/c/c6/Dopnul_wgs84_jtsk_xyerr.png

MK

- Original Message -
From: Jan Breuer
[mailto:jan.bre...@jaybee.cz]
To: OpenStreetMap Czech Republic
[mailto:talk-cz@openstreetmap.org]
Sent: Thu, 02 Aug 2012 17:52:08
+0200
Subject: Re: [Talk-cz] import budov


> V celem Liberci to bylo take uplne stejne posunute nahoodne o nekolik domu,
> ale pritom korektne otagovane. Mnoho desitek adres jsem tehdy opravoval
> rucne, kdyz jsem na to narazil.
> 
> JB
> 
> Dne 2.8.2012 16:35 "LM_1"  napsal/a:
> 
> O jakých chybách se tady bavíme? V Brně bylo spostu adresních bodů
> pěkně vyplněných, ale posunutých o třy čtyři domy vedle. Pro
> navigaci
> lepší než nic, ale pro opravy celkem peklo (navíc oproti prázdnotě
> hledání původního bodu).
> LM
> 
> Dne 2. srpna 2012 16:20 Jakub Sykora  napsal(a):
> 
> > Ja si myslim, ze se automatizovanemu importu nevyhneme. Tohle fakt rucne
> > delat asi nejde :)
> >
> > ...
> 

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

Re: [Talk-cz] Značení uzavírky a objízdných tras

[LM_1]

Obvykle se kácí dospělý/dorostlý les - celý. Čas se pravděpodobně dá
odhadnout s přesností na roky. Hranici kácení bych u soukromých lesů
očekával shodnou s hranicí parcel podle katastru.
Problém rozdílu mezi lesním pozemkem a místem pokrytým stromy se mimo
jiné snaží vyřešit návrhy jako
http://wiki.openstreetmap.org/wiki/User:Imagic/landcover

LM


Dne 2. srpna 2012 17:37 f.remenstech  napsal(a):
> Dne 2. srpna 2012 13:29 jzvc  napsal(a):
>> Dne 1.8.2012 10:32, Petr Kadlec napsal(a):
>>> 2012/7/31 LM_1 :
 Rozumím tomu, proč bych jako řidič chtěl vědět, kudy vede oficiální
 objízdná trasa, ale co vím tak žádná navigace tuto možnost
 nepodporuje.
>>> V Německu mají takové ty trvalé předpřipravené objízdné trasy, kde
>>> beru, že asi dává smysl je mít v mapě nějak reprezentované. A vskutku:
>>> http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Bedarfsumleitung
>>>
>>> Ale nejsem si jist, jestli dává nějaký velký smysl mapovat běžné ad
>>> hoc objížďky, ani se nedivím navigacím, že takovou potřebu nemají.
>>
>> Tohle uz se tu taky tusim nekdy resilo. OSM je navrhovana na trvale
>> platne mapovani, aktualne nema zadnou "vrstvu" s docasnymi daty, coz by
>> prave podobny veci pokryvalo.
>> Chtelo by to podobnou vrstvu nad temi daty, ktera by nebyla beznou
>> soucasti dat, a kazdy zaznm by tam mel nejak omezenou platnost (od:do),
>> a po skonceni platnosti se sam vyhodil.
>>
>> Silnici lze sice zavrit, ale stejne si to sosne jen minimum navigaci,
>> specielne pokud je to opravdu jen kratkodoby (14dnu ...). Kdyby
>> existovala da docasna vrstva, tak jelikoz bude mit radove min dat, daj
>> se aktualizace sosat i pres nase uzasne FUPy (a navic by se do toho daly
>> ladovat nejspis i data o nehodach ...).
>
> Dočasně by šlo mapovat les. Teď je to mýtina, za 3 roky hustník,
> po dalších X letech les (jde zjistit statisticky?). Po vykácení stejné
> části lesa někdo oblast resetuje na mýtinu... Předpokládám, že se
> nekácí náhodné kusy lesa?
>
> F.
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz

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

Re: [Talk-cz] import budov

[Jan Breuer]

V celem Liberci to bylo take uplne stejne posunute nahoodne o nekolik domu,
ale pritom korektne otagovane. Mnoho desitek adres jsem tehdy opravoval
rucne, kdyz jsem na to narazil.

JB

Dne 2.8.2012 16:35 "LM_1"  napsal/a:

O jakých chybách se tady bavíme? V Brně bylo spostu adresních bodů
pěkně vyplněných, ale posunutých o třy čtyři domy vedle. Pro navigaci
lepší než nic, ale pro opravy celkem peklo (navíc oproti prázdnotě
hledání původního bodu).
LM

Dne 2. srpna 2012 16:20 Jakub Sykora  napsal(a):

> Ja si myslim, ze se automatizovanemu importu nevyhneme. Tohle fakt rucne
> delat asi nejde :)
>
> ...
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Značení uzavírky a objízdných tras

[f.remenstech]

Dne 2. srpna 2012 13:29 jzvc  napsal(a):
> Dne 1.8.2012 10:32, Petr Kadlec napsal(a):
>> 2012/7/31 LM_1 :
>>> Rozumím tomu, proč bych jako řidič chtěl vědět, kudy vede oficiální
>>> objízdná trasa, ale co vím tak žádná navigace tuto možnost
>>> nepodporuje.
>> V Německu mají takové ty trvalé předpřipravené objízdné trasy, kde
>> beru, že asi dává smysl je mít v mapě nějak reprezentované. A vskutku:
>> http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Bedarfsumleitung
>>
>> Ale nejsem si jist, jestli dává nějaký velký smysl mapovat běžné ad
>> hoc objížďky, ani se nedivím navigacím, že takovou potřebu nemají.
>
> Tohle uz se tu taky tusim nekdy resilo. OSM je navrhovana na trvale
> platne mapovani, aktualne nema zadnou "vrstvu" s docasnymi daty, coz by
> prave podobny veci pokryvalo.
> Chtelo by to podobnou vrstvu nad temi daty, ktera by nebyla beznou
> soucasti dat, a kazdy zaznm by tam mel nejak omezenou platnost (od:do),
> a po skonceni platnosti se sam vyhodil.
>
> Silnici lze sice zavrit, ale stejne si to sosne jen minimum navigaci,
> specielne pokud je to opravdu jen kratkodoby (14dnu ...). Kdyby
> existovala da docasna vrstva, tak jelikoz bude mit radove min dat, daj
> se aktualizace sosat i pres nase uzasne FUPy (a navic by se do toho daly
> ladovat nejspis i data o nehodach ...).

Dočasně by šlo mapovat les. Teď je to mýtina, za 3 roky hustník,
po dalších X letech les (jde zjistit statisticky?). Po vykácení stejné
části lesa někdo oblast resetuje na mýtinu... Předpokládám, že se
nekácí náhodné kusy lesa?

F.

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

Re: [Talk-cz] import budov

[LM_1]

O jakých chybách se tady bavíme? V Brně bylo spostu adresních bodů
pěkně vyplněných, ale posunutých o třy čtyři domy vedle. Pro navigaci
lepší než nic, ale pro opravy celkem peklo (navíc oproti prázdnotě
hledání původního bodu).
LM

Dne 2. srpna 2012 16:20 Jakub Sykora  napsal(a):
> Ja si myslim, ze se automatizovanemu importu nevyhneme. Tohle fakt rucne
> delat asi nejde :)
>
> K
>
> Dne 2.8.2012 15:18, hanoj napsal(a):
>
 Já jsem pro hromadný import, případně následně pro vytvoření robota na
 údržbu. Minimálně u adresních bodů.

 MK
>>>
>>>
>>> A dopadne to jako potoky, ktery nejsou spraveny doted.
>>
>> *** Jestli si mam vybrat mezi:
>> * rucne s chybami=nikdy
>> * import s chybami=letos
>>
>> tak vyber je jasnej
>>
>> h.
>> hanoj
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-cz

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

Re: [Talk-cz] import budov

[Jakub Sykora]

Ja si myslim, ze se automatizovanemu importu nevyhneme. Tohle fakt rucne 
delat asi nejde :)


K

Dne 2.8.2012 15:18, hanoj napsal(a):

Já jsem pro hromadný import, případně následně pro vytvoření robota na údržbu. 
Minimálně u adresních bodů.

MK


A dopadne to jako potoky, ktery nejsou spraveny doted.

*** Jestli si mam vybrat mezi:
* rucne s chybami=nikdy
* import s chybami=letos

tak vyber je jasnej

h.
hanoj

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



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

Re: [Talk-cz] import budov

[Petr Morávek [Xificurk]]

hanoj wrote:
>> ony ty registry občas taky obsahují blbosti. Můj oblíbený příklad je KÚ
>> z UIR-ZSJ jménem "Krupá u Kostelce nad Černýni Lesy" ;-)
> *** to neni blbost, to je fakt. KU maji unikatni nazvy napric CR.

Blbost to je, i když snadno přehlédnutelná, diffni si tyhle dva řetězce:

Krupá u Kostelce nad Černýni Lesy
Krupá u Kostelce nad Černými lesy

Petr
<>

signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] import budov

[hanoj]

>> Já jsem pro hromadný import, případně následně pro vytvoření robota na 
>> údržbu. Minimálně u adresních bodů.
>>
>> MK
>
> A dopadne to jako potoky, ktery nejsou spraveny doted.
*** Jestli si mam vybrat mezi:
* rucne s chybami=nikdy
* import s chybami=letos

tak vyber je jasnej

h.
hanoj

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

Re: [Talk-cz] import budov

[hanoj]

> ony ty registry občas taky obsahují blbosti. Můj oblíbený příklad je KÚ
> z UIR-ZSJ jménem "Krupá u Kostelce nad Černýni Lesy" ;-)
*** to neni blbost, to je fakt. KU maji unikatni nazvy napric CR.

ha
hanoj

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

Re: [Talk-cz] import budov

[Petr Morávek [Xificurk]]

Libor Pechacek wrote:
> Zkratky a neaktuální názvy jdou na účet MVČR, nesprávně malá/velká písmena 
> jsou
> chybou importovacího softwaru.  Sice jsem software opravil, ale původní názvy
> už v mapě zůstaly. ;)

Ahoj,
ony ty registry občas taky obsahují blbosti. Můj oblíbený příklad je KÚ
z UIR-ZSJ jménem "Krupá u Kostelce nad Černýni Lesy" ;-)

Petr Morávek aka Xificurk



signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] import budov

[Libor Pechacek]

On Thu 02-08-12 13:34:32, jzvc wrote:
> Dne 2.8.2012 10:54, Libor Pechacek napsal(a):
> > :) Zrovna jsem se chtěl ozvat.
> >
> > Za svojí prací si stojím, investoval jsem hodně úsilí do korektnosti 
> > importů.
> > Na druhou stranu vím, že některé importy nejsou až tak důkladně provedené.
> >
> > Nemám nic proti přepsání svých importů daty z RÚIAN, obsahově by měly být
> > totožná.
> 
> Tim bych si nebyl tak jisty ... ;D, opakovane sem narazel na spatne
> nazvy ulic (u importovanych adres) - v tom smyslu, ze tam byly zkratky,
> blbe mala/velka pismena, pripadne nekde byly pouzity starsi nez aktualni
> nazvy ...

Zkratky a neaktuální názvy jdou na účet MVČR, nesprávně malá/velká písmena jsou
chybou importovacího softwaru.  Sice jsem software opravil, ale původní názvy
už v mapě zůstaly. ;)

Libor
>From 2ec263cad0d127d5a89662bbd380a3b06dc3e329 Mon Sep 17 00:00:00 2001
From: Libor Pechacek 
Date: Fri, 16 Sep 2011 16:43:37 +0200
Subject: [PATCH] Capitalize place names properly

Treat space and dash as word separators, capitalize roman numerals.

Signed-off-by: Libor Pechacek 
---
 CUZK.MergeDBCUZK/StringUtilities.cs |   47 ---
 1 files changed, 27 insertions(+), 20 deletions(-)

diff --git a/CUZK.MergeDBCUZK/StringUtilities.cs b/CUZK.MergeDBCUZK/StringUtilities.cs
index ac4fb88..9ba31a2 100644
--- a/CUZK.MergeDBCUZK/StringUtilities.cs
+++ b/CUZK.MergeDBCUZK/StringUtilities.cs
@@ -5,31 +5,38 @@ using System.Text;
 
 namespace CUZK.MergeDBCUZK {
 	public static class StringUtilities {
+		static System.Globalization.CultureInfo cultureInfo = System.Globalization.CultureInfo.GetCultureInfo("cs");
+		static HashSet noCapitalize = new HashSet(new string[] {
+			"nad", "pod", "u", "v", "na", "z", 
+			"ledna", "února", "března", "dubna", "května", "máje", "června",
+			"července", "srpna", "září", "října", "listopadu", "prosince",
+			"náměstí", "ulice", "třída", "nábřeží", "kraj"});
+		static Char[] romanNumerals = { 'i', 'v', 'x', 'l', 'c', 'd', 'm' };
+		
 		public static string CorrectLetterSize(string geoName) {
-			if (geoName == null)
+			if (geoName == null || geoName == "")
 return "";
 
-			string[] nameChunks = geoName.Trim().ToLower(System.Globalization.CultureInfo.GetCultureInfo("cs")).Split(' ');
-
-			StringBuilder result = new StringBuilder();
-			result.Append(nameChunks[0].Substring(0, 1).ToUpper(System.Globalization.CultureInfo.GetCultureInfo("cs")));
-			result.Append(nameChunks[0].Substring(1));
-
-			string[] noCapitalize = new string[] {"nad", "pod", "u", "v", "na", "z", 
-"ledna", "února", "března", "dubna", "května", "máje", "června",
-"července", "srpna", "září", "října", "listopadu", "prosince",
-"náměstí", "ulice", "třída", "nábřeží", "kraj"};
-
-			for (int i = 1; i < nameChunks.Length; i++) {
-result.Append(' ');
-if (noCapitalize.SingleOrDefault(s => s == nameChunks[i]) != null) {
-	result.Append(nameChunks[i]);
-}
-else {
-	result.Append(nameChunks[i].Substring(0, 1).ToUpper(System.Globalization.CultureInfo.GetCultureInfo("cs")));
-	result.Append(nameChunks[i].Substring(1));
+			string source = geoName.Trim().ToLower(cultureInfo);
+			StringBuilder result = new StringBuilder(source);
+			source = source + ' ';
+			
+			int subStart = 0;
+			for (int i = 1; i < source.Length; i++) {
+if (source[i] == ' ' || source[i] == '-') {
+	string word = source.Substring(subStart, i-subStart);
+	if(!noCapitalize.Contains(word)) {
+		if (word.TrimEnd('.').TrimStart(romanNumerals).Length == 0) {
+			result.Replace(word, word.ToUpper(cultureInfo), subStart, word.Length);
+		} else {
+			result[subStart] = Char.ToUpper(result[subStart], cultureInfo);
+		}
+	}
+	subStart = i+1;
 }
 			}
+			
+			result[0] = Char.ToUpper(result[0], cultureInfo);
 
 			return result.ToString();
 		}
-- 
1.6.0.2

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

Re: [Talk-cz] import budov

[jzvc]

Dne 29.7.2012 10:16, Martin Kokeš napsal(a):
> Já jsem pro hromadný import, případně následně pro vytvoření robota na 
> údržbu. Minimálně u adresních bodů. 
>
> MK 

A dopadne to jako potoky, ktery nejsou spraveny doted.

>
> - Original Message -
> From: hanoj [mailto:eha...@gmail.com]
> To:
> OpenStreetMap Czech Republic [mailto:talk-cz@openstreetmap.org]
> Sent: Sat,
> 28 Jul 2012 22:35:08 +0200
> Subject: Re: [Talk-cz] import budov
>
>
>> Ja bych nadhodil nekolik otazek treba pro adresni body:
> * Kolik je
>> adresnich bodu? 2.500.000
> * Kolik mapperu se bude ucastnit takove prace?
>> Prvni desitky.
> * Jak dlouho to bude trvat? ...
>
> * Jaka cast dat by mela byt
>> mappery pridavana tam kde nikdy nebyla? Vetsina.
> * Jak budou uzivatele
>> hodnotit (ne)kvalitu dat jiz v OSM? Na zaklade
> dat CUZK a u par stovek bodu
>> ze znalosti z terenu kde bydli.Tezko
>> ale
> suplovat:
> http://www.cuzk.cz/GenerujSoubor.ashx?NAZEV=10-POROVNANIADRES
>
> Opravdu
>> je individualni prace na vetsine uzemi republiky cesta, jak
> data RUIAN
>> dostat do OSM?
>
> h.anoj
>
>
> Dne 27. července 2012 17:17 Miroslav Šulc
>>  napsal(a):
>> v souvislosti s tím co píšeš mě
>> napadlo udělat to komplet jako josm
>> plugin. tj. serverová část by
>> zůstala tak jak jsem psal, ale všechno
>> ostatní by se dělalo přímo z
>> josm pluginu. ten by si stáhl data přes api
>> ode mě ze serveru z
>> aktuální databáze rúian, provedl by porovnání s
>> datovou vrstvou z
>> osm a vyhodil by nějaké info o rozdílech v osm a v
>> rúian s tím, že
>> mapper by si vybíral varianty a potvrzoval je, případně
>> by sáhnul
>> přímo do osm vrstvy a udělal úpravy tam. při uploadu změn do
>> osm by
>> se pak zapsalo i info ke mně na server o provedení importu. do
>> pluginu
>> by se pak dala přidávat funkcionalita dle potřeby.
>>
>> ff
>>
>> Dne
>> 27.7.2012 14:18, Jan Bilak napsal(a):
>>> Otázka je, jak by měla vypadat ta
>> připravená data. V případě importu
>>> nových věcí tak, kde žádné
>> nebyly, je to celkem primitivní. Ale mnohem
>>> náročnější bude import
>> do míst, kde již nějaká data jsou. Tam bude
>>> třeba něco starého
>> odstranit, něco modifikovat, něco přidat... Lze v
>>> OSM formátu
>> postihnout nějak všechny tyto typy změn (odstranění,
>>> modifikace,
>> přidání nových objektů)? A pokud lze, je možné to pak
>>> nějak
>> rozumně vizualizovat, aby to člověk mohl projít a rozhodovat
>>> "tohle
>> je ok, tohle zamítnu a zůstane při starém, tohle bude ještě
>>> trochu
>> jinak..." pomocí stávajících nástrojů? Nevím, jaké jsou
>> možnosti.
>>> Pokud nic vhodné stávajícího není, tak bych to viděl
>> spíše na
>>> interaktivní aplikaci, která zobrazí ty rozdíly ve vhodné
>> podobě, u
>>> každé umožní se rozhodnout, zda ponechat stará data,
>> nová data,
>>> automaticky zmergovat nebo ručně upravit. Ruční úpravu
>> by ta aplikace
>>> přímo nepodporovala, protože by to bylo příliš
>> náročné (vlastně by
>>> bylo třeba vytvořit obdobu editoru jako JOSM),
>> ale poznačilo by to
>>> nutnost ruční editace do dat nějakými tagy, aby
>> výsledek, který z
>>> aplikace vypadne, bylo možné otevřít např. v
>> JOSM a ručně provést
>>> potřebné úpravy.
>>>
>>> Např. u adresních
>> bodů by bylo podle mě vhodné, aplikace provedla
>>> nějaké
>> "inteligentní" matchování adresních bodů v OSM a RUIAN,
>>> zobrazovala
>> původní a nový bod vizuálně propojený šipkou, jinak
>>> vyznačené
>> body, které jsou pouze v OSM a naopak jinak vyznačené body,
>>> které
>> jsou pouze v RUIAN. Uživatel by mohl vždy zvolit, zda ponechat
>>> novou
>> nebo starou polohu bodu (zde by bylo možné i volit vlastní
>>> polohu -
>> jde o primitivní úkon) atd. Nakonec by aplikace vytvořila OSM
>>> patch,
>> který by obsahoval požadované úpravy včetně vhodně zmergovaných
>> tagů (ty by možná bylo třeba také kontrolovat v aplikaci) atd.
>>> U
>> budov to bude samozřejmě výrazně složitější.
>>> Obecně čistě
>> ručního importu se celkem obávám. Dat je vetší než malé
>> množství.
>>> Honza
>>>
>>>
>>> Dne 27. července 2012 13:41 Miroslav Šulc
>>  napsal(a):
 Dne 27.7.2012 13:20, Jan Bilak
>> napsal(a):
> Ahoj,
>
> teď z toho nechápu, zda si aplikaci
>> představuješ jen jako evidenční
> nebo zda aplikace má provádět
>> vlastní import (resp. s ním výrazně
> pomáhat).
 aplikace "pouze"
>> připraví data z rúian, samotný import provede mapper.
 tj. aplikace
>> pro import připraví data, ale nebude import provádět, ten
 se bude
>> dělat ručně. i kdybychom (pokud vůbec, to vyplyne z ručních
>> importů) v budoucnu uvažovali o nějaké automatizaci, tak v prvním
>> kroku
 se to stejně musí udělat ručně, abychom věděli, nakolik je
>> rúian
 spolehlivý zdroj, jaké problémy lze očekávat apod. pro
>> kontinuální práci
 s daty z rúian je pak potřeba ta evidenční
>> část.
> Tedy za zásadní považuji porovnání současných OSM
>> dat s daty RUIAN a
> následné provedení změn (posuny stávajících
>> bodů, opravy tagů,
> zachování stávajících tagů, dop

Re: [Talk-cz] import budov

[jzvc]

Dne 2.8.2012 10:54, Libor Pechacek napsal(a):
> :) Zrovna jsem se chtěl ozvat.
>
> Za svojí prací si stojím, investoval jsem hodně úsilí do korektnosti importů.
> Na druhou stranu vím, že některé importy nejsou až tak důkladně provedené.
>
> Nemám nic proti přepsání svých importů daty z RÚIAN, obsahově by měly být
> totožná.

Tim bych si nebyl tak jisty ... ;D, opakovane sem narazel na spatne
nazvy ulic (u importovanych adres) - v tom smyslu, ze tam byly zkratky,
blbe mala/velka pismena, pripadne nekde byly pouzity starsi nez aktualni
nazvy ...

>
> Libor
>
> On Wed 01-08-12 16:58:38, Miroslav Šulc wrote:
>> no, tady u nás je editorem bodů účet lpechacek, tak nevím, jestli to
>> importoval tenhle uživatel.
>>
>> ff
>>
>> Dne 1.8.2012 14:48, LM_1 napsal(a):
>>> Uvažoval jsem přesně takto.
>>> Není i dnes většina adresních bodů z importů? Ty ručně dělané budou
>>> pravděpodobně správně...
>>> LM
>
>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-cz
>


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

Re: [Talk-cz] Značení uzavírky a objízdných tras

[jzvc]

Dne 1.8.2012 10:32, Petr Kadlec napsal(a):
> 2012/7/31 LM_1 :
>> Rozumím tomu, proč bych jako řidič chtěl vědět, kudy vede oficiální
>> objízdná trasa, ale co vím tak žádná navigace tuto možnost
>> nepodporuje.
> V Německu mají takové ty trvalé předpřipravené objízdné trasy, kde
> beru, že asi dává smysl je mít v mapě nějak reprezentované. A vskutku:
> http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Bedarfsumleitung
>
> Ale nejsem si jist, jestli dává nějaký velký smysl mapovat běžné ad
> hoc objížďky, ani se nedivím navigacím, že takovou potřebu nemají.

Tohle uz se tu taky tusim nekdy resilo. OSM je navrhovana na trvale
platne mapovani, aktualne nema zadnou "vrstvu" s docasnymi daty, coz by
prave podobny veci pokryvalo.
Chtelo by to podobnou vrstvu nad temi daty, ktera by nebyla beznou
soucasti dat, a kazdy zaznm by tam mel nejak omezenou platnost (od:do),
a po skonceni platnosti se sam vyhodil.

Silnici lze sice zavrit, ale stejne si to sosne jen minimum navigaci,
specielne pokud je to opravdu jen kratkodoby (14dnu ...). Kdyby
existovala da docasna vrstva, tak jelikoz bude mit radove min dat, daj
se aktualizace sosat i pres nase uzasne FUPy (a navic by se do toho daly
ladovat nejspis i data o nehodach ...).

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


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

Re: [Talk-cz] import budov

[jzvc]

Ja vam tady do toho lehce vstoupim - moje predstava, jak by to mohlo
docela pekne fungovat = upravit soucasny tracer plugin, a to tak, ze
nebude trasovat z bitmapy, ale veme vektor/body.

=> zdroj zi zobrazim jako podklad, a pokud klipnu "do budovy", tak ji to
bafne a vlozi do aktivniho layeru. Melo by to samo mit funkci "merge" =>
pokud chci slucovat, melo by jit nastavit zda poloha bude stavajici nebo
ze zdroje + to drapne vsechny stavajici tagy + to samo prida IDcko ze
zdroje a omarkuje pokud je poloha z OSM (aby se to v pripade zmeny ve
zdroji nemenilo). Tohle by melo fungovat tak, ze klipnu (vyberu) dva
objekty stejnyho typu a on je automaticky podle danych pravidel slouci.

Zjistovani rozdilu = vemu objekty danyho typu v danym boxu a podivam se,
zda mam v OSM vsechny objekty danyho typu s danym ID. Ty co tam nejsou
vyrenderuju jako rozdil.
Dale u tech co tam jsou overim, zda maji stejne souradnice (a pripadne
dalsi parametry) jako ve zdroji (pokud ne = rozdil), pripadne zda sou
oznaceny (= v RUIAN je blbost).
Pokud to bude v podobe podkladu (trebas vrstva toho WMS generovanyho z
RUIAN), tak se da velmi snadno a rychle najit kde co chybi.  Melo by to
mit nejakou moznost zpetne prohlasit ze v RUIAN je blbost, a takovej
objekt by se neresil, dokud nebude v RUIAN zmenen (pripadne by to mohla
byt dalsi vrstva).

Ad adresni body - me osobne se nelibi, protoze jak uz sem psal vejs,
pokud ma budova definovany vchody, da se navigovat ke vchodu i z jiny
ulice nez te, kde ma adresu. Pokud je tam bod, tak kazda navigace povede
do ulice, kam ta adresa patri. Dovedu si to predstavit prave pro
oznaceni mist, kde z nejakyho duvodu budova neni, neni tam digitalini
km, ... protoze tam budovy neni moc jak vykreslit.

V takovym pripade bych si asi doved predstavit, ze (v ramci upraveneho
pluginu) vyberu trebas nejaky box a prohlasim ze do nej chci vlozit
vsechny adresni body ze zdroje. S matchovanim to asi bude vselijaky, neb
sem svyho casu podobny veci delal, uspesnost asi nepreleze 80 - 85%. Ale
opet, lze renederovat nejaky rozdil, a postupne se to da dokupy. Hlavne
musi byt nekde videt co kde chybi.



Dne 27.7.2012 14:18, Jan Bilak napsal(a):
> Otázka je, jak by měla vypadat ta připravená data. V případě importu
> nových věcí tak, kde žádné nebyly, je to celkem primitivní. Ale mnohem
> náročnější bude import do míst, kde již nějaká data jsou. Tam bude
> třeba něco starého odstranit, něco modifikovat, něco přidat... Lze v
> OSM formátu postihnout nějak všechny tyto typy změn (odstranění,
> modifikace, přidání nových objektů)? A pokud lze, je možné to pak
> nějak rozumně vizualizovat, aby to člověk mohl projít a rozhodovat
> "tohle je ok, tohle zamítnu a zůstane při starém, tohle bude ještě
> trochu jinak..." pomocí stávajících nástrojů? Nevím, jaké jsou
> možnosti.
>
> Pokud nic vhodné stávajícího není, tak bych to viděl spíše na
> interaktivní aplikaci, která zobrazí ty rozdíly ve vhodné podobě, u
> každé umožní se rozhodnout, zda ponechat stará data, nová data,
> automaticky zmergovat nebo ručně upravit. Ruční úpravu by ta aplikace
> přímo nepodporovala, protože by to bylo příliš náročné (vlastně by
> bylo třeba vytvořit obdobu editoru jako JOSM), ale poznačilo by to
> nutnost ruční editace do dat nějakými tagy, aby výsledek, který z
> aplikace vypadne, bylo možné otevřít např. v JOSM a ručně provést
> potřebné úpravy.
>
> Např. u adresních bodů by bylo podle mě vhodné, aplikace provedla
> nějaké "inteligentní" matchování adresních bodů v OSM a RUIAN,
> zobrazovala původní a nový bod vizuálně propojený šipkou, jinak
> vyznačené body, které jsou pouze v OSM a naopak jinak vyznačené body,
> které jsou pouze v RUIAN. Uživatel by mohl vždy zvolit, zda ponechat
> novou nebo starou polohu bodu (zde by bylo možné i volit vlastní
> polohu - jde o primitivní úkon) atd. Nakonec by aplikace vytvořila OSM
> patch, který by obsahoval požadované úpravy včetně vhodně zmergovaných
> tagů (ty by možná bylo třeba také kontrolovat v aplikaci) atd.
>
> U budov to bude samozřejmě výrazně složitější.
>
> Obecně čistě ručního importu se celkem obávám. Dat je vetší než malé množství.
>
> Honza
>
>
> Dne 27. července 2012 13:41 Miroslav Šulc  napsal(a):
>> Dne 27.7.2012 13:20, Jan Bilak napsal(a):
>>> Ahoj,
>>>
>>> teď z toho nechápu, zda si aplikaci představuješ jen jako evidenční
>>> nebo zda aplikace má provádět vlastní import (resp. s ním výrazně
>>> pomáhat).
>> aplikace "pouze" připraví data z rúian, samotný import provede mapper.
>> tj. aplikace pro import připraví data, ale nebude import provádět, ten
>> se bude dělat ručně. i kdybychom (pokud vůbec, to vyplyne z ručních
>> importů) v budoucnu uvažovali o nějaké automatizaci, tak v prvním kroku
>> se to stejně musí udělat ručně, abychom věděli, nakolik je rúian
>> spolehlivý zdroj, jaké problémy lze očekávat apod. pro kontinuální práci
>> s daty z rúian je pak potřeba ta evidenční část.
>>
>>> Tedy za zásadní považuji porovnání současných OSM dat s daty RUIAN a
>>> následné provede

Re: [Talk-cz] import budov

[Libor Pechacek]

:) Zrovna jsem se chtěl ozvat.

Za svojí prací si stojím, investoval jsem hodně úsilí do korektnosti importů.
Na druhou stranu vím, že některé importy nejsou až tak důkladně provedené.

Nemám nic proti přepsání svých importů daty z RÚIAN, obsahově by měly být
totožná.

Libor

On Wed 01-08-12 16:58:38, Miroslav Šulc wrote:
> no, tady u nás je editorem bodů účet lpechacek, tak nevím, jestli to
> importoval tenhle uživatel.
> 
> ff
> 
> Dne 1.8.2012 14:48, LM_1 napsal(a):
> > Uvažoval jsem přesně takto.
> > Není i dnes většina adresních bodů z importů? Ty ručně dělané budou
> > pravděpodobně správně...
> > LM
> 



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


-- 

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

Re: [Talk-cz] Zásahy BOTa - nutné a provedené opravy

[Michal Tauchman]

 - Vidochov (oprava silnice)
 - Mostek (oprava využití krajin, kompletní předělání zničeného lesa okolo obce)
 - Železnice (oprava drobných detailů smazaných BOTem)
 - Jičín (drobné opravy)
 - Pustějov - Nový Jičín (oprava roztržených silnic)
 - oprava silnice 46421, 46423, 191, 27 (E 53), 190, 145, 14516, 185, 1422, 141 
(obec Bavorov), 271, 501, 46420, 441, 3024, 2904, 27246
 - Bílov (opravy rozpojených silnic)
 - Litochovice/Marčovice (spojovací silnice)
 - Předslavice/Všechlapy (spojovací silnice)
 - koleje č. 1435
 - Vodňany (vodní nádrže)
 - Vodňanské Svobodné Hory (drobné opravy okolních cest)
 - Horní Jiřetín (rebuild smazaných cest)
 - Litvínov (opravy a doplnění roztržených a umazaných silnic)
 - Chomutov (drobné doplnění smazaných uliček)
 - Pecka a okolí (opravy cest), Pecka/Borovnice (tracks)
 - Fulnek (malá silnice obnovena)
 - Boseň (rekonstrukce okolního lesa)
 - Dvorský les (nad Trutnovem) (opraveno přerušení a nevykreslení v mapě)
 - Bobr u Žacléře (opraveny spoje a smazané cesty)
 - Stárkov (opravená spojení)
 - Dobruška (opravená spojení, doplněny silnice)
 - Kostelec nad Orlicí (opravená spojení, doplněny silnice)
 - Pardubice (drobné chyby)
 - Litomyšl (drobné opravy)
 - Loučky (obnova všech městských silnic)
 - Jablonec nad Nisou (smazané budovy)
 - Andělka (doplnění smazaných silnic)
 - Grabštejn (nápravy uliček)
 - Hrádek nad Nisou (drobné opravy)
 - Liberec (opravy silnic)
 - Mařenice (znovuzakreslení místní uličky)
 - Česká Lípa (ulice už byly opraveny, tak jen drobné detaily k doladění)

Další hotové opravy:

 - Turnov
 - Česká Lípa 


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