Türkiye'de deprem verisi kullanan bir uygulama yaparken veri kaynağı seçimi teknik olduğu kadar sorumluluk gerektiren bir karardır. Harita üzerinde son depremleri göstermek, büyüklüğe göre filtrelemek, kullanıcılara bildirim göndermek veya araştırma ekranı hazırlamak aynı entegrasyon kalitesini istemez.
Bu rehber, API Deposu'ndaki AFAD Deprem ve Kandilli Son Depremler kayıtlarını ürün kararı açısından karşılaştırır. Amaç sadece endpoint vermek değil; hangi kaynak hangi senaryoda daha güvenli ve sürdürülebilir olur sorusunu cevaplamaktır.
Hızlı karşılaştırma
| Kaynak | En iyi kullanım | Format yaklaşımı | Üretim notu |
|---|---|---|---|
| AFAD Deprem | Resmi, filtrelenebilir olay verisi | JSON, GeoJSON, XML, CSV, KML | Zaman aralığı ve filtrelerle çalışmak için uygun |
| Kandilli Son Depremler | Hızlı son depremler listesi | HTML/text satırları | Parse kırılganlığı dikkate alınmalı |
AFAD ne zaman daha iyi seçim?
AFAD Deprem, resmi kaynak olması ve yapılandırılmış çıktı seçenekleri nedeniyle üretim uygulamalarında güçlü başlangıçtır. Zaman aralığı, büyüklük, derinlik ve coğrafi filtre gibi parametrelerle çalışmak istiyorsanız AFAD tarafı daha temiz bir veri modeli sağlar.
Harita uygulamalarında GeoJSON desteği özellikle değerlidir. Koordinatları metinden ayrıştırmak yerine doğrudan harita katmanına uygun formatla çalışmak hem hata oranını düşürür hem de kodu sadeleştirir. Büyük veri listeleri için limit, zaman aralığı ve sıralama kararlarını netleştirmek gerekir.
Kandilli ne zaman anlamlı?
Kandilli Son Depremler, Türkiye'de kullanıcıların alışık olduğu ve sık takip ettiği kaynaklardan biridir. Son deprem listesi ekranı, araştırma prototipi veya karşılaştırmalı veri görünümü için pratik olabilir. Ancak veri HTML/text biçiminde geldiği için parser kodu daha kırılgandır.
Kandilli verisini kullanırken satır yapısının değişebileceğini varsayın. Alan sayısı, boşluk düzeni veya başlık formatı değişirse uygulama sessizce yanlış veri üretmemelidir. Ayrıştırma sonrasında tarih, büyüklük, koordinat ve yer adı alanlarını doğrulamak gerekir.
Bildirim ve uyarı akışları
Deprem verisini bildirim sistemine bağlamak ayrı bir ürün kararıdır. Aynı olayın tekrar gelmesi, kaydın geç güncellenmesi veya büyüklük bilgisinin revize edilmesi mümkündür. Bu yüzden event ID veya zaman/koordinat/büyüklük kombinasyonuyla idempotency kurmak gerekir.
Kullanıcıya gönderilen mesajlarda kaynak, büyüklük, konum ve zaman açık olmalıdır. Kritik afet iletişimi yapıyorsanız uygulamanın resmi uyarı sistemi gibi algılanmaması için metin ve sorumluluk sınırları dikkatle yazılmalıdır.
Cache ve veri kalitesi
Son depremler ekranında kısa süreli cache yeterli olurken, geçmiş analiz ekranlarında sorgu sonucunu daha uzun saklamak mantıklıdır. Böylece hem performans artar hem de sağlayıcıya gereksiz yük binmez. Veriyi saklıyorsanız kaynak ve çekilme zamanını ayrı alanlar olarak tutun.
İyi bir deprem veri modeli source, eventId, occurredAt, latitude, longitude, magnitude, depthKm, locationText ve rawPayload gibi alanları ayırmalıdır. Bu yapı, kaynak değiştiğinde UI'ın bozulmasını engeller.
Kullanıcı deneyimi ve sorumluluk
Deprem verisini gösteren bir arayüzde dil çok önemlidir. "Son depremler" ekranı bilgi amaçlıdır; "uyarı" veya "alarm" gibi ifadeler kullanıcıda resmi acil durum bildirimi algısı oluşturabilir. Bu nedenle sayfada veri kaynağı, güncelleme zamanı ve uygulamanın resmi kurum yerine geçmediği açıkça belirtilmelidir.
Harita ekranlarında da filtreler dikkatli tasarlanmalıdır. Kullanıcı sadece büyük depremleri görmek isteyebilir, fakat küçük depremlerin saklanması yanlış yorumlara yol açabilir. En iyi yaklaşım; büyüklük filtresi, zaman aralığı, kaynak seçimi ve liste/harita görünümünü birlikte sunmaktır.
Eğer uygulama mobil bildirim gönderecekse sessiz saat, bölge aboneliği ve minimum büyüklük eşiği kullanıcı tarafından ayarlanabilmelidir. Her küçük olayı herkese göndermek bildirim yorgunluğu yaratır; çok yüksek eşik seçmek ise kullanıcının beklediği bilgiyi kaçırabilir.
İlgili API Deposu kayıtları
Kaynaklar
Sik Sorulan Sorular
›Deprem verisi için AFAD mı Kandilli mi kullanılmalı?
Resmi ve yapılandırılmış çıktı gerekiyorsa AFAD daha iyi başlangıçtır. Hızlı son deprem listesi göstermek için Kandilli pratik olabilir, ancak HTML/text ayrıştırma gerektirdiği için daha kırılgandır.
›Deprem API'siyle anlık bildirim sistemi yapılabilir mi?
Yapılabilir, ancak polling aralığı, tekrar eden kayıtlar, gecikme ve yanlış alarm riskleri dikkatle yönetilmelidir. Kritik uyarı sistemi kuruyorsanız resmi yönlendirme ve afet iletişimi sorumluluklarını ayrıca değerlendirin.
›Deprem verisini haritada göstermek için hangi format daha uygun?
AFAD tarafında GeoJSON veya JSON çıktılar harita uygulamaları için daha kullanışlıdır. Kandilli verisi haritaya basılmadan önce metin satırlarından koordinat ayrıştırma ve doğrulama ister.
›Deprem verisi ne kadar cache'lenmeli?
Son depremler ekranında kısa cache veya periyodik yenileme gerekir. Arşiv ve analiz sayfalarında zaman aralığına göre daha uzun cache kullanmak API yükünü azaltır.