Vairāk

Telpisko datu API projektēšana

Telpisko datu API projektēšana


Apsveru mēģinājumu izveidot API, lai varētu dažus telpiskos datu kopumus padarīt pieejamus kolēģiem analīzei.

Daļa mana darba ir bijusi datu analīze un sagatavošana, kurus pēc tam citi var izmantot tālākai analīzei. Darbs (patlaban mazākā apjomā un mazāk izsmalcināts) ir līdzīgs Walkscore, taču tajā ir iekļautas milzīgas datu kopas. Pastāv arvien vairāk ierobežojumu attiecībā uz to, kā es varu kopīgot sākotnējos datus, taču mans atvasinātais darbs ir kopīgojams. Esmu domājis par to, kā vislabāk dalīties ar savas analīzes rezultātiem (ārpus lielo datu kopu nodošanas) un domāju, ka API būtu viena pieeja. Par kādām lietām, vai man vajadzētu domāt, veidojot API? Vai ir dizaina specifikācijas, kurām varu sekot?

Mana vīzija izklausās nedaudz grandiozāka nekā pašlaik, bet es domāju, ka tas būtu noderīgs ietvars, kas jāņem vērā šī darba sākumā.


Ar API es domāju, ka jūs domājat sava veida tīkla piekļuvi saviem datiem, izmantojot HTTP POST / GET tipa lietu, piemēram, Google Maps API? Vai tie būs rastra vai vektoru dati? Šīs diskusijas vajadzībām es pieņemu vektoru. Tas patiesībā ir tikai sakaru protokols, nevis lietojumprogrammu saskarne.

Jums nevajadzēs neko izstrādāt no nulles, jo ir daudz standarta protokolu (nevis API per se, man ir mazliet kļūda par lietu izsaukšanu par API, ja tādas nav, bet es jums tevi negaršos! ). Ja jūs vienkārši interesē tikai lasāmu vektoru datu piegāde klientiem, jums vienkārši nepieciešams WFS serveris, kas atrodas jūsu datu bāzes priekšā. Agrāk esmu izmantojis GeoServer, bet es dodu priekšroku TinyOWS vieglumam. Abi veic vienu un to pašu darbu: konfigurē tos piekļūt atvasināto datu datu bāzei, iestatiet tos darboties kā tīmekļa servera daļu (Apache ir izplatīta parādība, bet es dodu priekšroku lighttpd), un jums tas ir pieejams. QGIS var ielādēt datus no WFS servera, un, bez šaubām, to var arī Arc. OpenLayers ir arī WFS renderēšanas iespējas uz pārlūku balstītam risinājumam. Zemākajā līmenī GDAL var izmantot, lai pārveidotu datus no WFS uz jebkuru vektoru formātu, ko atbalsta OGR.

Ja vēlaties rediģēšanas iespējas, gan GeoServer, gan TinyOWS atbalsta WFS-T, ļaujot lietotājiem augšupielādēt savas analīzes atpakaļ uz jūsu serveri.

Izveidojot savu API, patiešām tiek pārvarēts mērķis, lai šie standarti būtu pirmkārt, ja vien jūs neesat neticami specializējies un jums nav īpašu prasību, piemēram, veiktspējas un vēl ... tas ir viss, ko es varu iedomāties. Iet pa šo ceļu bez saprātīga resursu apjoma ir pilns - lai arī ne neiespējams - uzdevums.


Jums ir pāris iespējas; kuru izvēle būs atkarīga no jūsu datu modeļa, izsniedzamo datu veida, paredzētā lietojuma modeļa, piekļuves kontroles, kā arī no piegādes platformas (Web, HTML, Java Server, IIS, statisko datu kopa).

  1. Paplašiniet esošu produktu, lai patērētu jūsu datu kopu. Jūs varētu apskatīt GeoServer instances mitināšanu savā (vai veltītajā) datorā un tādā veidā piegādāt savus datus. Ja jūsu dati nav tādā formātā, kuru GeoServer varētu saprast, jums ir iespēja rakstīt Java pakotni, lai nodrošinātu šo iespēju. Priekšrocība ir tā, ka jums ir precīzi noteikts standarts telpiskās informācijas piegādei gan vizualizācijai (WMS), gan funkciju manipulēšanai / lejupielādei (WFS), kā arī citas priekšrocības, piemēram, ģeokešatmiņa un flīžu ieklāšana.
  2. Izmantojiet savu API opciju, un jums ir pilnīga kontrole pār to, kā lietotāji ar to saskaras. Kas attiecas uz jūsu pirmo uzdevumu, Definējiet, kā vēlaties, lai lietotāji mijiedarbotos ar jūsu datiem. Šī saskarne ar jūsu datiem būs atslēga starp veiksmi vai neveiksmi. Ja jūsu saskarne ir pārāk atvērta, tā var kļūt sarežģīta un nelietojama, pārāk vienkārša un ierobežojoša, lēna vai bez tās pieņemšanas. Jebkurā gadījumā būs svarīgi noteikt veidu, kādā vēlaties, lai lietotāji piekļūtu jūsu datiem, un tas, kā jūs domājat, ka lietotāji vēlēsies izmantot jūsu datus.

Veiksmi, API nav mazs uzņēmums, jo jums jāapsver izlaišanas metode un cikli, kļūdu labojumi, testēšana. Tas viss veicina lietojamību. Es nesaku, ka nedari to, tā būtu lieliska pieredze. Lai arī jau esošā produkta izmantošana varētu būt arī pozitīva pieredze.