12 KiB
ساختار فعلی location_data
این فایل وضعیت فعلی اپ location_data را توضیح میدهد؛ هم از نظر ساختار فایلها و هم از نظر مدلها، APIها و جریان داده.
هدف فعلی اپ
اپ location_data فعلاً این مسئولیتها را دارد:
- نگهداری موقعیت زمین با
latوlon - نگهداری مرز مزرعه در
farm_boundary - نگهداری ساختار بلوکهای زمین در
block_layout - نگهداری دادههای خاک برای عمقهای مختلف در
SoilDepthData - نگهداری مشاهدات NDVI در
NdviObservation - برگرداندن ساختار بلوکهای زمین از API محلی بدون نیاز به API خارجی در فاز فعلی
نکته مهم:
- در فاز فعلی، endpoint اصلی
location_dataبرای ساختار زمین، فقط داده را در دیتابیس میخواند/ذخیره میکند. - فعلاً برای بلوکها، زیربلوکها و دادههای ماهوارهای هیچ درخواست خارجی زده نمیشود.
ساختار فایلها
location_data/
├── admin.py
├── apps.py
├── models.py
├── serializers.py
├── views.py
├── urls.py
├── tasks.py
├── soil_adapters.py
├── remote_sensing.py
├── ndvi.py
├── test_soil_api.py
├── test_soil_adapters.py
├── test_ndvi_health_api.py
├── postman/
│ └── soil_data.json
├── management/
│ └── commands/
└── migrations/
├── 0001_initial.py
├── 0002_soildepthdata_refactor.py
├── 0002_soillocation_ideal_sensor_profile.py
├── 0003_rename_app_label.py
├── 0004_soillocation_farm_boundary.py
├── 0005_merge_20260327_0840.py
├── 0006_remove_soillocation_ideal_sensor_profile.py
├── 0007_ndviobservation.py
└── 0008_soillocation_block_layout.py
مدلها و جدولها
1) SoilLocation
مدل اصلی اپ است و نماینده یک موقعیت یکتا برای زمین یا مرکز زمین محسوب میشود.
فیلدهای اصلی:
| فیلد | نوع | توضیح |
|---|---|---|
id |
BigAutoField |
شناسه داخلی رکورد |
latitude |
DecimalField(9,6) |
عرض جغرافیایی |
longitude |
DecimalField(9,6) |
طول جغرافیایی |
task_id |
CharField |
شناسه تسک Celery برای جریان قدیمی واکشی خاک |
farm_boundary |
JSONField |
مرز مزرعه به شکل Polygon یا corners |
input_block_count |
PositiveIntegerField |
تعداد بلوک اولیهای که از ورودی کشاورز میآید |
block_layout |
JSONField |
ساختار بلوکها و زیربلوکهای زمین |
created_at |
DateTimeField |
زمان ایجاد |
updated_at |
DateTimeField |
زمان آخرین تغییر |
قیدها:
- روی ترکیب
latitudeوlongitudeیکتا است.
رفتار مهم:
- اگر
input_block_countارسال نشود، مقدار پیشفرض1است. - اگر
block_layoutخالی باشد، به صورت خودکار با یک بلوک کامل ساخته میشود. - متد
set_input_block_count()ساختار اولیه بلوکها را میسازد.
2) SoilDepthData
این مدل دادههای خاک را برای هر عمق نگه میدارد و به SoilLocation وصل است.
عمقهای فعلی:
0-5cm5-15cm15-30cm
فیلدهای مهم:
| فیلد | نوع | توضیح |
|---|---|---|
soil_location |
ForeignKey |
ارتباط با SoilLocation |
depth_label |
CharField |
برچسب عمق |
bdod تا wv1500 |
FloatField |
پارامترهای مختلف خاک |
created_at |
DateTimeField |
زمان ثبت رکورد |
قیدها:
- برای هر
soil_locationو هرdepth_labelفقط یک رکورد وجود دارد.
3) NdviObservation
این مدل برای ذخیره مشاهدههای NDVI استفاده میشود.
فیلدهای مهم:
| فیلد | نوع | توضیح |
|---|---|---|
location |
ForeignKey |
ارتباط با SoilLocation |
observation_date |
DateField |
تاریخ مشاهده |
mean_ndvi |
FloatField |
میانگین NDVI |
ndvi_map |
JSONField |
داده مکانی NDVI |
vegetation_health_class |
CharField |
کلاس سلامت پوشش گیاهی |
satellite_source |
CharField |
منبع تصویر ماهوارهای |
cloud_cover |
FloatField |
درصد ابر |
metadata |
JSONField |
داده تکمیلی |
ساختار block_layout
فیلد block_layout فعلاً ساختار پایه تقسیم زمین را نگه میدارد.
نمونه پیشفرض وقتی کل زمین یک بلوک باشد:
{
"input_block_count": 1,
"default_full_farm": true,
"algorithm_status": "pending",
"blocks": [
{
"block_code": "block-1",
"order": 1,
"source": "default",
"needs_subdivision": null,
"sub_blocks": []
}
]
}
نمونه وقتی ورودی مثلاً block_count = 3 باشد:
{
"input_block_count": 3,
"default_full_farm": false,
"algorithm_status": "pending",
"blocks": [
{
"block_code": "block-1",
"order": 1,
"source": "input",
"needs_subdivision": null,
"sub_blocks": []
},
{
"block_code": "block-2",
"order": 2,
"source": "input",
"needs_subdivision": null,
"sub_blocks": []
},
{
"block_code": "block-3",
"order": 3,
"source": "input",
"needs_subdivision": null,
"sub_blocks": []
}
]
}
معنای فیلدها:
| فیلد | توضیح |
|---|---|
input_block_count |
تعداد بلوک اولیه |
default_full_farm |
آیا کل زمین هنوز یک بلوک کامل است یا نه |
algorithm_status |
وضعیت اجرای الگوریتم تقسیمبندی |
blocks |
لیست بلوکهای فعلی |
block_code |
کد بلوک |
order |
ترتیب بلوک |
source |
منشأ بلوک: default یا input |
needs_subdivision |
آیا الگوریتم تشخیص داده که این بلوک باید خردتر شود یا نه |
sub_blocks |
لیست زیربلوکها |
Serializerها
SoilDataRequestSerializer
ورودی endpoint اصلی location_data:
| فیلد | اجباری | توضیح |
|---|---|---|
lat |
بله | عرض جغرافیایی |
lon |
بله | طول جغرافیایی |
block_count |
خیر | تعداد بلوک اولیه، پیشفرض 1 |
SoilLocationResponseSerializer
خروجی اصلی برای یک location:
idlatloninput_block_countblock_layoutdepths
SoilDepthDataSerializer
لیست پارامترهای خاک برای هر عمق را برمیگرداند.
NdviHealthRequestSerializer و NdviHealthResponseSerializer
برای endpoint مربوط به NDVI استفاده میشوند.
Viewها و APIها
1) SoilDataView
مسیر:
GET /api/soil-data/POST /api/soil-data/
وظیفه فعلی:
- گرفتن
latوlon - گرفتن
block_countدر صورت وجود - ساخت یا پیدا کردن
SoilLocation - ذخیره
input_block_count - ساخت
block_layout - برگرداندن پاسخ با
source = local
رفتار فعلی:
- اگر location وجود نداشته باشد، ساخته میشود.
- اگر
block_countتغییر کند، ساختارblock_layoutدوباره ساخته میشود. - فعلاً هیچ fetch خارجی برای اطلاعات خاک یا ماهوارهای انجام نمیشود.
2) SoilDataTaskStatusView
مسیر:
GET /api/soil-data/tasks/<task_id>/status/
وضعیت فعلی:
- هنوز در کد وجود دارد.
- برای جریان قدیمی مبتنی بر Celery طراحی شده است.
- با تغییر اخیر، endpoint اصلی
location_dataدیگر بهطور پیشفرض task جدیدی صف نمیکند.
3) NdviHealthView
مسیر:
POST /api/soil-data/ndvi-health/
وظیفه:
- دریافت
farm_uuid - خواندن داده NDVI از سرویس داخلی NDVI
- برگرداندن اطلاعات سلامت پوشش گیاهی
فایل tasks.py
این فایل هنوز منطق قدیمی واکشی داده خاک را نگه میدارد.
اجزای اصلی:
fetch_soil_data_for_coordinates()fetch_soil_data_task()
نکته:
- این بخش هنوز برای سازگاری و جریانهای قدیمی در پروژه باقی مانده است.
- ولی در فاز فعلی تقسیم بلوکها، از این task برای endpoint اصلی
location_dataاستفاده نمیشود.
فایل soil_adapters.py
این فایل abstraction مربوط به تامین داده خاک را نگه میدارد.
کاربرد آن:
- mock provider
- live soil provider
- ساختار depth-based data fetch
در وضعیت فعلی:
- برای منطق بلوکبندی فعلی لازم نیست.
- اما برای جریان قدیمی یا مراحل بعدی میتواند دوباره استفاده شود.
فایل remote_sensing.py
این فایل مربوط به منطق سنجشازدور و دادههای ماهوارهای است.
در وضعیت فعلی:
- برای block layout فعلاً استفاده فعال ندارد.
- بعداً میتواند برای تحلیل هر بلوک یا زیربلوک استفاده شود.
فایل ndvi.py
این فایل سرویس/منطق NDVI را نگه میدارد و برای endpoint NDVI استفاده میشود.
migrationها
مهمترین migrationهای فعلی:
| migration | توضیح |
|---|---|
0001_initial.py |
ساختار اولیه SoilLocation |
0002_soildepthdata_refactor.py |
جداسازی دادههای عمقی در SoilDepthData |
0004_soillocation_farm_boundary.py |
اضافه شدن farm_boundary |
0007_ndviobservation.py |
اضافه شدن NdviObservation |
0008_soillocation_block_layout.py |
اضافه شدن input_block_count و block_layout |
تستها
فایلهای تست اصلی:
-
location_data/test_soil_api.py- تست ساختار محلی بلوکها
- تست پیشفرض یک بلوک
- تست تغییر
block_count
-
location_data/test_soil_adapters.py- تست adapterهای خاک
- تست ذخیره depth data
-
location_data/test_ndvi_health_api.py- تست endpoint NDVI
ارتباط با farm_data
location_data مستقیماً توسط farm_data استفاده میشود.
نمونه وابستگیها:
farm_dataازSoilLocationبه عنوانcenter_locationاستفاده میکند.farm_boundaryاز سمتfarm_dataمیآید.block_countهم از ورودیfarm_dataقابل ثبت است.farm_dataفعلاً فقط location و block layout را ذخیره میکند و برای این بخش sync خارجی انجام نمیدهد.
جمعبندی ساختار فعلی
الان location_data دو لایه دارد:
-
لایه فعلی فعال برای بلوکبندی زمین
- محلی
- ساده
- بدون API خارجی
- با
input_block_countوblock_layout
-
لایه قدیمی/جانبی برای خاک و NDVI
SoilDepthDatatasks.pysoil_adapters.pyNdviObservationremote_sensing.py
یعنی از نظر معماری، اپ الان هم داده مکانی زمین را نگه میدارد و هم زیرساختی برای تحلیل خاک/NDVI دارد، ولی منطق جدید بلوکها فعلاً مستقل و محلی پیاده شده است.