Uzamsal veriler için bir API tasarlama


10

Analiz için meslektaşları için bazı uzamsal veri kümeleri yapabilmem için bir API yapmaya çalışmayı düşünüyorum.

Çalışmamın bir kısmı, daha sonra başkaları tarafından daha fazla analiz için kullanılabilecek verileri analiz etmek ve hazırlamaktı. Çalışma (şu anda daha küçük ölçekte ve daha az sofistike iken) walkscore'a benzer, ancak bazı muazzam veri kümelerini içerir. Orijinal verileri nasıl paylaşabileceğim konusunda artan kısıtlamalar var, ancak türev çalışmam paylaşılabilir. Analizimin sonuçlarını (en büyük veri kümelerini aktarmanın dışında) en iyi nasıl paylaşacağımı düşünüyordum ve bir API'nın bir yaklaşım olacağını düşündüm. Bir API oluştururken ne tür şeyler düşünmeliyim? Takip edebileceğim tasarım özellikleri var mı?

Vizyonum şu anda olduğundan biraz daha görkemli görünüyor, ancak bence bu çalışmada erken düşünmek yararlı bir çerçeve olacaktır.


1
ArcGIS flex viewer veya daha fazla özelleştirmek istediğiniz bir şey gibi kullanıma hazır bir API mi arıyorsunuz?
artwork21

Bir şeyi (veya şeyleri) özelleştirmeyi denemek istiyorum. Şu anda PostGIS veri depolama ve analizi ve mapserver kullanıyorum (ama hiçbirini kullanarak uzman). Bunu başkaları için erişilebilir hale getirmek ve ne öğrenmem gerektiğini anlamak için bir sonraki adımın ne olacağını merak ediyorum.
djq

Yanıtlar:


7

API ile, Google Haritalar API gibi bir HTTP POST / GET türü ilişkisi üzerinden verilerinize bir tür ağ erişimi demek istediğinizi varsayalım? Raster veya vektör verisi olacak mı? Bu tartışmanın amaçları için vektör olduğunu varsayacağım. Bu gerçekten bir Uygulama Programlama Arayüzü yerine bir iletişim protokolüdür.

Sıfırdan bir şey tasarlamanız gerekmeyecek, çünkü çok sayıda standart protokol var (API'ler yerine, API'leri aramadıklarında çağırmakla ilgili bir hata var, ama sizi sıkmayacağım! ). Yalnızca istemcilerinize salt okunur vektör verileri sunmakla ilgileniyorsanız , veritabanınızın önünde duran bir WFS Sunucusuna ihtiyacınız vardır . Geçmişte GeoServer kullandım , ancak TinyOWS'un hafifliğini tercih ediyorum . Her ikisi de aynı işi yapar: bunları türetilmiş veri veritabanınıza erişecek şekilde yapılandırın, bir web sunucusunun parçası olarak çalışacak şekilde ayarlayın ( Apache yaygındır, ancak lighttpd'yi tercih ederim), İşte buyur. QGIS bir WFS sunucusundan veri yükleyebilir ve şüphesiz Arc da yükleyebilir. OpenLayers ayrıca tarayıcı tabanlı bir çözüm için WFS oluşturma yeteneklerine de sahiptir. Daha düşük seviyede GDAL, verileri WFS'den OGR'nin desteklediği herhangi bir vektör formatına dönüştürmek için kullanılabilir.

Düzenleme yetenekleri istiyorsanız, hem GeoServer hem de TinyOWS WFS-T'yi destekleyerek kullanıcılarınızın analizlerini sunucunuza geri yüklemelerini sağlar.

Kendi API'nizi oluşturmak, inanılmaz derecede uzman olmadıkça ve performans gibi özel gereksinimleriniz yoksa, bu standartları ilk etapta almanın amacını gerçekten yener. Makul miktarda kaynak olmadan bu rotaya gitmek imkansız olmasa da bir iştir.


Düşünceleriniz için teşekkür ederiz - belki de sorumda API'yı yanlış kullandım. Hem WMS hem de WFS hizmeti (raster ve vektör) ile ilgileniyorum; bunun hakkında daha fazla düşündüğüm için açıklamanız çok faydalı.
djq

6

Senin birkaç seçeneğin var; Bunların seçimi veri modelinize, sunulacak verilerin türüne, kullanım amacına uygun modele, erişim kontrolüne ve ayrıca dağıtım platformuna (Web, HTML, Java Sunucusu, IIS, statik veri kümesi) bağlı olacaktır.

  1. Veri kümenizi tüketmek için mevcut bir ürünü genişletin. Bir GeoServer örneğini (veya özel?) Bilgisayarınızda barındırmaya bakabilir ve verilerinizi bu şekilde teslim edebilirsiniz. Verileriniz GeoServer'ın anlayabileceği bir formatta değilse, bu yeteneği sağlamak için bir Java paketi yazma seçeneğiniz vardır. Avantajı, hem görselleştirme (WMS) hem de özellik manipülasyonu / indirmesi (WFS) için mekansal bilgi sunmanın yanı sıra coğrafi önbellekleme ve döşeme gibi diğer avantajlar için iyi tanımlanmış bir standarda sahip olmanızdır.
  2. API seçeneğinizi kullanın ve kullanıcıların onunla nasıl arayüz kurduğunu tam olarak kontrol edin. İlk görevinize gelen Kullanıcıların verilerinizle nasıl etkileşime girmesini istediğinizi tanımlayın. Verilerinizle olan bu arayüz başarı veya başarısızlık arasındaki anahtar olacaktır. Arayüzünüz çok açıksa, karmaşık ve kullanılamaz, çok basit ve kısıtlayıcı, yavaş olabilir veya benimsenmeyebilir. Her iki durumda da, kullanıcıların verilerinize erişmesini istediğiniz yolu ve kullanıcıların verilerinizi nasıl kullanacağını tahmin etme şeklinizi tanımlamak önemli olacaktır.

İyi şanslar, bir API, yayınlama yöntemini ve döngülerini, hata düzeltmelerini, testleri dikkate almanız gereken küçük bir girişim değildir. Bütün bunlar kullanılabilirliğe katkıda bulunur. Bunu yapma demiyorum, harika bir deneyim olurdu. Mevcut bir ürün üzerine inşa etmek de olumlu bir deneyim olabilir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.