GIS and AI with Omar

27/07/2026

A few things worth weighing:

“AI will replace programmers, so i should switch fields” assuming it.

Who tell you AI WON’t touch the field you are switching to.

All fields also being reshaped by AI.

So you need to improve yourself by using it.

Jumping to another technical field isn’t really an scape from it - it’s a different flavour of the same trend.

14/01/2026

Scale و Zoom في الخرائط و GIS
خلّينا نفهمها صح وببساطة.

لما نقول:
Scale = 1 : 50,000
ده معناه إن
1 سم على الشاشة = 50,000 سم على الأرض
يعني 500 متر.

ولما نقول:
Scale = 1 : 10,000
يبقى
1 سم على الشاشة = 10,000 سم على الأرض
يعني 100 متر بس.

طيب نركّز في النقطة المهمة 👇
لما تنتقل من
1 : 50,000 → 1 : 10,000

إنت كده:

بقيت تشوف مسافة أصغر

تفاصيل أكتر

يعني قربت للخريطة

وده معناه إن:
❗ تصغير رقم الـ Scale = تقريب
❗ تكبير رقم الـ Scale = تبعيد

وده عكس اللي دماغنا بتتخيله،
لأننا متعودين إن الرقم الكبير يعني حاجة أكبر.

لكن في الـ Scale:

الرقم الكبير بعد 1 = مساحة أكبر = بعيد

الرقم الصغير بعد 1 = مساحة أقل = قريب

الموضوع مش إنك “بتتحرك”
إنت واقف في مكانك
بس اللي بيتغير هو قد إيه من الأرض ظاهر قدامك

زي المنظار:

لما تضيق العدسة تشوف تفاصيل أكتر

لما توسعها تشوف مساحة أكبر
إنت ما اتحركتش… بس الرؤية اتغيرت.

الخلاصة اللي لازم تثبت:

Zoom إحساس للمستخدم (قرب/بعد)

Scale حقيقة هندسية (مقياس رسم)

تقريب = Scale أصغر

تبعيد = Scale أكبر

فلو شفت حد بيستخدم
Zoom و Scale كأنهم واحد
اعرف إن المشكلة جاية في الطريق 😄

13/01/2026

وأنا شغال على Query في ‎.NET باستخدام Entity Framework Core، لاحظت إن في بعض الحالات الأداء بيبقى سيئ جدًا لما أستخدم عدد كبير من Include() مع علاقات one-to-many أو many-to-many.

المشكلة هنا اسمها Cartesian Explosion.
اللي بيحصل إن EF Core بيحوّل كل الـ Include() دي إلى JOINs في Query واحدة، وده بيخلّي عدد الصفوف الناتجة يتضاعف بشكل ضخم بسبب تكرار بيانات الـ parent مع كل سجل في الـ child. النتيجة:
Query تقيلة، استهلاك Memory أعلى، وأداء أبطأ بدون ما تحس إن السبب واضح.

الحل اللي EF Core وفّره (من الإصدار 5.0) هو AsSplitQuery().

الفكرة ببساطة إن بدل ما EF Core ينفّذ Query واحدة كبيرة ومعقّدة، بيقسّمها إلى عدة Queries أصغر:

Query للـ entity الأساسي

Query منفصلة لكل Include()

كده بتتفادى مشكلة تضخّم النتائج (Cartesian Explosion)، وغالبًا الأداء بيكون أفضل، خصوصًا لما يكون عندك أكتر من collection متضمّنة في نفس المستوى.

لذلك :
لو عندك Query فيها Include() كتير وبتتعامل مع Collections، استخدم AsSplitQuery() بحذر وفي الأماكن الصح، وراقب الأداء، في سيناريوهات كتير بيكون الفرق واضح.

13/01/2026

كيف تسرّع أي خريطة في أي GIS App؟

السر مش في السيرفر…
السر في قراراتك.

✔️ استخدم Layer type صح (Feature ≠ Image)
✔️ ما تحمّلش كل البيانات مرة واحدة
✔️ اعتمد على Scale-dependent rendering
✔️ قلّل requests وقت التحريك والـ zoom
✔️ فكّر في المستخدم قبل ما تفكّر في الأدوات

الخريطة السريعة = تفكير صح قبل كود صح

13/01/2026

Maps don’t lie.
Bad assumptions do.

If you didn’t question the data,
you didn’t do GIS — you just drew shapes.

🔗

Bathymetric Chart Title Map of Bathymetric Chart of the Indian and Pacific Oceans Image (background) /content/dam/esrisites/en-us/common/404/404-map-indian-pacific-ocean.jpg Alt / Title Bathymetric map of the Indian and Pacific oceans