Brīdinājums par kļūdu QuantumGIS, kas var izsaukt datu zudumu
Uzmanību! Ir iznācis jauns QuantumGIS laidiens ar versijas numuru 1.8.0, taču MS-Windows versija satur GDAL/OGR bibliotēku, kas var novest pie datu zuduma, kad tiek rediģēti ESRI Shapefile formātā esoši dati! Šī kļūda bija arī versijā 1.7.4. GNU/Linux lietotāji, kuru datoros ir instalēta GDAL/OGR bibliotēkas versija 1.8.x ir pasargāti no šīs problēmas, savukārt 1.9.x lietotājus arī šī problēma skar. Ubuntu GIS PPA lietotājiem visticamāk arī ir GDAL/OGR versija 1.9.x.
Windows lietotājiem drošākais variants ir lietot QGIS 1.6.0, kas bija pēdējā versija, kurai līdzi nenāca GDAL/OGR 1.9.x, savukārt GNU/Linux lietotājiem risinājums ir pazemināt instalētās GDAL/OGR bibliotēkas versiju uz 1.8.x.
Konkrēti kļūdu ziņojumi un soļi, kā pārbaudīt, vai arī Jūsu QGIS versija var zaudēt datus, sniegti tālākajā raksta daļā.
Problēmas cēlonis – GDAL/OGR ESRI Shapefile atbalstam beidzot ir pievienots atribūtu kodējuma atbalsts, taču lielākā daļa esošo datu kopu un programmu ignorē šos kodējuma iestatīšanas mehānismus un ir bez kodējuma informācijas. Sekas tam ir, ka datu kopas, kurām nav norādīts kodējums, tiek uzskatītas par ISO-8859-1 (latin1) kodējumā esošām, kas savukārt noved pie datu zuduma, ja tiek veikta datu nolasīšana. Pirms šo izmaiņu ieviešanas problēmas nebija tik nopietnas, jo tā bija lietotāja atbildība, iestatīt pareizu atribūtu kodējumu, ko, piemēram, ESRI ArcGIS saimes programmās vispār nevar vienkārši izdarīt. Papildus tam vēl klāt nāk kļūdiņas kodējuma noteikšanā un apstrādē pašā OGR bibliotēkā. Daļa blusu būs izķertas GDAL/OGR laidienā 1.9.2. Iespējams, ka šī problēma skar arī citas ĢIS programmas, kas izmanto ORG bibliotēku ESRI Shapefile formāta datņu apstrādei!
Kā pārbaudīt, vai Jūsu instalāciju tas arī skar:
1) Iekš QuantumGIS izveidojam jaunu ESRI Shapefile datu slāni;
2) Tam pievienojam teksta atribūtu lauku, piemēram, “nosaukums”;
3) Digitizējam jaunu vektordatu objektu un kā tā teksta atribūtu norādam “āšņļ”;
4) Saglabājam rezultātu un atveram atribūtu tabulu.
Ja “āšņļ” vietā ir “????”, tad Jūsu QGIS instalācija nupat pazaudēja Jūsu ievadītos datus. Rekomendējam šo QGIS versiju ESRI Shapefile formāta datņu rediģēšanai nelietot.
Saistītie kļūdu ziņojumi:
QGIS: #5900 #5622 #5508 #5340 #5255
GDAL/OGR: #294
Birkas: GDAL/OGR, qgis, quantumgis
Uz Windows var taču lietot OSGeo4W, atstājot 1.8.x GDAL/OGR, līdz ar to var lietot jaunāku QGIS par 1.6.0. Nez, cik plašas iespējas izvēlēties vecākas komponentu versijas, ja instalē no jauna, bet pie atjaunināšanas vecās versijas var atstāt noteikti.
He- 1.8.0 pie palaišanas nobļāvās, ka bez GDAL/OGR 1.9.x nu nekādi (ar 1.7.4 problēmu nav). Nu neko- jāliek virsū GDAL/OGR 1.9.x un jāmeklē risinājums kodējuma problēmai. Pāris minūtes ar Google un atbilde rokā (http://ssrebelious.wordpress.com/2012/03/11/qgis-and-gdal1-9-encoding-issue-a-workaround/)- izveidojam .cpg failu, kurā norādām izmantoto kodējumu (piem., UTF-8). Elementāri un darbojas perfekti. Vienīgi .cpg failu jāatceras izveidot pirms rediģēšanas, kā arī pirms pievienot jebkurus agrāk veidotus datus.
Diemžēl *.CPG failu neuzrada komandas, kuras nodrošina jauna shape failu izveidi, kā tas ir, piemēram, pārprojicējot shape faili izmantojot „saglabāt slāni kā” :( Var nākties izmantot vides mainīgo SHAPE_ENCODING, piemēram, linux gadījuu varētu līdzēt:
$ SHAPE_ENCODING=UTF-8
$ export SHAPE_ENCODING
$ qgis
Windows vidē attiecīgi jāizmanto SET.
Pasaule ir maza :) Ikdienā SHP sanāk maz lietot, bet tik tikko bija tieši šis pats “saglabāt slāni kā” gadījums :)
Mmh, pats arī ātri vien ar šo problēmu saskāros, tā kā bez vides mainīgā neiztikt (faktiski tagad sanāk līdzvērtīga ķēpa kā ArcGIS gadījumā). Turklāt papildus čakars, ja pats lieto UTF-8, bet datus šeipfailā vajag dot ArcGIS lietotājam- jāver vaļā .dbf ar to pašu OpenOffice/ LibreOffice un jāsaglabā citā kodējumā…
Anyway tas vēl būtu sīkums, ja salīdzina ar to, ka 1.8.0 simbolu izmēri tiek nekorekti attēloti (1.7.4 ne viss bija perfekti, bet nu pēdējā versijā ir totāli k-kas sajāts). Nav tagad laika, bet, ja kāds nepacentīsies pirms tam (vai jau nav pacenties), būs vien jācepj bug report…
Ja ir galīgs izmisums ar kodējumiem uz Win var lietot NextGIS versiju (http://nextgis.ru/en/nextgis-qgis/ ), kugi gan paši atzīst, ka problēmu nav atrisinājuši, bet izmanto apkārtceļu – kādam brīdim var noderēt.
Var jau būt nedaudz nejauki un utopiski izklausīsies, bet šī nu varbūt ir lieliska iespēja, iespēju robežās, atbrīvoties no seno SahpeFile lietošanas ;) Protams nereāli un neba buga dēļ tam notikt.
Senatnīgs tas Shape fails ir, bet ko likt vietā? Protams iespējām bagātāki ir gan SptiaLite, gan FileGDB, gan PersonalGDB, bet savietojumu problēmas, īpaši pēdējai, satarp dažādām sistēmām ir pietiekoši lielas. Meklējumu rezultātāti ESRI mājaslapā pēc „SpatiaLite” arī nav pārāk iedvesmojoši :(
Par simboliem – QGIS 1.8.0 vispār ir tāda starpstadija (nu labi, tas sākās jau agrāk) starp veco un jauno simboloģiju. 2.0 versijā paredzēts veco simboloģiju vispār izmest, bet, savukārt, problēmas ar jauno aizvien vēl ir pietiekošas.
Esmu nomocījies ar latviešu valodu SHP failos un nekas prātīgs nav sanācis.
Sākumā izmēģināju pie SHP ielādes uzdot visus latviešu valodas kodējuma veidus (windows1257, CP1257, ISO-8859-13, UTF-8) – nekā. Tai pašā laikā atverot to pašu SHP informāciju, importētu, ERIS Peronālajā ģeodatubāzē MDB ar valodu viss ir kārtība un latviešu fonti ir savās vietās un izskatā.
Dāvis nav īsti skaidri pateicis par .cpg failu un kādam ir jābūt tā saturam.
Mēģināju izveidot to ar SHP faila nosaukumu un windows vidē nomainīt $ SET
ieguvu:
OGR [2] kļūda 1: Recode from SET SHAPE_ENCODING=UTF-8 to UTF-8 not supported, treated as ISO8859-1 to UTF-8.
manīju uz citiem kodējuma veidiem – rezultātu nekādu. Iespējams, ka kaut ko nepareizi daru. Vai kāds nevarētu pastāstīt kas īsti ir jādara, lai piespiestu QGIS draudzēties ar latviešu valodu?
Jautājums par to, ko likt SHP vietā informācijas apmaiņai starp dažādām sistēmām ir atklāts. Kamēr QGIS izstrādātāji nav atraduši alternatīvu, ir muļķīgi atteikties no SHP uzturēšanas.
*.cpg fails ir vienkāršāks par vienkāršu. Ja vēlas UTF-8, tad tajā failā ir viena rindiņa:
UTF-8
Ja vēlas Windows-1257, tad veido failu ar vienu rindiņu:
1257
Sveiki!
Vai kāds ir darbojies ar ģeogrāfisko datu apstrādi mysql vidē?
Mysql pamatus pārvaldīdams it labi, atradu, ka QGIS jauki sadarbojas ar mysql serveri, glabādams tajā līnijas, punktus, polilīnijas, poligonus.
Nu radās interese par līnijas garumu.
Pieņemsim, man ir līnija
LINESTRING(2653628.10204452 7749916.93336733,2674860.91456618 7773214.0365681)
Nogreznis Mangaļsalas rags – Babītes ezers.
Vai ir iespēja myqsl pavaicāt līnijas garumu?
Nezinīt, manis minētajā mysql vidē ar latviešu valogu problēmu nav, ja viss ir zem UTF-8.
Atbilde Nilam:
Glabāt un spēt analizēt nav viens un tas pats. MySQL, manuprāt, arvien vēl ir ļoti ierobežot telpisko funkciju klāsts, ja salīdzina ar PostGIS vai SpatiaLite:
http://dev.mysql.com/doc/refman/5.6/en/functions-for-testing-spatial-relations-between-geometric-objects.html
http://postgis.org/documentation/manual-1.5/reference.html#Spatial_Relationships_Measurements
http://www.gaia-gis.it/spatialite-2.4.0/spatialite-sql-2.4.html
P.S. Kas tas par .. koordinātām?
P.P.S. Raksts veltīts pavisam konkrētam failu formātam – SHP – nevis Latviešu valodas lietojumam vispār.
P.P.P.S. Projicētās taisnleņķa koordinātu sistēmās Pitagora teorēmai arvien ir spēks ;)
Nu tad mysql pamatus labi zinot dokumentācijā vajadzēja varēt atrast GLength()
http://dev.mysql.com/doc/refman/5.0/en/geometry-property-functions.html#function_glength
Lai veicas! ;)
Pēter, to jau es atradu., F-ju piemērojot tā atgriež skaitli. Bet kādās mērvienībās ir šis skaitlis, man neizdevās uzminēt. Ne kas loģisks.
Un, kā f-ja GLength() var aprēķināt attālumu neko nezinot par koordinātu sistēmu, kurā ir saglabāti dati? Manas zināšanas kartogrāfijā ir neapmierošanas :(
Mans līnijas garums pēc vaicājuma ir 31521.2205526261
Pēc ZL.LV datiem 17.41 km …?
Pēc idejas funkcija atgriež garumu koordinātu sistēmas mērvienībās. Ja neesi drošs, kas tev tur ir pārbaudi ar SRID(g); Datiem ir jābūt atbilstošajā koordinātu sistēmā, lai tev pateiktu pareizu garumu citādi nekā.
Rezultāts loģisks un izrēķināms kaut vai iekš’ Calc (c^2 = a^2 + b^2), ne velti, jautāju, kas par koordinātu sistēmu …
Nils, uzminot koordinātu sistēmu man arī sanāk tavam LINESTRING tie ~17 km :)
Tas tikai nozīme vienu, datubāzē sistēma tev ir nepareizi nodefinēta. Zirneklītis arī visu laiku velk uz šo pašu pusi. Datos jābūt kartībai, lai būt pareizs rezultāts.
Paldies visiem un par komentāriem un īpaši svecieni Pitagoram!
Ja projekts piederētu man, tad nešaubīgi izvēlētos pgsql. Par tā ģeogrāfisko atbalstu esmu lasījis, un tā pārākums pār mysql ir acīmredzams. Bet, par cik projekta īpašnieks neesmu un nekad nebūšu – rīkojos kā apstākļi spiež.
Pitagoru atceros no 8. klases ar krīta smaržu uz tāfeles un lielu koka lineāli rokā :)
Kā smejies, kā maizi ēd, tā dziesmu dziedi. Kunga maizē alga cieta. Cieta alga – vien- alga.
Neķer kreņķi :)
MySQL nav ne vainas un stradā pietiekoši labi, ja viss ir preizi izdarīts. Ja vienīgais ko tev vajag ir garuma aprēķins, laukums un līdzīgi un nav nepieciešamība pēc specifiskām telpiskām funkcijām ar MySQL pietiks gana labi. Galu galā MySQL arī attīstās un šis tas jauns arī nāk klāt.
Jautāsi, kādēļ tavs aprēķina rezultāts ir nepareizs?
Nu piemēram tev sistēmā ir pateikts, ka dati ir koordinātu sistēmā “A”, kuras:
– vērtību apgabals ir -180.0000, -90.0000, 180.0000, 90.0000 (piemērs WGS84)
– mērvienība ir grādi
Tad kā šādā gadījumā sistēmai saprast tavu LINESTRING(2653628.10204452 7749916.93336733,2674860.91456618 7773214.0365681), kur x un y pāri neatrodas vērtību apgabalā un ticamākais, ka vienība nav pat grādi, bet metri, collas vai pēdas? Īpašos gadījumos uz šādām vērtībām sistēma izmet kļūdas ziņojumu, bet ja nav kādu būtisku ierobežojumu, tu saņem lielisku nepareizu vērtību ;)
[…] izmantotās gdal/ogr bibliotēkas jaunākajās versijās un ir gana viegli risināma un apejama, par to esam jau iepriekš brīdinājuši. Ņemot vērā, ka problēma ir apejama, tās risināšana tiek veikta jau nākošajai Quantum GIS […]