Re: [Talk-cz] automaticka pojmenovavacka ulic
On Fri 2008-11-21 16:36:47, Tom?? Tich? wrote:
Ahoj,
neda?? se mi p?elo?it nameit - v SVN je n?jak? divn? verze libosm, na
kterou nejde aplikovat Tv?j patch, ani to s n? nejde p?elo?it. Ne?lo
by n?kam vystavit verzi libosm, se kterou to funguje ?
Je to jeste aktualni? Kdyztak osobne, at na to zase nezapomenu...
On Sun, Aug 31, 2008 at 00:51, Pavel Machek pa...@ucw.cz wrote:
...docela funguje, tj na uz pojmenovanych ulicich se vetsinou
trefi. Prvni verse je tady.
(Samozrejme ocekava uid-adr adresni body jiz importovane... Coz se da
pro lokalni pouziti udelat treba tou shellovou priserou, pak download
zbytku v josm a ulozenim.)
Index: applications/lib/libosm/Way.cpp
===
--- applications/lib/libosm/Way.cpp (revision 10302)
+++ applications/lib/libosm/Way.cpp (working copy)
@@ -65,7 +65,7 @@
if (hasTags() || segments.size()) {
strmway id=' id ' endl;
for(int count=0; countsegments.size(); count++)
- strm seg id=' segments[count]
'/ endl;
+ strm nd id=' segments[count] '/
endl;
tagsToXML(strm);
strm/way endl;
} else {
Index: applications/lib/libosm/Parser.cpp
===
--- applications/lib/libosm/Parser.cpp (revision 10302)
+++ applications/lib/libosm/Parser.cpp (working copy)
@@ -45,23 +45,6 @@
}
- else if(!strcmp(element,segment))
- {
- curID=0;
- inSegment = true;
- for(int count=0; attrs[count]; count+=2)
- {
- if(!strcmp(attrs[count],from))
- from = atoi(attrs[count+1]);
- if(!strcmp(attrs[count],to))
- to = atoi(attrs[count+1]);
- if(!strcmp(attrs[count],id))
- curID = atoi(attrs[count+1]);
- }
-
- curObject = new Segment(curID,from,to);
- components-addSegment ((Segment*)curObject);
- }
else if (!strcmp(element,way))
{
curID=0;
@@ -74,13 +57,13 @@
curObject = new Way(curID);
components-addWay((Way*)curObject);
}
- else if (!strcmp(element,seg) (inWay))
+ else if (!strcmp(element,nd) (inWay))
{
int segID;
for(int count=0; attrs[count]; count+=2)
{
- if(!strcmp(attrs[count],id))
+ if(!strcmp(attrs[count],ref))
{
segID=atoi(attrs[count+1]);
((Way*)curObject)-addSegment(segID);
Index: applications/lib/libosm/Makefile
===
--- applications/lib/libosm/Makefile(revision 10302)
+++ applications/lib/libosm/Makefile(working copy)
@@ -3,6 +3,7 @@
OBJ = Object.o Way.o Parser.o Components.o functions.o llgr.o
FeaturesParser.o
NETOBJ = Client.o
TESTOBJ = test.o
+NAMEITOBJ = nameit.o
RULESTESTOBJ = rulestest.o
CXX = g++
@@ -15,6 +16,9 @@
test: $(TESTOBJ) libosm.a libosmnet.a
$(CXX) -o test $(TESTOBJ) libosm.a libosmnet.a $(LDFLAGS)
+nameit: $(NAMEITOBJ) libosm.a libosmnet.a
+ $(CXX) -o nameit $(NAMEITOBJ) libosm.a libosmnet.a $(LDFLAGS)
+
rulestest: $(RULESTESTOBJ) libosm.a
$(CXX) -o rulestest $(RULESTESTOBJ) libosm.a $(LDFLAGS)
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] vazby?
On Wed 2009-11-04 13:43:26, Petr Nejedl?? wrote: Pavel Machek napsal(a): On Tue 2009-11-03 18:46:02, Martin Mares wrote: Dobry vecer vespolek! A to ma chudinka navigace pokazdy stahovat celej svet aby zjistila ve ktery je zemi? Neni spis chyba, pokud si nemuze jednoduse stahnout vsechny relace, ve kterych objekty z daneho uzemi lezi? To co se tu navrhuje ale nejsou relace, nybrz polygon okolo. Ne ne, to nebude fungovat. Takze jo, predstavuju si, ze u kazdy ulice bude is_in=jmeno_mesta a u kazdyho mesta pak bude is_in=CR . Prijde mi hloupe udrzovat v mape informace, ktere jsou z principu redundantni -- pokud je prislusnost k mestu definovana jako lezeni uvnitr hranice mesta, ma byt reprezentovana tou hranici, ne nejakymi odvozenymi atributy. Ty se preci mohou kdykoliv dopocitat podle potreby. Trochu hloupe to je, ale zase nemusi kazdy implementovat vypocet znova (coz by bylo taky ne-chytre). 'Kdykoliv dopocitat' bohuzel neni vubec trivialni -- presne pro to ze tu hranicii vubec nemusim mit ve stazenych datech. Navic veci jako navit funguji offline a konveruji mezi ruznymi formaty... A specialne pro offline navigaci s konverzi formatu tam ty atributy nejsou potreba. Konverzni algoritmus ma dost casu a prenosovky na to, aby si stahnul tu (napr.) Ceskou Republiku celou a dopocital si to v 'dost prenosovky'? Nevim, tahat 170MB zbytecne mi prijde divny. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] vazby?
On Wed 2009-11-04 14:43:14, Martin Mares wrote: Ahoj! Neni spis chyba, pokud si nemuze jednoduse stahnout vsechny relace, ve kterych objekty z daneho uzemi lezi? To co se tu navrhuje ale nejsou relace, nybrz polygon okolo. A nestacilo by, aby protokol umel stahnout vsechny polygony, ktere maji s danym uzemim neprazdny prunik? Stacilo, ale on to AFAIK neumi. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] vazby?
On Thu 2009-11-05 15:13:00, MP wrote: jen podotykam, ze tag is_in pro ulici je problematicky jeste z duvodu, ze existuji situace, kde je jedna ulice jednoho nazvu soucasti vice obci. Jinak drzet i u online navigace geopoliticke deleni na urovni statu lokalne mi prijde vice nez vhodne. Hranice se precijen kazdy den nemeni. Takze zjistit v jakem state se zrovna nachazim = podivat se uvnitr jake hranice prave jsou souradnice z GPS. Offline navigace si muze potrebna data dopocitat kdykoli, tam bych nevidel vubec zadny problem. Tohle by slo udelat treba tak, ze se z planet dumpu (pripadne z dumpu, kde je alespon cely stat, jako napriklad dumpy ceske republiky) udela vycuc jen hranic (cimz by pak ten soubor mel vcelku rozumnou velikost) a nekde se zpublikuje. Tenhle soubor s hranicemi by pak sel pouzit v navigaci pokud si tam chce slovek nacpat mensi kus nez jeden stat (v dumpech statu jsou i hranice kolem toho dotycneho statun a nic vetsiho uz v datech neexistuje - hranice kontinentu tam myslim nejsou a hranice zemekoule je jeden ctverec, ktery si kazdy muze vygenerovat sam :). Navic pokud se cela hranice nachazi vne stazene oblasti, tak navigace ji nemusi resit - proste vsechny adresy se nachazi v jednom state/meste, at uz je to cokoliv, neni pak potreba resit problem typu ze ulice Prazska je v skoro kazdem vetsim meste ci vesnici ve stredoceskem kraji. Tohle by fungovalo, ale znamena to udrzovani novy infrastruktury. Stale mi prijde jednodussi pridat tam is_in. Znamena to, ze klienti maji informace pristupny jako obvykle, a kazdy nemusi psat algoritmus na vyhledavani 'v kterych polygonech ze je tenhle bod'? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Pr?vn? rozbor definice ??edn?ho d?la
On Sat 2009-10-31 01:41:20, hanoj wrote: Dne 30. ??jna 2009 19:22 Martin Koke? sh...@typo3-hosting.com napsal(a): ?irou n?hodou jsem narazil na docela podrobn? rozbor, kter? potvrzuje moje d??v?j?? amat?rsk? dedukce ohledn? za?len?n? DIBAVODu. http://www.isvs.cz/legislativa/patri-uredni-databaze-vsem.html Velmi d?le?it? je podle m? pas??: Pro up?esn?n? dodejme, ?e takov? datab?ze m??e b?t ??edn?m d?lem i v p??pad?, ?e ji vytvo?il soukrom? subjekt (nap?. na zak?zku). Z?kon nespojuje ??edn? d?lo s ot?zkou autorstv? (tedy kdo ho vytvo?il), ale s ot?zkou, zda existuje ?i neexistuje ve?ejn? z?jem na vylou?en? z ochrany autorsk?ho z?kona. A kone?n? i nazna?en?, jak?m zp?sobem by m?ly b?t v?echny zak?zky ze strany ??ad? zad?v?ny: Subjekt, kter? datab?zi vytvo?il, by m?l v?dy od povinn?ho org?nu dostat p?i zad?n? zak?zky ?i p?i uzav?r?n? autorsk?ho ujedn?n? informace o tom, k ?emu bude d?lo vyu??v?no a z jak?ch zdroj? vych?z? pot?eba vytvo?en? t?to datab?ze. Co te? br?n? kompletn?mu importu DIBAVODu, p??padn? UIR-ADR? Ve?ejn? z?jem je pojem neur?it?, je t?eba ho vykl?dat a posuzovat v?dy znovu v ka?d?m jednotliv?m p??pad?. P?i tomto posuzov?n? se st?etnou dv? hlediska - ve?ejn? z?jem na vylou?en? z ochrany a z?jem (pr?vo) autora (v na?em p??pad? po?izovatele datab?ze). V?dy je t?eba pe?liv? zva?ovat, kter? z?jem p?ev???. Kdo z nas bude tento arbitr a pravne to prikryje? Neni lepsi zeptat se gestatora databaze, zda nas nebude jednou zalovat? Bohuzel ten 'majitel' databaze ma dobry duvod lhat :-(. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Pr??vn?? rozbor definice ????edn??ho d??la
A kone??n?? i nazna??en??, jak??m zp??sobem by m??ly b??t v??echny zak??zky ze strany ad?? zad??v??ny: Subjekt, kter?? datab??zi vytvo??il, by m??l v??dy od povinn??ho org??nu dostat p??i zad??n?? zak??zky ??i p??i uzav??r??n?? autorsk??ho ujedn??n?? informace o tom, k ??emu bude d??lo vyuv??no a z jak??ch zdroj?? vych??z?? pot??eba vytvo??en?? t??to datab??ze. Co te?? br??n?? kompletn??mu importu DIBAVODu, ppadn?? UIR-ADR? UIR-ADR uz importovany je, DIBAVOD by to importovat chtelo. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] vazby?
Ahoj! A nestacilo by, aby protokol umel stahnout vsechny polygony, ktere maji s danym uzemim neprazdny prunik? Stacilo, ale on to AFAIK neumi. A neni lepsi to ten protokol naucit, misto abychom zavadeli ruzne berlicky v podobe tagovani vsech objektu atributem is_in? Have a nice fortnight -- Martin `MJ' Mares m...@ucw.cz http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Lisp Users: Due to the holiday, there will be no garbage collection on Monday. ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] vazby?
A nestacilo by, aby protokol umel stahnout vsechny polygony, ktere maji s danym uzemim neprazdny prunik? Stacilo, ale on to AFAIK neumi. A neni lepsi to ten protokol naucit, misto abychom zavadeli ruzne berlicky v podobe tagovani vsech objektu atributem is_in? To neni tak jednoduchy. Protokol by musel umer pro kazdou cestu poznat jestli je to uzavreny polygon, nebo jestli je to jen cesta. Coz je slozitejsi nez se zda, system by musel pomerne podrobne zkoumat tagy aby zjistil co to je (to ze je cesta uzavrena jeste neznamena ze je to polygon - viz. treba zeleznicni okruh u velimi) a pak do hry prichazeji multipolygony, poskladane z nekolika cest (u ceskych lesu, kde vnejsi cesta je delsi nez 2000 bodu je i ta vnejsi cast poskladana z X cest) a tenhle vypocet do znacne miry komplikujici. Vysledkem by asi byl nejaky kompromis mezi tim, ze server to bude odhadovat a nacpe do vysledku i spoustu false positives co vypadaji jako polygon ale polygon nejsou (clovek si krome maleho okoli ulice kde chce mit navigace stahne tez hranice mesta, statu a kontitnentu a pak jeste X cest co jsou nekde pobliz, ale uz mimo oblast a algoritmus je blbe odhadl jakozto polygon) a tim, ze server bude v tomhle presny, ale stravi nad tim nechutne mnozstvi CPU casu. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
