[Talk-lt] 6200 lankytinų vietų!
Sveiki Lietuvos lankytinų vietų žemėlapyje jau 6200 lankytinų vietų: piliakalnių, dvarų, pažintinių takų, bokštų, gamtos objektų, muziejų, teatrų, maldos namų ir pan. Na ir greta dar 15000 papildomų vietų, reikalingų keliaujant: maistas, apgyvendinimas, transportas ir pan. https://places.openmap.lt Taigi visi jau sukūrėme daugiausia lankytinų vietų turintį Lietuvos žemėlapį, bet galime dar geriau! -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] Metinis susitikimas
Sveiki Primenu, kad šiandien 18:00 Savičiaus Špunkoje: https://openmap.lt/#m/18/54.67875/25.28902/0/0//p2811970425 vyks metinis asociacijos „Atvirasis žemėlapis“ susitikimas. Kviečiami visi, norintys pasikalbėti apie OpenStreetMap, aptarti rūpimus dalykus, paklausti klausimus, susipažinti, na ir šiaip pablegyzgoti apie žemėlapius. Susitikimas bus rūsyje, tai sakykite barmenams ir barmenėms, kad einate „pas Tomą“, jus nukreips žemyn :-) -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] Upių pavadinimai virš vandens telkinių
Sveiki > Jei teisingai suprantu, Aurimo ir Mindaugo pozicija yra rodyti upių > pavadinimus ir vandens telkiniuose? Tai būtų 2:1 pavadinimų naudai. > Jei taip: padarysiu waterway:name => name + nauja_žyma pakeitimą po > ~savaitės. Tada upių pavadinimai telkiniuose grįš į visus žemėlapius > išskyrus *.openmap.lt Visi waterway:name pakeisti į name. https://www.openstreetmap.org/#map=15/54.8070/24.2404 https://www.openstreetmap.org/#map=16/55.7727/25.8187 -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [OSM-talk] iD influencing tagging
2019-04-07, sk, 19:06 Bryce Jasmer rašė: > The wiki page for landuse=reservoir says: > "Description: Ambiguous and better alternatives exist, see water=reservoir" > So, is iD wrong to use this, or is the wiki incorrect? Wiki is incorrect. Even "creator" of "everything blue is natural=water" agreed (in wiki discussion) that his scheme is in no way superior to existing OSM water scheme and does not depreciate established landuse=reservoir tag (and other tags like waterway=riverbank etc.). And most importantly - mappers have "voted" with mapping more landuse=reservoir (426 123) than water=reservoir (194 454) (even with iD making it extremely hard for non experts to tag landuse=reservoir). ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] iD influencing tagging
2019-04-07, sk, 17:47 Bryce Jasmer rašė: > Can you give some examples of what the OSM normals are and how iD differs > from them? There is no way (other than writing tags directly) to tag reservoirs as landuse=reservoir (original and still wider used water tagging scheme), iD insists on natural=water+water=reservoir. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[Talk-lt] Metinis susitikimas
Sveiki Balandžio 10 dieną (trečiadienį) Savičiaus Špunkos (Savičiaus g. 9) rūsyje nuo 18:00 vyks metinis asociacijos „Atvirasis žemėlapis“ susitikimas. Kaip visada, kviečiami visi (ne tik asociacijos nariai), norintys pasišnekėti apie Open Street Map. -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] Upių pavadinimai virš vandens telkinių
2019-03-31, sk, 19:07 Mindaugas rašė: > Jei postgis nesunkiai moka atpažinti, kad tam tikra upės dalis yra po > ežeru, kodėl iš viso kalbame apie kažkokius specialius žymėjimus - > vektoriaus padalinimą, waterway:virtual=yes ir pan. Kodėl neužtenka > ant visos upės turėti vien tik water=river/stream, name=x? Na highway irgi galime padalinti pagal tai, kuri dalis yra miesto dalyje, kuri nėra ir taip sudėlioti tarkim maxspeed, bet taip nedaroma. Upės centrą (waterway=river) galima bandyti paskaičiuoti iš aukštesnės dimensijos objekto waterway=riverbank, bet taip nedarome (OSM'e, kituose GIS taip būna daroma, nes ne visi turi centro linijas pradiniuose DLM). Taip ir čia, norima konkrečiai įrašyti tos konkrečios atkarpos realias savybes, todėl ir dalinama upė, ne todėl, kad norima nerašyti pavadinimo ant ežero (nors tai ir buvo pradinė mano mintis, bet ši diskusija padėjo suprasti/pagalvoti ir apie skirtingas vandens telkinio praplaukimo vektorių savybes lyginant su upėmis). Dalinti jums nieko nereikės, viską, ką reikia, padalinsiu aš :-) >> Upę kurti pagal name žymas yra tikrai plastelininė logika (nes ... > O yra koks nors geresnis būdas (neskaitant nenaudojamo relation)? Kai > bandžiau palyginti su geoportal duomenim ir gauti koks procentas upių > yra padengtas OSMe, tai to plastelino daug prilipdžiau. Relation ir yra vienintelis teisingas būdas. Anksčiau ar vėliau, kuriant upių MRDB reikės dėliot tiek vertikaliai per skirtingus mastelius, tiek ir horizontaliai - jungti dabar dėl skirtingų priežasčių (tarkim dėl per upės centrą einančios admin. ribos ar pralaidų) padalintus upių vektorius į vieną. Tada turėtų ir ryšiai susidėlioti. >> Pabandžiau patikrinti po 5 random vietas: > Rusija/Karelija - visur epė su pavadinimu eina per ežerą; > Suomija/Karelija - visur upė nutrūksta vos įtekėjusi į ežerą (pas juos > gana dažnai tos protakos pavadinimų neturi, tai net sunku rasti, kad > tokiu pačiu pavadinimu įtekėtų ir ištekėtų) > Tai matyt praktika nėra vienoda. Teisingai. Todėl ir tariamės/diskutuojame čia, kad surastume sau tinkamiausią variantą. identifikuotume realias problemas ir pan. -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] Upių pavadinimai virš vandens telkinių
2019-03-31, sk, 15:30 Aurimas Fišeras rašė: >>Kodėl negalime? > Nes upių atkarpos nestandariškai sužymėtos, o relation:waterway yra tik > ant labai mažos dalies upių. Čia jau ratu sukame :-) Klausimas, ar waterway=river per vandens telkinius yra labai „standartinis“ dalykas. Upę kurti pagal name žymas yra tikrai plastelininė logika (nes nestabili, greitai sugriaunama ir, kaip jau minėjau, veikia tik labai nedidelėms vietinės reikšmės upėms, nepamirškime, kad kai kurios upės iš principo keičia pavadinimą nuo kažkokio taško). >> Bet taip, kaip daliname highway, >> kažkokia kitokia žyma bus ir upių atveju, gal virtual=yes, gal >> flow_speed=0 ir pan. Ir tai bus realios situacijos aprašymas (upė turi >> visai kitas savybes, kai „teka“ per telkinį), o ne duomenų keitimas >> grynai vardan braižymo. > Net ir tada, kai tuos duomenis turėsime ir naudosime tik braižymui? ;) Keitimą vardan braižymo turėjau omeny „tag for renderer“. Kai pridedamos su realybe nieko neturinčios žymos tam, kad braižymo rezultatas būtų toks, kokio norime. Šiuo atveju yra ne taip. >>2. Upės vektoriaus dalinimas. > Jei tai tik techninis dalinimas atvaizdavimui – ne. Tai upės fizinių savybių apibūdinimui. Vektorius vandens telkiniuose neturi absoliučiai jokių normalios upės savybių (na išskyrus šlapumą:-) >> OpenStreetMap-Carto, Garmino mkgmap projektui ir šimtams kitų >> projektų. Atkeitus waterway:name => name mes jau daugiau įtakos >> kitiems projektams nepadarysime. > O kodėl mes turime daryti įtaką kitų projektų žemėlapių atvaizdavimui? Jei atvaizdavimo korektiškumas mums dzin, tada tai nebeaktualu. >> + nauja_žyma pakeitimą po ~savaitės. > Kurios paskirtis bus tik įtakoti atvaizdavimą? Ne, nurodyti, kad ta waterway=river realiai visai ne upė. -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] Upių pavadinimai virš vandens telkinių
2019-03-30, št, 15:44 Aurimas Fišeras rašė: >>Nenorėčiau sutikti. Nes aš nemanau, kad per ežerą teka viena ar kita >> upė, ten yra tik ežeras. > Taip nėra, juk upė niekur nedingsta. Pvz., geoportal.lt lyginant > skirtingų metų ortofoto nuotraukas, kai koks vandens telkinys stipriai > nusekęs, akivaizdžiai matosi upės vaga (thalweg?) per vandens telikinį. > Jei turėtume vandens telkinių gylių duomenis (kaip dabar turime > aukščių), greičiausiai pamatytume ir upių vagas. Tvenkiniuose taip, galima sakyti, kad ten upė teka. Bet dėl ežerų reikia daugiau nuomonių. >>Na tokią žemėlapio klaidą galima būtų ignoruoti, bet tik tol, kol >> neegzistuojančios upės pavadinimas nedengia to, ką mes norime pamatyti >> - vandens telkinio pavadinimo. > Kodėl tai žemėlapio klaida, kai pavadinimai nepersidengia, o vektorinį > žemėlapį galima pritraukti, pasukti? Beveik nėra internetinių žemėlapių, kurie būtų kartografiškai teisingi. Čia viena iš kartografijos bėdų, kad atsiradus prieinamumui, žemėlapius pradėjo daryti bele kas, ir todėl yra prikepta milijonai labai prastų žemėlapių. Geras internetinis žemėlapis: https://map.geo.admin.ch Blogas internetinis žemėlapis: googlė maps (vertinant grynai iš kartografinės pusės) Klaida rodyti ir telkinio, ir upės pavadinimą pavyzdžiui todėl (bet ne tik todėl), kad atsiranda dviprasmiškumas: jei ant ežero poligono matau du pavadinimus „Bevardis“ ir „Bedugnis“. Kas tai? Du skirtingi ežero pavadinimai? Tai du ežerai? Kuris upė? Kuris ežeras? > Klausimas, ar kartografiškai teisingas skaitmeninis, interaktyvus > žemėlapis bus patogiausias naudoti? Dauguma dabar kartografų kuriamų žemėlapių yra skaitmeniniai. Ta prasme padaryti iš skaitmeninių duomenų, skaitmeniniu būdu apdoroti, paruošti ir susimbolizuoti, tik tiek, kad tada atspausdinti ant popieriaus, o ne pateikti internete (išskyrus SwissTopo aukščiau pateiktą variantą, na ar kokius Ordnance Survey ir pan.). Taigi nesuprantu, kodėl internetinis žemėlapis turėtų turėti kitokius (žemesnius) kokybės standartus? >>O kas, kur ir kodėl bando upę sujungti pagal name? > O pagal ką jungti? Kaip, pvz., su https://overpass-turbo.eu/ gauti upės > vektorių, kai nėra relation:waterway? Tai overpassas bet kokiu atveju nesujungs. Nemunas Lietuvoje turės name=Nemunas, palei siena Nemunas/Neman, toliau Neman ir pan. Ir tai nėra vienintelė upė, kuri kerta sieną, kitos kerta po kelis kartus, kažkiek kilometrų per jas eina siena ir pan. Name žyma netinka grupavimui bet kokiu atveju. Kitos upės turi pasikartojančius pavadinimus. Net didelės ir žinomos - tarkim Šešupė. > Pvz., UETK analogas. Ten nuėmus varnelę „Tvenkiniai“ pasimato upių > vektoriai, kurie ėjo po tvenkiniais. Sutinku, neblogas pavyzdys. Tik jie turi daug info, jei viską rašytų į kiekvieną segmentą, bus baisiau už baisiausią filmą. Taigi sprendimas - tik ryšys :-) > Kur nesakoma? Google paieška randa įvairių variantų įvairiose srityse. > O, pvz., Vikipedijoje „įteka“, „išteka“ naudojimą tiesiog diktuoja > Šablonas:Ežeras. Aišku, reiškia tai buvo tik mano confirmation bias. -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] Upių pavadinimai virš vandens telkinių
2019-03-30, št, 10:48 Aurimas Fišeras rašė: > Aš manau, kad tą reikia daryti braižymo stadijoje, o ne OSM duomenyse. > Pvz., darant upių/ežerų sankirtas ir atmetant tas upių atkarpas, kurios > eina per vandens telkinius, naudojant sluoksnius, ar kitus techninius > sprendimus. Teisingai sakai, galima iš upių vektorių išminusuoti vandens telkinių poligonus. Tame nėra problemos. Įtariu net materialized view'as gautųsi. > >Taigi reikia keisti duomenis. Čia turime du pasirinkimus: > >1) pridėti papildomą žymą (arba ją paskaičiuoti automatiškai), kad > > tai per vandens telkinį einanti upė > >2) išimti/perkelti upės kelio name žymą virš vandens telkinio. > Abu variantai iš esmės yra „tagging for renderer“. Nenorėčiau sutikti. Nes aš nemanau, kad per ežerą teka viena ar kita upė, ten yra tik ežeras. Plius nepamirškime, daugumoje ežerų, kuriant upių baseinų žemėlapį, būtent aš ir sudėliojau trūkstamas „grandis“. Anksčiau jų praktiškai niekas nežymėjo. Taigi žymint „tiksliai“, galima buvo tas grandis pažymėti kokia nors visiškai nauja žyma „river:connection=yes“ ar pan. Man grandžių realiai labiau reikia maršrutizavimui greitai pasirodysiančiame upių žemėlapyje, baseinų skaičiavimą galima buvo padaryti ir be upių vektorių per vandens telkinius. > Bent jau skaitmeniniuose žemėlapiuose nemanau, kad tai yra blogai. > Pvz., OsmAnd'e labai patogu, kai matosi kokia upė teka per vandens > telkinį, o ne tik krypties rodyklėlės. Na tokią žemėlapio klaidą galima būtų ignoruoti, bet tik tol, kol neegzistuojančios upės pavadinimas nedengia to, ką mes norime pamatyti - vandens telkinio pavadinimo. Tai, kad OsmAnd'e matosi dar ir rodyklėlės rodo arba kad OsmAnd kūrėjai nepagalvojo apie tai, arba jie nesitikėjo, kad per ežerą bus iš principo nubraižytas upės vektorius. Na ir šiaip, OsmAnd yra geriausia žemėlapių programėlė, bet vis tiek tai yra toli toli iki kartografiškai teisingo žemėlapio, tai labiau pakankamai gražus duomenų vizualizavimas (kaip, beje, ir „standartinis“ OpenStreetMap-Carto). > Braižymui nereikia, bet OSM duomenyse reikia. Dabar upę iš atskirų > atkarpų galima sukonstruoti pagal waterway=river + name=XXX arba per > relation:waterway, analogiškai keliams. Perdarius su waterway:name upės > paprastai sukonstruoti nebeišeina. O kas, kur ir kodėl bando upę sujungti pagal name? > Dabar su tokiais pakeitimais galime pagerinti „standartinius„ OSM > žemėlapius, bet apsunkinti specializuotų žemėlapių kūrimą, ypač > vektorinių, kur atvaizdavimas gali būti dinamiškas (pvz., uždedi > varnelę, pradeda rodyti upių pavadinimus). O galima konkrečiau? Koks yra specializuotas žemėlapis, kuriame norima ežere rodyti upę? Ir kam to gali reikėti? Apibendrinant: kad darant apdorojimą prieš žemėlapio braižymą - sutinku. Bet nesutinku, kad upė realiai eina per ežerą. Nežinau, ar čia man įsijungia confirmation bias, ar aš neteisingai suprantu, kodėl sakoma, kad į ežerą X ĮTEKA upės A, B, ir tada iš jo IŠTEKA upė B. Nesakoma, kad įteka A, o B PRATEKA. Šitoje vietoje būtų įdomu kitų nuomonė, kad būtų daugiau nei dvi nuomonės :-) Ir geresniam supratimui pagalvokite, kaip atrodys žemėlapis, jei per visą Sartų ežero ilgį eis upių pavadinimai (net keli). -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
[Talk-lt] Upių pavadinimai virš vandens telkinių
Sveiki Upės turi savo pavadinimus, vandens telkiniai irgi turi savo pavadinimus. Upių vektoriai eina ir per vandens telkinius, to mums reikia upių maršrutizavimui ir baseinų skaičiavimui. Bendra (kartografinė?) taisyklė braižant žemėlapius yra nepaišyti upės etiketės virš vandens telkinio. Kas logiška, nes realiai toje vietoje mes įsivaizduojame vandens telkinį, o ne pratekančią upę (kuri vandens telkinyje dažniausiai net neturės tikslios geometrijos, tik apytiksliai paskaičiuotą). Vienas sprendimo variantas, kuris nereikalautų jokių duomenų pakeitimų - galima braižyti upių etiketes prieš/žemiau už vandens telkinių plotus/poligonus. Deja čia bus problemų: kad neišlįstų dalis upės etiketės, vis tiek reikės keisti upės duomenis - karpyti ties vandens telkinio riba. Ir tai vis tiek neišspręs visų problemų, jei upė eina greta vandens telkinio (yra upių, kurios eina greta tvenkinių ar tarpe tarp kelių tvenkinių dalių), tai gali būti uždengta dalis upės etiketės, kai neturėtų būti jokio uždengimo. Žodžiu vien sluoksnių dėliojimu lyg ir nėra sprendimo(?). Taigi reikia keisti duomenis. Čia turime du pasirinkimus: 1) pridėti papildomą žymą (arba ją paskaičiuoti automatiškai), kad tai per vandens telkinį einanti upė 2) išimti/perkelti upės kelio name žymą virš vandens telkinio. 1'as variantas geras tuo, kad mes niekaip neįtakojame jau esamų žemėlapių. Tik savuose (openmap.lt) žemėlapiuose galėsime panaudoti šią žymą ir nerodyti upės pavadinimų ten, kur nereikia. Jis ir blogas tuo, kad neįtakojame jau esamų žemėlapių - visur virš ežerų, tvenkinių bus braižomas ir pratekančios upės pavadinimas. 2'as variantas reiškia, kad upės pavadinimai dingsta visur. Ir čia interpretacijos klausimas, ar čia darome „tagging for renderer“, ar čia taisome duomenis - nuimame upės pavadinimą ten, kur realiai nėra pavadinimo ar gal net upės (beje, standartinėse GIS sistemose tai gan įprasta). Taigi pabandymui aš jau nurankiojau nuo nemažos dalies upių virš vandens telkinių name žymas. Tiksliau perkėliau jas į waterway:name žymą, kad, jei pamatysim/nuspręsim, kad tai blogas sprendimas, būtų galima greitai hop ir sukelti viską atgal į name žymą. Kol kas neradau vietos, kodėl mums kada nors galėtų prisireikti name pavadinimo upės atkarpai virš vandens telkinio. Taigi, ką galvojate? P.S. Kaimynai tiesiog nurankioja name žymas virš ežerų, bet tai mažiau pastebima, nes jie panašu nenaudoja automatinių taisyklių, randančias tokias situacijas. -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
[Talk-lt] Vandens telkinių etiketės
Sveiki Pasistūmėjo reikalas su vandens telkinių etiketėmis: https://blog.openmap.lt/2019/03/12/vandens-telkiniu-etiketes/ -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
[Talk-lt] Įdomiosios administracinės ribos
Įdomių geometrijų gauname, administracines ribas stumdant pagal adresus. https://blog.openmap.lt/2019/03/07/idomiosios-administracines-ribos/ Primena kokią Olandijos-Belgijos sieną: https://en.wikipedia.org/wiki/Baarle-Nassau ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] Hakatonai
2019-03-08, pn, 10:40 Mantas rašė: > Sprendžiant iš anketos, tai norima organizuoti labiau ne hackathonus, o > workshopus? Pagal tavo formuluotę labiau panašu į workshopus. Bet šiaip mintis yra labai laisva. Gali būti viena tema, gali būti kelios. Esmė, kad susitikimo metu būtų vienas ar keli žmonės, kurie jau turi praktikos su tema ir kiti dalyviai, kurie nori gauti praktinių patarimų. Tada priklausomai nuo konkretaus susitikimo gali būti parodomas kažkoks iš anksto paruoštas pristatymas, o gali būti, kad dalyviai tiesiog užduoda klausimus ir žinantys parodo kaip kur kas. Galbūt „vedėjai“ net ir nežinos tikslaus atsakymo į užduotą klausimą, tada galima visiems drauge ieškoti atsakymo (google+bandymai). Dalyviai gali ateiti su iš anksto turimomis mintimis ką nori sukurti (gal net jau pradėtais projektais), o gali vietoje tiesiog pabandyti padaryti ką nors nedidelio pagal temą, kad gautų praktinės patirties. Žodžiu kol kas mintis yra daryti labai laisva forma. Su laiku bus matyti, kiek yra norinčių, kokie susitikimai pavyksta labiau, kokie mažiau. Todėl ir yra ši mikro-apklausa ir diskusija talk-lt, kad būtų galima išsiaiškinti, kokių žinių ir kokia forma reikia. Beje, viršuje išdėstytos mintys yra mano asmeninės (turiu patirties su mokymais ir workshopais, bet nė karto nesu daręs ar dalyvavęs hakatone:-). Galite visi siūlyti kitokius variantus, jūsų mintys labai laukiamos. -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
[Talk-lt] Hakatonai
Sveiki Vis planuojam planuojam hakatonus ir taip ir nesuplanuojam. Todėl reikia jūsų pagalbos. Užpildykite šią trumpą anketą, kad būtų aiškiau, kokių hakatonų norisi. https://apklausa.lt/f/zemelapiu-hakatonai-8l295b2.fullpage Gal šiaip kokių pastebėjimų/pageidavimų turite? Arba gal neaiškios kai kurios siūlomos hakatonų temos? -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] Baigti Vilniaus pastatai!
> Matyt tai ne tik pliki pastatai, bet ir atitinkami adresai? Taip, ten, kur buvo tik adreso taškas, adreso informacija perkelta į pastato objektą (kur pastatas matosi ortofoto). ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
[Talk-lt] Baigti Vilniaus pastatai!
Sveiki Vilniaus miesto savivaldybės ribose baigti braižyti visi pastatai (įskaitant ir sunkiausią dalį - sodus). Na bent jau taip galvojama - daugiau nerandu plotų, su nenubraižytais pastatais :-) Jei pamatysite kur nors dar nenubraižytų namų - pabaikite, arba užregistruokite pastabą. Beje, Lietuvoje trūksta tik 30 000 pastatų, kad jų turėtume vieną milijoną! -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [OSM-talk] We need to have a conversation about attribution
2019-03-01, pn, 17:55 Christoph Hormann rašė: > As long as data sources you use have been produced by people who got > paid for their work (through either taxpayer money or private > investments) the discussion is moot - that is not the same league, that > isn't even the same sport. You give first rate attribution to OSM and > second rate attribution to everything else. How/why is the financing of data source part relevant? How would you calculate the prominence of data source to split them into "displayed by default" and "displayed after pressing 'data sources'"? While for data visualisations you could calculate number of objects displayed, what would you do for maps and especially thematic maps? The latter two would have a specific target group with specific interests and a specific idea/information to be communicated which could take a smaller area of the map. A thematic map of X with a basemap of Y could have visually most part covered by Y, but most important part of such a map is X. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] We need to have a conversation about attribution
2019-03-01, pn 16:25, Mateusz Konieczny rašė: > For full screen map two lines of text is perfectly OK. > Two lines for ONE source, then additional lines for other sources. That is not OK. Plus corners are good spots for action places, it is not OK when attribution occupies two corners. It would be good to get oppinion from other people who are actually creating maps/apps, because oppinions without practical knowledge are limited. P.S. On all printed maps I put full OSM attribution and even more. > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] We need to have a conversation about attribution
I, being a mapper in the first place, do not put OSM contribution visible by default on webmaps I create (only after pressing data source link), because when you have more than one data source, it is not practical to show that much info. My second source is altitude data (hillshade, contours, altitude points) which requires a looong text of more than 50 characters. Even OSM attribution takes full line on smaller (not older) phones. Altitude data provider attribution wraps in such case. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-lt] Ką daryti su tokiais objektų pavadinimais?
2019-01-23, tr, 20:33 Jurkis rašė: > Užrodė žmonės tokį objektą Kauna - residental landuse "Bermudų trikampis". > Kaip elgtis su tokiais objektais? Nesinorėtų ištrinti, nes tai yra kaip ir > liaudies > kūryba, žmonių išmislas. Gal galima apiforminti kaip kokį neoficialų > pavadinimą ar pan? Sakyčiau trinti, nes jei tokį pavadinimą priimsim, tai tada kiekvienam objektui galima bus registruoti savo asmeninius pavadinimus. Prieš kelis metus trynėm vieno Kauno tualeto pavadinimą „Auksinis tualetas“ - jis buvo kur kas labiau žinomas, bet, visgi, labai gadino oficialų Kauno turistinį žemėlapį, kuriamą pagal OSM duomenis. Negaliu sugalvoti žemėlapio, kuriame būtų įdomu rodyti tokį pavadinimą. P.S. Jei jau labai labai labai norisi palikti, mačiau Vilniuje atsirado žymos loc_name su reikšmėm Koralai, Fabai ir pan. Tai galima kažkur ten numesti. -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
[Talk-lt] Animuotas žemėlapis
Gražus animuotas žemėlapis https://tangrams.github.io/tron-style/#17/54.69054/25.27965 #openstreetmap ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] Užtvankos
Sveiki Išbandžiau užtvankas ant keliasdešimties objektų - viskas lyg ir gražu. Jei nėra prieštaravimų, būčiau linkęs Kauno HE waterway=dam perkelti ant Marijampolės plento. Beje, įdomų variantą radau. Štai šioje vietoje yra užtvanka: https://topo.openmap.lt/#t/15.88/55.12122/23.75627/0/0/ Kur dabar ją žymėti? :-) Automagistralės keliai tai du. Ant vieno iš kelių? Per vidurį (nebus sąsajos su keliu). Patogiausia būtų šiaurinėje dalyje (Kauans->Klaipėda). -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] Užtvankos
Geoportale galima atsisiųsti Lietuvos TOPO 2016 žemėlapio duombazę (TOP50LKS 800Mb). Pirmas dalykas, į ką atkreipiau dėmesį, tai kad hidroelektrinės ir užtvankos yra dvi atskiros nesusijusios klasės. Taigi hidroelektrinės agregatai užtvankos žymėjimui įtakos neturi. (Hidroelektrinės apskritai pažymėtos taškais) Užtvankos pažymėtos linija ~aukščiausioje pylimo/konstrukcijos dalyje. Jei per užtvanką eina kelias - tai per jį ir eina užtvankos žymėjimas. KaunoHE: [image: paveikslas.png] Tik nedidelė atkarpa pažymėta kaip užtvanka. Daugiau už hidro-įrenginius, bet mažiau, nei kad realiai yra pylimo(?). Kitose vietose užtvanka žymima per visą pylimą: [image: paveikslas.png] Taigi lyg ir atitinka tai, ką matau OSM užpelkiuose: aukščiausioje dalyje vektorius, kuriame waterway=dam. Jei per užtvanką eina kelias - tai dar papildomai ir highway=*. Embankment - pagal skonį, bet tai jau nesusiję su užtvankomis. Kadangi waterway=dam aukščiausiame taške, reiškia vandens lygio svyravimai neturi įtakos užtvankos žymėjimui - logiška. Ką manote? -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] Užtvankos
2018-12-28, pn, 12:49 Aidas Kasparas rašė: > OSM wiki sako, kad dam yra „A wall built across a river“. > Taigi, ten, kur yra sienos su hidrotechninėmis konstrukcijomis > -- ten yra užtvanka, Grįžkime prie šito. Mano galva „a wall“ niekaip nesusiaurina iki „hidrotechninių konstrukcijų“... Siena gali būti betoninė, gali būti medinė, gali būti iš žemės, iš akmenų... visa tai yra „a wall“. Pasižvalgiau po užsienį, tai taip ir yra, pylimai irgi žymimi waterway=dam, tik jiems papildomai pridedama žyma. Tik tiek, kad bent jau Vokietijoje dauguma atveju užtvanka žymima ne vandens telkinio krašte, o pylimo centre (taip, kaip mes ir aptarėme vakar). Taigi lyg ir galima būtų atsisakyti mano vakar pasiūlyto man_made=embankment+embankment:type=dam ir vietoje jo tiesiog naudoti waterway=dam? -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] Užtvankos
Pabandžiau KaunoHE ir kelias kitas užtvankas pažymėti pagal aukščiau aptartas taisykles. KaunoHE: https://topo.openmap.lt/#t/13.96/54.87557/24.00528/0/0/ Užtvankos simbolizacija prie kelio visai neblogai atrodo. Tik waterway=dam iškrenta iš konteksto, nes norėtųsi, kad užtvankos simbolis tęstųsi per tiltą :-) Labai stambiam mastelyje užtvankos simbolio dantukai palenda po gelžkeliu. Marijampolės plentas yra aukštesnės klasifikacijos, nei užtvankomis paprastai einantys residential/unclassified keliai, tai dantukai stambesniuose masteliuose per mažai išlenda iš po kelio (pataisoma). Vakar aptarta užtvanka pataisyta, nuėmus waterway=dam nuo tvenkinio kranto ir uždėjus embankment žymas ant kelio: https://topo.openmap.lt/#t/14.62/54.69667/25.37993/0/0/ Dažnoje užtvankoje realiai tai net ir nėra, artai labai mažos grynai waterway=dam konstrukcijos, tai lieka tik embankment žymos ant kelio. Atrodo visai neblogai: https://topo.openmap.lt/#t/15.5/54.54253/25.16439/0/0/ Lenda problema, kad atsiradus dantukams, atsirado poreikis teisingai braižyti vektorių (pagal wiki, dešinė vektoriaus pusė turi būti žemesnioji pusė). Kur kryptis neteisinga, dantukai sukasi į tvenkinio pusę, nors turėtų būti į priešingą pusę. Kiek peržiūrėjau užtvankų, tai stebėtinai daug užtvankų realiai turi užtvankos viršumi einantį kelią. Visos jos prarastų waterway=dam žymą ir gautų embankment žymas ant viršuje einančio kelio. Pagal mūsų Lietuvos topografinio žemėlapio taisykles viskas puikiai, bet tada dings užtvankos žymėjimas iš mapperiams skirto OpenStreetMap-Carto stiliaus, ir, labai gali būti, iš eilės kitų internetinių ir aplikacijų žemėlapių... Na ir realiai beveik nei viena užtvanka nėra pažymėta embankmentu, visos pažymėtos naudojant waterway=dam tame vandens krašte, kuris eina palei pylimą/užtvanką. Taigi realiai tektų viską keisti (užtvankų kelių nėra labai daug ~260). Nenorime pažeisti taisyklės „dont tag for the renderer“, bet mūsų aptartas variantas realiai panaikinta visas užtvankas iš OSM-Carto. Nors remiamės wiki taisyklėmis, gali būti, kad realūs žymėtojai visai kitaip supranta, kaip reikia žymėti užtvankas... Kitavertus, vandens krašto žymėjimu waterway=dam atveju pasidaro neįmanoma be didelių preprocessinimų pavaizduoti užtvankas su per jas einančiu keliu smulkesniame mastelyje. -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] Užtvankos
2018-12-28, pn, 20:01 Aidas Kasparas rašė: > Na, jei pavyksta nupaišyti U formos pylimą, tada užtenka ir vienos. Bet aš nenoriu U formos pylimo :-) Man reikia užtvankos (plačiąja prasme - su pylimais) linijos, kuri dažniausiai bus daugmaž tiesi :-) Konkrečiai Kauno HE atveju - nereikalingi niuansai apie tai, kad yra gelžkelis, kuris kažkur aukščiau, kažkur žemiau už lygiagrečiai einantį automobilių kelią (tam yra izolinijos/horizontalės). Reikia žemėlapio skaitytojui maksimaliai paprastai perduoti informaciją (gal net smulkiame mastelyje) - čia yra užtvanka - vietovėje aiškiai matomas objektas, tinkantis orientacijai. > Bet jei riestoje dalyje visokių kitokių objektų kalnas, tai geriau tada > po atskirą liniją kiekvienai stačiai daliai. O tai nesigaus kaip dabar yra (ypač Kaune) - reljefas bandomas vaizduoti ne pagal paskirtį panaudotais cliff'ais, kai realiai tai yra aukščio informacija, ją turėtų perteikti izolinijos/horizontalės? T.y. papildomas sluoksnis, generuotas iš DEM, o ne į OSM sukrauti duomenys. > Analogiškai gatvei ir šaligatviams -- gali pažymėti, kad tokie yra > ant pačio kelio, gali „mikromapinti“ ir abiejose pusėse nupaišyti > po atskirą objektą jų tikrosiose vietose. Taip, o tada ateina Tomas, ir rankomis pridėlioja footway=sidewalk ant tokių primikromappintų objektų vien tam, kad vėliau juos būtų galima išmesti iš žemėlapio, kur jie ne tik nereikalingi, bet ir trukdo (padaro makalynę, kurioje naudinga info paskęsta tarp bereikšmės) :-D Bet iš dalies sutinku, kad niekur nepabėgsi, bus (jau yra) primappinta embankment ant kelių, kurie iškilę metrą iš aplinkos. Todėl ir pasiūliau pridėti embankment:type=dam, kad pagal jį būtų galima filtruoti konkrečiai užtvankoms naudingas embankment žymas, o kitas ignoruoti :-) Čia toks footway=sidewalk analogas ;-) -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] Užtvankos
2018-12-28, pn, 18:49 Aidas Kasparas rašė: > Pataisymas. Jei neina kelias, tai brėžiame dvi linijas, ten, kur prasideda > šlaitai. Kaip tai aprašyta embankment'o wiki. Kam dvi linijos? Mus domina tik vieta, kur baigiasi užtvankos pylimo aukštutinė plokštuma ir prasideda „kritimas“ žemyn (nes ši linija, kartu su „betoninės“ užtvankos dalimi sudaro „visą užtvanką“ pagal TOP50LKS). Ar kažką praleidau? > O dėl dantukų -- tai 50K nurodyta visur tuos dantukus paišyti. > Kažkodėl manau, kad ir 10K bus nurodyti dantukai. Pagal LT TOPO - taip. Bet 100% vien LT topo imti kol kas nesinori, nes kai kurie dalykai užsienio topografiniuose žemėlapiuose gražiau padaryti... (PAR'o užtvankų žymėjimas stora juoda linija daug paprastesnis ir mažiau sudėtingumo žemėlapyje). Tai pradinė mintis buvo smulkiame mastelyje rodyti storą juodą liniją, o stambesniuose - pridėti dantukus (kol kas topo.openmap.lt taip ir veikia). Bet „storos linijos“ variantas gali nepraeiti, jei linijos geometrija sutampa su keliu, o ne eina vandens krantu. > O stora linija reiškia, kad krantas sutvirtintas (9.9). Tik kaip šitai > tiesiogiai pažymėti OSM tai nelabai randu. Nebent surface=concrete > prie riverbank pridėti? Key:surface lyg ir kalba, kad vis daugiau > naudojamas su natural=* tagais. Čia vienas iš kitų žingsnių su vandens žymėjimu, bet turėtų būti paprasčiau, nes, manau, galima tiesiog daryti taip pat, kaip daro GRPK. Kaip ir rašai - dėti ant riverbank vektorių žymas, tik ne surface, o kokias nors savo reikės sugalvoti, nes reikšmės gali būti: numatytoji reikšmė - „aiškus paprastas krantas“ - braižoma linija šiek tiek tamsesne už vandens mėlyną. a) neaiškus krantas - braižoma punktyrinė linija, kintant vandens spalvai ir paprasto kranto spalvai b) sutvirtintas krantas - juoda/pilka linija c) griūvantis krantas - su dantukais į vidų Taigi kur paliekame kaip yra dabar - bus „paprastas krantas“- puiki numatytoji reikšmė. Visą kitą papildomai sužymėsim, kur žinosim ar galėsim patikrinti (t.y. bus įdomu). Bet kranto linijų piruetus palikime šiek tiek vėlesniam laikui. Jų tikrai reikės kuriant upių žemėlapį, kurio vis tiek šiais metais jau nebespėsime padaryti :-( -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] Užtvankos
2018-12-28, pn, 16:16 Aidas Kasparas rašė: > O gal žinai iš kur gauti dokumentą „Lietuvos Respublikos teritorijos M 1:50 > 000 > topografinio žemėlapio TOP50LKS sutartinių ženklų schemos“? Nes Google > duoda tik užuominas, kad NŽT gavo pinigų už tokio daikto parengimą. Aš > turiu vilties, kad ten bus parašyta, kur turi būti nubrėžta užtvankos linija. Geoportale tokio dokumento nėra: https://www.geoportal.lt/geoportal/specifikacijos?inheritRedirect=true Jei Andrius ar Marius nepastebės šito klausimo, paklausiu atskirai vėliau :-) >> Bet ar nesigaus taip, kad man_made embankment žymimas ne riboje tarp >> vandens ir žemės, o pylimo aukštutinėje dalyje, t.y. paliekant tarpą >> tarp vandens ir pylimo. > Manau, kad gausis. Tik ar tai yra problema? 50K žemėlapyje 1mm = 50m. > Ar mes apskritai turime vietą, kur atstumas nuo pylimo viršaus iki vandens > yra didesnis nei 10m? Taigi tuos 0,2mm užims žymėjimo linija, jau neskaitant > spyglių. O tai Kauno HE argi nesigaus 10m? Vanduo ten ojoj kaip toli nuo kelio, kuris yra aukščiausioje vietoje(?). Na bet kokiu atveju, reikia bandyti. Gaunasi, kad jei pylimu eina kelias, tai jam pridedame žymas man_made=embankment ir embankment:type=dam, jei per pylimą neina kelias - tada tiesiog brėžiam pylimo viršuje liniją ir jai dedame tas pačias žymas. Tik čia problemėlė, smulkesniame mastelyje embankment pastorinta linija pasislėps po kelio žymėjimu. Tai tektų nuo pat smulkiausio mastelio rodyti ir „dantukus“. Kai buvo žymimas vandens kraštas, tai smulkiame mastelyje gražiai šalia kelio matėsi stora juoda linija. TOP50LKS nėra embankment žymėjimo kaipo tokio. Matyt per smulkus mastelis... Arba užtvankos embankmentas interpretuojamas kaip užtvanka, kaip ir matosi 50K topo pavyzdyje. -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] Užtvankos
2018-12-28, pn, 12:49 Aidas Kasparas rašė: > OSM wiki sako, kad dam yra „A wall built across a river“. Taigi, ten, kur > yra sienos su hidrotechninėmis konstrukcijomis -- ten yra užtvanka, ten > kur yra tiesiog pylimai aš būčiau linkęs žymėti Tag:man_made=embankment > (dabar keliose vietose randu natural=cliff, kas tikrai neatitinka tikrovės). > Dabar apie palyginimus su popieriniais žemėlapiais. Aš gal kažko nepastebiu, > bet http://www.agi.lt/topo/resources/images/10_ze_LKS.jpg tiek užtvanka, > tiek pylimai ant kurių yra gretimi keliai, mano supratimu sužymėti taip pat. Taip, geras pastebėjimas. Tada tikriausiai ir čia užtvanka turėtų būti tik siaura dalis, o visa kita - jau embankment. https://topo.openmap.lt/#t/15.71/54.69597/25.37966/0/0/ > Beje, keturkampis tvenkinys į vakarus nuo Mickūnų turi neteisingai > pažymėtus išorinius šlaitus, bet teisingai pylimą per vidurį. Nebent sakysime, kad būtent pylimas per vidurį neteisingas. Juk, jei rezervuaras užpildytas, tai tikėtina, kad „nusileidimas“ yra tik išorėje. T.y. aplinkoje pakyla stačiakampis, kurio viduje yra vanduo sulig viršum ir per vidurį pylimas, daugmaž vandens aukščio. > Kazlų Rūdos apylinkių žemėlapyje randu, kad skirtingai žymimos > užtvankos ir pylimai (iškasos). Tačiau, iš vienos pusės, pylimus > randu tik tvenkiniuose. Iš kitos pusės, mastelis turbūt yra per didelis, > kad būtų išskirtos užtvankos dalys. O ir tikslas šito žemėlapio turbūt > buvo ne hidrotechninis. Tuo tarpu OSM turėtų leisti visas paskirtis sudėti į > krūvą. Įtariu teisingai čia pastebėjai, būtent mastelis viską ir keičia. Stambiame mastelyje galima atskirai žymėti tiek pačią „betoninę konstrukciją“, tiek ir pylimus atskirai, o smulkesniuose masteliuose (kaip ir PAR žemėlapyje) jau telpa tik vienas žymėjimas. Tiksliau žymėti vien tik betoninę dalį neapsimoka, nes ji tiesiog per smulki tarkim 50K masteliui. > Taigi, dabartinio žymėjimo logika buvo tokia. Jei yra argumentu, kodėl turėtų > būti kitokia -- visada galime susitarti kitaip. Argumentai yra bandyti padaryti topografinį žemėlapį tokį, kokį jį apibrėžia Lietuvos standartai: http://www.geoportal.lt/download/Specifikacijos/TOP50LKS_zemelapio_sutartiniai_zenklai.pdf 9 skyrius Hidrotechniniai statiniai, brastos. 9.2 ir 9.4 užtvankos. Linijinė geometrija pažymėta įtraukiant tiek betonines konstrukcijas, tiek ir pylimą. Tai galvoju, kaip čia teisingiau gautųsi. Gal kad vilkas sotus, ir avys sveikos - palikti taip, kaip yra OSM wikyje, t.y. pylimus žymėti su man_made=embankment, bet prie man_made=embankment užtvankų pylimuose pridėti tarkim embankment:type=dam? Tada 50K mastelyje būtų galima kaip užtvanką imti tiek waterway=dam, tiek ir man_made=embankment+embankment:type=dam? (rodyti ar nerodyti kitus embankment - kitas klausimas) (embankment:type, o ne embankment, nes pastarasis jau turi panaudojimą - aukščio kitimas iš abiejų pusių, o ne vienos) Bet ar nesigaus taip, kad man_made embankment žymimas ne riboje tarp vandens ir žemės, o pylimo aukštutinėje dalyje, t.y. paliekant tarpą tarp vandens ir pylimo. -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
[Talk-lt] Užtvankos
Sveiki Topografiniame žemėlapyje atsirado užtvankos. Bet tuo pačiu norėtųsi geriau apibrėžti, kas yra ta „užtvanka“ ar ką mes žymime kaip „užtvanką“. Tarkime pagrindinės Lietuvos užtvankos pažymėta tik siaura dalis, kur vanduo teka iš rezervuaro į toliau einančią upę: https://topo.openmap.lt/#t/16.35/54.87412/24.00028/0/0/ Man kažkaip norėtųsi užtvanka žymėti ir visą pylimą, t.y. vietą, kur vienoje pusėje yra aukštai esantis vandens lygis, o kitoje pusėje - žemiau esanti žemė. Tai Kauno HE atveju apačioj krantas iki miško pradžios Zuikinės šiaurėje, o viršuje iki Masiulio gatvės parkingo, kur pastatas matosi. Lyg tai taip ir būtų kituose topografiniuose žemėlapiuose (niekur neradau būtent Kauno HE). Tarkim iš Lietuvos topografinių žemėlapių rinkinio: http://www.agi.lt/topo/fcontent.html Keli lapai su užtvankomis: http://www.agi.lt/topo/resources/images/10_zem_SS_o.JPG http://www.agi.lt/topo/resources/images/10_ze_LKS.jpg http://www.agi.lt/topo/resources/images/50_zem_LKS.jpg PAR topografinis žemėlapis: https://htonl.dev.openstreetmap.org/ngi-tiles/#15/-34.0792/19.2914 Ką galvojate? -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [OSM-talk] Ground truth for non-physical objects
2018-12-17, pr, 11:00 Martin Koppenhoefer rašė: > for admin boundaries there will often be at least 2 "true" document > sources: one for each party / side. They are also often observable, > at least punctually. I wonder, of those saying that it is a peace of cake to map country boundaries by physically observing different things on the ground, how many of them have actually practically MAPPED at least a tiny bit of country borders (say 50km?). If so, maybe they can come forward and tell everybody where exactly and how exactly they did that. Especially interesting and useful would be stories of how maritime boundaries or boundaries with no considerable obstructions built have been actually mapped by physical observation. -- Tomas ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Ground truth for non-physical objects
2018-12-15, št, 13:57 Andy Townsend rašė: > If I want to find the border > between Ireland and Northern Ireland, for example, I might not (yet) > find anything stopping me driving through but I will see something along > the lines of "speed limits now in mph" or the reverse. And then the borderline in OSM will be drawn by simply connecting those scarce points on the roads with straight lines? > The fact that we can't get some boundaries from an on the ground survey > doesn't mean that we have to rely on "documents" for all of them, and > for a good reason - "documents" often contradict each other, even from > the same organisation. If you find an error in "documents" - why don't you inform the owner of the document so that they could fix the error (and maybe fix data in OSM until official document is fixed)? My opinion is that OpenStreetMap should COLLABORATE, not ISOLATE itself. Collaboration does NOT mean OSM will become just a fusion of data from different official documents. The fact that there are some errors in official documents means that we want to resort to guesswork and extremely simplified geometry for ALL non-physical objects? How many border vertexes are actually mapped by observing physical reflections in OpenStreetMap? 0,1% or less? And if I was to use an "ad absurdum" argument type: a lot is mapped by using so called "satellite imagery", which is not a photography, but a number of them processed and merged to produce an "Orthophotographic MAP" which is a DOCUMENT. Where will it lead us to? To methods of ~2006 when in order to map a building we had to walk around the building with GPSR (with some distance in order to minimise building obstruction to GPS signal), then measure the building and use that information to map ONE building? And note, building is a physical object which can be observed directly, but is quite difficult to measure with tools most mappers have... (Note: the point of ad absurdum argument in discussion is to point out flaws in initial statement, not to ridicule, so please do not take is as an offence) -- Tomas ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-lt] RC naujiena
Sveiki Džiugu, kad bent kažkas vyksta į tą pusę Registrų centre. Deja, kol kas konkrečiai mums nėra gerų žinių. Paklausiau dėl mums rūpimų adresų ir administracinių ribų registro ir dalyvavimo konsultacijose. Gavau tokį atsakymą (išėmiau mandagumus, dėkojimus ir pan.) „ Atsakydamas į Jūsų klausimus, noriu informuoti, kad adresų ir administracinių ribų duomenų rinkiniai nėra įtraukti iki 2019 m. planuojamų atverti duomenų rinkinių planą. Bet matydami Jūsų interesą, rimtai svarstysime tai padaryti vėliau ateityje. Jūsų asociacija be jokios abejonės gali dalyvauti konsultacijose dėl Registrų centro planuojamų atverti duomenų. Šiuo metu kaip tik yra rengiama galutinė konsultacijų su visuomene ir suinteresuotomis šalimis tvarka. Labiausiai tikėtina, kad bandysime suinteresuotas šalis pasikviesti pas save. Bet kuriuo atveju, sekite mūsų naujienas, būtinai informuosime apie eigą ir planuojamus susitikimus. “ -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [OSM-talk] Ground truth for non-physical objects
2018-12-12, tr, 15:47 Andy Townsend rašė: > If you're looking for a project that essentially mirrors "official" data > without actually checking that its valid then OpenStreetMap might not be > the project for you. I was never for indiscriminate, automated imports without manual checks. Accepting documents as source does not necessary mean allowing such imports. When doing manual checks you can find (and we DO find) errors in official documents. Then OpenStreetMap gets correct data, not official version. I'm also not saying to remove the ground truth rule as such. I'm only saying that the term "ground truth" in the context of non-physical objects must be clarified because currently it is being interpreted in a lot of different ways. What is "ground" in this term for non physical objects: 1. Physical place which could have some traces of an actual object. 2. Ground where non-physical objects actually live - documents. > the general view, which I think we can see from the balance of the posts > in this thread, is that most people back the "on the ground" principle - > if there's a housename that looks like looks like a house name, it's a > house name, even if it's not in an "official" list. Balance of posts could mean one of these: 1. You're right and majority is against usage of documents as sources for non-physical objects. 2. People just do not see it possible to change your interpretation or do not see the point in this discussion at all and simply continue doing what they have been doing. But even if we would be able to vote, count, elect here in talk mailing list, what authority would that have? In my opinion - close to none. As in most open source/data projects people "vote" with their actions. In this case by creating data in the OpenStreetMap database. And most non-physical data today does not come from physical observation. -- Tomas ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Ground truth for non-physical objects
2018-12-12, tr 19:18 Richard Fairhurst rašė: > Tomas Straupis wrote: > > Ad absurdum argument: can you invent your own street name or even > > placename and expect post, police, ambulance, firefighters, taxi to > > arrive (on time or at all)? > > Sure, in the UK, you could do that and I know people who have done so. If > you invent a street name here in Charlbury and then post a letter to it, > Carla the post-lady will ask around until she finds out where the street is > (or until she sees the sign you've erected), and then she'll deliver you > the > letter. A working postcode will speed the process up but isn't absolutely > necessary. > Cool. We live in a stone age down here in Lithuania. I cannot ask pizza guy to deliver me beer to Ipaville, Humulupulus street number "-42 babalas". (For some Afrikaans taste) And still... this proves my point of multiple non agreeable subjective opinions with inconsistent final result and extremely unnecessary hard means of collecting information. In environment, where absolute majority of info about non physical objects is collected by using official documents... Say this, do that... > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Ground truth for non-physical objects
Ad absurdum argument: can you invent your own street name or even placename and expect post, police, ambulance, firefighters, taxi to arrive (on time or at all)? Thank you for example anyway, I would have never ever believed such a thing could be true in GERMANY. (No sarcasm) in post soviet countries like Lithuania still cleaning the sh - maybe, but not Germany. We're banging heads of officials when we find address of place X outside of X admin limits. And only OSM can identify that and thus improve official data. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Ground truth for non-physical objects
Germany is not the "whole world". If you have multiple datasets for addresses then you have to decide, and physical check could be the solution for your country because of registry collision, whatever German community decides. In Lithuania there is one and only one official source for ANY official dataset. Process, owner and access is approved by law. With all due respect to Germany and ordnung, why a country with strict and not conflicting data should be bound to vague solution because of some other country which does not have such a solution? ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Ground truth for non-physical objects
Discussions about mapping invented addresses shows exactly what I wanted to say: we get drowned in endless pointless counter-counter-examples of counter-examples. Rules would have to be invented for addresses separately, and then separately for each country or even more detailed. We once again get to the same old example of reflections/shadows in the end of the cave. Vilnius is not a large city, with 0,5M population it has only ~60K addresses. Still EACH week ~50-100 addresses change (changes, additions, deletions). I do not imagine how would it be possible to capture all that "on the ground" without an army of mappers devoted specifically to this very boring and uninteresting but useful class - addresses. Correct me if I'm wrong, but regions (larger than 1 square km) with best (accurate and up to date) address coverage are the ones which use official address registries. P.S. I agree that when there is no open official source, physical observation is the only thing we have. -- Tomas ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Ground truth for non-physical objects
2018-12-11, an, 16:41 Rory McCann rašė: > On 11/12/2018 12:38, Tomas Straupis wrote: >>If someone puts a label "Military academy" on their house, would we >> map it as an actual military academy? > > No, but you would put "addr:housename=Military academy". Well IF you know it is not actually a Military academy. But if you're not allowed to enter it would be difficult to say. Take any different example, say banner says "Ministry of silly walks", how would it be possible to decide if it is a real ministry or not (if you're not allowed to enter) and decide if it is housename or office=government without looking into official documents? Also following the same logic, number "3A" in my example could go to addr:housename, but not addr:housenumber ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Ground truth for non-physical objects
2018-12-11, an, 13:27 Jochen Topf rašė: > It seems you haven't understood the on-the-ground rule 5 years ago and > you still haven't. For all intents and purposes there is such an > address. Mail will arrive there, people can find the house when looking > for it. Mail will not arrive there as mail will be stopped in post-office because of incorrect (not existing) address. People will not find such address in any IT solution. Such "address" is the same as "the red house on the corner with small pool in front of it". If someone puts a label "Military academy" on their house, would we map it as an actual military academy? This whole topic is to clear up what "ground rule" actually means for non-physical objects. But so far I'm not successful in avoiding getting drowned in questionable micro-examples with subjective explanations. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Ground truth for non-physical objects
> Note i have explained to Tomas in length the meaning of the concept of > verifiability for not directly physically manifested statements in > > http://blog.imagico.de/verifiability-and-the-wikipediarization-of-openstreetmap/#comments > > Using the example of a bus stop without signs or shelter i wrote: > > > A bus stop, even one without a sign or shelter, can be verified by > > observing that a bus regularly stops at the location. There is > > nothing in the concept of independent verifiability that limits its > > application to physical objects. This is a very good example of possibly misleading reflection. What if a driver is stopping in unofficial position somewhere outside of large city to let local people he knows out/in even when there is no official stop? What if a national park had a small sign in the forest track and the sign was not moved when national park boundaries have moved? I had an actual situation 5 or so years ago when an address was mapped in Vilnius. Address does not exist in official records. The user sent me a picture of this house number. I contacted municipality ant they explained that the sign is not an official one, it means nothing, there is no such address. You can think of a gazillion of such examples and analysing them (in my personal opinion) would lead to pointless endless discussions. The simpler the rules - the better? And in general. While it could be interesting to become some kind of detectives and follow the leads, use deduction to calculate the properties of non-physical object. Does it have to be mandatory/primary way when there is a simpler and more correct way? Isn't there enough of physical objects (or non-physical without open/accessible/official documents) to observe, verify and map? -- Tomas ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Ground truth for non-physical objects
2018-12-11, an, 12:06 Frederik Ramm rašė: > Non-physical (non-observable) things should definitely be the exception > in OSM, and it is my opinion that each class of non-physical things we > add needs a very good reason for adding them. I agree, but that is a different question. My suggestion is to discuss this later as a separate topic so that initial question of "what ground truth means" would not be buried. We could later have either (preferably) a criteria, or (if criteria is not possible) simply a table listing acceptable or not acceptable non-physical objects in the database. > Also, I think you are too fast in discounting the verifiability of > boundaries. Even in the absence of actual marked lines, fences, or > walls, you will often find the "reflections" that you speak of if you > look a bit closer: Which government do I pay my taxes to? Which police > department is responsible for my area? Which local authority do I get my > food stamps from, whatever. Well, the first thing is to decide if boundaries as non-physical objects originate in documents, or physical observation and which one we use. Mixing those is what is introducing subjectivity and thus different interpretation and problems. Then we can decide on priorities (if required at all). For example for all boundaries (except country boundaries) there is a clear candidate - local authority (government for administration division to states, counties, cities, suburbs etc.), same local authority or some national park administration whoever is deciding on official boundaries of national/regional parks, protected areas etc. I cannot think of an example, where some important object worth being in OpenStreetMap database would not have a single authority deciding on its geometry. And this could work with country border only if we accept the possibility of overlapping borders (which sometimes do exist even without conflicts between countries). Tax, police does not look like a firm criteria because: 1. You would need some documents to verify that anyway? 2. Tax/police regions do not necessarily correspond to administrative divisions and they could differ/overlap. Note that while it is relatively easy to spot a missing non-physical object and then add it, it is much harder to notice a change of it. If we would agree on using official documents it would allow to do such checking by local community regularly (which does not necessarily mean updating the data automatically by import, this could simply raise a flag "please check here"). This is what is done in "some" countries currently with ALL sides getting benefit and thus being a very good selling point for OSM and now it is very disturbing to find it is "against the old standing rules" :-) -- Tomas ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Ground truth for non-physical objects
Hello I think we should settle the question of how "ground truth" or "verifiability" applies to NON-PHYSICAL objects (it is clear with physical objects). Because currently I see at least two opinions: 1. Non-physical objects are mapped by observing/verifying their REFLECTION in physical world. 2. Non-physical objects are mapped by observing/verifying them DIRECTLY where they originate and live - in non-physical world - ~documents. It is very demotivating to hear the argument that "opinion X is your personal opinion, but (my) opinion Y is how OpenStreetMap works" without any evidence. Especially by people with not too much actual mapping/usage experience (say < 10 objects done, no application/map created etc.). And without thinking about the impact of it. Opinion 1 would mean that we should remove all(most?) non-physical objects: country, state, county, city, suburb, national/regional park boundaries (and a lot more) as most of that is unobservable on the ground and sometimes reflection of small part of them on the ground is misleading/outdated. Opinion 2 would mean that objects are mapped according to originating documents. De facto situation is that almost all non-physical objects are currently mapped according to documents. Which opinion is chosen has a huge impact on both participation and usage of OpenStreetMap. Decision would be able to remove this burden from OSMF which by definition should not be deciding on such matters. P.S. Wiki while not being authoritative talks about PHYSICAL objects. P.P.S. Let's skip non-physical attributes for the beginning. -- Tomas ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Distribution of OSM ids could be much more useful!
Could you ealborate more on why you mention permanent id here? I see your idea, but do not understand how it is connected to permanent id problem. There were some tests done regarding permanent id in Lithuania, but those were regarding places of interest. If this has something in common, I could share some ideas and observations, so that they do not now go in vain. Maybe somebody would like to continue research, as this is quite an important thing to OSM. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSMF makes a political decision where should be a technical solution?
2018-11-23, pn, 18:57 Andy Townsend rašė: > Where that best matches the situation on the ground about who has > control, yes. Ok. So do I understand OSMF position is this: 1. There are no technical problems with having international boundaries overlapping and representing official position of involved countries. 2. International boundaries DO sometimes overlap. 3. OSMF is aware that overlapping boundaries would have satisfied more users (especially LOCAL users). 4. Precedence is taken by "most widely internationally recognised and best meets realities on the ground" where only second part is actually important, so this sentence should be changed to "best meets realities on the ground IRRESPECTIVE OF WIDE INTERNATIONAL RECOGNITION". Is this correct? ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSMF makes a political decision where should be a technical solution?
2018-11-23, pn, 18:23 Andy Townsend rašė: > Yuri, I suspect that literally every statement that the DWG has made > throughout this process has said exactly the opposite of what you've > just suggested that we said. You're saying DWG position is that it IS acceptable to have overlapping country polygons? ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSMF makes a political decision where should be a technical solution?
2018-11-23, pn, 11:19 Oleksiy Muzalyev rašė: > The topic of territorial claims is very complicated, long lasting, and > painful. It involves not only such relatively remote and insignificant > cases as Hans Island, Sudan, Croatia, Crimea, Pakistan, etc. cases, but > also the industrial developed lands. For example, the Reconquista [1] in > the USA is about millions of square kilometers, including the > California, the 6th economical power in the world if taken by itself. > After visiting some areas of Los Angeles, California, the Reconquista > does not seem to me as ridiculous as before. Demography and linguistics > do have certain significance. It was already stated we're only talking about official claims by official governments. To my knowledge official Mexican government has no official claims on territory lost in XIXa. Victor and Yuri has stated, that having such an overlapping but representing official local position borders would help data users to adapt data to local needs: create Chinese map as Chinese want, create Ukraine map as most of the world wants etc. etc. And "ground truth" will not be enough to settle some peaceful border disputes or just agreement of joint rule. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSMF makes a political decision where should be a technical solution?
> I fear that this is only "kicking the can down the road" though because > we'd likely have - just as we have with names - one "default" set of > boundaries where we say "that's the one you get if you don't ask for any > particular one", and the fight would then be on which one that is going "default" is not required (map/app creator should have a freedom to make decision). The only change required is to allow OVERLAPPING borders which apparently is a normal thing for borders even when there is no war, nobody on the ground to make "ground truth". For example: https://en.wikipedia.org/wiki/Hans_Island ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSMF silently sides with Russia?
Congratulations to Ukraine celebrating the Day of Dignity. You HAVE a strong backbone! This thread is depleated. Bye ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSMF silently sides with Russia?
2018-11-21, tr, 16:04 Mateusz Konieczny rašė: > Taken together it means that Crimea (territory occupied by Russia) should be > marked > as de facto within Russia. On OSM-Carto map - it could be so. But I see no objective reasons why this should be the case in the data. Data could represent all sides. I've given examples how to do so, but it was proven again that there was NO ATTEMPT to have a resolution which would be acceptable to MORE people. The simplest solution was chosen because of false counterarguments: Finland's non existing border claims, historical and hypothetical but currently non existing disputes etc. -- Tomas ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSMF silently sides with Russia?
Are we looking for a solution of existing problem? Or thinking of hypothetical future problems and how they could potentially be harder (but not impossible) to solve using proposed solution? With a purpose of declaring it "too difficult" so "lets do nothing"? Most of us are happy to live in countries with no disputed borders, but as was stated in this thread a lot of people are not that lucky. And it means all those people do not get the solution THEY need from OSM, because WE want to make it simpler for US. What about declared diversity, equality and thinking beyond "middle-to-high salary first world country white man"? ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSMF silently sides with Russia?
>>Do you know a country which has a fluctuating representation of its
>> borders say in schoolbooks?
>
> In my lifetime, lots - countries (and I don't mean where boundaries
> changed, but the external recogition of them did). For example, the US
> only recognised the People's Republic of China in the 1970s. I suspect
> <...>
Representation of ITS borders. So China's understanding of China's
borders, Taiwan's understanding of Taiwan's borders, Ukraine's
understanding of Ukraine's borders etc. And at one time - TODAY.
>> Doesn't every country have ONE OFFICIAL
>> claimed border?
>
> No, for a few reasons. One is that countries might be in the process of
> accepting something like UNCLOS arbitration (so there isn't a settled
> border to claim yet), or they may have multiple claims some more rooted
> in reality than others. For example how much of Karelia east of the
> current border would you consider part of Finland, if any?
We could be understanding "territorial claims" differently. Haven't
heard that Finland would claim that their borders are different from
what they have today. Yes, part of territory was occupied and annexed
after Russia invaded Finland in the beginning of the WWII but never
heard that OFFICIAL position would be "this is our territory down
there over the border".
Wikipedia states: "Both Russia and Finland have repeatedly stated
that no open territorial dispute exists between the two countries."
> Which often aren't suitably licensed for use in OSM, or are quite vague
> ("that area over there really belongs to us").
But how is this different from borders as entered today, that is
without overlap?
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSMF silently sides with Russia?
> From a practical point of view different applications such as OSMand take a > snapshot of the database at a point in time. > How would your proposal work with these derivatives and there are quite a few > including the odd one that gets updated once or year or so. Sorry, I did not understand where is the problem? Use cases, where data is updated now and then are less of a problem as there is less restrictions on time - they can use overlapping borders (for most cases this would be ok), or do border calculation as required for THAT SPECIFIC APP (now it is only possible to get a restricted ONE result which most of the time will not be as required). > Are you suggesting that all applications that use OpenStreetMap data should > be modified to fall in line with your proposal? Those apps, which cannot tolerate overlap, would calculate a diff, calculating the difference is not something very new and challenging. "holes" in polygons are somehow calculated? But this would allow to use OSM data not only by citizens of countries which more or less do not care about "those stupid border disputes". > Yes, sure, by allowing every mapper to map his or her specific > subjective desire how the reality should look like we could eliminate > all disputes. Do you know a country which has a fluctuating representation of its borders say in schoolbooks? Doesn't every country have ONE OFFICIAL claimed border? All borders are verifiable mostly only by checking official documents. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSMF silently sides with Russia?
2018-11-20, an, 20:58 Christoph Hormann rašė: > This is not a workable approach as an universal rule. The volume of > boundary relation overlap world wide would be enormeous. You would > have a significant number of boundaries that have no practical meaning > today. Some countries have pretty excessive claims. Formally Taiwan > (the ROC) claims all of the PRC for example. It is also completely > non-verifiable (anyone can claim something is theirs). Correct me if I'm wrong, but border overlap is only important for geocoding purposes? It is possible to calculate border geometry (for the specific requirements of specific use case - so very flexible) not on every db update but less often (each day, each week, each month, on request, whatever). (Something like this WILL be or is already happening in databases doing real cartographic generalisation tasks). It would this way be reduced to simple TECHNICAL problem with known solutions. But it would eliminate all border DISPUTES and ELIMINATE all this political crap out of OSM discussions. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSMF silently sides with Russia?
2018-11-20, an, 19:59 Rory McCann rašė: > How should we decide which way to map disputed borders?! As it was mapped a week ago: BOTH ways (included in BOTH country polygons). If required - disputed territory (polygon geometry) can be mapped as "disputed=yes" with a tag "ground_control=ICHTAMNET|RU|UA", you could then additionally make a map of World disputed territories. Or you could use this to subtract from claimed territory to get "controlled" polygon. So: st_difference(Boundary UA, Disputed where ground_control != UA) gives you active territory for geocoding and stuff. Disputed borders (line geometry) could be mapped with additional tag: claimed_by=RU|UA so that Russians could ignore borders with claimed_by=UA, rest of the world could ignore borders with claimed_by=RU. OSM Could display both but differently. Voila... This way DATA represents ALL parties. No reason for the conflict. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSMF silently sides with Russia?
2018-11-20, an, 14:33 john whelan rašė: > I think you have expressed your opinion but unfortunately whilst difficult > for you to accept traditionally OSM maps a certain way and has done > for sometime even though many governments and others would wish > we did something else. Can you give an example where things in OpenStreetMap are mapped in a different way than overwhelming majority of world thinks? Note: I'm not asking to tag Crimea as just Ukraine (which would be my personal opinion). I'm asking to have an open discussion of disputed territory rules and hopefully revert to the previous "middle ground" which was acceptable to more/most parties - thus being less partitioning. There was no such discussion yet. In November there was something like that starting, but then Frederik wrote this: https://lists.openstreetmap.org/pipermail/talk/2018-October/081570.html Well, English is not my native tongue, but I do not see any possibility to discuss in these claims: "the Crimea issue is currently being discussed in DWG." "This policy is not likely to change any time soon." I read it as: we are discussing it internally but are not going to change anything. No surprise discussion has stopped shortly after that. I personally was expecting DWG to come up with some generalisation and a number of proposals which could be discussed. But that did not happen. Decision has been taken and not announced. P.S. I encourage people responding to me personally to reply to the mailing list, so that It would be visible this is not just my personal opinion. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSMF silently sides with Russia?
2018-11-20, an, 12:42 Elena ``of Valhalla'' rašė: > looking at a map where Crimea is part of Ukraine may lead people to plan > a trip to it, only to be stopped and possibly questioned. But going to Crimea without Ukrainian visa (and not via Ukraine controlled territory) would have legal consequences. > Most importantly, however, having Crimea as part of Ukraine on a map > that shows what's on the ground would lead people to think that the > illegal invasion has been resolved and everything is back to normal. > This, if I understand correctly, would be exactly the opposite of what > you want. Showing Crimea as part of Russia would also lead people to think that the illegal invasion is over, everything was "legalised" and issue settled, which is exactly the opposite of the reality. I want as much peace as possible. The previous solution to include Crimea in both while not ideal had a ~balance between the two sides. And now, for unknown reasons, this was changed to give all candies to one side (not the one supported by absolute majority of the world) introducing unnecessary negative effects. The matter of Crimea was more or less calm in OSM before this decision. -- Tomas ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-lt] A5 šiauriau Marijampolės
2018-11-12, pr, 12:38 Aurimas Fišeras rašė: > Aš radau tik: > http://lakd.lrv.lt/lt/projektai/via-baltica/2017-08-10 > > Pagal jį tikrinau, ar prie Puskelnių teisingai pažymėti tuneliai (53,87 > ir 54,33 km) Ar aš kažko nepastebiu, ar ten tik tekstas? Paklausiau LAKD, bet, panašu, jie irgi šiuo metu nelabai gali padėti. Matyt teks laukti, kol ortofoto atsinaujins :-( -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [OSM-talk] OSMF silently sides with Russia?
> If you ask students to contribute to the map and at the same time say > "btw they are in favour of evil Russian aggression" then of course > students (at least in Lithuania) will give it the thumbs-down. But if > you patiently explain the "on-the-ground rule" and that using this rule > has many positive effects but sometimes also means you have to do > something you don't like - then I guess people could be made to understand. While I have already stated a number of negative effects (which have so far been ignored), what positive effects does excluding Crimea from Ukraine gives? The only way you can get to occupied territory of Crimea from government controlled part of Ukraine is through a narrow straight which is heavily guarded. I cannot imagine the situation where anybody would "wonder" into occupied territory without knowing it. I cannot understand WHY was this reconsideration made in the first place. It was much more peaceful before this decision. P.S. And I really do not think sarcasm in "evil Russian aggression" is funny. -- Tomas ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSMF silently sides with Russia?
Youre saying something written in pdf is more important than huge practical and reputational damage done? Pdf cannot be wrong and it does not matter that OpenStreetMap loses a lot of opportunities and probable contributors? What will ordinary people understand from this decision? Will they read some hidden pdf? How can I ask students to contribute to the map, which makes such a damaging statement and has data which cannot be used to produce maps? ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] OSMF silently sides with Russia?
Hello I think this needs more attention and should not be silently buried in archives. OSMF/DWG has sided with Moscow to recognise illegal annexation of Ukraine's territory - Crimea. https://wiki.osmfoundation.org/wiki/Working_Group_Minutes/DWG_2018-11-14_Crimea Note that there was a vote in UN on this: https://en.wikipedia.org/wiki/United_Nations_General_Assembly_Resolution_68/262 only few countries on the level of North Korea, Zimbabwe, Russia, Venezuela have recognised this international crime. Does OSMF/DWG want to be in this group? Does OpenStreetMap has to be in this group? PRACTICAL1: this will make it impossible to create a correct political map using OSM data. PRACTICAL2: It is also EXTREMELY damaging to OpenStreetMap reputation. Now all opponents of OSM will be able to point fingers at this decision - "OSM recognises Crimeas annexation". And it now makes us all participate in Russian (ruled) project. PRACTICAL3: While there are some talks about using OSM instead or alongside of commercial GIS solutions in the context of EU INSPIRE directive, such intentions will be seriously damaged by OSMF/DWG actions, because Europe has a very clear position of not recognising Crimeas annexation. It would also be nice to know how members of DWG voted, to have more information on their attitudes towards Russian aggression. This would be important for those having a vote. But I do not know how to do that correctly, so that not to cause personal damage and avoid bullying. I personally do not know how/if I can proceed with pushing OpenStreetMap to government or educational use... -- Tomas ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[Talk-lt] A5 šiauriau Marijampolės
Sveiki Pabaigus A5 rekonstrukciją šiauriau Marijampolės, tai vienas, tai kitas žymėtojas vis šį bei tą pakeičia, deja vienas per kitą, vis keisdami elementus pirmyn ir atgal. Norėtųsi sutvarkyti tinkamai, bet važiuoti į tą pusę nelabai norisi. Gal kas žinote gerų info šaltinių? Planai, nuotraukos ir pan.? Kalba apie šitą vietą: https://openmap.lt/#m/13.04/54.6171/23.41638/0/0 -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
[Talk-lt] Vektorinis upių baseinų žemėlapis
Sveiki Prieš metus buvo rodytas Lietuvos upių baseinų žemėlapis. Tai šį kartą vektorinė jo versija „su mėnesienos efektu“ :-D https://blog.openmap.lt/2018/10/28/lietuvos-upiu-baseinai-ii/ -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
[Talk-lt] CartoCon 2018
Sveiki Šių metų lapkričio 30d. Lietuvos kartografų draugija kartu su VU organizuoja konferenciją CartoCon 2018. Bus ir mūsų pranešimų apie vektorinius žemėlapius. Bus ir praktinė sesija su vektoriniais žemėlapiais. Taigi prisijunkite! https://cartocon.lt/ -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] Topografinis Lietuvos žemėlapis
> Gražu! Bet jei žemėlapį "paguldai", 3d iliuzija dingsta. Ar įmanoma > aukščio informaciją perteikti ir žemėlapio 3d renderinimo varikliukui? Su naudojamom MapBox technologijom tikro 3d reljefo padaryti neina. Pats reljefas padaromas: http://blog.mastermaps.com/2014/10/3d-terrains-with-cesium.html (Dar krūva kitų bibliotekų yra 3d objektams) MapBox programuotojai rašo, kad ant tikro 3d reljefo iššūkis žemėlapį braižyti (kelius, namus, etiketes ir pan.). -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
[Talk-lt] Topografinis Lietuvos žemėlapis
Sveiki Naujas Lietuvos žemėlapis: https://blog.openmap.lt/2018/10/15/topografinis-zemelapis/ -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] Mašininis mokymasis
Paskutinis įrašas apie mašininį mokymąsi: https://blog.openmap.lt/2018/09/24/masininis-mokymasis-iii-procesas/ Beje, jeigu kas norite daugiau informacijos, norite prisidėti prie šios krypties (gal prie deep learning dalies, gal prie OSM duomenų tvarkymo pagal DL rezultatus) - rašykite arba čia į talk-lt, arba man asmeniškai. ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
[Talk-lt] OSM duomenų modelis
Įdomus Jochen Topf pristatymas apie OSM duomenų modelį, problemas ir galimus sprendimus: https://youtu.be/rbxabz22ni4 ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
[Talk-lt] Kelių danga
Sveiki OSM-Carto žemėlapio stiliuje („pagrindinis“ OSM žemėlapis) jau keli mėnesiai ruošiamas pakeitimas rodyti kelių dangą. Taigi galima iš anksto pasižvalgyti po sau pažįstamas apylinkes ir pažiūrėti, ar teisingai suvesta danga. https://places.openmap.lt jau ne mažiau kaip metai vizualiai rodo, kur yra įvesta kieta danga (balti keliai), o kur biri danga (gelsvi keliai). P.S. Pakeitimai žemėlapyje atsispindės po 3-4 dienų. -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] Mašininis mokymasis
Antras įrašas apie mašininį mokymąsi: https://blog.openmap.lt/2018/09/07/masininis-mokymasis-ii-rezultatai/ ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] Kaunas
Tiesiog griauti ir demotyvuoti tikrai nesinori, todėl ir rašau čia. Dėl detalumo ir žymėjimo. Tarkim su medžiais yra tokia mintis: landuse=forest žymime tik stambius miško plotus (kurie turėtų atsidurti smulkesniuose masteliuose). Tada turime landuse=residential|industrial|commercial, kurie žymi atitinkamas zonas. O vat jei norime padaryti mikromappinimą - pažymėti smulkius medžių plotus - juos pažymime natural=wood. Toks natural=wood rodomas tik stambiuose masteliuose (tarkim 17-19) ir tik tada, jei žemėlapyje yra noro rodyti smulkias detales. Tokie natural=wood NĖRA iškerpami iš po jų esančio landuse, taigi nerodant smulkių medžių plotų negauname nepageidaujamų „skylių“. Taigi ir avys sveikos, ir vilkas sotus (?). Čia vertėtų pridėti, kad tai tik Lietuvoje sugalvotas mechanizmas (nors jis suveikia ir su OSM-Carto stiliumi). Realiai jau dešimt metų vyksta ginčas tarp to, kaip reikėtų žymėti miškus, landuse=forest ar natural=wood, besprendžiant vietoj konvergavimo į vieną variantą atsiranda papildomi variantai (landcover:-). Bet konkreti žyma nėra esmė, svarbu kad turime DVI SKIRTINGAS žymas „stambiems“ ir „smulkiems“ miškams, kas leidžia kurti tiek stambių, tiek smulkių mastelių žemėlapius nedarant daug sudėtingų generalizavimo skaičiavimų. Analogiškai medžiams galima daryti ir su žole. Dideli plotai - landuse=meadow, mažiukai plotai - landuse=grass. Taigi, grįžtant prie Kauno, matyt sprendimas bus sunkus ir reikalaujantis daug laiko - visą plotą apibrėžti landuse=residential, esamus forest/orchard keisti į natural=wood, o meadow į grass. Su poligonų prisegimu prie kelių, matyt, kažkiek teks palikti, nes nesinori labai ilgai sėdėti prie šito reikalo. Dėl upių/upeliukų ir kelių smulkių detalių tai niekaip kitaip kaip su generalizavimu neišeis padaryti. T.y. braižome stambiam masteliui, o kurdami smulkesnio mastelio žemėlapius generalizuojame duomenis. Dėl plotų prijungimo prie kelių. Aš žymiu plotus tiesiog atskirais objektais, niekaip (jokiais taškais) nesusijusius su keliais. Nes jie neturi nieko bendro. Plius kelius padarius plotų dalimi arba pasidaro sunku pažymėti norimą kelią (jei kelias tiesiog paišomas „ant“ poligono kraštinės viršaus), arba kelias bereikalingai dalinamas į begalę mažų atkarpų, dėl ko keičiant kelio žymas reikia pereiti ir pakeisti žymas visose dalyse (su visomis iš to sekančiomis problemomis), o ir kuriant žemėlapius tokie mažų atkarpų kiekiai prideda nemažai nereikalingų problemų ir darbo (paišant etiketes, kuriant vektorinius duomenis ir šiaip darant skaičiavimus). -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
[Talk-lt] Kaunas
Sveiki Kaip galvojate, ką daryti su tokiu žymėjimu? https://www.openstreetmap.org/#map=17/54.92798/23.98653 Iš vienos pusės įdėta labai daug darbo. Iš kitos pusės: a) plotų kraštai sudaryti iš kelių (dėl ko pasidaro labai sunku ką nors taisyti, vienas kelias padalinamas į daugybę gabaliukų, dėl ko sunku keisti jo savybes, vektorinėse kaladėlėse daug vietos užimantis ir lėtai veikiantis bardakas) b) realiai visas šitas plotas yra vienas didelis landuse=residential. Iš jėgos vienas ar du plotai gali būti landuse=forest, iškirpti iš residnetial. O dabar sužymėta viskas kaip daug daug mažyčių vitražo gabaliukų. Visi poligonai lygiavertiškai nepersidengia, net tarkim amenity=parking ar koks footway area išpjauti iš aplinkinio ploto. -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
[Talk-lt] Mašininis mokymasis
Sveiki Po paskutinio įrašo apie dirbtinio intelekto galimybes, panašu susiformavo šiokia tokia klaidinga nuomonė. Galėjo pasirodyti, kad tuoj paspausime žalią mygtuką „dirbti“ ir visi namukai Lietuvoje patys nusipaišys. Tai jei trumpai - taip nebus (bent jau kelis ateinančius metus), o detaliau bus aprašyta serijoje įrašų apie bandymus dirbtinį intelektą užsiundyti ant Lietuvos ortofoto. Pradžiai pirmas įrašas. Kaip mašininis mokymasis galėtų padėti žymėti objektus Lietuvoje? Bendrais bruožais aprašyta nuotraukų atpažinimo užduotis ir ko galėtume/norėtume tikėtis iš rezultatų. https://blog.openmap.lt/2018/08/28/masininis-mokymasis-i-reikalavimai/ ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] Smulkių kelių (track/service) klasifikacija
Kadangi kitų pasiūlymų nebuvo, tai kol kas bandau tokį variantą: a) keliai service/track klasifikuojami pagal išvaizdą: service - kapitaliai padarytas kelias, paprastai supylus papildomą gruntą, su kieta danga arba be. track - vėžios b) service keliai, kurie yra ilgo atstumo (svarbūs vietovėje) arba iš kurių išeina kiti track keliai - gauna service=long_distance c) trumpi privažiuojamieji (pvz. prie namų) track keliukai gauna track=driveway Žiūrėsim, kas gausis. -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
[Talk-lt] Smulkių kelių (track/service) klasifikacija
Sveiki Prieš gerą pusmetį buvo rašyta apie kelių klasifikaciją: https://blog.openmap.lt/2017/12/09/keliu-hierarchija/ Tada buvo kalba tik apie kelius highway=residential ir highway=unclassified. Bet toks pat klausimas yra ir su smulkesniais keliais. Konkrečiai highway=service ir highway=track Iš principo norima išspręsti/sugalvoti, kaip gauti teisingą kelių grafą, bet tuo pačiu ir nenukrypti nuo standartinio (įprasto) supratimo, kada kelias yra track, o kada service PAGAL IŠVAIZDĄ. Taigi „pagal išvaizdą“. track - kai yra matomos dvi vėžės. Su išimtimi track + grade1 - čia labai stipriai pravažinėtos vėžės, kai jau nebėra per vidurį žolės tarpo, pagal užsienio patirtį, tai gali būti net ir grįsti keliai (grade2-5 - tik negrįsti). service - kelininkų padarytas rimtas kelias, gal grįstas, gal negrįstas. Dažniausiai pasitaiko tankiai gyvenamose vietovėse (kur klausimų kaip ir nekyla), bet būna ir užmiestyje (tarkim privažiavimas prie kokios nors fermos). Pagal „kelių grafą“. service - teoriškai turėtų būti tik privažiavimas prie ko nors (akligatvis arba trumpas pravažiavimas). track - gali būti bet kas: tiek miškų keliai, kurie gali jungti atskiras gyvenvietes ar būti trumpesnis kelias, kaip pervažiuoti iš vieno kelio į kitą. Bet tai gali būti ir privažiavimas prie ko nors (tarkime privažiavimas prie vasaros sodybos ar maudyklos per laukus). Problemos: 1. Neaišku, kaip žymėti privažiavimus prie sodybų užmiestyje. Kadangi tai privažiavimas, tai kaip ir tiktų service, bet kadangi tai per pievas einančios vėžės - tai kaip ir norisi track. 2. Kartais į fermos teritoriją įeina aiškus service kelias, bet toliau nuo tokio service atsišakoja vos matomas per pievas ar mišką einantis track keliukas. Kadangi track gali būti jungiamieji keliai, tai jie pradedami rodyti smulkesniame mastelyje nei service, todėl tokiuose masteliuose, kur service nerodomi, o track rodomi, gali atsirasti kelių grafo trūkiai. Sprendimo variantai: service keliai turi papildomą klasifikaciją service=* Ten iš principo galima būtų dėti tarkim service=long_way ar pan., kuris rodytų, kad tai jungiamasis service - tada jį galima būtų rodyti nuo to paties masteliuo, kaip ir track - tada neliktų kelių grafo trūkių. highway=track neturi žymos track=*, o labai norėtųsi atskirti privažiavimus prie namų (akligatvius), t.y. trumpus kelius, kad jie neužterštų žemėlapio smulkesniuose masteliuose. Beje, visus/bet kokius privažiavimus žymėti highway=service tikriausiai nėra labai gerai, nes gali būti ilgas track kelias mišku, o tada trumpas privažiavimas nuo track kelio iki sodybos. Praktiškai visuose pagal OSM duomenis daromuose žemėlapiuose service keliai matomi labiau nei track, taigi tokio privažiavimo atveju būtų keistas vaizdas - „ore“ kabantis service kelias. Ką manote/siūlote? -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
[Talk-lt] Vektorinis OSM žemėlapis ESRI Arc
Sveiki ESRI's paleido savo produktuose vektorinį OpenStreetMap žemėlapį. Straipsnis: http://www.arcgis.com/home/item.html?id=b834a68d7a484c5fb473d4ba90d35e71 Žemėlapis: https://arcg.is/0OO18z -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
[Talk-lt] Pastatai 2018
Sveiki Naujas įrašas apie pastatų OpenStreetMap kiekį. Palyginimas su GDR'u: https://blog.openmap.lt/2018/07/02/pastatai-2018/ Jei imtume plotus, pažymėtus kaip landuse=residential, kurie neturi nei vieno pastato (kandidatai vietų, kur trūksta pastatų), tai gauname tokius lyderiaujančius plotus: Vilniaus apskritis: https://www.openstreetmap.org/way/228932107 Kauno apskritis: https://www.openstreetmap.org/way/189195507 Klaipėdos apskritis: https://www.openstreetmap.org/way/268117423 Panevėžio apskritis: https://www.openstreetmap.org/way/143295165 Šiaulių apskritis: https://www.openstreetmap.org/way/517272358 Alytaus apskritis: https://www.openstreetmap.org/way/131544844 Marijampolės apskritis: https://www.openstreetmap.org/way/116888107 Tauragės apskritis: https://www.openstreetmap.org/way/76243119 Utenos apskritis: https://www.openstreetmap.org/way/190669050 Telšių apskritis: https://www.openstreetmap.org/way/145774115 -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
[Talk-lt] Vilniaus kelių pasikeitimai 2007-2018
Įrašas ir video apie Vilniaus duomenų pildymą: https://blog.openmap.lt/2018/06/28/vilnius-2007-2018/ -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
[Talk-lt] Atnaujinami ortofotografiniai žemėlapiai
Prasideda Lietuvos ortofotografinių žemėlapių 2018 atnaujinimo darbai. Šiais metais bus atnaujintas trečdalis vidurio Lietuvos. Spalio mėnesį šiuos Nacionalinės Žemės Tarnybos žemėlapius jau galėsime naudoti ir OpenStreetMap žemėlapių atnaujinimui (vektorizavimui) ir kaip internetinių žemėlapių pagrindą. Plačiau: http://www.nzt.lt/index.php?1216193349 ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] Adresai
Laba diena 2018 m. birželio 21 d. 08:33, Rambla Rambla rašė: > Pamenu buvo kalba dėl regionų adresų. Štai mūsų geoportale yra sudėta ant > OSM'o www.geoportal.lt/savivaldybes/anyksciai ; varnelę reikia uždėti ant > 'Administracinės ribos ir adresai' . Maps lt irgi adresai yra sudėti, tik > žemėlapio pagrindas yra ne OSM. Adresų problema yra ne techninė „iš kur gauti failą“, o teisinė „gauti leidimą naudoti oficialius adresų duomenis“. Geoportale yra tie patys registrų centro duomenys. Maps.lt irgi tie patys RC duomenys. Yra ir daugiau žemėlapių, kurie naudoja RC adresų duomenis. Žodžiu kol Seimas nepakeis įstatymų ir neatvers adresų duomenų - tol mes juos turėsim rankomis patys susivedinėti. Bet Seimas turi kur kas „svarbesnių“ reikalų nei kad kažką atverti ar pagerinti, jau nekalbant apie tai, kad nelabai jie orientuojasi aplinkoje :-) Tik didesniuose miestuose, kurie turi savo adresų duomenų bazes, galima susitarti su savivaldybe ir tas adresų bazes gauti ir sukelti į OSM. P.S. Bet tai nereiškia, kad norintys ir turintys laiko negali ieškoti kontaktų su RC ir per tą galą stumti adresų atvėrimo. Mantas gi kažką buvo pradėjęs su komunikacija? -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
[Talk-lt] Automatinis objektų aptikimas
Sveiki Jau gal pusmetį su Mindaugu svarstome galimybę padaryti automatinį pastatų (ar kitokių objektų) aptikimą iš ortofotografijų. O čia bac, ir Mapbox'as atvėrė savo įrankį: https://www.openstreetmap.org/user/daniel-j-h/diary/44145 Įrankis paima objektus iš OpenStreetMap duomenų, tada susirenka reikiamus ortofotografijos segmentus (kaladėles), tada pagal tai pasimoko, tada peržiūri (kitas?) ortofotografijos kaladėles ir randa jose panašius objektus, tada išmeta tuos, kurie jau yra pažymėti OSM, ir gauna rezultatą - spėjimą - kur yra dar nepažymėti objektai (pastatai, vanduo, stovėjimo aikštelės ir pan.). Kol kas tik tiek :-) Gal kas turite priėjimą prie VU megasuperduperkompiuterio? ;-) -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
[Talk-lt] 100 žemėlapių
Sveiki Startavo Lietuvos kartografų draugijos iniciatyva „100 Lietuvai svarbiausių žemėlapių“: http://100lietuvoszemelapiu.lt/ Galite pažiūrėti, pasiūlyti ir balsuoti už jau pasiūlytus žemėlapius. P.S. Yra ir vienas mūsų žemėlapis ;-) -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
[Talk-lt] Plovykla Kaune
Sveiki Gal kas iš Kauno turite informacijos ir galite pataisyti ir uždaryti šitą pastabą? https://www.openstreetmap.org/note/1412153 -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
[Talk-lt] Kartografinės problemos ir jų sprendimai
Sveiki Tiems, kas domisi kartografija, sudėjau keletą nuorodų į gražius OSM žemėlapio kartografinių problemų ir jų sprendimų aprašymus: https://blog.openmap.lt/2018/05/28/kartografijos-problemos-ir-ju-sprendimai/ -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] wetland=reedbed
2018 m. gegužės 21 d. 23:47, Mindaugas rašė: > Dar pasitikslinimui: ar "TIK VIRŠ" išreiškia norą, kad > natural=wetland+wetland=reedbed nebūtų be vandens po apačia? Gal kiek > keista, jei negalėtų egzistuoti vien tik > natural=wetland+wetland=reedbed... Mąstau, ar čia gerai - tarsi tokiu > atveju norėtųsi dėti "water=reedbed"? Žymėjimas OSM'e „generuoja“ vieną ar daugiau objektų GIS'inėje duomenų bazėje. Reedbed norisi dėti tik ant vandens, kad nebūtų keičiama vandens geometrija, tik pridedamas papildomas objektas. Tokio noro priežastis - daugumoje žemėlapių mano galva nėra prasmės vaizduoti reedbed, užtenka tik vandens (miško, marsh/swamp). Norisi, kad žemėlapyje neatsirastų „baltos“ dėmės tik todėl, kad nevaizduojamas reedbed. > O mes turime daugiau situacijų > (topologijos taisyklių ar nebūtinai), kai vienas objektas gali būti > tik ant kito objekto? natural=wood tik virš landuse=residential|commercial|industrial > Pažiūrėjęs į kitas šalis (nežinau kas būtų pavyzdinės - patarkit), tai > randu kaip nori prižymėta - reedbed be vandens, su vandeniu, wetland > (be poklasio) be vandens, su vandeniu ir t.t.: > https://www.openstreetmap.org/#map=15/62.2016/25.7803 Įtariu, kad daugiausia ką galime padaryti - skaityti wiki pagrindinius ir talk puslapius. Ir tai, wiki yra tik rekomendacijų pobūdžio straipsnis. Taigi kaip susitarsim - taip ir bus :-) > Pvz., naujai pataisytas reedbed ant Alsuodžio ež. viršaus: > https://www.openstreetmap.org/#map=18/55.29279/25.81578 > pas UETK nėra ežero ribose - reiškia reikėtų žymėti tik pelkę be ežero; Taip, mano galva galima keisti į marsh. Man asmeniškai iš ortofoto ten nepanašu į meldus, per daug jau viskas tvirtai/suspaustai atrodo, ir kraštas labai jau aiškus/staigus. Palyginkite su vaizdu čia: https://www.openstreetmap.org/#map=17/55.34992/26.08840 Aišku būtų įdomu pažiūrėti tikrą vaizdą vietoje. > Beje, iš kur tas UETK ežerų vektorius? - jis skiriasi nuo geoportal. > Čia irgi gali būti pasekmė, kad kai nupaišė kažkas UETK ežerus, tai > apipelkėjusių, o gal ir visai užpelkėjusių niekas neatnaujina??? Reikia GIS-Centro paklausti. Juk jų vektorizuotojai turėtų turėti instrukcijas, kaip žymėti vandens objektus. -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] wetland=reedbed
> Arba, jei kas pažįsta, kokio limnologo užklausti, ką jie dar laiko ežeru, o > kas jau šlapynė. O nenorime šiuo atveju tiesiog sprendimą palikti profesionalams/oficialioms institucijoms? T.y. ežerase-neežeras spręsti pagal tai, kaip klasifikuojama Valstybiniame upių, ežerų ir tvenkinių kadastre? https://uetk.am.lt/portal/startPageForm.action Juk įvedus reedbed žymėjimą, mes galime ir visiškai užžėlusį ežerą (jei jis klasifikuojamas kaip ežeras VUETK'e) „padengti“ reedbed'u. Tada ir avys sveikos (OSM klasifikacija atitinka oficialią klasifikaciją), ir vilkas sotus (pagal žemėlapį bus įmanoma orientuotis, kas tiksliai kur yra). > T. y., nematau pagrindo, kodėl vieni wetland tipai turėtų būti dedami ant > ežero, o kiti šalia ežero ir pagal ką tai būtų galima praktiškai nustatyti. Tai čia mūsų susitarimas toks būtų, kuris, kaip minėjau, ir turėtų aiškias topologijos taisykles (kas padėtų išvengti bardako ir subjektyvaus interpretavimo dažnai remiantis vien tik ortofoto), ir žemėlapius kurti būtų aiškiau, ir skaičiavimus daryti būtų paprasčiau, ir lyginti su oficialiais šaltiniais galima būtų be varginančių išimčių. Sutinku, kad reedbed pagal labai bendrinį apibrėžimą GALI būti ir už ežero ribos, bet jei tokio varianto neatsisakysime (t.y. tokio už ežero esančio reedbed nežymėsime marsh), tai galime gauti bardakėlį, o bardakėlis bus daug mažiau naudingas nei aiškus žymėjimas galbūt su kai kuriais interpretacijos netikslumais. -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] wetland=reedbed
2018 m. gegužės 21 d. 22:18, Mindaugas rašė: > viskas logiška, nors gal galėtų būti mintis pažiūrėti kaip elgiamasi > kitose šalyse su aktyvia OSM bendruomene. Kai prieš pusmetį ar metus parašiau į „talk“ apie topologijos taisykles, tai likau nesuprastas. Todėl įtariu, kad nelabai kas galvoja apie topologijos taisykles... O kol jų nėra - vyksta atsitiktinis žymėjimas įtakotas to, koks „netyčia gaunasi“ vaizdelis viename ar kitame žemėlapyje. > Dar nesuprantu, ar tai būtų: natural=water + wetland=reedbed? Ar gali > būti wetland=reedbed, be natural=wetland? Objekto klasė yra natural=wetland Objekto poklasis yra wetland=reedbed Poklasis be klasės negali egzistuoti. > Ar galima tam pačiam > objektui priskirti du tagus su skirtingom reikšmėm: > natural=water+natural=wetland+wetland=reedbed? Ne, vienas objektas negali turėti daugiau nei vienos X žymos. reedbed žymėjimo ir vaizdavimo (negalutinis) pavyzdys: https://topo.openmap.lt/#t/14.19/55.3498/26.09263/0/0/ -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
[Talk-lt] wetland=reedbed
Sveiki Per paskutinį susitikimą buvo keltas klausimas dėl to, kaip žymėti meldus. Teritorija, kur auga meldai, teoriškai vis tiek yra ežeras ar tvenkinys. Bet suprantama, kad meldų žymėjimas yra svarbus. Tarkim plaukiant baidare ar valtimi paprastai vengiama plaukti per meldus. Tai kad visi(?) būtų laimingi: a) meldai pažymėti b) nesugadintas vandens telkinių plotas galvoju, kad reedbed naudojimo topologijos taisyklė būtų tokia: reedbed gali būti TIK VIRŠ natural=water ir landuse=reservoir. Vaizdavimas būtų virš vandens (dažniausiai mėlyno) koks nors šablonas: brūkšniukai, taškiukai ar pan. gal balti, gal žalsvi, gal gelsvi pagal kartografo pasirinkimą. Ką galvojate? P.S. Dabar randu daug(visi?) reedbed, kurie „po apačia“ neturi vandens. P.P.S. Prie pelkių dar yra „bog“ (aukštapelkės) klausimas, bet kol kas susitarkime tik dėl reedbed. -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] Atvirojo žemėlapio metinis susitikimas
2018-05-15 8:34 GMT+03:00 Rambla Rambla rašė: > Ar skaitėt apie naują Google Maps API naują kainų politiką? Koks sutapimas, kaip tik mapboxas išmetė straipsniuką apie tai, kaip naudoti jų API arba tiesiog migruoti iš google į mapbox: https://blog.mapbox.com/quickstart-guide-to-mapbox-javascript-api-4b376c68dd46 Teisingas atsakymas žinoma https://switch2osm.org/ Gaila, kad mes dar nespėjome pasidaryti iframe'o, kuris leistų paprastą žemėlapiuką „mano sodyba yra čia“ padaryti su mūsų vietiniu openmap žemėlapiu. Beje, tai ne pirmas kartas, kai gūglas kelia kainas. Iš karto sujudo visi kiti tiekėjai. Bet daugumos jų žemėlapiai tokie fe, ypač jei išlendame iš miestų. Man įdomiausia, ar/kaip tai įtakos gūglo žymėtojus (lokal gaidus)? Vat juos būtų įdomiausia prisivilioti pas mus :-) -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] 357 admin boundaries (all AL8?) damaged in Lithuania
2018-04-28 15:00 GMT+03:00 wrote: > "Missing Boundaries" found that 357 Admin Boundaries in your country have > been damaged. > <...> > does someone know, what is going on? Some admin boundaries, which have been added without proper agreement with data source have been removed by the person who had mapped them. Only outer ways have been removed without removing the relation itself. We're in the process of cleaning that up. Thank you for the heads up! -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
[Talk-lt] Atvirojo žemėlapio metinis susitikimas
Sveiki visi Kitą pirmadienį - 2018-04-30 - bus rengiamas metinis asociacijos „Atvirasis žemėlapis“ visuotinis narių susitikimas. Dienotvarkėje turime tik vieną oficialų klausimą - metinės ataskaitos patvirtinimą: http://asociacija.openmap.lt/report/2017/ Asociacija ir jos veikla yra visiškai atvira, be juridinių dalykų mažai kuo skiriasi nuo talk-lt, todėl kviečiame visus norinčius prisijungti. Pakalbėsime kaip visada apie viską, kas susiję su OpenStreetMap ir šiaip žemėlapiais. Taigi jei turite klausimų, pasiūlymų ar šiaip norite sužinoti, kaip kur kas vyksta, o gal tiesiog norite susipažinti asmeniškai - ateikite! Susitikimo vieta - Savičiaus gatvės Špunkos rūsys: https://craftbeer.openmap.lt/#c/16.6/54.67922/25.28925/0/0/p2811970425 Pradžia - 18:00. Pabaiga - :-) Iki! -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] Klausimai ir pasiūlymai
Laba diena
2018 m. balandžio 14 d. 11:27, Kostas rašė:
> Kažkada buvo kalbama, kad nusipirkti adresų informaciją nebūtų naudinga, nes
> pagal naudojimo taisykles adresų nebūtų galima perplatinti. Klausimas toks -
> tai kaip adresus (ir dar už pinigus) platina tokiuose žemėlapiuose kaip
> „Lietuvos Keliai“? Tai gal vis dėl to galima? Ar tiesiog jiems galioja
> kitokios sąlygos?
Jiems galioja tokios pačios sąlygos.
„Lietuvos keliai“, kaip ir tarkim maps.lt ar maps.google.com
naudoja/vaizduoja RC duomenis, bet neleidžia jų pasiimti ir panaudoti
savo tikslams. Tai UŽDARI žemėlapiai. T.y. negalima pasiimti „Lietuvos
kelių“ žemėlapio adresų susikelti į savo duombazę. Net jei techniškai
tą galima būtų padaryti, tą draudžia visų šitų produktų naudojimo
sąlygos (adresų info susikėlimas būtų vagystė).
Tuo tarpu OSM naudojimo sąlygos yra atviros: bet kas gali atsisiųsti
OSM duomenis ir naudoti juos savo poreikiams.
Taigi:
RC->LietuvosKeliai->[STOP]
RC->googlemaps->[STOP]
bet
RC->OpenStreetMap->{bet kas, bet kaip}
Va todėl OpenStreetMap atveju adresų sukėlimas būtų „perplatinimas“.
T.y. problema ne tame, kad OpenStreetMap rodytų adresus ar leistų jų
ieškoti, problema, kad bet kas galėtų iš OSM atsisiųsti adresus
(nemokamai ir niekam apie tai nepranešę), o ne pirkti iš RC.
> Taip pat turiu porą pasiūlymų:
> Šiuo metu įvairi informacija, susijusi su Lietuvos žymėjimo ypatumais yra
> laikoma dviejuose skirtinguose puslapiuose - Lt:WikiProject Lithuania ir
> Atviro žemėlapio vadovas vikiknygose. Mano manymu, tai tik apsunkina visus
> reikalus. Nebūtų galima visko turėti vienoje vietoje?
wikibooks pradinė mintis buvo paruošti kažką panašaus į knygą. Dėl
laiko trūkumo ta idėja užbuksavo, tai dabar teoriškai galima būtų
jungti į vieną vietą.
> Antras pasiūlymas - visi mes susiduriame su skirtingai pažymėtais vienodais
> objektais - vienas žmogus gali Maximą pažymėti kaip „name=MAXIMA X“, kitas
> „name=Maxima, X“ ir t.t.. Tas pats galioja ir kitiems tag'ams, kad ir tą
> pačią Maximą kažkas gali pavadinti „shop=convenience“, kitas
> „shop=supermarket“, ir t.t.. Mano pasiūlymas būtų toks: Sukurti puslapį,
> kuriame dauguma bendrovių (vaistinės, parduotuvės, t.t.) tag'ų būtų
> standartizuoti (pvz Maximas žymėti kaip „shop=supermarket“, pavadinimą
> reiktų rašyt „name=Maxima [parduotuvės dydis]“ ir t.t.), kad nesigautų
> vienur „Euro Vaisinė“, kitur „EUROvaistinė“ ir t.t.. Kaip ką žymėti būtų
> galima balsuoti tiesiog čia arba su kokia nors el. balsavimo priemone. Gal
> net JOSM kaip preset'us padaryti išeitų.
wikibooksuose tas yra padaryta kai kuriems objektams:
pėsčiųjų/dviračių takams, paveldui, vandens objektams ir pan. Jei yra
poreikis, tai manyčiau procesas turėtų būti toks:
a) parašyti savo pasiūlymą dėl parduotuvių/vaistinių žymėjimo į talk-lt
b) gauti pastabas (jei nėra pastabų - reiškia visi sutinka)
c) surašyti info į wikibooks
d) informuoti talk-lt apie wikibooks papildymus
P.S. Jei susitarimai būtų pakankamai objektyvūs, tai būtų galima
pridėti automatines QA taisykles. T.y. kasdien būtų patikrinama, ar
taisyklių laikomasi, nes negalima tikėtis, kad visi visi žinos apie
taisyklių egzistavimą ir/ar jų laikysis.
--
Tomas
___
Talk-lt mailing list
Talk-lt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-lt
[Talk-lt] Atvirasis žemėlapis 2017-2018
Sveiki Asociacijos „Atvirasis žemėlapis“ 2017 metų ataskaitos: http://asociacija.openmap.lt/report/2017/ Bendra info ir šių metų planai: https://blog.openmap.lt/2018/04/09/2017-metu-rezultatai-ir-2018-planai/ Jei kas norite prisidėti - laukiame! :-) -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
[Talk-lt] 2% parama
Sveiki Ačiū visiems, kas praėjusiais metais skyrė paramą asociacijai „Atvirasis žemėlapis“. Kai tik Ramūnas baigs vargti vargą su krūva ataskaitų, viešai bus pateikta tiksli informacija kiek gavome paramos, kur konkrečiai ji buvo panaudota ir kokie planai šiems metams. Šį kartą rašau, nes pastebėjau nedidelį trūkumą pavyzdinėje paramos formoje: http://asociacija.openmap.lt/support/gpm_support.html Aš nebuvau nurodęs, kad galima pildyti lauką „E5. Mokesčių dalį skiriu iki mokestinio laikotarpio“. Jei šis laukas paliekamas tuščias - parama skiriama tik vienerius metus. Jei norite paramą skirti daugiau nei vienus metus (nepildyti paramos formos kiekvienais metais), lauke E5 galite nurodyti, iki kurių metų skirti paramą (daugiausia 5 metus). Taigi jei kas praėjusiais metais palikote E5 tuščią ir norite toliau skirti paramą Atvirajam žemėlapiui - šiais metais reikia iš naujo pildyti paramos formą. Ačiū visiems! -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
[Talk-lt] Kartografinė generalizacija - geležinkeliai
Sveiki Šiek tiek žemėlapių hardcoro bet paprastai. Apie kartografinę generalizaciją: https://blog.openmap.lt/2018/03/15/generalizacija/ -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] Garmin žemėlapis
2018 m. kovo 15 d. 11:30, Mindaugas rašė: > Čia nevisai suprantu tų administracinių ribų prasmės. Būtų aišku, jei > tarkim prie namo yra tik addr:street ir addr:number, o addr:city nėra. > Tokiu atveju addr:city, kurio reikia adresų paieškai, generuojamas > pagal kažkokius administracinius miestų poligonus. Bet šiuo atveju > mes jau turime addr:city prie objekto. Bendra OSM kryptis yra addr:city nenaudoti, o naudoti administracines ribas. Tarkim OsmAnd taip daro. Garminą kadangi patys generuojam, tai teoriškai galėtume pasikeisti, bet praktiškai kažkas turėtų skirti daugiau laiko nei aš turiu pastoviai prižiūrėti taisykles. Kodėl tada pas mus yra add:city ir kodėl jis net yra privalomas pagal mūsų QA taisykles? Ogi tikrinimui: addr:city turi būti savo administracinėse ribose. Administracinėse ribose X negali būti addr:city=Y. Kitas dalykas. Turime nemažai vietų, kur yra miestas/miestelis X ir greta jo esantis kaimas lygiai tokiu pačiu pavadinimu X. Aišku tai įneša kitas problemas adresų paieškoje :-) > Jei būtų labai norima būtų sutvarkyti adresų indeksą (pvz. gauname > visos Lietuvos adresus importui, bet admin_level suvedimas visiems > kaimams užtrunka ilgai), tai galima automatiškai generuoti admin_level > poligonus, kad jie padengtų adresus su visais nurodytais addr:city. Teisingai, galima generuoti poligonus ir juos naudoti tik Garmino žemėlapio kūrimui (nekelti į OSM db). -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] Garmin žemėlapis
2018 m. kovo 14 d. 21:44, Mindaugas rašė: > 3. Minėjau, kad įrašius vietoje namo numerio tuščią eilutę randa visus > namus. Įtariu, kad priežastis yra daugiau nei vienas objektas db su addr: žymomis. Buvau rašęs prieš kelis mėnesius pasiūlymą palikti tik vieną addr: objektą vienam adresui, o kitus žymėti contact: žymomis. Tada buvo nuspręsta, kad paliekam kelis addr: objektus, nes tik addr: objektus moka įvesti populiariausias poi redaktorius - iD. Todėl dabar db tvarkingumo dėlei kontaktiniai adresai gauna žymą addr:contact=yes, bet čia tik Lietuvoje suprantama žyma tvarkingumui, niekas daugiau jos nenaudoja. > Iš ten buvo ankstesnis Laisvės al. namų sąrašas. Pasirodo > viskas yra sudėtingiau. Su nauju failu, įrašęs tuščią namo numerį, > Laisvės al. randa namus: 19, 28, 30, 41, 42, 45, 49, 49 (antrą kartą), > 50, 54, 59, 65, 65, 74, 74, 76, 78, 81, 83, 83, 84, 87, 91, 92. Taigi > yra ir atsiradusių naujų ir dingusių lyginant su ankstesniu sausio > mėn. failu. Tačiau, jei įrašai paieškoje namo numerį ne iš šio sąrašo, > gali būti įvairiai: 3A) pvz. įrašius 80 - randa vienintelį 80-tą namą. > 3B) įrašius pvz. 95 tarp paieškos rezultatų rodo namus: 94, 92, 94, > 97, 97, 98, 91, 99, 101, 101, 101, 87, 85, 83, 84, 83, 78, 76, 76, > 114, 74, 118, 65, 65, 63 (eilės tvarką išlaikiau, kaip rodo GPSe, t.y. > ne iš eilės). Čia siūlyčiau ieškoti konkretaus adreso. Jei neranda - problema - aiškinamės. Priešingu atveju - spėčiau tai Garmino akmens amžiaus BK0010 sąsajos bėdos... Ir įtariu, kad veikimas priklausys nuo konkretaus įrenginio ir jo programinės įrangos (versijos). > Tačiau klausimas, kodėl 95-to namo nerado, nes jis yra OSM. Geras klausimas. Gal todėl, kad tai mokykla, turinti amenity žymą. T.y. mokykla įrašoma į POI indeksą ir neįrašoma į adresų indeksą. > Gal dar hint'u (o gal kaip tik neaiškumo padaugės) galėtų būti 81-mas > namas. Jį randa du kartus - vieną objektą rodo su pašto indeksu 44291, > kitą - be indekso. Kodėl?! OSM yra 81 ir 81A namai, bet abu be > indekso. Garmin ieškant 81A vis tiek randa tuos pačius du 81 namus. > Beje, abu adresus rodo ne namo centre, o labiau ant gatvės: 54.89736 > 23.90817 ir 54.89746 23.90817, t.y. jie yra skirtingose Laisvės al. > pusėse. Kiek teko skaityti mkgmap sąrašyną, tai adresas pozicionuojamas ne pagal poziciją OSM'e, o gatvėje (ant gatvės vektoriaus artai kažkurioje pusėje nuo gatvės vektoriaus). T.y. gatvės taške arba kairėje arba dešinėje pusėje nuo taško gatvės vektoriuje. Bet kodėl vienas OSM objektas identifikuojamas du kartus negaliu pasakyti. > Daugėdai nuo rugsėjo turi mano papildytą > https://www.openstreetmap.org/way/527966002 , tačiau nei sausio mėn., > nei dabartinis failas Daugėdų nerodo miestų sąraše! Paieška veikia pagal administracines ribas. Jų daug trūksta. Kadangi turiu mažą motyvaciją tokius objektus suvedinėti, tai kartas nuo karto pažiūriu, kokie yra miestai su daugiausia įvestų adresų ir be administracinių ribų. Tada jiems suvedu admin ribas. Daugėduose yra tik vienas adresas... Tai laukti teks ilgai... Arba reikia prašyti manęs asmeniškai (be problemų rašykite, jei turite konkrečių poreikių, bet be variantų „suvesk visus X apskrities miestus“), arba reikia įvesti daugiau adresų tame mieste :-) > 5. Vis dar randu mistinį adresą: 139 20, Kaunas koordinatėmis 54.84993 > 23.96661 Negaliu atsakyti. Nežinau. Bet panašu į Punia degalinę adresu Marijampolės 20 (Marijampolės plentas turi ref=139) > Taip pat susitvarkė ir kažkokie alternatyvūs gatvių pavadinimai. Pvz. > buvo ir "Laisves Al." ir "Laisves Aleja". Dabar liko tik "Laisves Al." > (gal OSM duomenys nuo sausio pataisyti). Jei gatvė yra mieste, galiu > parinkti iš pradžių gatvę, paskui miestą ir gatvė nedingsta - anksčiau > bent kai kuriasi atvejais dingdavo. Čia galiu pasakyti, kad (mano žiniomis) tvarkingai prižiūrimos tik Vilniaus gatvės ir adresai. Pagrinde todėl, kad Vilnius kol kas vienintelis drąsus miestas, atidavęs atvirai adresus (kur Kauno/Matijošaičio fanai?:-). Bet tikriausiai ir todėl, kad tik Vilniuje yra žmonių, užsiimančiu sisteminga adresų priežiūra. Taigi kitiems miestams tiesiog reikia pasitempti, Vilniečiai už jus to nepadarys. > , išeities tekste randu visokių triukų - adresų interpoliavimo (kaip > suprantu, turi 1 ir 11 namą, tai tarpe išdėlioji namus 3, 5, 7 ir 9), > metodą housenumberMatch.getClosestPointOnRoad() ir t.t. Nelabai > pagaunu viso konteksto, kada tos funkcijos naudojamos, bet gali būti, > kad tas adresų indekso generavimas yra naudojamas kažkoks neaiškus > algoritmas. Garminas niekada nepateikė savo failo formato aprašymo. mkgmap programuotojai viską spėlioja... baitą po baito, bitą po bito... :-( Stebuklas, kad jie išspėliojo tiek, kiek dabar jau turime. O formatas tai keičiasi, įrenginių milijonas... Ir jau populiarėja naujas „NT“ formatas... -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] Garmin žemėlapis
Problema su gabalo Lietuvos dingimu buvo mkgmap riktas, kuris jau pataisytas. Taigi „mistikos“ nebeliko. -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-lt] Garmin žemėlapis
Ačiū už naudingus pastebėjimus! 2018 m. kovo 12 d. 23:44, Mindaugas rašė: > 3. Randa ne visus namus, kurie yra OSM. Pvz., Laisvės al. randa tik > 25, 28, 47, 61, 65, 72, 76, 83, 92, 94, 97, 98, 99, 99, 101, nors OSM > matau ir 42, 44, 50, 50A, 56, 58, etc. Šitas labai keistas. Nes tarkim 25 ir 44 yra identiški objektai: abu poligonai, abi turi tik building ir tris adreso žymas, abu panašiu atstumu nuo Laisvės alėjos kelio, abu Kauno administracinėse ribose. > 4. Randa ne visus miestus/kaimus, pvz. neranda Seredžius. Seredžius neturi nei vieno adreso. Todėl jo nėra indekse. > 5. Yra gatvių (kadangi parenkamos iš sąrašo, galima tą pastebėti) > kurios prasideda skaičiais. Pvz. "130 Gimnazijos G." ir vienintelis > šioje gatvėje rastas namas yra 3 atitinka Gimnazijos g. 3, Kaunas. > Kaune gatvės prasideda tik skaičiais 130, 139, 141, 222. Yra netgi > adresas 139 20, Kaunas (kur 139 yra gatvės pavadinimas, 20 yra namo > numeris) @ 54.84993 23.96661. Tačiau tokiom koordinatėm nėra jokio > objekto. Kituose miestuose yra gatvių prasidedančių kitais skaičiais > ar sudarytų vien iš skaičių. Prie gatvės pavadinimų anksčiau buvo pridedamas ir kelio numeris (ref žyma). Gimnazijos gatvė yra kelias su ref=130. > Pastebėjau, kad yra > https://github.com/openstreetmap/mkgmap/blob/master/doc/addresses/address.txt > kuriame yra informacijos kitokios nei > https://wiki.openstreetmap.org/wiki/Mkgmap/help/options - gal kažką > galima išskaityti naudingo... Peržiūrėjau, viskas atitinka. Atnaujinau mkgmap versiją ir taisykles (taisyklėse mačiau keitėsi kažkas su ref'ais, tai gali įtakoti „130 Gimntazijos g.“.). Žemėlapis pergeneruotas (garmin.openmap.lt), tai būtų puiku prie progos vėl patestuoti. Ačiū -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
