שינוי מערכת תיאום מערכת Geobide, ED50 ו- ETRS89
ניצול כדי לעקוב אחר היכולות של חבילת Geobide, נראה את האפשרויות להשתנות מערכות הפניה. מעניין עבור אלה שצריכים להפוך בין Datum שונים, במקרה זה נראה איך לעשות את זה עם מערכות ED50 ו ETRS89 וזה כמעט באותו מקרה באמריקה הלטינית בין NAD27 ו WGS84.
האם הנתונים מועברים?
זה לא המקרה של Google Earth, שבו נעשה יותר טרנספורמציות, התמונות הרבות נעקרות, משהו כזה ניתן לבדוק בחפיפות בין טייקים שונים; עם זאת, במדינות רבות, מדינות או קהילות אוטונומיות, מוסדות ציבור סיפקו ל- GoogleEarth את התמונות שלהם עם התייחסות גיאוגרפית מדויקת, עם החיסרון ש- GoogleEarth משתמש ב- WGS84 כנתון כללי, ולכן השימוש בנתונים במערכת אחרת מחייב שינוי. השינוי תלוי קודם כל בהגדרה שלו, אך גם באזור בו אנו נמצאים. לכן מערכות גנריות אינן מספקות את הפרמטרים המיוחדים של כל אזור.
ניקח כדוגמה את השינוי ED50-30N (EPSG: 23030) ל- ETRS89-30N (EPSG: 25830) עבור Navarra, ולספרד. להגדרה הגנרית של הטרנספורמציה דרגת דיוק שונה בהתאם לאזור בו היא מיושמת. מסיבה זו, ישנם כמה פרמטרים נוספים, שאינם נכנסים להגדרה הגנרית ואילו ב Navarra למשל הם אחדים אך באסטוריאס הם עשויים להיות בעלי ערכים אחרים אחרים.
אם נסתכל על התמונה שלמעלה שנלכדה מ- Geomap, נראה מפה עם שתי שכבות (אורתופוטו וחבילה) המונעות יחסית זו לזו. זוהי תוצאה של הקרנת טיסה של קדארה של נווארה ב- ED-50N שכבה של GoogleMaps ב- WGS84 והקיזוז המתקבל קשור לבעיה המתוארת בפסקה הקודמת.
הדרכה לאחרונה בנושא Geobide, שממנה אנו מבצעים מאמר זה מפרסמת כעת לפחות 4 שיטות לתיקון. עם Geobide, ניתן כעת לציין את המרת הנתון לשינוי בין מערכות קואורדינטות בארבע דרכים שונות:
-
שינוי כללי:
אפשרות זו משתמשת בטרנספורמציה כללית ללא פרמטרים מרחביים, והיא הפחות מדויקת. עבור Navarra למשל המעבר מ- ED50 ל- ETRS89 יש שגיאה של 100-200m ב- x ו- y. (זכור כי זה לא משפיע על מערכות לתאם עם נתון שווה).
די דומה הוא המקרה של NAD27 עם WGS84 הליכה מטרים 202 בצפון מטרים 6 ממזרח בשינויים באזור המרכז כמו שאתה לשנות את הרוחב, למרות שזה רק משמעותיים הרוחב מדובר מאקוודור תוך האורך מגיע מהמזרח השקר.
-
טרנספורמציה באמצעות רשת NTv2:
אפשרות זו משתמשת ברשת עם ערכים כדי לתקן את ההמרה על ידי אינטרפולציה ליניארית. אפשרות זו מדויקת יותר מהשיטה הראשונה והיא אומצה על ידי IGN. מדויק, כמובן, אם יש לנו רשת עבור אזור העבודה שלנו.
היישומים של גיאובייד כעת הם מציעים את שתי הרשתות שסופקו על ידי ה- IGN לספרד, המכסות את חצי האי ואת האיים הבלאריים, ואשר פורסמו בשנים 2003 ו 2009. המשתמש יכול לבחור בקלות את הרשת לשימוש.
באינטרנט ניתן למצוא רשתות רבות, אפילו ברחבי העולם, אך לפי גודל הן אינן זמינות אוטומטית בהורדות של יישום Geobide.
-
Molodensky טרנספורמציה (שיטה של 3- פרמטרים):
3 משתמש בערכים היסטים במקור שבין האליפסואידים. אשף מוגדר מראש המומלץ על ידי IGN עבור ספרד.
בורסה וולף טרנספורמציה (שיטה של 7- פרמטרים)
טרנספורמציה זו משתמשת בערכי 7 כדי להפוך בין אליפסואידים. הפרמטרים שהוזנו הם: היסט (Dx, Dy, Dz), סיבוב (Rx, Ry, Rz) וגורם קנה המידה (μ)
ביישומים גיאובייד 3 אשפים הם מוגדרים מראש המומלצים על ידי IGN עבור צפון, מרכז אזור ומזרח חצי האי, בהתאמה.
תוצאות
כפי שאתה יכול לראות את התוצאות לא להשתנות הרבה בין השיטות האחרונות 3, אבל כן עם הראשון. לכן עליך לדעת אם הטרנספורמציה זקוקה לאפשרויות מתקדמות אלו.
בין ED50-xxN (EPSG: 230xx) מערכות ETRS89-xxN (EPSG: 258xx) בתחום ספרד עצמה צריכה לשמש Datums / ellipsoids ED50 ו ETRS89 / WGS84 אינם שווי ערך.
לדוגמה, אם נתונים מתקדמים אלה אינם מוגדרים ב- Geomap, הנתונים של Navarra ב- ED50-30N (EPSG: 23030) שיוצגו במהירות על הנתונים המסופקים על ידי Google Maps (Elipsoide WGS84) יועברו. כדי שייראו טוב, יש צורך להשתמש בטרנספורמציות המדויקות ביותר שכבר הוסברו.
נראה לי מאוד כי Geobide עושה מאמץ משמעותי לא רק כדי לעזוב את היכולות של המערכת שלו, אלא גם לתעד קצת יותר פירוט שאלה זו שכן הוא יכול להשפיע הרבה על איכות ודיוק של העבודה, מלבד רק כדי להבין את זה יותר מדי הוא עוד מאמץ.
עד כה, כל זה היה משולב אוטומטית לתוך המנוע, אבל כמו החברים של Geobide אמר לנו, את הדרישות של המשתמשים הובילו אותם כדי להפוך אותו גלוי ביישומים, כך שהמשתמש עצמו מודע לכך ואפילו משנה את הגדרה, או לשים אחד אחר עבור אזור העבודה שלך.
טרנספורמציה של גבהים אליפסואידים / גיאואידים
בגירסה החדשה, הגודל eleipsoidal / הגיאוד גובה ההבדל בחישוב יש גם שונה כך המשתמש יכול עכשיו לבחור את המודל geoid לשמש.
PRJ קובץ nomenclatures
ולבסוף, עוד שינוי שנראה לי טוב מאמץ עבור יכולת פעולה הדדית עם סטנדרטים OGC או שיטות של תוכניות פופולרי. קבצי ה- PRJ ש- Geobide מייצרת נמצאים במינוח OGC WKT, שהוא תקן המוכר על ידי כלים רבים של CAD / GIS. לא כך עבור יישומי ESRI, אשר PRJ שלהם, למרות שהם מכילים את ההגדרה המתמטית זהה לאלה סטנדרטיים, להגדיר את מערכות הקואורדינטות אחרת.
לדוגמה:
בתכנים של קובץ PRJ OGC, מערכת ETRS89-30N (EPSG: 25830) מוגדר על ידי הקוד "89N ETRS30 / UTM אזור"; את היישומים ESRI, במקום זאת הם מכנים אותו "ETRS_1989_UTM_Zone_30N". אם ב ArcGis אנחנו מערבבים שכבות עם PRJs בשני nomenclatures תוכנה זו תבצע את השינוי המרחבי גם כאשר ההגדרה המתמטית של מערכות תיאום זהה.
לשים לב לזה עקשנות, Geobide אפשרה אפשרות חדשה בבורר מערכת הייחוס כך שהמשתמש יוכל לציין אם הוא רוצה מערכת קואורדינטות עם PRJ בסגנון EPSG או בסגנון ESRI.
