להעביר תכונות מ גיאוגרפית מפת בנטלי

לפני כמה זמן אנחנו כבר מדברים על מה זה אומר לעשות את הקפיצה מ Microstation גיאוגרפיים ל בנטלי מפהדיברנו על איך הן בעבודה שרטוטים וכמה יתרונות חשובים של בנטלי Map. כבר בפוסט דיברתי על איך זה אפשרי להעביר את המבנה של הפרויקט, במקרה זה אני רוצה ללעוס על איך להעביר מפות עם מאפיינים גיאוגרפיים לשיעורים תכונה xfm.

אמנם, מבנה הפרויקט שנבנה עם מורשת גיאוגרפית ניתן לייבא מפת בנטלי, זה לא אומר כי התכונות שיש אובייקטים יוכרו על ידי הפרויקט החדש, הם חייבים להיות מוקצה.

כיצד עבדו הגיאוגרפים

בסגנון הגיאוגרפיה לאובייקטים באמצעות MSLINK היה שיוך למסד נתונים, זה היה כל מה שהיה לאובייקט, קישור מסוג OLE. MSLINK זה קישר את האובייקט הגרפי מקובץ dgn דרך MAPNAME של הטבלה MAPS, ובאמצעות MSCATALOG כדי לזהות מהיכן ניתן לקבל את הנתונים Entitynum. בנוסף, היו שולחנות כפולים לפרויקטים תואמי אינטרגרף שנשאו בדרך כלל UG לפני כן.

בנוסף, לאובייקט היה FEATURE, למרות שזה לא היה דינמי, בעת הקצאתו הוא רכש את המאפיינים שהוגדרו עבור תכונה זו (כולל פקודות) והוא נקשר לטבלת CATEGORY. לאובייקט יכולה להיות יותר מתכונה אחת והעדיפות הייתה זו שהוקצה על ידי הסגנון הסופי, ש- FEATURE ואובייקטים אחרים המקושרים לבסיס נקשרו לטבלת MSCATALOG שם הוקצו להם ישות שהיה הטבור של הכל.

אחר כך הקובץ אינדקס (MAPID), כך שלכל טבלה המקושרת לגיאוגרפיה יש לפחות שני שדות: MSLINK (מספר ישות ייחודי על כל מפה) שהוא תמיד המפתח הראשי ו- MAPID ( על המפה שבה הוא מאוחסן, הוא ייחודי בקטלוג המפה) שהוא מפתח זר לטבלת ה- MAPS.

אז הדרך היחידה לקיים אינטראקציה עם הנתונים היה להיות מחובר לבסיס, פעולות עם זה נעשה אל החיה  כגון עדכון הטבלאות שהיו בהן מידע על האובייקט כגון שטח, היקף וקואורדינטות כך ש- Publisher ידע כיצד להציג אותו. אתה יכול גם לחלץ תוויות אשר נפלו כאובייקטים ממסד הנתונים עם אותו קישור של האובייקט המקושר.

זה נראה פשוט אבל זה עלה לי עולם כדי להבין את זה מ MGE, ואת הדבר הכואב הוא שכל מה עשן זה לא עוזר הרבה עבור פרויקט עם מפת בנטלי.

איך מפת בנטלי עובדת

פרויקט מפת Bentley שומר על אותו היגיון של קטגוריה, תכונה, מפה, אובייקט; אבל במקרה זה, על ידי החלפת הטופס של קישור נתונים OLE ידי XML הרבה של השינויים בתהליך.

במקרה זה, האובייקט במפה יכול לאחסן נתונים (באותו dgn), שמובן כ- xml או כפי שבנטלי wfm מכנה זאת. ואז זה גם משתנה שכעת האובייקטים יכולים להיות בעלי תכונה אחת בלבד, ולהיות קשורים מרחבית על ידי כללים טופולוגיים; לפני כן, אותה קו יכול להיות הגבול של עץ התפוח וגם גבול הנכס, ועכשיו הם חייבים להיות עצמים נפרדים אך עם קשר טופולוגי כזה שכאשר משנים אחד את השני זה גם כן.

אז אינטראקציה עם נתונים נמצאת במרחק של קליק אחד בלבד, בין אם אתם מחוברים לפרויקט ובין אם לאו, תוכלו לקרוא את כל מה שנשאר כ- xfm data. ואז הטיפול ב תוויות ומאפיינים של התכונות, רק על ידי ביצוע שינויים מהמנהל הגיאו-מרחבי. בעבר, ביצוע שינויים היה דינמי רק בתצוגה דרך Publisher, אך אובייקטים דרשו להסיר את המאפיין ולהקצותו מחדש.

בנוסף, חברת Bentley Map מציעה אפשרויות ליצירת טפסי נתונים, תהליכים עוקבים, פקודות משויכות (שיטות / פעולות / תחומים / קריטריונים / דוחות) ופירואטים אחרים המאפשרים בניית נתונים.

משהו לא השתנה הרבה, וזה כמו שמשתמשים אומרים ESRI, כי עשן לוקח את הירוק ללעוס לעכל אותו.

הבעיה

עם זאת, העברת המבנה של הפרויקט אפשרי, ולאחר מכן להוסיף פונקציות באמצעות מנהל Geospatial, אשר מתכוון להיות מוכן להמשיך להאכיל נתונים אבל הדילמה היא:

והמפות שנבנו בגיאוגרפיה?

עבור זה בנטלי לא תוכנן כל חפץ המאפשר המרת אובייקטים מ פרויקט מורשת xfm ... איזה עסק מזוין!

ההצעה שאני מציע היא אחת אני רואה קיימא, לאחר שיחה עם חבר מי מצ 'ילה פנה אלי, לאחר כמה מיילים הגענו geofumada מיושן אבל פונקציונלי.

שלב 1. ייצוא לקובצי צורה

מפרוייקט גיאוגרפי פתוח, נבחרה האפשרות לייצא תכונות לעיצוב קבצים (file / export / SHP). זה חייב להיעשות עבור כל אחד תכונה הקיים על המפה.

זה יהיה צורך להילחם קצת כאשר האובייקטים הם centroid / הגבול, שכן יהיה צורך להעביר אותם צורות על ידי העברת ligue.

הייצוא יכול גם להיעשות על Mapinfo, כפי המועדפת.

שלב 2. ייבוא ​​ממפת בנטלי

ועכשיו, מתוך פרויקט מפת בנטלי, בחרנו את האפשרות לייבא (סוגי קבצים / ייבוא ​​/ נתוני GIS), עם זה את החלון יכולת פעולה הדדית, אתה לחיצה ימנית על יבוא ובחר ייבוא ​​חדש.

בלחצן העכבר הימני ב- Imoport1 אתה בוחר קובץ או ספרייה שלמה. אפשר לייבא קבצים צורה, או קבצי minfo סוג mif ו הכרטיסייה.

בעת הפעלת תכונה תכונה אנו יכולים לראות כי ניתן לבחור את רמת, צבע, שקיפות ומאפיינים אחרים.

כדי להקצות אותו ל תכונה אשר מעניינת אותנו מספיק כדי להקצות את השכבה (רמה).

כמה כואב

כפי שאמר ממין בפקין המקסיקאי הישן:

"דנה!"

אתה צריך לעשות את זה עבור כל תכונה על כל מפה בכל קטגוריה בכל פרויקט.

לשם כך, תוכל לשמור את לייבא, אז זה נקרא רק קובץ לפי קובץ או לפי ספרייה. האמת היא שיש עבודה קשה לשינוי נתונים, במיוחד אם מדובר בקבצים נפרדים. זה לא יזיק, עבד vba ב- .NET עבור aut
דלג על התהליך במקום להתמודד עם המשימה הזו ברגל, מה שעלול להוביל ליותר מכמה התאבדויות ביום. הבעיה העיקרית היא שכדי לעשות את הקפיצה אנו ממשיכים להיות תלויים בייעוץ מיוחד (ומעושן מאוד) כדי להבין את האומץ של בנטלי מפה וגיאוגרפיה, זה אפשרי, אבל היישומים לא צריכים להיות כל כך אסטרליים (בואו נודה בזה, שניהם) למשתמשים רגילים.

אפילו יותר כואב, אם המידע המקורי dgn היה מאוחסן בהיסטוריה... לקובץ החדש לא תהיה שום היסטוריה.

לסיכום

הפיתרון שאני מציג הוא בר-קיימא אם יש לך מעט נתונים, או אם הוא נשמר במחסנית מרחבית, כך שהמסקנה העצובה היא שהמעבר מגיאוגרפיה למפת בנטלי אינו כל כך קל, בגלל שינוי נתונים. אם המנהל הגיאו-מרחבי, כפי שאמר קודם, הוא כאב שיניים, העברת נתונים יכול להיות אפילו יותר כואב אלא אם כן בנטלי חושב על פתרונות עבור המשתמשים שלה כי לא רוצה ללכת מיום אחד למשנהו.

דיבור עם חברי הגיאומאדות עשה אנלוגיה לא נבונה, אבל מאז היום הוא יום משעמם במלון של מוות רע והשוואה כל כך בטוח, ברשותך אני אשתמש בו:

"זה לא כמו לשנות שותפים ...

... יכול להיות כמו לאבד שוב הבתולים "