أكثر

لماذا يُرجع gdalwarp إحداثيات زوايا غير صحيحة لميزة Geotiff الخاصة بي؟

لماذا يُرجع gdalwarp إحداثيات زوايا غير صحيحة لميزة Geotiff الخاصة بي؟


لدي صورة مصدر بتنسيق png موجودة في Lambert Azimuthal Equal Area ولدي المدى الطويل / العرض. لذلك قمت بتشغيل gdal_translate لإنشاء نقاط التعادل والتحويل إلى gtif. ثم قمت بتشغيل gdalwarp لإعادة طرحه على Web Mercator. يوضح gdalinfo أن الإحداثيات المحيطة مناسبة لإخراج gdal_translate ، ولكن ليس لإخراج gdalwarp. كيو باسا؟

ها هي عملية gdal_translate الخاصة بي على الملف المصدر:

gdal_translate -of GTiff -a_srs "+ proj = laea + lat_0 = 40. + lon_0 = -105 + x_0 = 0 + y_0 = 0 + a = 6370997 + rf = 298.257" ^ -gcp 0 0 -119.344674 47.148697 ^ -gcp 525 0 -90.655326 47.148697 ^ -gcp 525431 -93.609897 31.438244 ^ -gcp 0431 -116.390103 31.438244 ^ -a_ullr -119.344674 47.148697 -93.609897 31.438244 ^ src.png ">

السبب الذي يجعلك تحصل على قيم صغيرة جدًا هو أن صورتك الأصلية مُسقطة ، لذا فهي تستخدم وحدات خطية - والتي أعتقد في هذه الحالة PROJ4 أن القيم الافتراضية متر - بدلاً من الدرجات. إذن أنت تحدد مساحة تبلغ حوالي 680 مترًا مربعًا من غرب الولايات المتحدة.

الآن ، كيف يمكنك تحديد الإحداثيات الصحيحة لاستخدامها هو أمر صعب لأن صورتك تغطي مثل هذه المساحة الكبيرة ، ستحصل على الكثير من التشويه عند الحواف.

عذرًا ، هذا ليس حلًا كبيرًا - هل يهتم أي شخص آخر بتولي الأمر؟ إذا كان لدي وميض من الإلهام ، فسأنشره هنا.


الشكل 1. مثال على منطقة التغطية والمدى المكاني لنطاق أمريكا الشمالية لتنبؤات الدخان RAP. قريبًا إلى RealEarth.

أصيب العديد من الباحثين في علوم الأرض بالإحباط بسبب صعوبة رسم خرائط لمخرجات نموذج التحديث السريع (RAP) من NOAA & # 8217s المراكز الوطنية للتنبؤ البيئي (NCEP) في نظم المعلومات الجغرافية (نظم المعلومات الجغرافية). إليك & # 8217s الأخبار السارة: لدينا الآن طريقة للقيام بذلك بالنسبة لمجال أمريكا الشمالية بدقة 13.5 كم (الشكل 1) باستخدام المكتبات القياسية التي تم تحديثها مؤخرًا: PROJ v6.x و GDAL v3.x. لماذا هذا مهم؟ لأنه مع بدء البحث في علوم الغلاف الجوي في التقارب مع البحث في علوم الأرض ، لا تزال الحواجز التقنية أمام مشاركة البيانات موجودة والتي تمنع الابتكار والتعاون. هذا الحل يزيل أحد تلك الحواجز. إنه يمنح ممارسي نظم المعلومات الجغرافية طريقة للوصول إلى مخرجات النموذج من مجال أمريكا الشمالية لخطة عمل إعادة التوطين باستخدام أدواتهم في بيئة الحوسبة المألوفة لديهم. & # 8212 سام باتزلي ، CIMSS / SSEC ، جامعة ويسكونسن ماديسون

إعتراف

أنا & # 8217 لقد عملت على حل هذه المشكلة وإيقافها لعدة أشهر. وصلت إلى كيفين سامبسون في UCAR لأنني صادفت بعض التعليمات البرمجية التي كتبها لمحاولة معالجة هذه المشكلة. تبادلنا الأمثلة والاختبارات والأفكار في سلسلة من رسائل البريد الإلكتروني ، وفي كل مرة نقترب أكثر من الحل. لا يمكننا حل هذه المشكلة دون العمل معًا. نفس الشيء ينطبق على إريك جيمس، إحدى الشركات التابعة لـ NOAA في مختبر أبحاث نظام الأرض (ESRL) التي تشارك في وضع تنبؤات الدخان في مخرجات RAP (لا تزال البيانات الأولية تجريبية ولم يتم توزيعها علنًا بعد). لقد عرّفني على حزم البرامج wgrib2 و NCL (لغة أوامر NCAR) وقدم معلمات مجال غير منشورة أكدت حلنا النهائي.

خلفية

جاء دخولي إلى هذا اللغز عبر طلب من JPSS-PGRR (دليل إثبات نظام الأقمار الصناعية القطبي المشترك والحد من المخاطر) ، مبادرة الحريق والدخان لوضع تنبؤات الدخان بالساعة من نطاق RAP لأمريكا الشمالية الكامل في منصة التصور لدينا & # 8220RealEarth. & # 8221 & # 8220 لا مشكلة ، & # 8221 على الرغم من ذلك. & # 8220 سيكون الأمر سهلاً كما لو كان وضع توقعات الدخان HRRR CONUS التي كنا نقوم بها الآن لأكثر من عام. & # 8221 كنت مخطئًا. نشأت المشكلة من عدم التوافق الأساسي في وصف الإسقاطات الجغرافية عبر التخصصات الأكاديمية.

الطريقة التي يتم بها تحديد المدى والشكل الجغرافي لنطاق RAP الكامل لأمريكا الشمالية (المعروف أيضًا باسم & # 8220Arakawa E-network على شبكة خطوط الطول / العرض الدوارة & # 8221) في بيئة النمذجة هي إسقاط أسطواني متساوي البعد (أو لوحة Carrée) ، حيث تم تدوير الأرض (ممثلة كروية مثالية) جنوبًا بحيث يمكن رؤية القطب الشمالي ودائرة القطب الشمالي بأكملها بالإضافة إلى أجزاء من سيبيريا وشمال أوروبا وهاواي وحتى أجزاء من أمريكا الجنوبية أسفل خط الاستواء (انظر الشكل 1). لنمذجة الطقس ، هناك مزايا واضحة لاستخدام شبكة Arakawa. كما هو مذكور في مدخل Wikipedia الخاص به ، فإنه يوفر طريقة & # 8220 لتمثيل وحساب الكميات الفيزيائية المتعامدة (خاصة الكميات ذات الصلة بالسرعة والكتلة) على شبكات مستطيلة تستخدم لنماذج نظام الأرض للأرصاد الجوية وعلوم المحيطات. & # 8221 بينما لا يوجد شيء خطأ بطبيعته في تمثيل الأرض كشبكة متداخلة على كرة مستديرة ، فهي غير تقليدية في عالم الجيوديسيا والجغرافيا ونظم المعلومات الجغرافية. عادة ما ينشئ الجغرافيون في علوم الأرض خرائط مثل هذه بإسقاط سمتي متساوي البعد. يعمل نهج القطب المستدير (الذي يشير إليه الجغرافيون على أنه تحول مائل عام) بشكل جيد في بيئة النمذجة ، ولكن نادرًا ما يستخدمه الجغرافيون لأنه يعتمد على نموذج كروي للأرض (وليس الشكل الإهليلجي المفضل والأكثر دقة ، WGS84) ويتضمن تحولين (إسقاط أسطواني ودوران). إنه ببساطة لم يكن ولا يزال غير مدعوم بالكامل في معظم برامج نظم المعلومات الجغرافية. علاوة على ذلك ، فإن المجموعة الكاملة من المعلمات التي يحتاجها نظام المعلومات الجغرافية لوصف & # 8220Arakawa E-network على شبكة خطوط الطول / العرض المستديرة & # 8221 بدقة 13.5 كم ، فوق أمريكا الشمالية لم يتم نشرها في مكان واحد (حتى الآن). تخطي إلى الخطوات 4 و 5 و 6 إذا كنت تريد الانتقال مباشرة إلى الإجابات.

حزم البرامج والأدوات المستخدمة بشكل أكثر شيوعًا في علوم الغلاف الجوي مثل MATLAB ، ووحدة GEOGRID ضمن نظام المعالجة المسبقة لتوقعات أبحاث الطقس (WRF) ، ومشغلي البيانات المناخية (CDO) ، وأدوات رسم الخرائط العامة (GMT) ، و wgrib2 ، و NCL تقدم دعمًا جزئيًا أو داخليًا لإسقاطات القطب المستديرة. باستثناء MATLAB ، لا يتم استخدامها بشكل شائع في بيئات نظم المعلومات الجغرافية. ومما يزيد من تعقيد المشكلة استخدام تنسيقات تجميع البيانات الهرمية والمتعددة الأبعاد فائقة الكفاءة مثل GRIB2 و HDF و netCDF كتنسيقات إخراج البيانات من RAP والنماذج المماثلة. بينما يتحسن برنامج GIS في تحليل البيانات الوصفية لهذه التنسيقات ، فإنه يرسم فراغًا عند مواجهة إسقاطات وأوصاف غير قياسية للأرض ، مثل عمود مستدير. لذا ، إذا كنت تريد تراكب البيانات من شبكة RAP & # 8217s لأمريكا الشمالية على بيانات من نفس الموقع الجغرافي في نظام المعلومات الجغرافية دون تثبيت وتعلم مجموعة جديدة كاملة من الأدوات ، فليس الأمر بهذه السهولة.

لحسن الحظ ، يمكن لمزيج برامج التحويل من PROJ و GDAL الآن استيعاب فكرة & # 8220 القطب المدور. & # 8221 لسوء الحظ ، هناك حاجة إلى خطوات إضافية لترجمة معلمات القطب المستدير RAP مجال أمريكا الشمالية بعبارات مفهومة ومتوقعة بواسطة PROJ أو جدال. يصف الجزء المتبقي من هذا المنشور الخطوات التي اتخذناها لإنجاحها.

وصف الإسقاط بعبارات ملائمة لنظم المعلومات الجغرافية

هدفنا هنا هو إنتاج GeoTIFF بإسقاط محدد جيدًا يمكننا بعد ذلك إعادة طرحه في شيء يمكن لبرنامج رسم الخرائط GIS مثل QGIS و ArcGIS (المبني حاليًا على إصدارات أقدم من GDAL و PROJ) التعامل معه. لذلك حتى عندما نحدد GeoTIFF الناتج بشكل صحيح (وهو ما نقوم به في الخطوة 5 أدناه) ، فلن يعمل في GIS حتى تتضمن إصدارات البرامج المستقبلية أحدث إمكانات GDAL و PROJ. لذلك قمنا بتطبيق إسقاط إضافي في الخطوة 6 لجعل GeoTIFF متوافقًا مع الإصدارات السابقة.

الخطوة 1: الحصول على بعض الأمثلة على البيانات

نحتاج أولاً إلى مجموعة بيانات نموذجية للعمل معها. تتوفر بيانات نموذج RAP المتاحة للجمهور هنا: ftp://ftpprd.ncep.noaa.gov/pub/data/nccf/com/rap/prod/rap.<yyyymmdd>/ (استبدل اليوم & # 8217s تاريخ لـ & ltyyyymmdd & gt أو تصفح للوصول إلى دليل من اختيارك). أوصي بتسجيل الدخول باستخدام & # 8220user: anonymous & # 8221 and & # 8220password: & lty your email & gt & # 8221 باستخدام عميل FTP مثل FileZilla أو أداة سطر أوامر مثل wget أو curl للحصول على مثال لمجموعة البيانات. نظرًا لأن البيانات النموذجية التي نريدها بتنسيق GRIB2 الثنائي ، تأكد من التنزيل مع ضبط نوع النقل على & # 8220binary. & # 8221 إذا كنت تتصفح في FileZilla ، فستلاحظ العديد من الملفات في دليل & # 8220prod & # 8221. يرتبط معظمها بشبكات AWIPS محددة (نظام برمجي مغلق تستخدمه خدمة الطقس الوطنية). هذه الملفات هي مجموعات فرعية من نطاق أمريكا الشمالية الكامل ، عادةً في إسقاط لامبرت المخروطي المطابق القياسي الذي سيعمل بالفعل في GIS لأن معلمات الإسقاط الخاصة بهم يمكن التعرف عليها بواسطة GIS ، ولكن ما نريده هو ملف مثال لنطاق RAP الكامل مع النمط & # 8220rap.t06z.wrfprsf02.grib2 & # 8221. ترجمة اسم الملف هذا & # 8230 & # 8220rap & # 8221 هو اسم تنفيذ النموذج & # 8220t06z & # 8221 يرمز إلى إخراج الخطوة الزمنية للساعة للنموذج الذي يتم تشغيله في UTC / Zulu (هناك 21 خطوة زمنية مدتها ساعة واحدة في كل منهما يرمز طراز run & # 8220wrfprs & # 8221 إلى إخراج نموذج WRF بمستويات ضغط ، تتألف أساسًا من مجموعة عمودية من مستويات الارتفاع ، من نطاق أمريكا الشمالية لمعظم المتغيرات & # 8220f02 & # 8221 تعني الساعة بالتوقيت العالمي المنسق للتشغيل المتوقع (يتم تشغيل النموذج كل ساعة) و & # 8220grib2 & # 8221 هو تنسيق الإخراج.

لقد اختبرت هذه المنهجية فقط على الملفات العامة المذكورة أعلاه وملفات GRIB2 التجريبية التي لم يتم نشرها بعد والتي تحتوي على متغيرات إضافية مثل الدخان السطحي والدخان المتكامل للعمود. من الناحية النظرية ، سيعمل هذا النهج مع جميع ملفات إخراج GRIB2 للشبكة الإلكترونية المتداخلة & # 8220Arakawa على شبكة خطوط الطول / العرض المستديرة & # 8221 بدقة 13.5 كم ، مجال أمريكا الشمالية الكامل مع ملفات إخراج GRIB2.

الخطوة 2: E Pluribus Unum & # 8211 قراءة البيانات الوصفية واستخراج TIFF

أولاً ، دع & # 8217s نرى ما لدينا. سيعطينا تشغيل gdalinfo على الملف الذي تم تنزيله حديثًا ملخصًا. تأكد من تشغيل أحدث إصدار (أو 3.0 أو أعلى) من أدوات GDAL. لن تتمكن الإصدارات السابقة من قراءة ملفات GRIB2 هذه.

الآن قم بتشغيل gdalinfo باستخدام العلامة -proj4 (تم تعليق proj في الإصدار 4 لفترة طويلة حتى أصبح جزءًا من الاسم لفترة من الوقت). سيبدو الجزء العلوي من الإخراج كما يلي:

لذا فكر في هذا على أنه مكعب بيانات به طبقات بيانات متعددة تمثل خطوة زمنية واحدة لإخراج التنبؤ: أربعة أبعاد (خط العرض وخط الطول والارتفاع والوقت). هذا هو جمال GRIB2. إنها طرق فعالة للغاية لتنظيم وتخزين ونقل الكثير من المعلومات. مثل تنسيقات البيانات العلمية الهرمية الأخرى مثل HDF و NetCDF ، فهي في الأساس قاعدة بيانات ملفات قائمة بذاتها وتصف نفسها بنفسها. تكمن صعوبة GRIB2 في حالة & # 8220wrfprs & # 8221 والمجال الكامل لأمريكا الشمالية ، في أنك حتى الآن تحتاج إلى برامج متخصصة مشتركة فقط في علوم الغلاف الجوي لفتحها. ومع ذلك ، من وجهة نظري المبتدئ ، يحتاج المرء إلى حزام أسود حقيقي في برنامج wgrib2 أو NCL للحصول على أي شيء ذي معنى. هدفي هو السماح للأشخاص في علوم الأرض باستخدام أدوات مألوفة لديهم والتي تعد جزءًا من سير العمل للوصول إلى مجموعات البيانات المهمة هذه.

من الأمر & # 8220gdalinfo & # 8221 أعلاه ، لدينا الآن تعريف للكرة المستخدمة في هذا الإصدار من النموذج: & # 8220 + proj = longlat + a = 6371229 + b = 6371229 + no_defs & # 8221 (& # 8220 + a & # 8221 هو نصف القطر الاستوائي و & # 8220 + b & # 8221 هو نصف القطر القطبي & # 8212 لأن هذه كرة ، هذا هو نفسه + R = 6371229 ، & # 8220 + no_defs & # 8221 يوجه PROJ بعدم التعيين القيم الافتراضية للمتغيرات غير المحددة). يمكننا أيضًا أن نرى أن & # 8220Size هو 953 ، 834 & # 8221. هذه هي أبعاد البكسل لطبقات البيانات النقطية في العرض والارتفاع. بخلاف ذلك ، لا تعطينا gdalinfo أي شيء يسمح لنا بوضع هذا في الفضاء الجغرافي. على سبيل المثال ، لا يتعرف gdalinfo على وجود إحداثيات الزاوية ، وبالتالي لا يمكنه حساب حجم البكسل (الدقة المكانية) في ملف GRIB2 ذو القطب المستدير هذا. لذلك لا يمكن تعيين هذه البيانات ببساطة بواسطة برامج GDAL / PROJ و GIS كما هي. سيتعين علينا اللجوء إلى أدوات wgrib2 أو NCL للمساعدة في جمع المزيد من المعلمات من ملف GRIB2.

حقيقة ممتعة: الوحدة [& # 8220 درجة & # 8221،0.0174532925199433]] هي التعريف القياسي للدرجة. يتم حسابها بقسمة Π (باي) على 180 راديان.

إذا قمت بتشغيل الأمر gdalinfo أعلاه ، فلا شك أنك لاحظت أن هناك 779 & # 8220Bands & # 8221 أو مجموعات بيانات داخل ملف GRIB2 ، وكان عليك التمرير احتياطيًا عبر جميع 11.730 سطرًا للوصول إلى الجزء العلوي من الإخراج فقط لرؤية معلومات المعلومات العامة أعلاه. هذا & # 8217s الكثير من المعلومات. دع & # 8217s نبسط. من بين كثيرين العصابات ، دع & # 8217s استخراج واحد كمشغل TIFF لمعرفة كيف يبدو. باستخدام اقتراح من Kevin Sampson ، سنقوم باستخراج المتغير & # 8220TSOIL & # 8221 (درجة حرارة التربة) لأنه على عكس المتغيرات الأخرى مثل السحب أو الرياح ، يُظهر TSOIL ميزات جغرافية ثابتة وعناصر خط ساحلي كافية يمكننا أن نرى ما نعمل معه بينما نحاول تحويل هذه البيانات إلى واقع جغرافي. من gdalinfo أعلاه ، نجد أن TSOIL يقع في النطاق 628. الآن دع & # 8217s يستخرج TIFF (أنا & # 8217m أعطيها الاسم & # 8220unnav & # 8221 لأنه & # 8220un-navigated & # 8221 وهو مصطلح جوي يستخدم العلماء وعلماء الأرصاد الجوية للإشارة إلى عدم وجود نظام إحداثيات جغرافي أو تحديد المعلومات ، أو عدم التنقل فيها أو فقدها. قد يقول الجغرافيون أنه & # 8220 ليس محددًا جغرافيًا & # 8221).

نحصل على نطاق واحد ، ونقطة عائمة 64 بت TIFF. بعد اللعب بالتباين والقياس في Photoshop والتحويل إلى ملف PNG صديق للويب ، يبدو الأمر كما يلي (الشكل 2):

الشكل 2: الناتج الخام من RAP North American Domain. لاحظ أن الشمال والجنوب ينقلبان.

ربما يكون أول ما نلاحظه هو أن هذه صورة طبق الأصل لما كنا نتوقعه لنطاق أمريكا الشمالية كما هو موضح في الشكل 1. يوضح موقع جرينلاند والخطوط العريضة الباهتة لساحل أمريكا الشمالية أن البيانات بها & # 8220 جنوبًا -up & # 8221 بدلاً من & # 8220 شمال-أعلى & # 8221 اتجاه. إنه غير تقليدي ، ولكنه ليس & # 8220 خاطئ ، & # 8221 في حد ذاته. لا حكم. نحن فقط نلاحظ ذلك ونعود إلى المدونة بلطف لطيف. يمكننا أن نجد الفرح والامتنان في الأبعاد والشكل العام. هذه تبدو جيدة. دع & # 8217s اضغط على.

الخطوة 3: عصر الماء من الحجر & # 8211 الحصول على معلمات إضافية

نحن بحاجة إلى مزيد من المعلومات. لتعريف هذا الإسقاط بمصطلحات PROJ ، سنستخدم تحويلًا مائلًا عامًا لإسقاط أسطواني متساوي الأبعاد قائم على الكرة. يبدو أمر التحويل الذي نريد استخدامه كما يلي: & gtproj + proj = ob_tran + o_proj = eqc + o_lon_p =؟ + o_lat_p =؟ + lon_0 =؟ + R = 6371229. لذلك ، في هذا الجزء ، نحتاج إلى معرفة موقع القطب الجديد (+ o_lon_p =؟ + o_lat_p =؟) وخط الطول المركزي للخريطة الناتجة (+ lon_0 =؟). لجعل ناتجنا نقطية ، سنحتاج أيضًا إلى خط عرض مركز الإسقاط ونقاط الزاوية. لذلك من أجل تعريف كامل لهذه الشبكة بتنسيق مناسب لنظام المعلومات الجغرافية ، نحتاج إلى ما لا يقل عن عشرة معلمات (بما في ذلك الإصدار الثاني من خط طول مركز الإسقاط الذي سنتحدث عنه لاحقًا). من هذه ، سنتمكن من إنشاء GeoTIFF متوافق مع GIS:

  • نوع التحويل: + proj = ob_tran
  • نوع الإسقاط الأولي. + o_proj = مكافئ
  • نصف قطر كرة الإسقاط + R = 6371229
  • أبعاد البكسل للخطوط النقطية: -أحجام 953834
  • خط طول القطب الجديد: + o_lon_p =؟
  • خط عرض القطب الجديد: + o_lat_p =؟
  • خط طول مركز الإسقاط: + lon_0 =؟ (مصدر)
  • خط طول مركز الإسقاط: + lon_0 =؟ (استهداف)
  • خط عرض مركز الإسقاط: + lat_0 =؟
  • نقاط الزاوية (أعلى اليسار ، أسفل اليمين) بالوحدات المسقطة (بالمتر): -a_ullr ulx؟ uly؟ lrx؟ يضحك؟

بعد البحث المكثف على الإنترنت والتشاور كثيرًا مع إريك جيمس ، حصلت على نقاط الزاوية التي بدت معقولة. لكنني أردت تأكيد ذلك ولدي طريقة أكثر موثوقية للحصول على هذه المعلومات. بناءً على اقتراح Eric & # 8217s ، التفت إلى NCL وأداة تسمى & # 8220ncl_filedump & # 8221 (مع الخيار -c لمعلومات الإحداثيات) ، لتفريغ المزيد من البيانات الوصفية حول هذا المجال للحصول على المعلمات الأربعة المتبقية التي تصف قالب شبكة القطب المستدير . عند القيام بذلك ، أحصل على ما يلي:

الآن لدينا نقاط زاوية رسمية في خطوط الطول والعرض. كأزواج خطوط الطول / العرض لدينا أربع نقاط: 1) -139.0858 -10.5906، 2) -72.91415 -10.5906، 3) 22.66102 46.59194، 4) 125.339 46.59194.

الخطوة 4: المعجزات والتفكير السحري & # 8211 المنطق والحظ & # 8211 المحاولة والخطأ

مع الإسقاط المائل ، من الصعب معرفة النقطة التي تذهب إلى أين ما لم ترسمها كما في الشكل 3. نحن هنا نستخدم Azimuthal Equidistant (محدد بواسطة + proj = aeqd + lat_0 = 54 + lon_0 = -106 + x_0 = 0 + y_0 = 0 + a = 6371229 + b = 6371229 + الوحدات = m + no_defs) كتقريب للقطب المستدير لمجال أمريكا الشمالية ، فقط لاختبار نقاط الزاوية والمركز. هنا & # 8217s ما نراه في QGIS: LL) -139.0858 -10.5906، LR) -72.91415 -10.5906، UR) 22.66102 46.59194، UL) 125.339 46.59194 مركز) -106 54

الشكل 3. تعيين نقاط الزاوية والوسط في إسقاط تقريبي (Azimuthal Equidistant) يساعد في تحديد أي نقطة ، من حيث الأعلى ، والسفلي ، واليسار ، واليمين.

للحفاظ على سلامتنا العقلية أثناء الغوص في الواقع المجرد ، من المفيد استخدام التفكير السحري والنظر في هذه المعلمات من حيث & # 8220 حالة المصدر ، & # 8221 أو كيفية تعيين البيانات محليًا (الشكل 2) و & # 8220 حالة الهدف ، & # 8221 أو كيف يظهر في النهاية على الخريطة المسقطة (الشكل 1). تبدو النقاط رائعة على الخريطة في الشكل 3 ، ولكننا نعلم أن بياناتنا مقلوبة ، لذلك نحتاج هنا إلى وصف حالة المصدر في المصطلحات المستهدفة وعكس خطوط العرض ، أو قيم y (فقط). أعلى اليسار يصبح أسفل اليسار ، وأعلى اليمين يصبح أسفل اليمين مثل هذا: UL) -139.0858 -10.5906 ، LR) 22.66102 46.59194

يتم إعطاء مركز خط الطول 254 ويستخدم نموذجًا 360 درجة للعالم بدلاً من النموذج الأكثر تقليدية من -180 إلى 180 حول خط الطول الرئيسي أو & # 8220Greenwich. & # 8221 طرح 360 من 254 يعطينا الشكل الأكثر دراية -106 (غرب) ، والتي تعتبر مع 54 (شمالًا) منطقية كنقطة مركزية لحالتنا المستهدفة عندما ننظر إلى الشكل 3. للحصول على مركز الإسقاط عند 54 درجة شمالًا بدلاً من خط الاستواء (سيكون هذا هو خط العرض المركزي لـ الإسقاط الأسطواني غير المدور) ، علينا تدوير الأرض داخل تلك الأسطوانة إلى الجنوب بمقدار 36 درجة (90-36 = 54). استمرارًا لتفكيرنا السحري ، نشك في أن نموذج خط العرض يستخدم 180 بدلاً من النموذج التقليدي -90 إلى 90 وفي حالة المصدر المقلوب ، ندرك أن خط عرض القطب الشمالي في هذا النموذج هو 0 ، وخط الاستواء هو 90 و القطب الجنوبي 180. بما أن خط العرض للقطب يدور بمقدار 36 درجة ، فلنفترض & # 8217 ثانية طرح 36 من 180 ، بالتناوب 36 درجة شمالًا من القطب الجنوبي (180-36 = 144). نظرًا لأننا لا نريد تدوير القطب شرقًا أو غربًا ولا نعرف ماذا نفعل به ، فإننا نضع ثقتنا في قوتنا الأعظم ونترك المصدر & # 8220New pole longitude & # 8221 عند 180 عام ، مع الرغبة في تغييره إلى نوع عام آخر مثل 0 أو 360 إذا لزم الأمر. لم يكن ذلك ضروريا. هذه هي المعلمة الغامضة الوحيدة التي لا أستطيع شرحها. 180 هو الشيء الوحيد الذي يبدو أنه يفعل الحيلة في الأرض المقلوبة. ربما تم تعريف القطب الجنوبي الأصلي على أنه 180 ، 180 ، وبما أننا نقوم فقط بتدوير مائل ، فإن خط الطول التعسفي هذا (نظرًا لأن أي خط طول صالح لقطب الكرة) يظل كما هو. أرحب بالتفسيرات المقترحة. من خلال مراسلاتي مع إريك جيمس ، يمكنني أن أؤكد أن القيمة المعينة لتلك المعلمة في ملف بدء تشغيل إدخال النموذج هي التي تطلق RAP. [تنبيه المفسد لخط طول المصدر لمركز الإسقاط: 74! حاولت استخدام Center Longitude كـ -106 ، لكنه لم يعمل & # 8217t. حاولت استخدام 254 وهذا لم يعمل أيضًا. لقد لاحظت أنه في إحدى رسائل البريد الإلكتروني التي تبادلناها ، كان زميلي كيفن سامبسون يحاول استخدام الرقم 74 وتوقع أن نموذج خط الطول ربما يصل إلى 360 في الاتجاه الآخر (& # 8230 نظرًا لأن البيانات مقلوبة ، فإن ذلك يجعل حمولات القوارب منطقية: 254-180 = 74). لكن إذا لم & # 8217t لاحظت ما جربه كيفن ، فأنا أشك في أنني كنت سأفكر في هذا ولن تكون مشاركة المدونة هذه موجودة.]

إذن لدينا الآن جميع المعلمات العشر ، معًا في مكان واحد:

  • نوع التحويل: + proj = ob_tran (مصدر)
  • نوع الإسقاط الأولي. + o_proj = مكافئ (مصدر)
  • نصف قطر كرة الإسقاط + R = 6371229 (المصدر)
  • أبعاد البكسل للخطوط النقطية: - حجم 953834 (الهدف)
  • خط طول القطب الجديد: + o_lon_p = 180 (المصدر)
  • خط عرض القطب الجديد: + o_lat_p = 144 (المصدر)
  • خط طول مركز الإسقاط: + lon_0 = 74 (مصدر)
  • خط طول مركز الإسقاط: + lon_0 = -106 (هدف)
  • خط عرض مركز الإسقاط: + lat_0 = 54 (الهدف)
  • نقاط الزاوية (أعلى اليسار ، أسفل اليمين): -a_ullr -6448701.88 -5642620.27 6448707.45 5642616.94 (المصدر)

& # 8220 ولكن انتظر ، & # 8221 تسأل ، & # 8220 كيف حصلت على نقاط الزاوية من lon / lat إلى x / y متر؟ & # 8221 سؤال جيد! قمنا بتحويل النقاط باستخدام PROJ مع معلمات الإسقاط الأخرى & # 8230 وتمهيد قليل & # 8230 وبعض التخمين & # 8230 وبعض التفكير السحري. بكلماتها الخاصة ، & # 8220PROJ هو برنامج تحويل إحداثيات عام يقوم بتحويل الإحداثيات الجغرافية المكانية من نظام مرجعي إحداثي (CRS) إلى آخر. وهذا يشمل الإسقاطات الخرائطية وكذلك التحولات الجيوديسية. يتضمن PROJ تطبيقات سطر أوامر لتحويل الإحداثيات بسهولة من ملفات نصية أو مباشرة من إدخال المستخدم. & # 8221 إنه جزئيًا ما يستخدمه GDAL ، والأعمال الداخلية للعديد من أنظمة GIS ، لمعالجة البيانات النقطية ، بكسل تلو الآخر. يمكننا استخدام تطبيق سطر الأوامر لنقاط الزاوية الفردية الخاصة بنا.

لقد وجدت أيضًا أنه يمكنني استخدام هذا كطريقة لاختبار وضبط العديد من معلمات التحويل الموضحة أعلاه. في عملية إيجاد حل لنقطة المركز ، قمت بشكل أساسي بعكس هندسة المنطق الذي أنتج معلمات القطب وخط العرض وخط الطول أعلاه. اختبرت مجموعات مختلفة من المعلمات باستخدام التحويل المائل العام. ما أفهمه هو أن الإسقاط الأسطواني متساوي البعد بشكل عام يرسم خريطة الكرة الأرضية التي تتمركز في lon / lat 0،0 على مربع ثنائي الأبعاد بوحدات من الأمتار مع أصل ديكارتي 0،0 ويمتد إلى الخارج مع +/- شمالًا على المحور ص و +/- شرقاً على المحور السيني. لذلك ، توقعت أن نقطة المركز الصحيحة لهذا الإسقاط المستدير ستكون 0،0 أيضًا. تبين أن هذا كان تخمينًا مهمًا لمنطق الحظ. بعد الكثير من المحاولة والخطأ ، ها هي الأوامر والنتائج:

إنه لأمر رائع حقًا أن يتعرف GDAL 3.x على التحويل المائل العام الذي يصفه PROJ ويعالج ذلك. أعتقد أنه بمرور الوقت سيكون لهذا تأثير كبير على قابلية التشغيل البيني للبيانات والتعاون عبر علوم الأرض والغلاف الجوي.

الخطوة 5: استخرج GeoTIFF من GRIB2 وقم بتطبيق تعريف الإسقاط

لذلك يتم تجميع كل هذا في أمر & # 8220gdal_translate & # 8221. ربما يجب أن أضع هذا في الأعلى.

الخطوة 6: إعادة طرح للتوافق مع الإصدارات السابقة مع GIS

هذه الخطوة ضرورية فقط حتى يشتمل برنامج GIS على GDAL 3.x و PROJ 6.x. أنا & # 8217m باختيار الإسقاط السمتي متساوي البعد المتمركز حول -106 ، 54 كما في الشكل 3 حتى نتمكن من الإعجاب بإسقاط مماثل في QGIS.

تبدو النتيجة النهائية على هذا النحو (الشكلان 4 و 5) وتظهر ملاءمة ممتازة للأرض الطبيعية 1: 10 م & # 8220Admin 0 - البلدان. ​​& # 8221 حان الوقت لإسقاط البالونات!


مساعدة geoTIFF

المعلومات الجغرافية:
النسخة 1
Key_Revision: 1.0.0 تحديث
معلومة_موسومة:
ModelTiepointTag (2،3):
0 0 0
-87.1435563 1.47207446 0
ModelPixelScaleTag (1،3):
8.97580174e-006 8.97580174e-006 0
End_Of_Tags.
معلومات_مفتاح:
GTModelTypeGeoKey (قصير ، 1): ModelTypeGeographic
GTRasterTypeGeoKey (قصير ، 1): RasterPixelIsArea
GeographicTypeGeoKey (قصير ، 1): GCS_WGS_84
GeogCitationGeoKey (Ascii، 7): & quotWGS 84 & quot
GeogAngularUnitsGeoKey (قصير ، 1): Angular_Degree
End_Of_Keys.
End_Of_Geotiff.

GCS: 4326 / WGS 84
المرجع: 6326 / النظام الجيوديسي العالمي 1984
الإليبسويد: 7030 / WGS 84 (6378137.00،6356752.31)
خط الطول الرئيسي: 8901 / غرينتش (0.000000 / 0d 0 '0.00 & quotE)

إحداثيات الزاوية:
أعلى اليسار (87d 8'36.80 & quotW ، 1d28'19.47 & quotN)
أسفل اليسار (87d 8'36.80 & quotW ، 1d22 '2.05 & quotN)
أعلى اليمين (87d 3'25.34 & quotW ، 1d28'19.47 & quotN)
أسفل اليمين (87d 3'25.34 & quotW ، 1d22 '2.05 & quotN)
المركز (87d 6 '1.07 & quotW ، 1d25'10.76 & quotN)

إنه ليس على الإطلاق حيث يحتاج إلى تحويله إلى wgs84 وإعادة تشكيله. يجب أن يكون حوالي 34 شمالاً و 93 واط. أي خطأ ارتكبت ؟


FSXA تصدير GeoTIFF خطوط الطول / العرض

ربما أنت على حق. لقد فعلت ذلك على النحو المقترح ، وتقوم عملية إعادة العينة حاليًا بتجميع الخلايا (6437 منها). كان بالتأكيد أكثر بساطة مما كنت أعتقد.

ومع ذلك ، ما زلت في حيرة من أمرنا بشأن سبب تشويه إعادة الإسقاط في Global Mapper ، ولماذا لا يتعرف SBX على البيانات الموجودة في ملف .prj ، ولماذا يعتقد SBX أنني لم أختر أي عناصر للتصدير.

سوف أتحقق من هذه الإجابات بافتراض أن طريقتك الأبسط تنجز المهمة. شكرا لمساعدتي.

هذا ينطبق على أي شخص كان لطيفًا بما يكفي للرد هنا أيضًا: شكرًا لك!

كاك 911

تم تجميعها بشكل جيد وتم تنشيطها في FSX ، لكن. كلها حمراء. يبدو مثل المريخ. أي فكرة عما هذا؟

سكوت 967

في GM ، يجب عليك حفظه على أنه 24 بت ، وأعتقد أنه يتم تعيينه افتراضيًا على لوحة 8 بت ، هل قمت بفحص ذلك؟

هكورنيا

من تجميع التصوير الضوئي للذاكرة داخل SBX يتم تنفيذه فقط لملفات BMP.

أميل إلى استخدامه كخلفية لبيانات المتجه فقط ، وأجمع البيانات يدويًا في ملف inf.

يتم تجريد البيانات الوصفية بواسطة Photoshop وما شابه على أي حال ، لذلك هذا مهم لسير العمل الخاص بي.

لم أضطر إلى تحويل Datum ، حيث كانت جميع صوري موجودة في WGS84. وعلى هذا النحو لم يواجه SBX أبدًا صعوبة في قراءة البيانات الوصفية من ملفات Globalmapper Exported.

أعتقد أنه من الطبيعي أنه لن يقوم بتجميع الصور الفوتوغرافية لك.

احصل على المعلومات وقم بقصها / لصقها في ملف inf.

كاك 911

أتذكر رؤية هذا الخيار ، وأعتقد أنني تركته في الإعداد الافتراضي. سأعود وأجرب خيار 24 بت. شكرا على اقتراحك.

تشير وثائق SBX إلى عدة إشارات إلى تنسيق geoTIFF ، لكنني أفترض أن ذلك قد يكون من الأشياء القديمة. لكي نكون صادقين تمامًا ، تبدو طريقة .inf باستخدام Resample أسهل على أي حال. ربما سأستمر في استخدام SBX للقيام بحركة المرور وبعض ميزات المتجهات الأخرى ، على الرغم من ذلك.

كاك 911

أردت فقط إخبارك أن خيار التصدير 24 بت في Global Mapper أصلح مشكلة قناة RGB. كل شيء في sim وتبدو جميلة.

سكوت 967

من الجيد أن تسمع. يمكن لجنرال موتورز أيضًا أن تحصل على مارك ألماني يعمل بنفس السهولة. فقط قم بالتصدير كإرتفاع جغرافي 16 بت.

كاك 911

لدي مشكلة جديدة ، لكنني لم أعتقد أنني يجب أن أبدأ منشورًا جديدًا بالكامل.

Resample يستوعب GeoTiff الخاص بي ، ولدي مساحة ضوئية لطيفة بدقة 1 قدم لمطاري في FSX. لكن.

أنشأت 3ds Max الخاصة بي المدارج والممرات لا تصطف بشكل صحيح. أعلم أن الإجابة الواضحة ستكون أنني ببساطة فعلت شيئًا خاطئًا في Max ، لكنني تحققت عدة مرات ولم أجد أي أخطاء.

لقد أنشأت أعمدة الأرض باستخدام نفس الصور التي قمت في النهاية بإعادة تشكيلها في FSX كخلفية لي. في Max 8 ، يتراكب بشكل مثالي ، لكن في FSX ، لا يتم ترتيب الأشياء بشكل جيد على الإطلاق. إذا قمت بإصلاح أحد طرفي المدرج ، فسيكون الطرف الآخر بعيدًا بمقدار 10 أقدام تقريبًا. لا يوجد قدر من تدوير نموذجي سيصلحه ، على ما يبدو.

يبدو الأمر كما لو أن الصورة (في FSX) ممتدة قليلاً ، لذا فإن الخطوط المتوازية لم تعد متوازية. إنه خفي للغاية ، لكن الأطراف المقابلة لمدرج يبلغ طوله 11000 قدم تبعد حوالي 10 أقدام.

لدي شعور واضح بأن هذا يتعلق بإعادة الإسقاط الذي قام به مخطط الخرائط العالمي على صوري. نظرت في SDK وحاولت العبث بإعدادات xDim و yDim ، لكن لا يبدو أنها تحدث أي فرق.

كيف يمكنني التغلب على هذا؟ لا يبدو تغيير أطوال مدارج Max 8 الخاصة بي إلى قيم أخرى غير أطوال العالم الحقيقي كحل بالنسبة لي ، لذلك يترك لي تصحيح الصور أو تغييرها.

هل يجب تجريد معلومات الإسناد الجغرافي من TIF وتحديد المحارف الخاصة بي يدويًا في ملف .inf؟ كيف سيبدو شكل ملف .inf؟

كنت آمل في استخدام ميزة Gridding في Global Mapper لمحاولة إزالة بعض الصور الإضافية حول حواف منطقة التصدير الخاصة بي. خلاف ذلك ، سيكون لدي الكثير من المساحة البيضاء المتبقية بعد صنع قناع ألفا الخاص بي. ناهيك عن أنني أريد أن أخفض من استبعاد autogen.

ولكن إذا تلاعبت ببيانات الزاوية الخاصة بـ & quotmain & quot Tiff ، كيف يمكنني إدارة جميع المربعات التي أريد إنشاؤها؟

آسف للعديد من الأسئلة ، وأنا أقدر أي فكرة قد تكون لديكم يا رفاق.

سكوت 967

أشك نوعًا ما في أن إخراج بيانات georef من Geotiff سيغير أي شيء ، ما لم يكن هناك خطأ في التقريب يتم تقديمه. هناك برنامج مجاني ، geotiff header examiner geotiffe.exe يمكنه استخراج البيانات من تصنيف جغرافي ، ولكن من السهل إنشاء ملف tfw في GM والحصول على نفس البيانات.

AFAIK GM يستخدم & quot؛ معيار الصناعة & quot؛ خوارزميات إعادة الإسقاط. شيء واحد أود التحقق منه من صحة معلمات الإسقاط / المسند (على سبيل المثال ، تحقق من الوحدة & quot؛ قدم الاستقصاء & quot في الولايات المتحدة) على الرغم من أنني لا أعتقد أن ذلك قد يتسبب في حدوث خطأ بمقدار 10 أقدام على طول المدرج.

شيء واحد في GM هو أن هناك خيار & quot إنشاء وحدات بكسل مربعة & quot عند التصدير يتم تمكينه افتراضيًا. أنا دائما أزل ذلك.

لقد حصلت على نتائج جيدة من خلال رسم صورتي في برنامج طلاء باللون الأرجواني في المنطقة التي لا أريدها ثم تعيين اللون الأرجواني كـ nullValue الخاص بي في ملف inf. يقوم برنامج الرسام الخاص بي بتدمير علامات geotiff ، لكني قمت بتشغيل الصورة مرة أخرى من خلال GM لإعادة وضعها مرة أخرى.

لم أحاول أبدًا تراكب أعمدة الأرض التي تم إنشاؤها بواسطة GMAX ، لذلك لا أعرف ما هي مشكلات تحديد المواقع التي قد تكون هناك. لا أعرف كيف تحدد & quot؛ الحقيقة & quot؛ عندما تعمل بمثل هذه الدقة العالية المطلوبة.

Rhumbaflappy

مدير

لا أعرف كيف تضع صور المدرج ، لكن كن على دراية بأن العناوين في FS مغناطيسية. ليست عناوين صحيحة. تحتاج إلى استخدام برنامج مثل TCalcX للحصول على عنوان حقيقي في sim.

أيضًا ، لم تعد الصورة المعاد تشكيلها ، الموجودة الآن في الإسقاط الجغرافي ، تمثل تمثيلًا للطول أو العرض الحقيقي.

الإسقاطات الجغرافية بدرجات خطوط الطول والعرض. يستخدم Max أو GMax قياسات خطية للأمتار أو الأقدام. لذلك لا يمكنك حقًا استخدام صورة من هذا النوع كخلفية قصوى.

قد تكون قادرًا على استخدام صورة خلفية إسقاط UTM ، وهو قياس خطي (على ما أظن). ربما يمكن لشخص آخر أن يتناغم هنا.

كاك 911

Dick ، ​​لقد نسيت أن أذكر أن كل ما صممته في Max يتوافق تمامًا مع وثائق الخطة الرئيسية للمطار. تم تحديد المحامل الحقيقية ، وأبعاد المدرج ، وعرض الممر ، والمسافات من خط الوسط إلى خط الوسط ، وأنصاف أقطار الشرائح في المستندات ، وقمت بإنشاء أعمدة الأرض الخاصة بي بأمانة وفقًا لهذه الأبعاد.

لنسخ هذه البيانات احتياطيًا ، قمت باستيراد الصور الجوية التي ذكرتها في بداية هذا الخيط (لا تزال في إسقاط State Plane ، وعند 1 قدم / بكسل) ، ووضعها على مستوى واستخدامها كخلفية أثناء تصميم الرصيف. كانت النتيجة مطابقة تمامًا للأبعاد المنشورة.

In a nutshell that's why I think the reprojected imagery in FSX is the culprit.

@Scott, I've re-exported numerous times with various settings in order to try and isolate any setting that I might have set incorrectly. The "square pixels" option was one of them. I also check the Feet (Survey) setting, and double checked the arc degrees per pixel, all to no avail. Nothing I changed seemed to make any difference in FSX.

I also went through the SDK and fiddled with the INF file. I tried the xDim and yDim entries, but that didn't have any effect either.

Thats what led me to believe that if I manually tell resample to slightly move the Southeast corner of my image, perhaps I can get it to line up properly.

When comparing the imagery to the surrounding vector features in FSX, certain road line up exactly, while others seem to be off slightly. on the order of about 10 feet in places. It's not really about rotation, more like a slight distortion. I just can't tell if it's in the x or the y dimension.

I'd love to post some pics to make what I'm seeing more clear, but I can't really do that, unfortunately.

If you guys have any more ideas, I'm all ears. I'll keep fooling around with it in the mean time. Thanks again.

GaryGB

Somebody please correct me if I'm wrong (as I am not a GMAX user).

Imagery to be used as source data in any file format for FS ground textures / background images / maps / vector content etc. in ANY FS utility, whether FS SDK Resample, SHP2VEC, AFCAD, ADE, AFX /Airport Studio, SBuilder, SBuilderX, Slartibartfast. and/or GMAX, 3dsMAX, Sketchup etc. should first be projected in the required Geographic Lat-Lon WGS84 datum.

The same is true of imagery intended to be used for texturing large areas ex: long RWYs or other terrain regions such as custom ground poly in any of the above FS utilities. just because you can "warp" or "stretch"imagery in an app doesn't mean that will produce the best result compared to an image already projected closer to the final "shape" that FS will require.


FYI: This does not apply to 3D scenery objects such as buildings. vegetation, SimObjects, Aircraft etc. to be placed "above" ground.


Yes imagery will look "squished", and squares will look like rectangles with longer dimensions along the horizontal (East-West) direction. that is what WGS84 ينبغي "look like" but FS will 'warp' it back into "normal" looking 'square' quad matrix cell tiles at run time, so no worries !


يفعل ليس do any significant manual "stretching" of imagery intended for use in apps with such a 'rubber sheet' feature option (ex: AFX /Airport Studio).

Likewise, do ليس do any processing of imagery with 'arbitrary' parameters via GDALWarp or other such tools to "warp" an image into what you فكر في "looks right". هو - هي يجب be projected correctly as WGS84. or IMHO you are better off NOT attempting to use it.

Administrator

For use in GMax/FSDS/SketchUp the imagery should not be in lat/long projection, but in a local flat earth projection. Since that is the grid those programs work in.

Most other programs will indeed require WGS84 lat/long.

GaryGB

But I thought Christopher Columbus discovered that the Earth wasn't flat ? <. just kidding, of course ! & GT


Apparently Sketchup performs the required re-projection when one geo-locates a (max 1024x1024 pixel) image tile directly from Google Earth via its own internal engine.


Can that same internal engine in Sketchup be used to import ex: a GeoTiff (treated as a generic Tiff I would assume), or a BMP file ?


I suspect that internal engine in Sketchup can't be used by the end user to do this with any other image import process.


So, IIUC, if we import non-georectified imagery into ex: Sketchup to use as a background for tracing objects to be placed into FS on the ground (ex: custom ground polys), what is a freeware application that end users could utilize to "re-project" or 'warp' the imagery properly before import ?


I think we'd all like to be certain about this for FS Development, especially considering such issues as I've seen addressed in the Global Mapper forum:

And regarding the making of large FS airport backgrounds / very long RWYs etc, this was rather intriguing in its implications for would-be 3D modelers:

& مثل We need to decide: what is the acceptable difference between distance measured
on the ground and distance measured on the map.
Local ‘flat earth’ grids only work over a very small area. If your work area extends
beyond a kilometre, you can no longer use a localised flat earth grid . ولكن هل
could define your own local map projection with a small (negligible, but acceptable)
scale-factor. It is relatively easy to convert data between your local projection and the
national grid.
If you are designing a long linear feature, it will usually have its own reference
system – chainage (i.e. distance from a known starting point), along the feature and
offset perpendicular to the feature. You could introduce a variable scale-factor, so that
chainage corresponds with what you measure on the ground. An even neater solution
would be to use what is commonly known as ‘snake’ projection: this dynamically
converts between chainage and grid co-ordinates on large, generally linear projects.
& مثل

& مثل in Great Britain, Ordnance Survey (ordnancesurvey.co.uk) provides
geodata referenced to a map projection known as British National Grid.
In most places, there will be a difference between a distance measured
on the ground. This difference is known as scale-error or scale-factor
distortion. It is variable depending upon location in the country, and can affect
measurements by an amount ranging between zero and 4cms every 100m. & مثل

Thanks for your further clarification of what the proper name of that conversion / re-projection format is which we should look for in GIS apps, for subsequent 3D world modeling in GMAX / 3DSMAX and Sketchup with FS as the ultimate destination of such content.


PS: I see that Google Maps (AFAIK the same as Google Earth) says this about their projection and coordinate system:

There are several coordinate systems that the Google Maps API uses:

* Latitude and Longitude values which reference a point on the world uniquely. (Google uses the World Geodetic System WGS84 standard.)
* World coordinates which reference a point on the map uniquely
* Tile coordinates which reference a specific tile on the map at the specific zoom level

World Coordinates

Whenever the Maps API needs to translate a location in the world to a location on a map (the screen), it needs to first translate latitude and longitude values into a "world" coordinate. This translation is accomplished using a map projection. Google Maps uses the Mercator projection for this purpose. You may also define your own projection implementing the google.maps.Projection interface. (Note that interfaces in V3 are not classes you "subclass" but instead are simply specifications for classes you define yourself.)

For convenience in the calculation of pixel coordinates (see below) we assume a map at zoom level 0 is a single tile of the base tile size. We then define world coordinates relative to pixel coordinates at zoom level 0, using the projection to convert latitudes & longitudes to pixel positions on this base tile. This world coordinate is a floating point value measured from the origin of the map's projection to the specific location. Note that since this value is a floating point value, it may be much more precise than the current resolution of the map image being shown. A world coordinate is independent of the current zoom level, in other words.

World coordinates in Google Maps are measured from the Mercator projection's origin (the northwest corner of the map at 180 degrees longitude and approximately 85 degrees latitude) and increase in the x direction towards the east (right) and increase in the y direction towards the south (down). Because the basic Mercator Google Maps tile is 256 x 256 pixels, the usable world coordinate space is <0-256>, "


Hmmm. remarkably similar to the FS world quad matrix cell system of ex: LOD-13 tiles having 256 x256 Area Points each cell !


But then, I've seen rumors posted that a number of folks with the original KeyHole / Google Earth team used to work for ACES.

This was a rather interesting "MS" Document as well:

Introduction to Spatial Coordinate Systems: Flat Maps for a Round Planet


So, I guess we should also look at what MS 'Bing' Maps (aka MS Virtual Earth") uses too:

To make the map seamless, and to ensure that aerial images from different sources line up properly, we have to use a single projection for the entire world. We chose to use the Mercator projection, which looks like this:
Bb259689.150afcdc-99eb-4296-9948-19c0a65727a3(en-us,MSDN.10).jpg

Although the Mercator projection significantly distorts scale and area (particularly near the poles), it has two important properties that outweigh the scale distortion:

1. It’s a conformal projection, which means that it preserves the shape of relatively small objects. This is especially important when showing aerial imagery, because we want to avoid distorting the shape of buildings. Square buildings should appear square, not rectangular.

2. It’s a cylindrical projection, which means that north and south are always straight up and down, and west and east are always straight left and right.

Since the Mercator projection goes to infinity at the poles, it doesn’t actually show the entire world. Using a square aspect ratio for the map, the maximum latitude shown is approximately 85.05 degrees.

To simplify the calculations, we use the spherical form of this projection, not the ellipsoidal form. Since the projection is used only for map display, and not for displaying numeric coordinates, we don’t need the extra precision of an ellipsoidal projection. The spherical projection causes approximately 0.33% scale distortion in the Y direction, which is not visually noticeable. & مثل


2 Answers 2

Your code tries to convert from EPSG:4326 to EPSG:4326.
But your data is actually in EPSG:3857 (wild guess on my end).
You need to use EPSG:3857 as "source" CRS.

GeoJSON had no specification until https://tools.ietf.org/html/rfc7946 so older GeoJSON might not be in WGS84 which rasterio might assume to be the case.

In the end, reprojecting the geoTIFF using QGIS (instead of trying to unsuccessfully reproject geoJSON) to WSG84 did the trick and made the rasterio example work.


Conversion and georeferencing of maps for ttMaps

Before using a map with ttMaps, make sure you have the right! Some publishers of paper maps prohibit you to scan them, and vendors of maps on CDROM impose very restrictive licenses, such as the ban on the use of maps with other software than that provided by the vendor.

Maps format

The format that was chosen for ttMaps is the ECW format, developed by the company Er Mapper, recently acquired by ERDAS.. Why use such a choice? This format has many advantages for mapping applications:

  • Excellent lossless compression ratio, better then that of JPEG
  • Rapid access to image file, at any zoom level
  • Ability to decompress a portion of the image without decompressing the entire file

It is a format chosen by the IGN to deliver maps and aerial photographs. It is therefore possible to directly use the files from IGN. See, for example, screenshots some of which were produced with samples of IGN maps.

Calibrating maps

Before you start converting the maps to ECW format, you must make sure they are calibrated (georeferenced), therefore you need to know:

  • the datum
  • the projection
  • the geographic extents, ie :
    • either the coordinates of the upper left corner and the pixels sizes
    • either the coordinates of the upper left corner and of the lower right corner

    In general, the datum and projection are shown in the legend text of paper maps. If you do not know the geographical extents, you must first calibrate the map. I will not explain in detail how to do this, because there are many programs available, such as:

    Tools for conversion to ECW format

    • Er Mapper software (for Microsoft Windows), of which you can download a trial version (30 day trial) at http://www.erdas.com/Products/ERDASProductInformation/tabid/84/currentid/1052/default.aspx .
    • GDAL free software, available for several systems :
      • Windows : Install the GDAL package. Binaries are available on the GisInternals web site.
      • Linux : GDAL is available in most distributions (choose a package with ECW support)
      • Mac OS X : On the page http://www.kyngchaos.com/software:frameworks, download the frameworks GDAL, UnixImageIO, GEOS 3, SQLite3 and PROJ 4.6, together with the ECW plugin. Install them. In a console, type: export PATH=/Library/Frameworks/GDAL.framework/Programs:$PATH

      Conversion of maps with GDAL

      Here are three examples of using GDAL to convert the maps to the ECW format.

      Georeferenced maps

      Some file formats, such as GeoTIFF, include georeferencing data. For example, download the Sample GeoTiff file. After unpacking the archive, you can use the gdalinfo command to display information about the file:

      This information allows us to know the reference system (here WGS84) and the projection used (here, UTM Zone 10 North). Unfortunately, Er Mapper uses its own names to designate the reference systems and projections. Before making the conversion, you must find these names.

      • For France, there is a paper (in French): Syst mes de projections dans Er Mapper et Mapinfo.
      • For the rest of the world, you can read this document: Supported map projections and datums
      • If you installed the Er Mapper software, you can also browse the files in the GDT_DATA folder, especially the files datum.dat and project.dat .

      For the image above, the datum is WGS84 and the projection is NUTM10. The command to use to convert the file to ECW format is:

      The parameter TARGET=90 indicates that you wish to obtain a compression ratio of the image equal to 90% (Change the rate depending on the type of image).

      Note : Avoid using the same base name for input file and output file, otherwise you may encounter some problems with the current version of gdal_translate.

      Conversion of maps shipped with a world file

      Some files, such as TIFF, JPG or PNG may be accompanied by a world file containing the geographical extents of the map. These files have respective extensions .TFW, .JGW and .PGW .

      One example is the SCAN1000 map of IGN, which is freely available on the IGN site.

      Download for example SCAN 1000 Corsica (Version Lambert II extended) and unzip the archive. The useful files are COR_0000.TIF (TIFF image) and COR_0000.TFW, which contains the coordinates and size of pixels. The gdalinfo command shows that this file uses a color palette:

      The gdal_translate utility is not capable of converting a file based on a color palette to a file in 16 million of colors. Fortunately, a conversion utility ( pct2rgb.py ) comes with the GDAL package. You must therefore begin doing this conversion:

      The website of the IGN tells us that this map uses the NTF reference system (New Triangulation French), with the Lambert projection II extended. The conversion command will be as follows:

      However, we note that the map is surrounded by an unnecessary white border. It is possible to convert only a part of the map, using the -srcwin option of the gdal_translate command:

      For the Linux users (or Windows with CygWin), here's a script that converts the SCAN100 map.

      Conversion of a map without georeferencing data

      Download for example the image BlueMarble. The coordinates of the upper left corner are -180 , 90 and those of the lower right corner are 180 ,-90 . The datum is WGS84, and the projection is GEODETIC.

      The command you can use for the conversion is:

      Georeferencing of an ECW file

      If you have a file in ECW format not containing the whole georeferencing information (datum, projection and extents), it is possible to add this information without having to decompress / recompress the file with gdal_translate. To do this, you may use the tool ECW Header Editor , that you can download at ERDAS.

      To georeference the image, you must proceed as follows:

      • Install the software "ECW Header Editor"
      • Launch the software "ECW Header Editor"
      • Open the ECW file through File menu - Open
      • Fill in the Datum and Projection
      • Give the coordinates of the upper left corner of the image and size of pixels
      • Save the image through the File menu - Save.

      It is also possible to use gdal_edit , that works on Windows, MacOS and Linux.

      Georeferencing a file already calibrated for OziExplorer

      There are lots of maps for OziExplorer. Thus, we are going to show step by step, on three practical examples, how to convert your maps to ECW format.

      How to check if the calibration file is correct

      Often it occurs that calibration files for Oziexplorer do not contain the correct information on the projection and the datum. This is because some people use OziExplorer without sufficient knowledge, sometimes without even taking the time to try to understand the datums and projections.

      There is a simple test to be carried out on a calibration file. The principle is to verify that the edges of the map are parallel to the axes of the projection.

      To start, display the .map file contents (it contains plain text). In general, the file contains the coordinates of four control points, most often the four corners of the map. To ensure that the map is aligned with the axes of the projection, you just have to check that:

      • The left corner have the same eastings
      • The right corners have the same eastings
      • The upper corners have the same northings
      • The bottom corners have the same northings

      مثال 1

      هدف Easting Northing
      Coordinates of the upper left corner 0 2700000
      Coordinates of the upper right corner 1100000 2700000
      Coordinates of the lower right corner 1100000 1600000
      Coordinates of the lower left corner 0 1600000

      In this first example, we see that the map is well positioned. Indeed:

      • The easting of the left edge is 0
      • The easting of the right edge is 11000000
      • The northing of the upper edge is 2700000
      • The northing of the lower edge is 1600000

      مثال 2

      هدف Easting Northing
      Coordinates of the upper left corner 4.269040 45.882684
      Coordinates of the upper right corner 4.912734 45.870023
      Coordinates of the lower right corner 4.891744 45.422152
      Coordinates of the lower left corner 4.253713 45.434813

      In this second example, we see that the map is misaligned. Indeed:

      • The left edge of the map passes through points of eastings 4.269040 and 4.253713: it is tilted
      • The right egde of the map passes through points of eastings 4.912734 and 4.891744: it is tilted
      • The upper edge of the map passes through points of northings 45.882684 and 45.870023: it is tilted
      • The lower edge of the map passes through points of northings 45.422152 and 45.434813: it is tilted

      Note : This simple method is able to prove that the projection indicated in the .map file is incorrect. It does not check that the projection, datum and coordinates are correct, this should be done by displaying known points in ttMaps.

      Tutorial n 1 : Conversion of a french map coming with a correct calibration file

      Here is an example, with a .map file found on a forum:

      .map file lines وصف
      Map Datum,NTF France المسند
      Map Projection,(II) France Zone II,PolyCal,No,AutoCalOnly,No,BSBUseWPX,No تنبؤ
      Image Width,44000 Image width, in pixels
      Image Height,44000 Image height, en pixels
      Point01,xy, 0, 0,in, deg, , ,N, , ,E, grid, , 0, 2700000,N Coordinates of the upper left corner
      Point02,xy,44000, 0,in, deg, , ,N, , ,E, grid, , 1100000, 2700000,N Coordinates of the upper right corner
      Point03,xy,44000,44000,in, deg, , ,N, , ,E, grid, , 1100000, 1600000,N Coordinates of the lower right corner
      Point04,xy, 0,44000,in, deg, , ,N, , ,E, grid, , 0, 1600000,N Coordinates of the lower left corner

      This table contains all the information necessary to create a georeferenced ECW file.

      • The first line gives the datum: New Triangulation French (ErMapper code is NTF)
      • The second line gives the projection: Lambert France Zone II (Ermapper code is LM2FRANC)
      • The fifth line gives the coordinates of the upper left corner: (0, 2700000)
      • With the coordinates of the lower right corner (1100000, 1600000) and the number of pixels, you can deduce the size of pixels:
        • Horizontal (1100000 - 0) / 44000 = 25 m
        • Vertical: (2700000 - 1600000) / 44000 = 25 m

        The easiest way to make the conversion is to use GDAL:

        Note : The LARGE_OK=YES option here is essential, because the size of the map (44000 x 44000 x 3 = 5808000000 bytes) exceeds 500 Mb.

        Tutorial n 2 : Conversion of a french map coming with an incorrect calibration file

        .map file lines وصف
        WGS 84,WGS 84, 0.0000, 0.0000,WGS 84 المسند
        Map Projection,Latitude/Longitude,PolyCal,No,AutoCalOnly,No,BSBUseWPX,Yes تنبؤ
        Image Width,5000 Image width, in pixels
        Image Height,5000 Image height, en pixels
        Point01,xy, 0, 0,in, deg, 45, 52.96104,N, 4, 16.1424,E, grid, , , ,N Coordinates of the upper left corner (in degrees + decimale minutes)
        Point02,xy, 5000, 0,in, deg, 45, 52.20138,N, 4, 54.76404,E, grid, , , ,N Coordinates of the upper right corner (in degrees + decimale minutes)
        Point03,xy, 5000, 5000,in, deg, 45, 25.32912,N, 4, 53.50464,E, grid, , , ,N Coordinates of the lower right corner (in degrees + decimale minutes)
        Point04,xy, 0, 5000,in, deg, 45, 26.08878,N, 4, 15.22278,E, grid, , , ,N Coordinates of the lower left corner (in degrees + decimale minutes)

        We see immediately that the map is not aligned with the WGS84 projection. The main challenge will be to find the correct projection and datum.

        As it is a French map, it's not very difficult: Most french maps use the NTF datum and the extented Lambert II projection (at the exception of some maps of Corsica that use the Lambert IV projection).

        We'll check that by converting the coordinates of the four corners of the map into NTF/extented Lambert II. There are many softwares to convert coordinates, use whatever you prefer.

        Points Longitude (WGS84) Latitude (WGS84) X (Lambert IIe) Y (Lambert IIe)
        Upper left corner 4.269040 45.882684 750000.06 2099889.00
        Upper right corner 4.912734 45.870023 799993.98 2099915.04
        Lower right corner 4.891744 45.422152 799982.76 2050105.46
        Lower left corner 4.253713 45.434813 750024.37 2050092.08

        This map has probably been calibrated manually, and there are errors of a few tens of meters. After rounding results, we get:

        Points X (Lambert IIe) Y (Lambert IIe)
        Upper left corner 750000 2100000
        Upper right corner 800000 2100000
        Lower right corner 800000 2050000
        Lower left corner 750000 2050000

        So we see that the map is well aligned with respect to the axes of the projection NTF/extended Lambert II, and we can now convert it:

        Note : The LARGE_OK=YES option is not useful, because the size of the map (5000 x 5000 x 3 = 75000000 bytes) does not exceed 500 MB

        Tutorial n 3 : Conversion of an english map coming with a correct calibration file

        To understand this example, it is necessary to know the reference system used in the United Kingdom. Read for example http://en.wikipedia.org/wiki/British_national_grid_reference_system.

        .map file lines وصف
        Ord Srvy Grt Britn,WGS 84, 0.0000, 0.0000,WGS 84 المسند
        Map Projection,(BNG) British National Grid,PolyCal,No,AutoCalOnly,No,BSBUseWPX,No تنبؤ
        IWH,Map Image Width/Height,32704,32576 Taille de l'image, en pixels
        Point01,xy, 200, 128,in, deg, , ,N, , ,W, grid, HV, 01000, 00000,N
        Point02,xy,32400, 128,in, deg, , ,N, , ,W, grid, HW, 62000, 00000,N
        Point03,xy,32400,32328,in, deg, , ,N, , ,W, grid, NG, 62000, 39000,N
        Point04,xy, 200,32328,in, deg, , ,N, , ,W, grid, NF, 01000, 39000,N

        This conversion is more complex than previous ones:

        • First difficulty: the coordinates use a system of letters + numbers, useless with most software.
        • Second difficulty: the coordinates given by the .map file do not correspond to the corners of the map.

        We will begin by converting the coordinates from letters + numbers to fully numerical coordinates. For that, it is enough to know that the squares measure 100km aside and that the reference is the southwest corner of the SV square (see map on Wikipedia). We deduce the following table:

        Square X Offset Y Offset
        HV 0 1000 km
        HW 100 km 1000 km
        NG 100 km 800 km
        NF 0 km 800 km

        that allows us to calculate the coordinates of the four control points:

        Control Point of reference Easting Northing
        Point01 1000 1000000
        Point02 162000 1000000
        Point03 162000 839000
        Point04 1000 839000

        We note in passing that the map is well aligned with respect to the axes of the projection.

        Now calculate the coordinates of the upper left corner and lower right corner of the map.


        2 Answers 2

        A workaround for this issue is to first use gdalwarp to transform the input image into EPSG:3857 so that no re-projection is done by gdal2tiles . على سبيل المثال:

        It looks like the image has been reprojected but the areas outside the original image (black pixel areas) have not been assigned as nodata. Also, in your last gdal2tiles run it looks like you're assigning nodata to color white (255).

        Perhaps you could try running gdal2tiles again with the " –srcnodata=0 " option,

        or run gdal_translate on your already-reprojected images to specify black pixels (0) as noData, then re-run gdal2tiles with either the srcnodata option unused or set to black " –srcnodata=0 ".


        How to disable geolocation in browsers?

        Google Chrome

        1. Click the Chrome menu button on the browser toolbar (with the 3 dots).
        2. Click on Settings .
        3. Scroll down and click on Advanced .
        4. In the &lsquoPrivacy and security&rsquo section, click Site settings .
        5. Click &lsquoLocation&rsquo and toggle &lsquoAsk before accessing&rsquo to &lsquoBlocked&rsquo.

        For further information see Google&rsquos location sharing page.

        Firefox

        1. In the URL bar, type about:config .
        2. In the search bar type geo.enabled .
        3. Double click on the geo.enabled preference. Location-Aware Browsing should now be disabled.

        For further information see the Firefox Location-Aware Browsing page.

        Internet Explorer

        1. Open the Tools menu by clicking on the gear icon in the upper-right corner of the browser window.
        2. Open the Privacy tab.
        3. Under Location, select the option Never Allow Websites To Request Your Physical Location .

        Microsoft Edge

        1. Hit the Windows button & select Settings
        2. Navigate to Privacy -> Location and toggle location to Off

        Apple Safari

        1. Choose System Preferences from the Apple () menu.
        2. Click the Security & Privacy icon in the System Preferences window.
        3. Click the Privacy tab.
        4. If the padlock icon in the lower left is locked

          , click it and enter an admin name and password to unlock it
        5. Select Location Services .
        6. Uncheck &lsquoSafari&rsquo to disable geolocation.

        Opj_stream_get_number_byte_left: Assertion `p_stream->m_byte_offset >= 0' failed. #1151

        The text was updated successfully, but these errors were encountered:

        We are unable to convert the task to an issue at this time. Please try again.

        The issue was successfully created but we are unable to update the comment at this time.

        KermMartian commented Sep 25, 2019 •

        Edit: in fact, I replicate this issue with the exact same input file, trying to perform exactly the same conversion. Impressive. Makes me slightly doubt the integrity of the file.

        Rouault commented Sep 26, 2019

        The image is fine. This works with GDAL 3.0 (presumably 2.4 as well) with openjpeg >= 2.3.0. But you need a lot of memory (9 GB)

        KermMartian commented Oct 3, 2019

        Using a machine with 256GB of RAM:

        And GDAL 2.4.0 compiled against apt-installed libopenjp2-7-dev (that's OpenJPEG 2.3.0):

        I grabbed a fresh copy of the image to perform this test, then unzipped it, but perhaps that's still tripping me up in some way (e.g., a problem unzipping a 3+GB zip)? Does your sha256sum match?

        Rouault commented Oct 3, 2019

        OK, I finally reproduced the issue. A debug build of openjpeg was needed (at least one without -DNDEBUG), so that assertions are compiled in. The bug was actually in the GDAL OpenJPEG I/O layer, that wasn't ready to deal with reading single-tile codestreams larger than 2GB.

        There was also an error in the MCT stage of openjpeg triggered by opj_decompress, which caused the "Tiles don't all have the same dimension" error. couldn't test the fix since I don't have actually enough RAM to reach that point, but there were a few 'obvious' uint32 overflows I've fixed. Anyway that part wasn't triggered by GDAL since it reads by much smaller chunks, whereas opj_decompress is brute force and decompresses the whole image at once.

        You can’t perform that action at this time.

        You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.


        Help - Information Point on Telecommunications

        The Help tab contains detailed information on using the Information Point on Telecommunications (PIT) and the Electronic Services Platform (PUE).

        The Help tab is arranged by topic and provides information on the method for setting up an account and logging in to the services, as well as instructions, FAQ and instructional videos.

        In the case of questions please contact us using the submission form.

        To access PIT, proceed as follows:

        1. Registration/log-in (the manual is available in Polish version only).

        Registering and logging in to UKE systems takes place via PUE (https://pue.uke.gov.pl) or PIT (https://pit.uke.gov.pl) websites.

        We recommend registration at the PUE level, which enables to fill in and submit “Wniosek o dostęp do PIT” (“Application for access to PIT”).

        2. Setting up an account for an entity (the manual is available in Polish version only).

        To correctly submit “Wniosek o dostęp do PIT” (“Application for access to PIT”) and to continue work in the PIT system, you need to set up an account for an entity (organisation, company) and assign a representative.

        3. Submission of “Wniosek o dostęp do PIT” (“Application for access to PIT” (the manual is available in Polish version only).

        An entity’s representative, acting on behalf of the entity, submits the application. Correct submission of the application is confirmed by an Official Confirmation of Receipt (UPO), which will be delivered to the applicant’s mailbox.

        4. The PIT system administrator immediately grants authorisation based on a submitted application for access to PIT.

        5. Once authorisation is granted pursuant to the application, the user is notified via e-mail.

        6. The user logs in to PIT (https://pit.uke.gov.pl), selects the context of the entity and works in the system.

        Detailed information on registering, logging in, setting up an entity account, changing the operation context and working on a document on the UKE Electronic Services Platform can be found at https://pit.uke.gov.pl/en-us/help/.

        Any questions may be submitted using the submission form.

        Information Point on Telecommunications (PIT)

        As part of the Information Point on Telecommunications (PIT), the Office of Electronic Communications provides access to view services WMS1 and WMTS2 for the different categories of spatial data:

        Service layers after logging in:

        1. Existing linear infrastructure
        2. Planned linear infrastructure
        3. Existing surface infrastructure
        4. Planned surface infrastructure
        5. Existing point infrastructure
        6. Planned point infrastructure
        7. GESUT data

        Service layers without logging in:

        1. Rates for occupying traffic lanes
        2. Forest districts
        3. Access to real estate
        4. SIIS: hotspots
        5. SIIS: co-locations
        6. SIIS: lines
        7. SIIS: planned expansion
        8. SIIS: nodes

        A key is required for layers available after logging in. The key can be generated by authorised entities in the PIT administrative panel.

        1) خدمة خرائط الويب (WMS) is an international standard for sharing spatial data over the Internet in raster form. Technical standards are available at the Open Geospatial Consortium (OGC) website: http://www.opengeospatial.org/standards/wms.

        2) Web Map Tile Service (WMTS) is an international standard for sharing spatial data over the Internet in raster form, as pre-defined sections of a map, so-called tiles. The process of generating tiles is launched upon the update of a particular product, while the files are appropriately structured and stored on servers. Such a solution speeds up the response of the service to a user’s enquiry concerning a section of a map, since they receive graphics already prepared in advance, as opposed to the WMS service, which generates a graphic file upon each such request.

        For operators of electronic communications networks, in particular new entities on the market, it may be much more efficient to use already existing technical infrastructure, including the one belonging to other public utilities, for the deployment of electronic communications networks, in particular in areas where an adequate electronic communications network is not available or where the construction of a new teletechnical infrastructure may be unprofitable. In addition, sectoral synergies can significantly reduce the need for construction works related to the deployment of electronic communications networks, and thus can also reduce the associated social and environmental costs, such as pollution, nuisance and traffic congestion. For this reason, locating elements of telecommunications networks on a wide and ubiquitous technical infrastructure, such as technical networks used to provide electricity, gas, water supply, sewage and rainwater drainage, heating and transport networks can bring significant savings to investors.

        The basic objectives of running PIT are:

        - to ensure the most efficient planning and deployment of high-speed telecommunications networks,

        - to facilitate the efficient use of technical infrastructure for the purpose of building high-speed telecommunications networks, by providing access to information useful from the point of view of a telecommunications undertaking.

        Entity performing tasks in the field of public utilities - a natural person, a legal person or an organizational unit without legal personality which is granted legal capacity through specific legal provisions, that provides technical infrastructure for the purpose of:

        a) generating, transmitting or distributing gas, electricity or heat,
        b) providing lighting in places referred to in Article 18 (1) item 2 of the Act of 10 April 1997 - Energy Law,
        c) supplying people with water, collecting, transferring, treating or draining sewage, heating, drainage systems, including drainage ducts,
        d) transport, including railways, roads, ports and airports.

        Technical infrastructure - any element of the infrastructure or network that can be used to place in it or on it infrastructure or telecommunications network elements, without becoming an active element of this telecommunications network, such as pipelines, sewers, masts, ducts, chambers, manholes, cabinets, buildings and entrances to buildings, aerial installations, towers and columns, excluding:

        a) cables, including optical fibers,
        b) elements of the network used for the supply of water intended for human consumption,
        c) service ducts within the meaning of Article 4 (15a) of the Act of 21 March 1985 on public roads.

        Service duct – an arrangement of protective housing elements, cable wells and other facilities or devices used for placing or operating:

        a) technical infrastructure devices related to the road management or traffic needs,
        b) telecommunications lines with power supply and power lines, not related to the road management or traffic needs.

        Telecommunications undertaking – an undertaking or another entity authorised to pursue business activities under separate provisions and which conducts business activities consisting in the provision of telecommunications networks, associated facilities or in the provision of telecommunications services, whereby the telecommunications undertaking authorised to provide:

        a) telecommunications services shall be referred to as a “service provider”,
        b) public telecommunications networks or associated facilities shall be referred to as an “operator”.

        Network operator - a telecommunications undertaking or an entity performing public utility tasks, including a local government unit.

        Provisions of the Act of 7 May 2010 on supporting the development of telecommunications services and networks (Mega-law) define groups of information provided to the President of UKE via the PIT portal.

        Table 1. Groups of information to be provided to the President of UKE via the PIT portal.

        On the existing technical infrastructure, other than the infrastructure covered by the inventory, as referred to in Article 29 (1) of the Mega-law, as well as on service ducts, specifying:

        a) their location and arrangement,
        b) type and current status and method of use,
        c) contact details on access matters.

        On investment plans in the scope of the performed or planned construction works, financed in whole or in part from public funds, regarding technical infrastructure or service ducts, specifying:

        a) location and type of works,
        b) element of the technical infrastructure or of the service duct which is subject of the works,
        c) expected date of launching works and their duration,
        d) contact details for coordination of construction works.

        On addresses of the internet websites with the description of the conditions of access, as referred to in Article 30 (1) and (3) of the Mega-law, and of placing objects and devices on the property, as referred to in Article 33 (1) of the Mega-law.

        The following entities are required by the provisions of the Mega-law to provide the President of UKE with the specified information via the PIT portal:

        Table 2. Entities obligated to provide the President of UKE with information via the PIT portal.

        Way of providing
        information

        Timeframe for providing and updating information

        The PIT portal is constantly connected to the publishing system.

        Time of submission agreed with the President of UKE.

        On the date specified in the application of the President of UKE.

        Information from group 1. in Table 1., at the request of the President of UKE.

        Direct input of information to the PIT system by the entity.

        On the date specified in the application of the President of UKE.

        Not later than within 30 days from the date of completion of the construction of the service duct.

        Within 30 days from the date of issuing the permit.

        Article 40 (8) of the Act of 21 March 1985 on public roads.

        Submission immediately after receiving the application.

        The network operator can provide information to PIT, which will exempt it from the obligation to provide such information at individual requests of telecommunications undertakings. The provided information should be consistent with the actual status and be updated annually by 31 March reflecting the status valid on 31 December of the previous year.

        In accordance with the applicable provisions of law, the following information can be provided:

        1. On the existing technical infrastructure, other than the infrastructure covered by the inventory, as referred to in Article 29 (1) of the Mega-law, as well as on service ducts, specifying:

        a) their location and arrangement,
        b) type and current status and method of use,
        c) contact details on access matters.

        2. On investment plans in the scope of the performed or planned construction works, financed in whole or in part from public funds, regarding technical infrastructure or service ducts, specifying:

        a) location and type of works,
        b) element of the technical infrastructure or of the service duct which is subject of the works,
        c) expected date of launching works and their duration,
        d) contact details for coordination of construction works.


        شاهد الفيديو: Zašto dijeta daje rezultate samo u početku