Bir mezarlık nasıl modellenir - ölen kişi başına bir puan veya mezar başına bir tane? [kapalı]

12

Bu, bir CBS sisteminde bir mezarlığın uygulanmasından ekonomik olarak nasıl kurtulacağımız konusundaki projem hakkındaki önceki sorumun devamı niteliğindedir ...

Mezarlıkta bulabiliriz

Düzenli mezarlar: 2 kişiye kadar
Aile mezarları: 2'den fazla, bazıları 20'ye kadar (Katolik cemaatinden kız kardeşler…)
Savaş Anıtı: yaklaşık 30 kişi
Kül Saçılma Alanı: 100 kişiden başlayan sınırsız
Mezar Çömleği Bulunan Alanlar: nokta başına en fazla 2
Mezar Duvarları: 3'e kadar yükseklik

Peki, tanımlamanın en iyi yolu nedir?

her kişi bir POINT nesnesi olarak
her mezar bir POINT nesnesi olarak, kişiler özniteliklerin bir parçasıdır

Her kişi için bir POINT nesnesi olarak seçerdim:

Tüm insanlar için basit bir CSV dosyası.
Sütunlar şunlar olabilir: FirstName - FamilyName - YearDeceased
Bir mezardaki kişi sayısından bağımsız
Bu şekilde KÜL KESME ALANI bile dosyaya girebilir
Sonunda aynı mezara gömülen diğer kişilerin arama sonuçlarına eklemek için bazı kodlar yazılmalıdır.

Her mezarda bir POINT nesnesi olarak gördüğüm komplikasyonlar:

Her ROW bir mezardaki maksimum kişi sayısı için sütunlara ihtiyaç duyar…
Bu, çok sayıda insanın bulunduğu birkaç mezar nedeniyle çok sayıda hücrenin boş olacağı anlamına gelir
Peki ya KÜL DAĞITIM ALANI? 100 kişi tablodaki tüm ek sütunları gerektiriyor…
Tüm verilerin bir CSV dosyasında olması makul değildir, ancak daha fazla dosyaya sahip olmak konuyu oldukça karmaşıklaştıracaktır.

Yani, yorumlarınızı bekliyoruz: POINT nesnesi olarak kişi veya mezar? Yoksa bunların hiçbiri ve başka bir şekilde yapmam gerekiyor mu?

Benim kasabamda, 3 yıl önce, onlar için SHP dosyaları yapılmış bir büro vardı. Bu dosyaları teslim ettim ve mezarların POLYGONS olarak çizildiğini fark ettim. Bu, “mezar verileri” için bir DBF dosyası ile birlikte gelir. Normal mezarların 4 set koordinatı vardır, mantık gibi görünüyor. Ama birkaç şey benim için saçma geliyor:

Altıgen sütunlar altıgen figürler kümesi olarak çizilmiş bir “urn duvarı” vardır… Bu, her figürün 6 takım koordinatı olduğu anlamına gelir…
“Kül saçılma alanında”, küçük dikdörtgen isim levhalarına sahip bir sütun vardır, her bir isim plakası için 4 koordinat seti içeren dikdörtgen bir POLYGON çizmişlerdir… Bana göre, bu durumlarda POLYGONS kullanmak veritabanında çok fazla görünmektedir.

Bunun yanı sıra, yanılıyorsam beni düzeltin:

POLYGONS, DBF dosyaları gerektirir, bu nedenle bir DBF editörü (ekstra maliyetler)
POINTS yalnızca CSV dosyaları gerektirir, bu nedenle EXCEL yeterlidir (ek ücret yoktur)

Çoğu kasabada, ölen kişilerin verileri bir CSV dosyasına gelir:

doğrudan EXCEL'de veya
WIN95 hala etrafında iken yapılan DOS tabanlı bir program dışa aktarılmış ...

“Kişilerin verilerini” bir CSV dosyasında ve EXCEL'de yönetmeye devam etmek aşağıdakileri önler:

DBF dosyalarını düzenleyebilecek yazılım satın alma
"kişilerin verilerini" DBF dosyasına aktarma konusunda endişelenmek CSV'den DBF dosyalarına veri aktarma, düzenleme ve kaydetme ve verilerinizde bozulma olmaması her zaman zahmetli görünmüyor. Özellikle ArcGis (ESRI) ile çalışırken bunun böyle olabileceğini okudum.

— Patrick Van Den Noortgaete
kaynak

@DenaliHardtail - Bir parselin birden fazla işareti olabilir. Hem geleneksel mezar taşı hem de askeri bir plaketi olan savaş gazilerini düşünün.

2

Yanıtlar, yazılım ve kullanım hakkında daha spesifik ayrıntılar olmadan büyük ölçüde fikir tabanlı olacaktır (örneğin, ilgili tablo yoluna giderseniz, web haritalama yazılımınız / sunucunuz bu sorgulamayı destekliyor mu?). Kök soru, mezar başına kişi başına nokta basit - kişi, soru yok. Birden fazla kişi özniteliği olan nokta / mezar kötü bir fikirdir, çünkü daha önce bahsedilen birçok nedenden dolayı kötü veritabanı tasarımıdır. Fakat 'başka bir yolla yap' sorusunu sormak, onu yine çok geniş ve kanaat odaklı yapar. İdeal olarak noktaları ve alanları yapardım , ancak basit tutuyorsa sadece puanlar.

— Chris W

1

Ayrıca, QGis şekil dosyalarını (.dbf dahil) düzenleyebilir, OpenOffice .dbf'yi düzenleyebilir, her ikisi de ücretsizdir.

— RemcoGerlich

1

Bu soru giderek artıyor. Lütfen CBS'yi hatırlayın.SE en iyi odaklanmış, soru başına en fazla birkaç paragrafta cevaplanabilecek bir sorudur. Bu haliyle, tüm bu Soru-Cevap bir soru-cevaptan çok daha iyi bir sohbete uygundur. Evet, size verilen şekil dosyalarında tanımladığınız veri organizasyonlarından bazıları garip / aşırı / kötü tasarım gibi görünüyor. Çokgenlere karşı noktaları anlama ve bir dbf gerektirme anlayışınız kusurludur (bir şekil dosyasının bileşenlerini araştırmak isteyebilirsiniz) ve en iyi ihtimalle ArcGIS ile csv sorunları hakkındaki izlenimleriniz çarpıktır. CSV'ler e-tablo değil, e-tablolar veritabanı değildir.

— Chris W

2

(Devam ediyor) Metin dosyaları, e-tablolar, veritabanları ve özellikle uzamsal veritabanlarının farklı yetenekleri ve çalışma yöntemleri vardır. CBS'yi kullanmak isteyip istemediğinize karar vermeniz gerektiği veya nokta koordinatları içeren metin tabanlı dosyalara dayanan web eşlemesine bağlı kalmanız gerektiği anlaşılıyor. QGIS ücretsizdir, istediğiniz bir şeyleri bir CBS perspektifinden yapabilir ve bu şeyleri öğrenmek nispeten kolaydır. Web haritalama bileşeni başka bir hikaye.

— Chris W

21

Karmaşık bir şekilde giderdim: 1: n ilişkisinde iki tablo

mezarların nokta konumu ile bir tablo
Grave-ID ve kişi verileri içeren başka bir tablo

İki tablo arasında ilişki kurabilirsiniz, böylece bir mezar seçildiğinde kişi tablosundaki tüm kişi kayıtları seçilir.

Person1, Person2 ... gibi alanlara sahip tablolara sahip olma fikri korkunç ve kötü bir tasarımdır.

— tookarf
kaynak

Bu karmaşık değil. Bu, verilerinizi düzgün bir şekilde modelleyecektir! İyi ilişkisel tasarım için +1.

— jpmc26

Ben de öyle düşünmüştüm. Ama "ilişki kurma" yı bilmiyorum, hiç bir CBS uzmanı değilim. Bunu incelemek / incelemek zorunda

— kalacak

@Patrick - Şekil dosyanızı ve bir dBase dosyanızı QGIS'e yükleyin, şekil dosyanızın özellikler iletişim kutusunu açın, Katılmalar'ı seçin ve dBase ile şekil verileri arasında bir bağlantı oluşturun. Bilmek için biraz oynamayı deneyin.

— takearf

5

Mezarın kendisi bir arsa olduğundan ve insanlar için bire çok ilişkisine sahip olduğu için mezar için bir çokgen yaratacağım; bir mezarda sıfır (boş, mevcut veya satılık?) veya birçok kişi olabilir. Çokgen yerine bir nokta da kullanabilirsiniz. Çokgenler satış ve bakım için daha iyi sunumlar yapacaktır.

— DenaliHardtail
kaynak

2

Mezarlık işinde değilim, ama olabildiğince kapsamlı olmayı seviyorum. Parselleri / saçılma alanlarını / anıtları çokgen olarak içerdiğim gibi mezar taşları için puanları da olacaktı.

— JasonT

@ JasonT bu iyi bir nokta. Arsada birden fazla kişi gömülürse, bir arsa (arazi) birden fazla mezar taşı / işaretçisi içerebilir mi? Katılıyorum, her işaretleyici kendi noktası.

— DenaliHardtail

1

Birisi önceden gömme düzenlemelerini yapmışsa, bir arsa işgal edilmeden bir sahibi olabilir.

— Random832

4

DenaliHardtail'in arazilerin doğru boyutlarını temsil etmek için çokgenleri kullanma önerisini alırdım. Bu katmanın Grave_ID, Grave_Type, Grave_Capacity ve Grave_Occupancy_Number içeren bir tablosu olabilir. Sonra karşılık gelen mezar çokgenlerinin üzerinde noktalara sahip bir nokta katmanı olabilir. Nokta katmanı tablosunun sütunları Kişi Kimliği, Ad_Adı, Aile_Adı, Doğum Tarihi, Ölüm Tarihi, Graveowner ve Grave_status (Satıldı, Boş, vb.) Olabilir. Daha sonra her kişi için karşılık gelen Grave-ID'yi ekleyebilirsiniz, böylece kişiyi mezarla eşleştirebilir ve daha sonra tüm mezar ve bireysel kişi bilgileriyle tek bir excel tablosu oluşturabilirsiniz.

— altwitt
kaynak

3

Verileri normalleştirmek beni bazı eksik fikirlere / noktalara götürür. Ayrıca, Excel'in düşündüğünüz "veritabanı" için istediğiniz her şeyi yapabileceğini düşünüyorum. İpucu: Sayfa veya birden çok dosya kullanın ve Arama işlevlerinin varyasyonlarını kullanın. QGIS'ten içe aktarma / arama yapmak için yararlı dosyalara kaydedin

Veri kümenizi başlatmak için bu ayrık tabloları [veya excel sayfalarını] öngörüyorum. Her bir Sayfa / dosya, sütunlar açıkça verildiği (ve bir üst satır olarak dondurulduğu ...) sürece acemi kullanıcılar tarafından kolayca korunur ve acemi kimliklerin benzersiz olduğunu ve atandıktan sonra değişmeden kaldığını hatırlatır. Sayfalar ve sütunlar:

PlotDescription - sütunlar şunları içerir: PlotID (çokgene bağlar), ownerID, plotTypeID (çizim türü: mezar, duvar, crypt vb.). Bu sayfa, yeni bir grafik oluşturana kadar genellikle statiktir.
Sahip - sahip kimliği, tam açıklamalı sütunlar (ad / KişiAdresi / vb.), Merhum (T / F). Birden fazla sahibiniz varsa, ad alanında tam olarak listelendiğini ve bir iletişim adresinizin olacağını öngörüyorum.
Deceased - DeceasedID, PlotID, tam ad / etc / diğer tanımlayıcı veriler, elevationCode. DeceasedID şu ana kadar başka bir yerde bulunamadı, ancak iyi form her ölen kişi için benzersiz bir kimlik oluşturur; verilere yapılan açılımlarda yararlı olabilir - örneğin, etkinlikler veya pazarlama için yaşayan akrabaların bir listesi.
ElevationCode - ElevationID ve ardından kısa bir açıklama ("inGround", "inCrypt", "ilk satır", "ikinci satır", "kül yığını" vb.). Bu sayfa genellikle statiktir
PlotType - PlotTypeID ve kısa bir açıklama - crypt, grave, etc. Bu statik bir sayfadır

Acemi zihniyet için, kimlik sorunlarını ve sütunlarını, sahipler ve ölenler arasında üst üste binme biçiminde tamamen normalleştirmenizi önermiyorum ve çeşitli kimliklerden başka bir şey olmayan gereksiz 1-çok yardımcı tablolar oluşturuyor. Basitlik için bir uzlaşma olarak, arsa ve sahip tabloları arasında bire bir öngörüyorum

Bu genelleştirilmiş kurulumun kül yığınları, duvar kriptoları, sahip / bakımcı takibi, bir arsada ölen çoklu ve daha fazlası gibi sorunları ele alacağını düşünüyorum.

Son olarak, sahibi ve ölen için iki tabloda / sayfada birkaç kalıcı satır oluşturmayı unutmayın: bilinmeyen sahip; ölmeyen bilinmeyen; bilinmeyen çoklu ölen; mezarlığa ait; sahiplenilmemiş; vb.

— John
kaynak