Re: [Talk-cz] Cizojazyčná jména
Asi má rád červený čokoládový dort. Mě teda skoro víc pobavila "cuisine:Pohlreich"... -- Petr Dne 24.9.2016 v 06:37 Matěj Cepl napsal(a): > On 2016-09-24, 13:26 GMT, Jan Martinec wrote: >> Pokud je name česky (tj . místním jazykem - OTGR), není >> problém, když je tam name:xy, byť tady tím jazykem mluví jen >> turisti. >> >> Problém bych viděl jen u editů typu maps.me: "já plácnu do >> name název v portugalštině, a hotovo" (typicky Staroměstský >> orloj a radniční věž) > To by člověk nevěřil, že někdo může vytvořit něco takovéhleho, > co? http://www.openstreetmap.org/changeset/41349769 > > Matěj > ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Mapnik
Hmm, sledoval bych to top-em, jestli nevyteka z pameti, i kdyz to nesahne na swap - muze byt problem konfigurace, swap je bezne trochu pouzit i na systemech, co maji pameti prehrsle... -- Nenik Jakub Sykora wrote: Urcite bych se podival do /var/log/syslog pripadne spustit dmesg - da se tam ledacos objevit podle casoveho razitka... Ale opravdu to vypada na nejakou nestabilitu zpusobenou tim, ze je to ve VM. K Dne 11.2.2011 12:35, Jakub Rychlý napsal(a): Na tom Linuxovém disku je 25GB volného místa. Swap je zvlášť a při renderování z databáze na něj systém ani nešáhne. Po smazání těch dlaždic s nulovou velikostí a znovuspuštění renderování se ty dlaždice vykreslí a k ním i další, ale po čase (klidně po hodině) to zase spadne. Myslím, že ve volném místu to nebude. V Linuxu se neorientuju a nemám ponětí v kterém logu hledat, ale pokusím se. Zkusím i ten sdílený disk, jak radil Radek Bartoň. Díky za rady. Rychlý ___ 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] Návod na zakreslování turistický ch tras
Zdeněk Pražák wrote: no já mám WIN XP a starší počítač pouze s 512 MB paměti a když jsem JOSM poprvé spustil tak se mi často zasekával a bylo mi ppoté doporučeno natvrdo mu vyhradit 256 MB paměti. Aha. Ono totiz dostatecne moderni JDK ma ergonomics, ktere nastavi velikost java heapu na nejaky zlomek dostupne RAM (s hornim a dolnim limitem), zatimco starsi JDK mely defaultni limit heapu natvrdo 64MB. A to, jake bude celkove chovani spravy pameti v JVM zavisi mimo jine na poctu nalezenych procesorovych jader... -- Nenik ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Izometrická 3D mapa z OSM
Aleš Janda wrote: Celkově bych řekl, že je to viditelná změna k lepšímu :-) Vypada to uzasne! * i přes náhodnost se vykresluje les relativně inteligentně - nikdy nejsou dva stromy příliš u sebe a nikdy strom nezasahuje do cesty, potůčku apod. Např. pokud prostředkem lesa vede silnice, stromy jsou vždy okolo Tady roste strom z namesti: http://osm.kyblsoft.cz/3dmapa/?zoom=17lat=75.54991lon=16.6067layers=B Nicmene podle Mapniku je to asi slozeny multipoly, protoze uprostred ma byt jeste kousek zelene: http://osm.org/go/0Jv16lmJC- -- Nenik ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Dibavod konfliktni data
Jan Dudík wrote: BTWm, jeden dotaz - při pokusu o upload Hracholuské nádrže mě nechtělo pustit dál, že to má víc než 2000 bodů. Já tedy polygon rozdělil na několik menších uzavřených. je to správný postup? Nee, spravne je brehovou linii rozdelit na nekolik na sebe navazujicich way a ty vsechny dat do jedne multipolygon relace jako outer. -- Nenik ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Izometrická 3D mapa z OSM
Aleš Janda wrote: Ty mosty budou perlička, protože to budu vykreslovat nad terénem (a musím to nějak spojit s navazujícími silnicemi). Každopádně vyřešení mostů, tunelů a tagu layer bude chtít ještě trochu práce - teď každý element vykresluji de facto bez informací o ostatních - jakmile ale jsou třeba dva mosty nad sebou, musím to nějak přehodnotit - s tím bude ještě trochu práce :-) Priklad takove pekne mostni palandy je tady: http://osm.org/go/0JziQSnz -- Nenik ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Jak vygenerovat mapu (ideálně do QuickGPS)?
Aleš Janda napsal(a): Chtěl bych se zeptat na celkem běžnou věc - pořídil jsem si externí GPS k mobilu a rád bych mapoval pomocí něj. Bohužel ani po víc jak měsíci jsem nerozchodil žádný způsob, jak na mobilu OpenStreetMap zobrazit. GpsMid. Pouziva vektorova data. Otázka tedy je - jak exportovat mapu do bitmapy (nebo čehokoliv, co by pak tak šlo zpracovat), co je větší než jen mapa malého města? Co používáte vy? Pouzivam montage tool z imagemagick baliku. man montage Kostky mapy pro urcity rozsah si snadno stahnu wgetem... Nenik ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] vazby?
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 ramci konverze a indexace sam. To pro dynamicky stahujici online navigace je to horsi, ale ty zase maji k dispozici online indexacni web service. Nenik ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Spolupráce na OSM
Frettie napsal(a): Ano, nicméně to neřeší to, když to někdo změní, tak bude mít ten člověk problém s nalezením toho správného prvku s tím správným autorem. Aspon se nauci OSM history API 2009/6/26 Pavel Kovář f...@vsetin.org: U každého prvku v mapě je vidět autor ne ?Stačí aby si hledající uvěřil že autorem je skutečně ten autor kdo to má být. S pozdravem Pavel Kovář ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] adresni body a POI
Petr Kadlec napsal(a): povazujete za vhodne slucovat adresni body a POI? Matne si pamatuji ze o tom sla kdysi rec. Me se to zda charakterem geoprvku reprezentujici POI a adresni body i stavem rendereru za nestaste. Když jsem začínal, přišlo mi to přirozené a párkrát jsem to tak udělal. Pak jsem zjistil, že to renderer vůbec nezvládá, a i nějak obecně jsem si zdůvodnil, že to není úplně dobrý nápad, takže teď už je neslučuju… No pokud z vyhledavace na shop=organic vypadne ze: shop=organic [souradnice] near(1m) Namesti Sitna 3104, Kladno tak je mozna OK to rozdelovat, (ne vzdy jdete do obchodu s GPSkou, ze) ale zase se mi prici, aby na benzince byly ctyri puntiky, jako ze fuel, shop, restaurant a jeste k tomu cislo popisne... -- Nenik ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Začátečnické dotazy
Milan Zamazal napsal(a): RC několik vteřin na zobrazení menu je neobvyklé. Přitom zrovna RC menu je spíše záležitostí samotné Javy než JOSM. Používáte RC Windows, Linux nebo OS-X? Říká se, že pod Windows jsou Javové RC programy znatelně pomalejší než v ostatních systémech. Jinak RC vzhled máte nastavený na Metal? A v neposlední řadě -- jak RC výkonný máte počítač? Debian GNU/Linux, amd64, X2 3800+, vzhled Metal. Zkusil jsem josm nainstalovat na jiný, systémově i hardwarově podobný, počítač a tam je mnohem svižnější. Podezříval jsem Java Access Bridge, ale tím to není. Takže díky za informaci, podumám, v práci to nebrání, jen je to otravné. Diagnostice by pomoho spustit to z prikazove radky a behem toho vytuhnuti procesu nekolikrat poslat SIGQUIT (Cltr-\). Java na konzoli pokazde vypise thread dump a v nem bude dobre videt, co se zrovna delo. A treba poznat i jaky plugin to zpusobuje ;-) Nenik ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Gradiozni experiment tendujici ke konvergenci disputace o notaci adresnich elementu
Radomir Cernoch napsal(a): Dobrý den, čeká Vás dlouhý mail. Chystáte-li se jej rovnou smazat, čtěte alespoň poslední sekci. Uff, tak konecne jsem trochu pouzitelny (tentokrat uz hezky doma na Peklove). Adresa 'Vodičkova 792/40, Praha' se tak zapíše jako: 'addr:housenumber' = 792/40 'addr:[čp_klíč]' = 792 'addr:[čo_klíč]' = 40 'addr:street' = Vodičkova 'addr:city'= Praha 'is_in'= Praha, CZ Ano, takhle bych si to predstavoval. Mirna, vetsinou strojove dodana, duplicita vyvazi zvysenou kompatibilitu s obecnymi renderery a hledaci. * E[če] +1 1) Čísla evidenční -- Tady nemam silny nazor. 3) Čísla popisná Nebo je tu snad někdo, kdo na 'konskriptionsnummer' nedá dopustit? Za to, ze bude vse fungovat jak ma bych i pripustil presne oznaceni tim osklivym nemeckym slovem. Ostatne tyhle tagy tam pridavame kvuli semanticke cistote, tak proc je ciste nenazvat. Nenik ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Adresy, finale diskuse
Martin Kokeš napsal(a): Dne 5.6.2009 9:07, Petr Nejedlý napsal(a): Zdar, Moje namitky proti konscriptionnummer: 1. Nikdy zadny globalni search engine nebude zohlednovat tuhle opicarnu. 2. Nikdy zadny globalni rendered nebude renderovat tuhle opicarnu. 3. (plyne z 1 a 2) AndNav2 me nikdy nedovede na takovou adresu. 1. Ale ano, bude a zohledňuje. Zkuste si vyzkoušet v libovolných webmapách v libovolném městě zadat adresu s číslem popisným a číslem orientačním. Najde vám obojí. 2. Pokud nikdo nenavrhne a nepožádá o začlenění příslušného stylu, o co se, jak vidno, už vynasnažil Radek Černoch, tak ne. 3. Pokud bude vývojář AndNav2 líný začlenit do svého SW funkci, kterou disponuje libovolný TomTom Navcore, IGO, Garmin, tak nedovede. V opačném případě ano. Nepochopili, takze na ujasneni: Mluvim o OSM, ne libovolnych web mapach. Ty to prave umi, nebot nemaji tu opicarnu. tou opicarnou myslim, ze informaci, podle ktere chceme hledat a kterou chceme renderovat si na nasem pisecku hodlame dat jen(*) do nejakeho exotickeho tagu. Samozrejme jde jak do vyhledavace tak do rendereru dodelat podporu nasi lokalni anomalie, jenze jak by to vypadalo, kdyby si kazdy na svete pridal tu svoji lokalni a lokalnejsi (/III v jistem zminenem meste) anomalii do dalsiho tagu a chtel, aby mu nad tim osm.org (a jine globalni projekty, jako treba zmineny AndNav, ktery ostatne pro hledani pouziva dalsi, pologlobalni sluzbu) fungovaly vsechny takove ty normalni featury jako je renderovani a hledani. *) Zatimco jsem spal (SF, CA, USA), zacaly se veci pohybovat mnou preferovanym smerem. Tato opičárna u nás je od C.K. R-U, stěžujte si u svých samospráv, proč za ta léta, kdy jsou u vesel a nejsou řízení centrálně, ještě nezavedli čísla orientační (housenumbers), jak je současným standardem: Tou opicarnou jsem nemyslel zpusob evidence adres, ale jeho navrhovanou reprezentaci v OSM. Nenik ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Adresy, finale diskuse
Radomír Černoch napsal(a): 3. (plyne z 1 a 2) AndNav2 me nikdy nedovede na takovou adresu. rationale(hodne nadnesene): Na Bali mani ricenumber (cislovani domu zavedene za ucelem zdaneni ryzove urody). V honolulu maji Mely by vsechny ty tooly tohle zohlednovat? Záleží na tom, jestli je to pro ně zásadní údaj. V ČR to zásadní je, protože velká část domů jiné číslo nemá. A prave proto, ze je zasadni, by mel byt v zasadnim tagu. Tomu nerozumím. V čem je 'konskriptionsnummer' větší přívěsek v databázi než 'alternatenumber'? Vágnější význam má přece 'alternatenumber', nebo ne? S pozdravem, Radek Černoch PS: Já se omlouvám za svoji tvrdohlavost. Ale dobrá polovina argumentů proti změně je založená na tom, že se někomu z estetických důvodů nelíbí jméno tagu. Také bych byl rád, aby se mi při vyslovení toho slova nezauzloval jazyk, pojďme se ale bavit o skutečně praktických dopadech přejmenování. Me osobne je jmeno pridavneho tagu ukradene, pro me je primarne dulezite, aby byla dostupna dostatecne dobra informace v tom tagu, ktery zna a pouziva cely svet, byt s mirnymi semantickymi odchylkami. Proti tomu totiž stojí přesnější datový model, v němž klíč tagu přesně určuje jeho hodnotu. Presnejsi, ale slozitejsi. At tam ta informace klidne je i presne, ale at tam je hlavne obecne. Nenik ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Adresy, finale diskuse
Radomír Černoch napsal(a): Jinak hodně bych ocenil kdyby někdo na českou wiki strčil vzorově otagovaný baraček a panelák s více vchody. Něco o tagování domů jsem teď na wiki dával (Cz:JOSM/Plugins/CzechAddress), je to ale zaměřené na plugin samotný. Nějaké praktické HowTo bych také rád přidal. Jen -- panelák s více vchody má více adres? Jak se to značí správně? Škoda že je zavrhováno tagování čísel evidenčních. V jednom takovém bydlím a vážně bych rád, aby se ke mě dalo normálně doroutovat a nemusel jsem každému vysvětlovat, že pak ještě tam a tam. Ostatně, proč adresní body vůbec do OSM ukládáme? Aby se podle nich dalo hledat a tím pádem i navigovat. A evidenční čísla se nepřidělují objektům ani tak dle velikosti, jako spíše dle určení, takže ve finále může těch evidenčních čísel ke kterým budete chtít routovat (typicky rekreační objekty) být vcelku dost... Nenik ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] N?pad na jednodu??? kreslen? budov
MP napsal(a): Je tu jeste josm-ng, kde prohlizeni je celkem rychly, ale loadovani dumpu pro celou republiku trva vecnost a sezere to dost pameti. Coz o to, pri testovani -ng pouzivam privatni binarni format (semanticky ekvivalentni s normalnim .osm souborem) a ten nactu pro celou CR za 15s, ale stale to je skoro 400MB dat v pameti, z nichz vetsina (2/3) je tam kvuli editaci a pro prohlizecku zbytecna. Dovedl bych si ale snadno predstavit zobecneni -ng rendereru, aby nebyl zavisly na datech v pameti a misto toho dotahoval on-demand z predindexovanych souboru na disku. Ted vpodstate takovy renderer zkousim napsat na Android, kde je ta java (a hlavne grafika) fakt pomala, tak treba z toho neco bude. -- Nenik ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
