OSM2PGSQL(1) OSM2PGSQL(1)

osm2pgsql - مبدل داده‌های OpenStreetMap به PostgreSQL

osm2pgsql [OPTIONS] OSM-FILE...

دستور osm2pgsql داده‌های OpenStreetMap را به یک پایگاه‌داده‌ی PostgreSQL/PostGIS وارد می‌کند. این ابزار بخش حیاتی بسیاری از زنجیره‌های ابزار رندر، سامانه تبدیل نشانی به مختصات Nominatim و سایر برنامه‌های پردازش‌کننده‌ی داده‌های OSM است.

osm2pgsql می‌تواند در حالت “create” (پیش‌فرض) یا در حالت “append” (با گزینه -a, --append) اجرا شود.

در حالت “create”، دستور osm2pgsql جدول‌های پایگاه‌داده مورد نیاز پیکربندی را ایجاد کرده و فایل(های) OSM مشخص‌شده در خط فرمان را به درون این جدول‌ها وارد می‌کند. توجه داشته باشید که اگر می‌خواهید پایگاه‌داده شما قابلیت به‌روزرسانی داشته باشد، باید از گزینه -s, --slim نیز استفاده کنید.

در حالت “append”، دستور osm2pgsql جدول‌های پایگاه‌داده را با داده‌های حاصل از فایل‌های تغییرات OSM مشخص‌شده در خط فرمان به‌روزرسانی می‌کند.

این صفحه راهنما تنها برخی از مبانی اولیه را پوشش داده و گزینه‌های خط فرمان را شرح می‌دهد. برای اطلاعات بیشتر به راهنمای Osm2pgsql مراجعه کنید.

این برنامه از نحو معمول خط فرمان گنو پیروی می‌کند که در آن گزینه‌های طولانی با دو خط تیره (--) شروع می‌شوند. آرگومان‌های اجباری برای گزینه‌های طولانی، برای گزینه‌های کوتاه نیز اجباری هستند.

اجرا در حالت الحاق (append). فایل تغییرات OSM را بدون حذف داده‌های موجود به پایگاه‌داده اضافه می‌کند.
اجرا در حالت ایجاد (create). اگر -a, --append مشخص نشده باشد، این حالت پیش‌فرض است. داده‌های موجود در جدول‌های پایگاه‌داده را حذف می‌کند!

نمایش راهنما.
نمایش نسخه osm2pgsql.

تنظیم سطح گزارش‌گیری (debug، info (پیش‌فرض)، warn یا error).
فعال‌سازی (true) یا غیرفعال‌سازی (false) گزارش پیشرفت کار. تنظیم این گزینه روی auto گزارش پیشرفت را در کنسول فعال کرده و در صورت هدایت مجدد خروجی به یک فایل، آن را غیرفعال می‌کند. پیش‌فرض: true.
فعال‌سازی ثبت دستورات SQL جهت اشکال‌زدایی.
فعال‌سازی ثبت تمام داده‌های اضافه‌شده به پایگاه‌داده. این کار حجم عظیمی از داده تولید می‌کند! تنها برای اشکال‌زدایی.
مشابه با --log-level=debug.

نام پایگاه‌داده PostgreSQL جهت اتصال. اگر این پارامتر شامل علامت = باشد یا با یک پیشوند معتبر URI (postgresql:// یا postgres://) آغاز شود، به عنوان یک رشته conninfo در نظر گرفته می‌شود. برای جزئیات به راهنمای PostgreSQL مراجعه کنید.
نام کاربری PostgreSQL.
اجبار به درخواست گذرواژه.
نام میزبان کارساز پایگاه‌داده یا مسیر سوکت دامنه یونیکس (unix domain socket).
درگاه کارساز پایگاه‌داده.
طرح‌واره (schema) پیش‌فرض برای تنظیمات مختلف اسکیما در سرتاسر osm2pgsql (پیش‌فرض: public). این طرح‌واره باید در پایگاه‌داده وجود داشته باشد و توسط کاربر پایگاه‌داده قابل نوشتن باشد.

انتخاب قالب فایل ورودی. گزینه‌های موجود عبارتند از auto (پیش‌فرض) برای تشخیص خودکار قالب، xml برای فایل‌های قالب XML در OSM، o5m برای فایل‌های قالب o5m و pbf برای قالب دودویی OSM PBF.
اعمال فیلتر کادر احاطه‌کننده (bounding box) بر داده‌های واردشده. مثال: --bbox -0.5,51.25,0.5,51.75

ذخیره تمام نمایه‌ها (indexes) در فضای جدول (tablespace) به نام TABLESPC در PostgreSQL. این گزینه جدول‌های ایجادشده توسط خروجی pgsql را نیز تحت تأثیر قرار می‌دهد. این گزینه منسوخ شده است. به جای آن از گزینه‌های --tablespace-slim-index یا --tablespace-main-index استفاده کنید.
ذخیره جدول‌های حالت slim در فضای جدول مشخص‌شده.
ذخیره نمایه‌های جدول‌های حالت slim در فضای جدول مشخص‌شده.
پیشوند نام جدول‌ها (پیش‌فرض: planet_osm).
ذخیره داده‌های موقت در پایگاه‌داده. بدون این حالت، تمام داده‌های موقت در RAM ذخیره می‌شوند و اگر حافظه کافی نداشته باشید، فرآیند واردسازی با موفقیت انجام نخواهد شد. با حالت slim، باید بتوانید داده‌ها را حتی روی سامانه‌ای با RAM محدود وارد کنید؛ هرچند اگر RAM کافی برای کش کردن حداقل تمام گره‌ها نداشته باشید، زمان واردسازی داده‌ها احتمالاً بسیار طولانی‌تر خواهد شد.
حذف جدول‌های حالت slim از پایگاه‌داده و فایل flat node پس از اتمام فرآیند واردسازی. این کار می‌تواند اندازه پایگاه‌داده را به‌طور چشمگیری کاهش دهد، چرا که حجم جدول‌های حالت slim معمولاً برابر با جدول‌های اصلی و حتی کمی بزرگ‌تر از آن‌ها است. با این حال، اوج مصرف دیسک را در طول واردسازی کاهش نمی‌دهد. علاوه بر این می‌تواند سرعت واردسازی را افزایش دهد، زیرا دیگر نیازی به ساخت نمایه‌ها برای جدول‌های حالت slim نیست که (بسته به سخت‌افزار) می‌تواند زمان واردسازی را تقریباً نصف کند. با این وجود، اگر می‌خواهید پایگاه‌داده‌تان قابلیت به‌روزرسانی داشته باشد، جدول‌های حالت slim باید حفظ شوند، زیرا این جدول‌ها برای پردازش فایل‌های تغییرات (diff processing) ضروری هستند.
فقط برای حالت slim: استفاده از حداکثر NUM مگابایت حافظه RAM برای کش کردن گره‌ها. اختصاص کش کافی به osm2pgsql برای نگهداری همه گره‌های واردشده، معمولاً سرعت واردسازی را به‌شدت افزایش می‌دهد. هر گره کش‌شده به ۸ بایت حافظه به‌علاوه حدود ۱۰ تا ۳۰ درصد سربار (overhead) نیاز دارد. به عنوان یک قاعده کلی، مقداری کمی بیش از حجم فایل ورودی با قالب PBF اختصاص دهید. اگر حافظه RAM به‌اندازه کافی بزرگ نیست، حدود ۷۵٪ از حافظه را اختصاص دهید. مطمئن شوید که RAM کافی برای PostgreSQL باقی می‌گذارید؛ این برنامه حداقل به اندازه مقدار مشخص‌شده در تنظیمات shared_buffers خود نیاز دارد. پیش‌فرض: 800.
گنجاندن ویژگی‌های (attributes) هر شیء در جدول‌های میانی و در دسترس قرار دادن آن‌ها برای خروجی‌ها. ویژگی‌ها عبارتند از: نام کاربری، شناسه کاربری، شناسه مجموعه تغییرات (changeset id)، برچسب زمانی و نسخه.
استفاده از یک فایل روی دیسک برای ذخیره موقعیت مکانی گره‌ها به‌جای نگهداری آن‌ها در حافظه (در حالت غیر slim) یا در پایگاه‌داده (در حالت slim). این روش بسیار کارآمدتر از ذخیره داده‌ها در پایگاه‌داده است. ذخیره اطلاعات گره‌ها برای کل سیاره به بیش از ۵۰۰ گیگابایت فضا در PostgreSQL نیاز دارد، در حالی که همین داده‌ها با استفاده از حالت flat-nodes “تنها” در ۹۰ گیگابایت ذخیره می‌شوند. این کار همچنین می‌تواند سرعت اعمال فایل‌های diff را افزایش دهد. این گزینه حالت flat-nodes را فعال کرده و مسیر فایل پایگاه‌داده را تعیین می‌کند. این یک فایل منفرد بزرگ است. این حالت فقط برای واردسازی داده‌های کل سیاره توصیه می‌شود چرا که برای واردسازی‌های کوچک کارایی مناسبی ندارد. به‌طور پیش‌فرض غیرفعال است. این فایل پس از واردسازی روی دیسک باقی خواهد ماند؛ برای حذف آن از --drop استفاده کنید (اما در این صورت دیگر امکان به‌روزرسانی نخواهید داشت).
استفاده از طرح‌واره SCHEMA در PostgreSQL برای تمام جدول‌ها، نمایه‌ها و توابع در بخش میانی. طرح‌واره باید در پایگاه‌داده وجود داشته باشد و توسط کاربر پایگاه‌داده قابل نوشتن باشد. به‌طور پیش‌فرض از طرح‌واره تنظیم‌شده با --schema استفاده می‌شود، یا در صورت عدم تنظیم، از public.
هنگامی که از فایل flat nodes استفاده می‌شود، گره‌ها در پایگاه‌داده ذخیره نمی‌شوند. از این گزینه برای وادار کردن برنامه به ذخیره گره‌های دارای برچسب (tag) در پایگاه‌داده نیز استفاده کنید.

خروجی مورد استفاده را مشخص می‌کند. در حال حاضر osm2pgsql از گزینه‌های pgsql، flex و null پشتیبانی می‌کند. خروجی pgsql خروجی پیش‌فرضی است که همچنان برای سازگاری با نسخه‌های پیشین نگه‌داشته شده است. راه‌اندازی‌های جدید باید از خروجی flex استفاده کنند که امکان پیکربندی بسیار انعطاف‌پذیرتری را فراهم می‌کند. خروجی null هیچ داده‌ای نمی‌نویسد و فقط برای اهداف آزمایشی یا همراه با --slim جهت ایجاد جدول‌های slim کاربرد دارد.
فایل سبک (style). این گزینه نحوه واردسازی داده‌ها به پایگاه‌داده را مشخص می‌کند و قالب آن به خروجی بستگی دارد. (برای خروجی pgsql، پیش‌فرض /usr/share/osm2pgsql/default.style است؛ برای سایر خروجی‌ها مقداری پیش‌فرض وجود ندارد.)

ذخیره جدول‌های داده در فضای جدول TABLESPC در PostgreSQL.
ذخیره نمایه‌ها در فضای جدول TABLESPC در PostgreSQL.
ذخیره مختصات بر حسب درجه‌های عرض و طول جغرافیایی.
ذخیره مختصات در سیستم تصویر مرکاتور کروی (مرکاتور وب، EPSG:3857) (پیش‌فرض).
استفاده از سیستم تصویر با شناسه EPSG:SRID.
پیشوند نام جدول‌ها (پیش‌فرض: planet_osm). این گزینه بر نام جدول‌های بخش میانی و همچنین جدول‌های خروجی pgsql تأثیر می‌گذارد.
تعیین یک اسکریپت Lua برای پالایش و نرمال‌سازی برچسب‌ها. این اسکریپت شامل توابع بازخوانی (callback) برای گره‌ها، راه‌ها (ways) و رابطه‌ها (relations) است که هرکدام مجموعه‌ای از برچسب‌ها را دریافت کرده و مجموعه‌ای دگرگون‌شده و پالایش‌شده از برچسب‌ها را برمی‌گردانند که سپس در پایگاه‌داده نوشته می‌شوند.
گنجاندن ویژگی‌ها (نام کاربری، شناسه کاربری، شناسه مجموعه تغییرات، برچسب زمانی و نسخه). این کار نیازمند ورودی‌های اضافی در فایل سبک شما نیز هست.
اضافه کردن برچسب‌های فاقد ستون اختصاصی به یک ستون hstore اضافی (کلید/مقدار) در جدول‌های پایگاه‌داده.
اضافه کردن تمام برچسب‌ها به یک ستون hstore اضافی (کلید/مقدار) در جدول‌های پایگاه‌داده.
اضافه کردن یک ستون hstore اضافی (کلید/مقدار) با نام PREFIX شامل تمام برچسب‌هایی که کلید آن‌ها با PREFIX آغاز می‌شود؛ برای نمونه، \--hstore-column "name:" یک ستون hstore اضافی شامل تمام برچسب‌های name:xx ایجاد می‌کند.
تنها نگه‌داشتن اشیایی که حداقل در یکی از ستون‌های غیر hstore دارای مقدار باشند.
ایجاد نمایه برای تمام ستون‌های hstore پس از اتمام واردسازی.
به‌طور معمول osm2pgsql هندسه‌های چندبخشی را به سطرهای مجزای پایگاه‌داده به ازای هر بخش تقسیم می‌کند. بنابراین یک شیء OSM می‌تواند چند سطر را در جدول‌های خروجی اشغال کند. با استفاده از این گزینه، osm2pgsql در عوض عوارض چند‌هندسه‌ای (multi-geometry) را در جدول‌های PostgreSQL تولید می‌کند.
نگه‌داشتن داده‌های خط ساحلی به‌جای پالایش و حذف آن‌ها. به‌طور پیش‌فرض، اشیای دارای برچسب natural=coastline با این فرض که از Shapefileهای تولیدشده توسط OSMCoastline (https://osmdata.openstreetmap.de) برای داده‌های خط ساحلی استفاده خواهد شد، نادیده گرفته می‌شوند.
محاسبه ستون مساحت با استفاده از مختصات مرکاتور کروی، حتی اگر سیستم تصویر متفاوتی برای هندسه‌ها به کار گرفته شده باشد.
استفاده از طرح‌واره SCHEMA در PostgreSQL برای تمام جدول‌ها، نمایه‌ها و توابع در خروجی pgsql. طرح‌واره باید در پایگاه‌داده وجود داشته باشد و توسط کاربر پایگاه‌داده قابل نوشتن باشد. به‌طور پیش‌فرض از طرح‌واره تنظیم‌شده با --schema استفاده می‌شود، یا در صورت عدم تنظیم، از public.

ایجاد فهرست انقضای کاشی‌ها (tile expiry list).
نام فایل خروجی برای فهرست کاشی‌های منقضی‌شده.
حداکثر اندازه برای یک چندضلعی (polygon) جهت منقضی کردن کل چندضلعی، نه فقط مرزهای آن.

غیرفعال‌سازی خوشه‌بندی موازی و ساخت موازی نمایه در تمام جدول‌ها، و ساخت نمایه‌ها به‌صورت متوالی پشت سر هم.
تعیین تعداد ریسه‌های (threads) موازی مورداستفاده برای عملیات مشخص.

•
تارنمای osm2pgsql
•
راهنمای osm2pgsql
•
postgres(1)
•
osmcoastline(1)
2.3.1