Ipiķi un citi
Vakardienas izpēte un jūsu komentāri rezultējās ar nežēlīgiem panākumiem.
Tātad, pētot un domājot kļuva skaidrs tas, ka problēma ir ar izejas datiem. Procesa laikā noskaidroju, kas tad galu galā ir shapre faili, un kāda tajos ir informācija. Ātri uzmeklējot devīgajos internetos failus “pagasti.shp” un “novadi.shp”, tie nokļuva manā rīcībā. Šajos failos, kā izrādās, ir visa nepieciešamā informācija (poligoni, kuri apraksta pilsētu, pagastu, novadu robežas) UTM koodrināšu sistēmā.
Tālākais jau bija tehnikas jautājums. UTM koordinātas ir iespējams pārkonvertēt uz platuma un garuma grādiem, ja zin to projekciju, kura izrādījās esam WGS84. Izmantojot mazu utilītu ogr2ogr tika iegūts XML fails ar nepieciešamajām koordinātām man vajadzīgajā formātā. Fiksi uzmetot Ipiķus uz Gūgles kartes, viss izskatījās dievīgi (ar daždesmit metru nobīdi dažviet, bet tā nav problēma).
Tālākā iterācija problēmai ir sekojoša. Izmantojam MySQL Spatial paplašinājumus, lai iestumtu datubāzē kā novadu robežas, tā pagastu un pilsētu robežas. Teorijā pēc tam var jebkuram punktam pateikt, kur tas atrodas. Diemžēl praksē MySQL GIS funkcionalitātes iespējas ir gauži ierobežotas un problemātiskas. Piemēram,
laacz@skapis[gis]> -- Kur ir Ipiķi? SET @ipiki = GeomFromText('POINT(58.0093006 25.1778021)'); SELECT Within(@point, g) AS `within`, name, type FROM gis WHERE Within(@ipiki, g) = 1; +--------+------------+---------+ | within | name | type | +--------+------------+---------+ | 1 | Ipiķu | pagasts | | 1 | Mazsalacas | novads | | 1 | Rūjienas | novads | +--------+------------+---------+ 3 rows in set (0.00 sec)
Lieki piebilst, ka Mazsalacas novads nepārklāj Ipiķu atrašanās vietas punktu nevienā acī, bet MySQL tā nedomā. Tas gan nenozīmē, ka es vaļasbrīžos neturpināšu cīņu :)
Papildināts 21:58. Izrādās, ka MySQL (vēl aizvien arī tekošajā 5.1 GA versijā) operē nevis ar poligoniem, bet gan ar taisnstūriem, kuri šos poligonus pilnībā ietver (bounding rectangles), kā rezultātā neder. PostgreSQL izmantot tikai šiem nolūkiem neredzu jēgu. Tiesa, cilvēki strādā pie tā, lai MySQL ieviestu pilnvērtīgu OpenGIS atbalstu, bet, kā jau MySQL pierasts, tādas lietas nāk ļoti, ļoti lēnām (konkrēti - anonss par testēšanu ir 2 gadus vecs)...
2009. gada 11. novembrī, plkst. 15:42
Es jau palīdzētu, bet es ne sūda nesaprotu ko Tu tur gribi panākt!
2009. gada 11. novembrī, plkst. 16:24
Iesaku DjangoGIS
2009. gada 11. novembrī, plkst. 17:34
Silti iesaku nemēģināt izgudrot velosipēdu, bet vērsties ar savu sāpi pie draudzīgā gisnet.lv kolektīva - ja nu Latvijā kādam ir vienlaikus varēšana un vēlēšanās ar to nodarboties, tad tie ir viņi :)
2009. gada 11. novembrī, plkst. 19:22
lacis pazudis http://miljons.com/lv/7783/
2009. gada 11. novembrī, plkst. 21:33
Ieteiktu pamēģināt PostgreSQL + PostGIS, noteikti būs labāks par MySQL spatial
2009. gada 12. novembrī, plkst. 00:37
http://www.draugiem.lv/gallery/?pid=69638835 video par laacha pazushanu
2009. gada 12. novembrī, plkst. 08:18
Man ar te iestājas BlackHalt jautājums, varbūt neizskoju pavedienam. A tai gūglei nav sapratīgi barot iekšā KML? Ja negribās postgresql var mēģināt spatialite, tikai tā ir tāda maz un pagaidām ne īpaši stabila mantiņa. Protams var skriptoties un izmantot tos pašus shp nekur neko nekonvertējot.
2009. gada 12. novembrī, plkst. 10:45
Lai arī ar Google API neesmu strādājis, man ar' radās jautājums, vai nav vienkāršāk shp pārkonvertēt uz kml, un tad izmantot to. Un ieteikums vērsties pie gisnet.lv arī ir vietā. :)
2009. gada 12. novembrī, plkst. 12:20
Antuanete te tik sen nebija redzēta komentējam, ka es pat biju piemirsis jau, ka lai nu kas, bet viņa gan ir "drusku" :) kompetenta iekš subject un varētu līdzēt...
Kā saka, atnāca tēvs un ar cirvi nolīdzināja, ko dēls bija mēģinājis ēvelēt :)
2009. gada 12. novembrī, plkst. 13:18
Tāds intīms brīdis šādi ielūkoties tādā īstenā programmēšanas pasaulē. Visi tie nezināmie apzīmējumi skan gluži kā melodija manām ausīm!
2009. gada 12. novembrī, plkst. 14:14
uzminat, par ko šitās 2 naktis lācis ir sapņojis? pareizi, ipiķi, pipiķi par un ap :D smadzeņsports ir veselīgs pasākums vainu savam priekam vai tam ir kāds busines apakšā, veslīgi, lai veicas!
2009. gada 12. novembrī, plkst. 16:48
Modric - šajā konkrētajā jautājumā es neesmu necik kompetenta, bet zinu, kur meklēt pareizos cilvēkus :) Būtu ātrāk ieskatījusies iepriekšējā Laacz ierakstā, tad gan būtu varējusi aiztaupīt dažu labu galvlauzīšanas etapu :)
2009. gada 12. novembrī, plkst. 20:52
Antuanete, paldies, taču process bija interesants un, kas pats galvenais, vainagojās panākumiem :) Ja neskaita MySQL daļu.
2009. gada 13. novembrī, plkst. 07:55
tev noscript daļā vārdā "atbalstam" ir kļūda - "pārlūkā jābūt ieslēgtam JavaScript atbalstasm!"
2009. gada 13. novembrī, plkst. 12:20
Antuanete - sorre, būšu sajaucis tevi ar citu - viņai kartogrāfija/ģeodēzija ir profesija.
2009. gada 15. novembrī, plkst. 21:52
Punkta piederība daudzstūrim vulgaris jau vairs nav tik sūra raķešzinātne
2009. gada 17. novembrī, plkst. 19:20
Kā tu pārkonvertēji UTM koordinātas uz WGS84 - ar ogr2ogr iebūvētiem līdzekļiem vai kā citādi? Man nesanāk pareizi.
2009. gada 17. novembrī, plkst. 20:00
krysits, šķiet, izmantoju ko šādu:
ogr2ogr -t_srs WGS84 -f GML out.mif in.shp
2009. gada 19. novembrī, plkst. 09:30
laacz, labaak pastaasti kaa uz googles kartes (kas ir manaa lapaa) uzmest wikimapia datus? (vinji integreetaa karte neder, gribu uz savas uzmest un veel lietas sameetaat pa virsu)
vot nesanaak.
2009. gada 25. novembrī, plkst. 21:30
ERROR 6: Unable to load PROJ.4 library (libproj.so), creation of OGRCoordinateTransformation failed. Failed to create coordinate transformation between the following coordinate systems. This may be because they are not transformable, or because projection services (PROJ.4 DLL/.so) could not be loaded. Source: PROJCS["Transverse_Mercator",
Acīmredzot nebija sakompilējusies pareizi gdal bibliotēka.
2010. gada 4. augustā, plkst. 17:58
krysits, iesaku pamēģināt http://fwtools.maptools.org/ kompilāciju no GIS rīkiem. Man arī bija līdzīgas kļūdas, bet šeit viss aizgāja.