نویسنده: جاناتان استنگر، Phd
Spatial Partners، استرالیا – شریک GIS Cloud

استفاده از GIS Cloud خارج از جعبه ، برنامه نقشه برداری ابری را برای اکثر کاربران فراهم می کند که متناسب با تمام نیازهای تجاری آنها باشد. در حالی که همه پلتفرم‌ها محدودیت‌هایی برای عملکرد خود دارند، GIS Cloud به دلیل تمایل آن به ارائه فرصت‌های یکپارچه‌سازی از طریق REST API ، کتابخانه جاوا اسکریپت و پایگاه‌های داده خارجی تا حدودی منحصربه‌فرد است. پایگاه داده میزبانی شده در فضای ابری که با هر مجوز ویرایشگر نقشه گنجانده شده است بسیار راحت است تا داده های شما ایمن نگه داشته شوند، اما دسترسی به سرور پایگاه داده واقعی در دسترس نیست. محدودیت‌های ناشی از عدم دسترسی را می‌توان با پیکربندی GIS Cloud برای بازیابی مستقیم داده‌ها از یک سرور دور زد.

که میزبان و مدیریت می کنید، مانند AWS RDS برای PostGIS.

برخی از دلایلی که باعث می شود شما با این همه مشکل روبرو شوید عبارتند از:

• شما نمی خواهید یک پایگاه داده فضایی موجود از داده ها را به پایگاه داده GIS Cloud منتقل یا منعکس کنید
• سازمان شما از یک پایگاه داده فضایی موجود برای برنامه های کاربردی دیگر مانند QGIS یا Carto استفاده می کند (شاید افزونه QGIS یا GIS Cloud Map Portal را در نظر بگیرید )
• شما باید کنترل مستقیمی روی مکان میزبانی داده ها داشته باشید، مثلاً به دلایل انطباق
• شما از دسترسی مستقیم به پایگاه داده برای تسهیل یکپارچه سازی یا گزارش دهی استفاده خواهید کرد
• داده های مکانی شما دارای یک مدل داده است که برای کار با GIS Cloud بسیار پیچیده است
• می خواهید از Triggers/Views/Materialized Views برای تعامل با داده های خود استفاده کنید

اگر قصد دارید با یک پایگاه داده خارجی کار کنید، این مقاله می‌تواند نکاتی را در مورد آسان‌تر کردن این فرآیند به شما ارائه دهد.

محل

 

اولین توجه شما این است که پایگاه داده خارجی شما در کجا میزبانی می شود. هر بار که دو دستگاه نیاز به برقراری ارتباط دارند، تاخیر کوتاهی وجود دارد که به عنوان تاخیر شناخته می شود. هرچه هر دستگاه دورتر باشد، احتمال اینکه عملکرد کندتری را تجربه کنید بیشتر است.

سرورهای جهانی GIS Cloud بر روی AWS در منطقه در دسترس بودن “us-east-1” میزبانی می شوند . بنابراین، اگر بتوانید پایگاه داده خود را در آنجا میزبانی کنید، بهترین شانس برای تأخیر کم را خواهد داشت زیرا این دو سرور به هم نزدیک هستند. این نمودار تأثیری را که مسافت مسیر می تواند روی کاربر بگذارد را نشان می دهد.

اگر پایگاه داده موجود شما در محل ذخیره می شود  ،  ممکن است بخواهید میزبانی آینه ای را در AWS در نظر بگیرید تا مسیری را که GIS Cloud برای بازیابی داده ها طی می کند و در عین حال پایگاه داده “اولیه” خود را در محل نگهداری می کند، کوتاه کند. به جای این، شاید بهتر باشد برای عملکرد بهینه، داده های خود را مستقیماً به پایگاه داده GIS Cloud منعکس کنید . اگر به دلایل انطباق نیاز دارید که داده‌های خود را در جای دیگری میزبانی کنید، با GIS Cloud بررسی کنید زیرا نمونه‌هایی به صورت محلی در کشورهای دیگر وجود دارد. ما توانستیم با میزبانی داده ها در همان منطقه در دسترس بودن AWS به عنوان سرورهای GIS Cloud سرعت دسترسی MDC را تا ۱۰ برابر افزایش دهیم .

 

طرح واره جدول

 

هنگامی که GIS Cloud از طریق یک اتصال خارجی به جداول دسترسی پیدا می کند، سعی می کند با جداول مانند جداول در پایگاه داده GIS Cloud رفتار کند. از آنجایی که هیچ راهی برای اطلاع از جزئیات نحوه طراحی جدول خود در GIS Cloud وجود ندارد، بهتر است ساختار جدولی را که GIS Cloud استفاده می کند کپی کنید تا رفتار غیرعادی را تجربه نکنید.

اولین ملاحظه این است که ستون های هندسی باید به عنوان یکی از انواع اصلی ایجاد شوند (نقطه، رشته خط، چند ضلعی، یا چند نسخه از اینها). مشابه بیشتر کاربردهای GIS، لایه‌های GIS Cloud به یک نوع هندسه در هر لایه محدود می‌شوند.

پس از این، نام ستون هندسه خود را تنظیم می کنید. اگر ستون هندسه شما از آن استفاده می کند، پیش فرض PostGIS را بگویید“geom”، ستون در تعریف لایه شما به گونه ای نشان داده می شود که گویی یک ویژگی است. اگر از “__geometry” به عنوان نام استفاده کنید، این به طور خودکار توسط GIS Cloud پنهان می شود زیرا آن را به عنوان هندسه تشخیص می دهد.

برخی از ستون های اضافی برای گنجاندن در طرح جدول خود برای GIS Cloud عبارتند از: “__created”، “__modified” و “__owner” که همگی باید از نوع عدد صحیح بزرگ باشند. به طور مشابه، اگر ستون کلید اصلی شما “id” یا “__id” نام داشته باشد، آن را از کاربر پنهان می کند که می تواند مطلوب باشد.

بعدی انتخاب انواع داده است. GIS Cloud REST API و فرم هابا توجه به نوع داده هایی که می پذیرند کاملاً مجاز هستند. منظور من از این این است که اگر عددی را به GIS Cloud ارسال کنید و مقصد یک رشته باشد، مقدار را وادار به مطابقت می‌کند و خطاها را به حداقل می‌رساند. با این حال، هنگام پیکربندی طرح جدول خود ممکن است وسوسه شوید که در مورد انواع ستون خود بسیار سختگیر باشید. این می‌تواند باعث درگیری‌های غیرمنتظره شود زیرا GIS Cloud API تمام تلاش خود را برای کار با داده‌های شما انجام داده است، اما پایگاه داده مقدار وارد شده در فرم مجموعه داده‌های موبایل را رد کرده است.

یک مثال کلاسیک از این ممکن است تاریخ زمان باشد که می‌تواند فرمت‌های مختلفی داشته باشد، اما GIS Cloud با خوشحالی با تاریخ‌ها به‌عنوان رشته‌هایی کار  می‌کند و نیاز به اشکال‌زدایی خطاهای رمز و راز را از بین می‌برد .

مربوط به انواع داده ها، مسئله اضافه کردن یک محدودیت “NOT NULL” به ستون های شما است. این اغلب معقول است، اما اگر فرم GIS Cloud متصل به لایه با محدودیت های پایگاه داده شما هماهنگ نباشد، می تواند منجر به خرابی های غیرمنتظره شود. برای به حداقل رساندن مسائل غیرمنتظره، بهتر است فیلدهای مورد نیاز را در سطح فرم به جای پایگاه داده اعمال کنید.

در نهایت، مهم ترین مورد نیاز جدول اگر قصد دارید ویژگی های جدید را در جدول خارجی خود جمع آوری کنید. GIS Cloud نمی‌تواند به راحتی الزامات کلید اولیه را از جدول خارجی شما تعیین کند و بنابراین یک رویکرد دست‌آمیز را اتخاذ می‌کند. بنابراین، ستون Primary Key شما  باید به صورت خودکار افزایش/تولید متناسب با گویش SQL شما تعریف شود.

محرک ها/نماها/نماهای مادی شده، اوه من!

 

GIS Cloud از استفاده از Views برای دسترسی به جداول فضایی پشتیبانی می‌کند که می‌تواند راهی عالی برای “مسطح کردن” یک مدل داده پیچیده‌تر با استفاده از مجموعه‌ای از دستورات SELECT JOIN ON باشد. این بدان معناست که شما ممکن است یک جدول فضایی داشته باشید که دارای یک کلید خارجی برای پیوستن به جدول SQL دیگر باشد، که خود ممکن است یک کلید خارجی برای پیوستن به جدول دیگر داشته باشد. با یک نمای می توانید یک “جدول” ایجاد کنید که دارای ستون هایی از هر سه جدول برای نمایش در GIS Cloud باشد.

PostgreSQL، که اساس PostGIS است، دارای یک ویژگی منحصر به فرد از Materialized Views است. اینها دقیقاً مانند یک View هستند، اما نتیجه پرس و جوی SQL در پایگاه داده ذخیره می شود و باید به صورت دستی برای به روز رسانی فعال شود. مزیت این روش این است که می توانید شاخص های مکانی و غیر مکانی را تعریف کنیددر مشاهده نتایج که می تواند جستجو/بازیابی را سرعت بخشد .

همچنین راهی برای جدا کردن یک کپی “کار” از داده های GIS و یک نسخه “منتشر شده” ارائه می دهد. با این حال، GIS Cloud هنوز از این جداول پشتیبانی نمی کند، بنابراین برای دور زدن این موضوع باید یک View ایجاد کنید که از نمای Materialized انتخاب کند.

در نهایت، یکی از ویژگی های کلاسیک پایگاه های داده، Triggers است . اگر پایگاه داده خود را دارید، هیچ محدودیتی در اعمال تریگر ندارید. اما مراقب باشید که تأثیرات بالقوه عملکرد را در نظر بگیرید زیرا GIS Cloud هنوز نیاز به خواندن و نوشتن در پایگاه داده شما دارد و از این محرک ها آگاه نیست. هر چیزی که پاسخگویی به عبارت SELECT یا UPDATE را به تاخیر بیاندازد ممکن است بر عملکرد برنامه تأثیر منفی بگذارد.

بیوگرافی نویسنده

شرکای ما از استرالیا – شرکای فضایی در فناوری فضایی و اتوماسیون داده ها تخصص دارند. آنها راه حل هایی را برای چالش های داده پیچیده تعریف و طراحی می کنند و راه حل های خود را بر روی پلت فرم GIS Cloud ایجاد می کنند.

معمار اصلی آنها ، دکتر جاناتان استنگر، یکی از این راه حل ها را در ارائه ای که در ۱۲ مه در نمایشگاه جهانی نرم افزار ایمن FME 2021 برگزار شد، در جلسه ای با عنوان “جایی که رویاهای داده های شما به حقیقت می پیوندند” به نمایش گذاشت. او در مورد “ترفندهای جادویی برای رام کردن سیستم های خارجی وحشی با استفاده از تونل های SSH و تماس های HTTP با حجم بالا” صحبت کرد.

FME استاندارد طلایی برای ETL، ادغام و اتوماسیون مبتنی بر GIS است، اما هنگام کار با APIهای GIS مبتنی بر ابر مانند آنچه برای GIS Cloud در دسترس است، با مشکل مهمی مواجه می‌شود. با FME خارج از جعبه و GIS Clouds API ، ممکن است بیش از ۵ دقیقه برای به روز رسانی تنها ۱۰۰۰ ویژگی مواجه شوید.

این ارائه را تماشا کنید و بیاموزید که چگونه عملیات مشابه را به ۳۰ ثانیه کاهش دهید و اتوماسیون را از طریق FME و GIS Cloud ادغام کنید!