subject:"Re\: \[Talk\-cz\] Import budov"

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 fordf...@fordfrog.com napsal(a):
Dne 27.7.2012 13:20, Jan Bilak napsal(a):
Ahoj,

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

Tedy za zásadní považuji porovnání současných OSM dat s daty RUIAN a
následné provedení změn (posuny stávajících bodů, opravy tagů,
zachování

Re: [Talk-cz] import budov

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] import budov

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
 fordf...@fordfrog.com 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
 fordf...@fordfrog.com napsal(a):
 Dne 27.7.2012 13:20, Jan Bilak
 napsal(a):
 Ahoj,

 teď z toho nechápu, zda si aplikaci
 představuješ jen jako evidenční
 nebo zda aplikace má provádět
 vlastní import (resp. s ním výrazně
 pomáhat).
 aplikace pouze
 připraví data z rúian, samotný import provede mapper.
 tj. aplikace
 pro import připraví data, ale nebude import provádět, ten
 se bude
 dělat ručně. i kdybychom (pokud vůbec, to vyplyne z ručních
 importů) v budoucnu uvažovali o nějaké automatizaci, tak v prvním
 kroku
 se to stejně musí udělat ručně, abychom věděli, nakolik je
 rúian
 spolehlivý zdroj, jaké problémy lze očekávat apod. pro
 kontinuální práci
 s daty z rúian je pak potřeba ta evidenční
 část.
 Tedy za zásadní považuji porovnání současných OSM
 dat s daty RUIAN a
 následné provedení změn (posuny stávajících
 bodů, opravy tagů,
 zachování stávajících tagů, doplnění
 chybějících tagů, ...).
 Samozřejmě s tím, že proces bude pod
 manuální kontrolou člověka, který
 bude import provádět (tedy
 nikoli plně automatický, ale
 poloautomatický). O těchto funkcích
 se v popisu nezmiňuješ.
 vycházel jsem hlavně z importu budov tam,
 kde je nemáme, to je asi ta
 nejjednodušší

Re: [Talk-cz] import budov

2012-08-02 Tema obsahu 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 lpecha...@gmx.com
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 lpecha...@gmx.com
---
 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 HashSetstring noCapitalize = new HashSetstring(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

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

 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

 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 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
attachment: xificurk.vcf

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

2012-08-02 Tema obsahu 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

2012-08-02 Tema obsahu 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 kub...@kbx.cz 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

2012-08-02 Tema obsahu 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 flukas.robot+...@gmail.com 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 kub...@kbx.cz 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] import budov

2012-08-02 Tema obsahu Martin Kokeš

Předpokládám, že tehdy při importu UIR-ADR nikdo chybu při převodu JTSKWGS84 
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 flukas.robot+...@gmail.com 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 kub...@kbx.cz 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] import budov

Martin Kokeš wrote:
 Předpokládám, že tehdy při importu UIR-ADR nikdo chybu při převodu JTSKWGS84 
 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
attachment: xificurk.vcf

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

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 kub...@kbx.cz 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

2012-08-02 Tema obsahu 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 http://wiki.openstreetmap.org/wiki/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

2012-08-02 Tema obsahu 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

2012-08-02 Tema obsahu 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

2012-08-02 Tema obsahu 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
 JTSKWGS84 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] 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/



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

2012-08-02 Tema obsahu 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

Dne 3. srpna 2012 1:07 Martin Kokeš sh...@typo3-hosting.com 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