მონაცემთა მოდელი¶
ეს გვერდი არასრულია
ქვემოთ მოცემულია ის, რაც კატალოგის სტრიქონებიდან და კოდიდან დანამდვილებით ვიცი. სადაც ვვარაუდობ, ეს პირდაპირ წერია. შრეების სრული სქემა repo-შია და შესამოწმებელია — ჩანაწერი ჟურნალშია.
შრეები¶
დადასტურებული სახელები (კოდი მათ ბრჭყალებში ეძებს, ანუ ლიტერალური სახელებია):
| შრე | გეომეტრია | საიდან ვიცი |
|---|---|---|
Poles |
წერტილი | Unable to create or find the Poles layer! / Layer 'Poles' not found! |
Route |
ხაზი | Route layer 'Route' not found! |
ODF |
წერტილი | <extracomment>: "it doubles as the layer name" |
| Service Area | პოლიგონი | entry into Service Area layer |
| Optical slacks | წერტილი | "the group of slack tools, and the map layer they write to" |
შრეების სახელები არ ითარგმნება
'Poles' და 'Route' ბრჭყალებში რეალური შრის სახელებია, არა სიტყვები.
თარგმანში ისინი ხელუხლებელი რჩება — თორემ შეტყობინება რეალობას აცდება. ბრჭყალების
გარეთ „Route layer" კი ითარგმნება: ტრასის შრე 'Route' ვერ მოიძებნა!
შენობების შრე¶
ველების ნაკრები, რომელიც Object = შენობის ჰიპოთეზას ადასტურებს:
- სართულების რაოდენობა
- სარდაფის დონეების რაოდენობა
- ქუჩა
- სახლის ნომერი
სწორედ ეს ჩამონათვალი აქვს მოყვანილი მეინთეინერს იმის დასამტკიცებლად, რომ Object
ნიშნავს შენობას, და არა ზოგად GIS ობიექტს.
იდენტობა — fiberq_uuid¶
ყოველ ობიექტს უნიკალური იდენტიფიკატორი აქვს ველში fiberq_uuid.
ვალიდაციის წესი B4 სამ რამეს ამოწმებს:
| შეტყობინება | ქართული |
|---|---|
Layer is missing the fiberq_uuid identity field |
შრეს აკლია იდენტიფიკაციის ველი fiberq_uuid |
Feature has no fiberq_uuid value |
ობიექტს არ აქვს fiberq_uuid-ის მნიშვნელობა |
Duplicate fiberq_uuid |
fiberq_uuid დუბლირებულია |
თუ ველი აკლია, გამოსავალიც შეთავაზებულია: „Re-open the project so migration can add fiberq_uuid, or re-create the layer." — ანუ არსებობს მიგრაციის მექანიზმი, რომელიც პროექტის გახსნისას ველს ამატებს.
სქემის ვერსია
ანგარიშში ცალკე ველია Schema version → სქემის ვერსია. ანუ სქემა ვერსირებულია
და მიგრაციები თანმიმდევრობით ედება. (Repo-ს issue #21 და #22 ამას ადასტურებს:
canonical schema model + project schema_version marker, versioned schema migration
runner + uuid identity invariant.)
სიგრძეების ველები¶
აქ სერბული მემკვიდრეობა პირდაპირ ჩანს — ველების სახელები სერბულია და არ ითარგმნება:
| ველი | რა არის |
|---|---|
duzina_m |
სიგრძე მეტრებში (sr dužina = სიგრძე) |
duzina_km |
სიგრძე კილომეტრებში |
slack_m |
მარაგი მეტრებში |
total_len_m |
სრული სიგრძე მეტრებში |
ორი ინვარიანტი¶
ვალიდაცია ორ არითმეტიკულ დამოკიდებულებას ამოწმებს:
შესაბამისი შეტყობინებები (D3):
total_len_m ({total}) should equal duzina_m + slack_m ({expected})duzina_km ({km}) does not match duzina/1000 ({expected})Stored {field} ({stored}) does not match the drawn geometry ({computed})
შენახული vs დახაზული¶
ეს განსხვავება მთელ D3 წესს ხსნის:
- შენახული სიგრძე (
stored) — ატრიბუტში ჩაწერილი რიცხვი - დახაზული გეომეტრია (
computed) — რუკაზე დახაზული ხაზის რეალური სიგრძე
თუ ვინმემ ტრასა გადაატანა, გეომეტრია შეიცვალა, ატრიბუტი კი ძველი დარჩა → ხარვეზი.
Recalculate lengths სწორედ ამას ასწორებს.
როგორ იზომება
Lengths are measured on the project ellipsoid, the same way the QGIS measure tool does. Slack values are read but never changed.
სიგრძეები იზომება პროექტის ელიფსოიდზე, ისევე როგორც QGIS-ის საზომი ხელსაწყოთი. მარაგის მნიშვნელობები იკითხება, მაგრამ არასდროს იცვლება.
CRS¶
- პროექტს უნდა ჰქონდეს CRS მითითებული (E1)
- FiberQ-ის ყველა შრე ერთსა და იმავე CRS-ს უნდა იყენებდეს
- გეოგრაფიული CRS პრობლემურია: მიბმის დაშვება გრადუსებში იზომება
- სიგრძის გასაზომად საჭიროა ან პროექციული CRS ან პროექტის ელიფსოიდი
შესამოწმებელი¶
- შრეების სრული ჩამონათვალი და თითოეულის ველები
- კაბელის ატრიბუტები — ტიპი, ქვეტიპი, ტევადობა
- ელემენტების შრე — ერთია თუ ტიპის მიხედვით რამდენიმე?
-
Relationsროგორ ინახება - შუალედური ელემენტის ჩაწერის ფორმატი (მანძილი კაბელის გასწვრივ)