Sezgisel "kurallarım" ı kullanıyorum ... Hızlı bir karar için kullanışlıdır,
Senin hakkında DATABASE : özellikleri ve / veya uzamsal analizi ise kıta ölçekli ve hassasiyet (ciddi uygulamalar) ihtiyaç coğrafya kullanın . Başka kullanım geometrisi: tüm veritabanları yaklaşık aynı ( şehir ölçeğinde ) bölgedeyken veya hassasiyete ihtiyacınız yoksa vb. Yalnızca geometriye ihtiyacınız vardır. @Underdark'ın önerdiği derste
benzer kurala bakınız .
PERFORMANS / HASSAS DENGESİ açısından ihtiyaçlarınız hakkında : geometri daha hızlıdır; Performansa ihtiyacınız varsa ve coğrafyayı kullanmayı düşünüyorsanız, önce kıyaslamalarınızı yapın.
Anahtar kavramlar
Bu sayfada, bazı anahtar kelimeler görüyoruz ve bazı kavramlara odaklanıyoruz: hassasiyet , performans ve kullanım esnekliği / emtia gibi bir şey .
Diğerleri tarafından hatırlandığı gibi, mağaza ve hesaplamalar için fark, coğrafyada ve düzlemde geometrinin kullanımıdır:
- Küre (coğrafya) daha iyi, daha kesin. Bkz Los Angeles / Paris örneğini .
- Coğrafyanın evrimi: @DavidF'ın dediği gibi, "daha önce coğrafya tipi eklenmiştir, bu yüzden daha az fonksiyon desteklenir / uygulanır".
Belki de 2020 yılında tüm GIS veritabanları aynı standart SRID / EPSG'ye ayarlanacaktır (günümüzde 4326 koduna eşdeğer, WGS84 için). Bugün coğrafya, performans ve işlevsel kısıtlamalar nedeniyle varsayılan bir seçenek değildir.
Tartışma
Bence bu derin bir teknik / teorik sorun değil, "en iyi uygulamalar" meselesidir.
Hassas
Verilerinizdeki hatayı tahmin ettikten sonra, testleriniz ve sonuçları karşılaştırın: coğrafya ile elde edilen hassasiyet, veri hatasından daha mı yüksek? ST_Distance (fonksiyonlu MAX ve AVG toplayıcılar ) deney bu tür ana referanstır.
Verim
Düzlemsel bir UTM koordinat sisteminde ~ 100km2 (çap ~ 11km) kentsel alanda kıyaslama örnekleri . NOT: sık kullanılan geometri / coğrafya dönüşümü ile başlayarak - sık sık bazı fonksiyonlar mevcut değildir ve bazıları ST_Buffer ve ST_Intersection gibi içsel olarak dönüşüm yaparlar.
Tezgah # 1: Her biri (ortalama) ~ 13 puan olan, şehir alanlarını temsil eden ~ 87000 çokgenli bir masa,
BEGIN; EXPLAIN ANALYSE CREATE TABLE temp_geom AS
SELECT gid, the_geom FROM urbanlots; ROLLBACK;
-- time 2080 ms ~ 2.0 s
BEGIN; EXPLAIN ANALYSE CREATE TABLE temp_geog AS
SELECT gid, Geography(ST_Transform(the_geom,4326)) AS geog
FROM urbanlots; ROLLBACK;
-- time 12374 ms ~ 12.4 s ~ 6 * geometry.
öyleyse, geography_time = 6 * geometri_time.
Bench # 2: kentsel blokları temsil eden ~ 3500 çokgenli bir masa, her biri poli (avg) ile ~ 50 puan: 0.6s vs 2.7s, geography_time = 4.5 * geometry_time.
Bench # 3: ~ Her biri ~ 5 puan olan şehir sokaklarını temsil eden 10000 hat. ~ 0.87s ve ~ 0.36s, geography_time = 2.4 * geometri_time.
Tezgah # 2'ye dönün, masaları yaratıp sorguları yapın,
EXPLAIN ANALYSE SELECT ST_Area(g.the_geom)+ST_Distance(g.the_geom,t.the_geom)
FROM temp_geom g, (SELECT the_geom FROM temp_geom WHERE gid=1) as t;
-- time 182 ms ~ 0.2 s
EXPLAIN ANALYSE SELECT ST_Area(g.geog)+ST_Distance(g.geog,t.geog)
FROM temp_geog g, (SELECT geog FROM temp_geog WHERE gid=1) as t;
-- time 58657 ms ~ 59 s ~ 300*geometry
-- curioselly for only distances, geography=4*geometry
Sonuç: Çok az görev ve iyi hardaware için, zamanlar “kabul edilebilir-aynı zamana” yaklaşır, ancak büyük görevler için dikkate alınması gereken performans derecelendirmeleri vardır.
Esneklik / Mal
Kriterler üzerinde günlük iş yapıyorum, puan sayısını (by ST_NPoints) kontrol ediyorum ... Coğrafya için var olmayan, atılması gereken bir operasyon örneği. "Coğrafya / geometri atışı", programcılar, ustalar vb. İçin can sıkıcı bir iştir.
SQL ve PL / pgSQL işlev kütüphanelerini yeniden kullanırken coğrafya uyarlamalara ihtiyaç duyar. Ayrıca, kodu optimize etmek veya çok sayıda ara dönüşümle ilgili hassas sorunlardan kaçınmak istiyorsanız, coğrafi konumla birlikte, bir yerleşik yerleşik işlevler dizisinin olmaması başka bir sorundur. Coğrafya programı, kolay bir iş değildir.
Yalnızca işlem, veri değişimi vb.
Alışılmadık talepler için, Mapserver gibi yoğun bir kullanıcı olmadan, yalnızca (PostGIS) çalışmanız girdi verilerini işlemek ve herhangi bir zamanda (saat veya gün gibi) geri dönmek anlamına geldiğinde, işlenen verinin değeri, genel kural "" rahatsın! " (bkz. yukarıdaki "Esneklik / Emtia"). Değilse, normal kuralları kontrol edin.
NOT: (olağan olmayan) göreviniz yalnızca PostGIS'den Mapserver'a veri gösteriyorsa, işlem gerektirmeden, girdi verilerinizin aynısını (geometri veya coğrafya) korumak için daha iyi bir karar verilir.
Veri merkezileşme coğrafya iyidir başka iştir inanıyoruz: bağlamda çeşitlilik giriş biçimleri ve referans sistemlerinin olağan olan bu tür coğrafya yürütür gibi bir standartta, kullanımı faydalıdır ... yapılandırması üzerinde Sözleşmesi olduğunu merkezileşme ve veri alışverişinde iş odağı olduğunda iyi bir ilke (bkz. Google Haritalar!).