أكثر

تحديد دقة GRASS النقطية

تحديد دقة GRASS النقطية


أحاول حساب الحجم باستخدام GRASSplugin. لدي معلومات المنطقة الخاصة بي في تنسيق متجه ومعلوماتي العميقة في البيانات النقطية. قرأت أنه من المهم ضبط دقة المسح قبل استخدام GRASS. كيف أعرف الدقة التي يجب استخدامها؟ المدى الخاص بي حاليًا هو العالم بأسره لهذا المشروع ولكن لا يلزم أن يكون كذلك.

هنا تيف للمنطقة التي أعمل بها: إنه موجود حاليًا في WGS84 لكنني سأحفظه باعتباره CRS مخصصًا باستخدام لامبرت ، متمركزًا في 70 درجة:


اعتمادًا على احتياجاتك ، يجب أن يكون الدقة عادةً بحيث تكون بضعة آلاف من الخلايا في كل من اتجاه X واتجاه Y كافية. إذا كان لديك طبقات خريطة للعالم كله ، فإن دقة 5 كيلومترات ستمنحك حوالي 8000 × 8000 خلية في خطوط المسح الخاصة بك. هذا "مريح". ولكن ، مرة أخرى ، عليك تحديد احتياجاتك بوضوح ، واختيار المدى + الدقة لتلبية أهدافك.


مقارنة مع دقة النقطية المختلفة

والغرض من ذلك هو مقارنة الغطاء الثلجي الكسري للبكسل الخشن بالغطاء الثلجي الثنائي (0 للثلج و 1 للثلج) للبيكسلات ذات الدقة المنخفضة. كلتا مجموعتي البيانات من نفس المنطقة وتشتركان في نفس إحداثيات WGS84.
فيما يلي طريقتان من الطرق التي أفكر بها:

كما أفهم ، فإن أخذ العينات النقطية العشوائية مستقل عن الدقة في ArcGIS. لذلك ، لديّ نقطتان ، أحدهما بدقة أكثر دقة ، يقول بالكيلومترات والآخر بدقة أفضل بالأمتار. أقوم بإنشاء نقاط عشوائية لكل من النقطيات. ثم أقوم بتشغيل أداة & quotExtract multi value to point & quot لاستخراج قيم البكسل للسمات إلى هذه النقاط. يرجى ملاحظة أن السمات لها علاقة بتغطية المنطقة الكسرية بالنسبة المئوية (0-100٪) بالبكسل لأحد النقطيات ، بينما النقطية الأخرى ذات الدقة 500 م لها قيم ثنائية / منفصلة ، أي 0/1. الهدف هو إجراء مقارنة بين قيم النقاط بناءً على تغطية المنطقة الجزئية / النسبة المئوية لكل خلية في البيانات النقطية الأكثر خشونة إلى البيانات النقطية بدقة دقة البيانات الثنائية.
لذلك على سبيل المثال في يوم معين ، تكون المنطقة المغطاة الكسرية 96٪ لبكسل خشن معين. كما أعلم ، يحتوي البكسل الخشن على ما يقرب من 165 بكسل ، وبالتالي فإن 60 من وحدات البكسل ذات الدقة الدقيقة لليوم المحدد لها قيمة 1. ومن ثم ، أقوم بإضافتها وقسمتها على 165 ، بشكل أساسي ((60/165) * 100) = 36.36 ٪. يمكنني بعد ذلك مقارنة قيمتي المساحة الكسرية أي 96٪ مع 36.36٪

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

هل ستكون هذه مقارنة صحيحة بين مجموعتي عينات النقاط العشوائية ، على الرغم من اختلاف دقة البيانات النقطية تمامًا؟

أجد عدد البكسل في البكسل الأكثر خشونة ، والذي يبلغ حوالي 165 بكسل ، وبعد ذلك بالنسبة إلى تلك التي يبلغ عددها 165 بكسل ، أقوم بإضافة قيم ثنائية واحدة لهذه البكسلات وأقسمها على إجمالي عدد وحدات البكسل وهو 165 ، وقد يمنحني هذا تغطية منطقة جزئية من الثلج. يمكنني بعد ذلك مقارنة تغطية المنطقة الكسرية للبكسل الخشن مع تغطية المنطقة الكسرية لـ 165 بكسل. ولكن حتى في هذه الحالة ، ألاحظ أن بعض وحدات البكسل تقع مباشرة على خط حدود البكسل الأكثر خشونة.

الغرض كله هو المقارنة بطريقة يمكن تجنب إعادة تشكيل القرار.

إجابة واحدة

لست واضحًا بالضبط ما الذي تريد اختباره هنا. هل لديك فرضية؟ يمكنك بالتأكيد اتباع نهج أخذ العينات في تقييم & quoturacy & quot التصنيف الثنائي الدقة المنخفضة جنبًا إلى جنب مع فرضية اختبار التكافؤ التوزيعي للفئات ذات الحدين.

هذا مثال عملي ، في R ، لما سيبدو عليه اختبار الفرضية وتقييم الدقة. تم توفير المثال في R لأن ArcGIS ليس لديه الأدوات اللازمة لإجراء هذا النوع من التحليل.

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

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

لاختبار الفرضيات ، باستخدام اختبار Kruskal-Wallis ، يمكننا تحديد ما إذا كانت توزيعات السكان متطابقة دون افتراض التوزيع الطبيعي. الفرضية الصفرية هي أن نسب الثلج في البيانات عالية الدقة هي مجموعات متطابقة عبر القيم ذات الحدين [0،1].

يمكننا أيضًا استخدام إحصاء فقدان السجل لتقييم دقة البيانات منخفضة الدقة ، بناءً على معاقبة حجم & quotmiss-التصنيف & quot. تأكد ، إذا كنت تتعامل مع النسب المئوية ، أن تقوم بإعادة التدريج إلى 0-1.

يمكننا أيضًا تقييم البيانات عن طريق تقسيم الفئتين. يقوم اختبار Kolmogorov-Smirnov بتقييم التكافؤ التوزيعي و Mann-Whitney هو اختبار غير معلمي حيث تكون الفرضية الصفرية هي أنه بالنسبة للقيم المختارة عشوائياً x و y من مجموعتين ، فإن احتمال x أكبر من y يساوي احتمال وجود y أكبر من x.

بالتناوب ، يمكنك فقط تقاطع البيانات عن طريق إجبار البيانات ذات الدقة الأقل على المضلعات واستخراج القيم من البيانات عالية الدقة. يمكنك بعد ذلك تلخيص القيم أو ربط البيانات بمجموعة بيانات وحساب إحصائية التقييم.

هنا ، نقوم بالإكراه على المضلعات واستخراج قيم نقطية عالية الدقة إلى المضلعات منخفضة الدقة (وحدات البكسل)

الآن ، ببساطة احسب بضع لحظات إحصائية

أو يمكننا أيضًا ربط القيم وحساب خسارة السجل

لحساب مشكلات المحاذاة المحتملة ، يمكنك تصفية البيانات المستخرجة الناتجة عن طريق العمود & quotcoverage_fraction & quot ، أو كما قمت لاحقًا بتغييرها إلى & quotpixel_fraction & quot. هذا هو جزء التقاطع بين كل بكسل ومضلع. لذا ، فإن 0.2 سيكون تداخلًا بنسبة 20٪ في التقاطع. يمكنك اختيار عتبة وإزالة أي قيمة بكسل لا تلتزم بالتداخل الكسري.


الحجج

متجه لأسماء الملفات النقطية GRASS 7

الافتراضي NULL إذا لم يكن NULL ، يجب أن يكون متجهًا منطقيًا يتطابق مع vname ، موضحًا أي (CELL) نقطية لإرجاعها كعامل

يمكن تعيين القيمة الافتراضية التي تم تعيينها بواسطة set.ignore.stderrOption على TRUE لإسكات نظام () الإخراج إلى خطأ قياسي لا ينطبق على أنظمة تشغيل Windows

افتراضيا أخذ القيمة التي تم تعيينها بواسطة set.pluginOption NULL يقوم بالكشف التلقائي ، ويتغير إلى FALSE إذا كان vname أطول من 1 ، وسيتم تشغيل فحص سلامة البيانات النقطية والمنطقة الحالية ، وستعود الوظيفة إلى FALSE إذا تم العثور على عدم تطابق إذا TRUE ، المكون الإضافي متاح ويجب قراءة البيانات النقطية بمنطقتها الأصلية ودقة الوضوح إذا تم استخدام المكون الإضافي ، ولا يتم احترام أي وسيطات أخرى بخلاف mapset

الافتراضي NULL ، إذا كان البرنامج المساعد هو TRUE ، فسيتم اكتشاف مجموعة الخريطة للملف المراد استيراده تلقائيًا إذا لم يكن NULL وإذا كان المكون الإضافي TRUE ، فستتجاوز سلسلة الأحرف مجموعة map المكتشفة تلقائيًا ، وإلا سيتم تجاهلها

(غير فعال ، ينطبق فقط على استخدام البرنامج المساعد) افتراضيًا يأخذ القيمة المحددة بواسطة set.useGDALOption استخدم البرنامج المساعد و readGDAL إذا تم الكشف عنه تلقائيًا أو البرنامج المساعد = TRUE أو لكتابة writeGDAL و GTiff و r.in.gdal ، إذا كان FALSE باستخدام r.out .bin أو r.in.bin

الافتراضي صحيح - تنظيف الاتصالات المفتوحة المحتملة المستخدمة لقراءة البيانات الوصفية قد يتم تعيينها على FALSE لتجنب الآثار الجانبية للاتصالات الأخرى المفتوحة من قبل المستخدم التي يتم قطعها

الافتراضي "GTiff" اسم برنامج تشغيل GDAL صالح قابل للكتابة لتحديد تنسيق الملف للملفات الوسيطة

الافتراضي NULL وإلا قيمة السلسلة لملحق اسم ملف برنامج التشغيل المطلوب

تقوم TRUE افتراضيًا بإرجاع كائن SpatialGridDataFrame ، إذا كان FALSE ، فقم بإرجاع قائمة بكائن GridTopology وقائمة من النطاقات و proj4string انظر المثال أدناه

كائن SpatialGridDataFrame للتصدير إلى GRASS كطبقة نقطية

رقم عمود السمة أو الاسم

بشكل افتراضي NULL ، وفي هذه الحالة يتم تعيينه على قيمة واحدة أقل من floor () من قيم البيانات ، وإلا فإن قيمة NODATA صحيحة (مطلوبة لتكون عددًا صحيحًا بواسطة GRASS r.out.bin)

خطأ افتراضي ، إذا أدرجت TRUE "الكتابة فوق" في قيمة وسيطة الإشارات إذا لم تكن موجودة بالفعل للسماح بالكتابة فوق البيانات النقطية GRASS الحالية


الحجج

متجه لأسماء الملفات النقطية GRASS 7

الافتراضي NULL إذا لم يكن NULL ، يجب أن يكون متجهًا منطقيًا يتطابق مع vname ، موضحًا أي (CELL) نقطية لإرجاعها كعامل

يمكن تعيين القيمة الافتراضية التي تم تعيينها بواسطة set.ignore.stderrOption على TRUE لإسكات إخراج النظام () إلى الخطأ القياسي لا ينطبق على أنظمة تشغيل Windows

افتراضيا أخذ القيمة التي تم تعيينها بواسطة set.pluginOption NULL يقوم بالكشف التلقائي ، ويتغير إلى FALSE إذا كان vname أطول من 1 ، وسيتم تشغيل فحص سلامة البيانات النقطية والمنطقة الحالية ، وستعود الوظيفة إلى FALSE إذا تم العثور على عدم تطابق إذا TRUE ، المكون الإضافي متاح ويجب قراءة البيانات النقطية بمنطقتها الأصلية ودقة الوضوح إذا تم استخدام المكون الإضافي ، ولا يتم احترام أي وسيطات أخرى بخلاف mapset

الافتراضي NULL ، إذا كان البرنامج المساعد هو TRUE ، فسيتم اكتشاف مجموعة الخريطة للملف المراد استيراده تلقائيًا إذا لم يكن NULL وإذا كان المكون الإضافي TRUE ، فستتجاوز سلسلة الأحرف مجموعة map المكتشفة تلقائيًا ، وإلا سيتم تجاهلها

(غير فعال ، ينطبق فقط على استخدام البرنامج المساعد) افتراضيًا يأخذ القيمة المحددة بواسطة set.useGDALOption استخدم البرنامج المساعد و readGDAL إذا تم الكشف عنه تلقائيًا أو البرنامج المساعد = TRUE أو لكتابة writeGDAL و GTiff و r.in.gdal ، إذا كان FALSE باستخدام r.out .bin أو r.in.bin

الافتراضي صحيح - تنظيف الاتصالات المفتوحة المحتملة المستخدمة لقراءة البيانات الوصفية قد يتم تعيينها على FALSE لتجنب الآثار الجانبية للاتصالات الأخرى المفتوحة من قبل المستخدم التي يتم قطعها

الافتراضي "GTiff" اسم برنامج تشغيل GDAL صالح قابل للكتابة لتحديد تنسيق الملف للملفات الوسيطة

الافتراضي NULL وإلا قيمة السلسلة لملحق اسم ملف برنامج التشغيل المطلوب

تقوم TRUE افتراضيًا بإرجاع كائن SpatialGridDataFrame ، إذا كان FALSE ، فقم بإرجاع قائمة بكائن GridTopology وقائمة من النطاقات و proj4string انظر المثال أدناه

كائن SpatialGridDataFrame للتصدير إلى GRASS كطبقة نقطية

رقم عمود السمة أو الاسم

بشكل افتراضي NULL ، وفي هذه الحالة يتم تعيينه على قيمة واحدة أقل من floor () من قيم البيانات ، وإلا فإن قيمة NODATA صحيحة (مطلوبة لتكون عددًا صحيحًا بواسطة GRASS r.out.bin)

خطأ افتراضي ، إذا أدرجت TRUE "الكتابة فوق" في قيمة وسيطة الإشارات إذا لم تكن موجودة بالفعل للسماح بالكتابة فوق البيانات النقطية GRASS الحالية


ضبط دقة GRASS النقطية - نظم المعلومات الجغرافية

بولدر ، أول أكسيد الكربون 80303
الولايات المتحدة الأمريكية
[email protected]

يصف هذا المستند كيفية الحصول على وتثبيت وتكوين نظام معلومات جغرافية علمي عام قوي (GIS): نظام دعم تحليل الموارد الجغرافية (GRASS). يوفر معلومات حول الموارد الأخرى لمعرفة المزيد حول GRASS و GIS بشكل عام للحصول على البيانات وما إلى ذلك.

يشجع هذا المستند أيضًا مجتمع Linux على التفكير في تحسين هذا البرنامج كتطبيق رئيسي لنظام UNIX / Linux. ("متى سيتم دمج Linux مع المجال العام أو" التطبيقات القاتلة "ذات الترخيص العام لـ Linux"؟) لمزيد من المعلومات حول هذا الموضوع ، راجع القسم 8 أدناه.

هناك طرق عديدة لوصف نظام المعلومات الجغرافية. فيما يلي ثلاثة تعريفات عملية (من David A. Hastings ، 1992 ، نظم المعلومات الجغرافية: أداة لتحليل وتفسير علوم الأرض):

(الحد الأدنى من التعريف): نظام المعلومات الجغرافية هو نظام أجهزة / برمجيات للتخزين والإدارة (مع النسخ الورقية أو الرسوم على الشاشة) وقدرات استرجاع انتقائية للبيانات ذات المرجعية الجغرافية. غالبًا ما يتم استخدام تعريفات مثل هذا من قبل البائعين والمستخدمين لنظم المعلومات الجغرافية المتجهية فقط ، والتي تهدف إلى إدارة معقدة وإخراج بيانات رسم الخرائط.

(تعريف موازٍ): نظام المعلومات الجغرافية هو نظام أجهزة / برمجيات لإدارة وعرض البيانات المكانية. إنه مشابه لنظام إدارة قاعدة البيانات التقليدي ، حيث نفكر الآن في المصطلحات المكانية بدلاً من الجدول ، وحيث يسمح "كاتب التقرير" الآن بإخراج الخرائط وكذلك الجداول والأرقام. وبالتالي يمكننا اعتبار نظم المعلومات الجغرافية "قواعد بيانات مكانية" على عكس "نظم إدارة قواعد البيانات الجدولية" التقليدية. قليل من الناس يستخدمون هذا التعريف ، ولكن قد يساعد في شرح نظم المعلومات الجغرافية لمستخدم نظم إدارة قواعد البيانات.

(تعريف أكثر عدوانية): نظام المعلومات الجغرافية هو نظام من الأجهزة والبرامج والبيانات التي تسهل تطوير وتعزيز ونمذجة وعرض البيانات متعددة المتغيرات (على سبيل المثال متعددة الطبقات) ذات المرجعية المكانية. يقوم ببعض الوظائف التحليلية بنفسه ، ومن خلال تحليله ، يساعد الاسترجاع الانتقائي وقدرات العرض المستخدم على تحليل البيانات وتفسيرها بشكل أكبر. بتكوينه بشكل صحيح ، يمكن لنظام المعلومات الجغرافية (GIS) نمذجة (على سبيل المثال إعادة الإنشاء الصناعي) لميزة أو ظاهرة كدالة لميزات أو ظواهر أخرى قد تكون ذات صلة - حيث يتم تمثيل جميع الميزات أو الظواهر (تتميز) بالبيانات المكانية والجداول ذات الصلة. أحيانًا ما تكون الأهداف التحليلية الموصوفة هنا مثيرة للجدل - وغالبًا ما يتم التشدق بها من قبل متخصصي نظم المعلومات الجغرافية لرسم الخرائط الذين لم يروا بعد ما يمكن إنجازه علميًا من خلال عدد قليل من نظم المعلومات الجغرافية التي تتجاوز مناهج رسم الخرائط.

يمكن العثور على تعريف آخر في جامعة إدنبرة.

GRASS (نظام دعم تحليل الموارد الجغرافية) هو نظام GIS قائم على البيانات النقطية ونظام Vector GIS ونظام معالجة الصور ونظام إنتاج الرسومات. تم إنشاؤه بواسطة سلاح المهندسين بالجيش الأمريكي ومختبر أبحاث هندسة التضييق (الولايات المتحدة الأمريكية / CERL) وعززه العديد من الآخرين ، ويستخدم على نطاق واسع في المكاتب الحكومية والجامعات والمنظمات التجارية في جميع أنحاء العالم هو مكتوب في الغالب بلغة C لمختلف الأجهزة القائمة على UNIX. Linux هو أحد تطبيقاته الأكثر قوة.

يحتوي GRASS على أكثر من 40 برنامجًا لتقديم الصور على الشاشة والورق أكثر من 60 برنامجًا لمعالجة البيانات النقطية وأكثر من 30 برنامجًا لمعالجة المتجهات ، ما يقرب من 30 برنامجًا لمعالجة الصور متعددة الأطياف ، و 16 برنامجًا لإدارة البيانات و 6 برامج لإدارة الملفات.

تكمن قوة GRASS في عدة مجالات. واجهة المستخدم البسيطة تجعله منصة مثالية لأولئك الذين يتعلمون عن نظم المعلومات الجغرافية لأول مرة. يمكن للمستخدمين الراغبين في كتابة التعليمات البرمجية الخاصة بهم القيام بذلك عن طريق فحص كود المصدر الحالي ، والتفاعل مع مكتبات GIS الموثقة ، وباستخدام دليل مبرمجي GRASS. يتيح ذلك دمج وظائف أكثر تعقيدًا بشكل كامل داخل GRASS.

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

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

تم النسخ من Project Assist Intro إلى GRASS.

في أوائل الثمانينيات من القرن الماضي ، بدأ مختبر أبحاث هندسة البناء التابع لفيلق المهندسين بالجيش الأمريكي (الولايات المتحدة الأمريكية / CERL) في شامبين ، إلينوي ، في استكشاف إمكانيات استخدام أنظمة المعلومات الجغرافية لإجراء البحوث البيئية ، والتقييمات ، ورصد وإدارة الأراضي تحت الإشراف. وزارة الدفاع الأمريكية. كان جزء من الدافع وراء هذا الإجراء هو المسؤولية الجديدة عن البيئة المشفرة في قانون السياسة البيئية الوطنية في أواخر السبعينيات.

أجرى بيل جوران من الولايات المتحدة الأمريكية / CERL مسحًا لنظم المعلومات الجغرافية المتاحة ، بافتراض أنه يمكنه العثور على العديد من الأنظمة القادرة على التحليل البيئي ، والتي يمكنه من خلالها اختيار واحد أو أكثر للتوصية باستخدامه بواسطة CERL وربما أنظمة أخرى في وزارة الدفاع. ومع ذلك ، فقد فوجئ بعدم العثور على نظم المعلومات الجغرافية التي تلبي احتياجاته. ما بدأ كعملية اختيار تحول إلى تمرين تصميم لبرنامج تطوير نظم المعلومات الجغرافية الخاص به.

استأجرت USA / CERL العديد من المبرمجين ، وبدأت بكتابة المتجه النقطي الهجين GIS لبيئة VAX UNIX. هذا جعل الفريق واحدًا من أوائل من طور بجدية GIS لـ UNIX. على الرغم من أنهم لا يزالون يواجهون تحديات مع إصدارات مختلفة من UNIX ، فقد طوروا إجراءات الترميز في معيار ANSI UNIX ، وتجنب "التغيير والتبديل" في الكود تجاه أي نكهة خاصة ببائع معين من UNIX.

طور GRASS أسلوب برمجة يتميز بـ:

استخدام مكتبات UNIX حيثما أمكن ، بالإضافة إلى إنشاء مكتبات GRASS لأعمال GIS المتكررة مثل فتح الملفات النقطية التي قد تكون مضغوطة (عن طريق ترميز طول التشغيل) أو لا.

القدرة على التعامل مع كلا نوعي بيانات GIS الرئيسيين: النقطية والمتجه.

تفضيل معالجة البيانات النقطية ، حيث كان ترميز التحليل العلمي أسهل باستخدام نماذج البيانات النقطية (مقارنة بنماذج البيانات النقطية).

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

القدرة على التعامل مع الشبكات النقطية بمناطق تغطية مختلفة. مرة أخرى ، كان هذا خروجًا عن التقليد النقطي المتمثل في جعل جميع الشبكات متطابقة في التغطية الجغرافية.

القدرة على تشغيل ملفات البيانات النقطية ذات الطول ، من أجل تقليل أحجام الملفات بشكل كبير في معظم الملفات.

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

قبول نماذج البيانات المعيارية الواقعية. بينما أنشأ المنافسون تنسيقات بيانات مرهقة (وسرية في كثير من الحالات) ، قبلت GRASS تنسيق متجه الخط الرقمي القياسي الفعلي وتنسيق شبكة نقطية ثنائية غير معنون. تخلى GRASS لاحقًا عن DLG كتنسيق ملف متجه داخلي ، وترك تنسيقه النقطي يتطور. ومع ذلك ، لا تزال DLG وشبكة البيانات النقطية الثنائية غير المعنونة تنسيقات يتم التعامل معها بشكل روتيني لـ GRASS ، وتنسيقاتها الجديدة مفتوحة مثل التنسيقات السابقة.

تمت إدارة رمز GRASS في عدة أدلة. تم وضع المساهمات الأولية في دليل src.contrib. تم نقل المزيد من التعليمات البرمجية الثابتة إلى دليل src.alpha. بعد البقاء في src.alpha لدورة إصدار كاملة واحدة ، انتقل الكود ، مع إصلاحات الأخطاء الناتجة ، إلى المستوى الأكثر احترامًا ، دليل src.

أشرف على GRASS ثلاثة مستويات من لجان الرقابة. تحتفظ الولايات المتحدة الأمريكية / CERL بالمسؤولية النهائية عن GRASS. نفذت معظم تطوير GRASS ، ونفذت الإدارة اليومية لاختبار وإصدار GRASS. اجتمعت لجنة GRASS التوجيهية المشتركة بين الوكالات (GIASC) ، المؤلفة من وكالات فيدرالية أخرى ، بشكل نصف سنوي لمراجعة تقدم التنمية وتقييم الاتجاهات المستقبلية لـ GRASS. (حضر المشاركون الأكاديميون والتجاريون في GRASS أيضًا اجتماعات GIASC وكان جزء فقط من كل اجتماع "فيدراليًا للوكالات فقط." أصبح GRASS في النهاية اسميًا ورسميًا "منتجًا" لـ GIASC ، على الرغم من اعتراف الجميع بالدور القيادي للولايات المتحدة الأمريكية / CERL. اجتمعت لجنة التوجيه العسكرية بشكل دوري لمراجعة التقدم الذي أحرزته GRASS في خدمة هدفها الأصلي: تلبية احتياجات وزارة الدفاع لتقييم وإدارة بيئة الأراضي العسكرية.

تفاعل الجمهور مع CERL و GIASC من خلال مركز معلومات GRASS التابع للولايات المتحدة الأمريكية / CERL. كان اختبار GRASS Beta واسع الانتشار ومكثف جدًا للمستخدمين الرئيسيين لـ GRASS. اختار العديد من المستخدمين الرائدين ، مثل National Park Service و Soil Conservation Service ، GRASS باعتباره GIS الرئيسي أو الوحيد. لقد قطعوا التزامات كبيرة لتعزيز واختبار GRASS ، لكنهم اعتبروا أن هذا الاستثمار يستحق وقتهم. قالوا إن تأثيرهم على اتجاه GRASS أكبر من تأثيرهم على أي نظام بديل معروف. كما شعروا أنه على الرغم من جهودهم الكبيرة ونفقاتهم في دعم GRASS ، إلا أنهم حصلوا على صفقة في القوة المناسبة للدولار.

اعتمدت العديد من الجامعات GRASS كبيئة تدريب وبحث مهمة. أجرى العديد دورات قصيرة للجمهور ، بالإضافة إلى استخدام GRASS في مناهجهم الخاصة. ومن الأمثلة على هؤلاء المستخدمين الأكاديميين الرائدين لـ GRASS جامعة سنترال واشنطن ، وجامعة أركنساس ، وجامعة تكساس A & # 38 M ، وجامعة كاليفورنيا في بيركلي ، وجامعة روتجرز.

على الرغم من أن GRASS تلقت بعض الانتقادات (يقول البعض) لكونها جيدة جدًا وعلنية جدًا ، فقد تم اقتراضها أيضًا بشكل متحرر من قبل بعض مطوري الأنظمة الأخرى. على الرغم من أن المجموعة الأولى قد تكون قد نظرت إليها على أنها منافسة غير عادلة ، إلا أن المجموعة الثانية ربما لاحظت أنها لم تكن حق المؤلف ، وكانت بمثابة اختبار قيم لمفاهيم نظم المعلومات الجغرافية. حصل GRASS على جائزة من جمعية نظم المعلومات الحضرية والإقليمية (URISA) لبرامج الجودة في عام 1988.

مع تطور CERL و GRASS خلال أواخر الثمانينيات وأوائل التسعينيات ، حاولت CERL خفض التكاليف العامة المرتبطة بدعم إصدار المجال العام. لقد أنشأت ومولت في البداية مؤسسة Open GRASS ، بالتعاون مع العديد من المستخدمين الرئيسيين لـ GRASS. تطورت مؤسسة Open GRASS منذ ذلك الحين إلى اتحاد GIS المفتوح ، والذي يهدف إلى مزيد من التشغيل البيني الشامل على مستوى واجهة المستخدم والبيانات ، ولكن يبدو أنه لا يستفيد من اختبار GIS الرئيسي المفتوح (GRASS).

في أواخر عام 1997 ، أخذت مجموعة في جامعة بايلور زمام المبادرة في تطوير موقع ويب جديد لـ GRASS. يحتوي هذا الموقع سريع التطور على كود مصدر GRASS 4.1 وثنائيات Sun Solaris ووثائق GRASS 4.1 ودليل على الإنترنت. بحلول نوفمبر 1997 نشر هذا الموقع الإصدار الأول من الكود المصدري GRASS 4.2 والثنائيات حاليًا لـ Sun Solaris) مع نظامي Linux و Windows NT قيد الدراسة). يتضمن GRASS 4.2 العديد من التحسينات من موقع CERL ، بالإضافة إلى بعض التحسينات الخاصة بايلور. تظهر وثائق GRASS 4.2 أن المجموعة تشجع التعاون في مزيد من تطوير GRASS ، وتبحث عن شركاء. وهي تأمل في زيادة استخدام شبكة الويب العالمية في تطوير وإدارة GRASS. جاري تطوير GRASS 5 وتجميعه. يرتبط الموقع أيضًا بموقع Blackland GRASS في جامعة Texas A & # 38 M ، لأولئك الذين يرغبون في وصول غير مكلف للغاية إلى GRASS لنظام التشغيل Windows 95.

ملاحظة: تقوم مجموعة مخصصة (بما في ذلك أنا) باستكشاف القضية الأساسية المتمثلة في استمرار ، وإعادة تكوين ، وربما زيادة ، قيمة GRASS كقاعدة اختبار عامة لتقنية نظم المعلومات الجغرافية. إنه يستكشف رعاية اختبار وإصدار GRASS5.0 ، ويستكشف إمكانيات نموذج إدارة أكثر توزيعًا لتصميم GRASS وتطويره. إنه يستكشف عالم برمجيات معالجة البيانات المكانية للمجال العام (بما في ذلك المعلومات الجغرافية وأنظمة معالجة الصور) ، وربما أنظمة إدارة قاعدة البيانات الجدولية. كيف يمكن تحسين هذه المعرفة (1) كأداة اختبار عامة ومفتوحة لمثل هذه التكنولوجيا و (2) استخدامها بشكل أفضل من قبل الجمهور؟ هل يمكن أن يتضمن هذا نموذج إدارة Linux ، ربما؟ انظر القسم 8 لمزيد من المناقشة حول هذا الموضوع.

الحد الأدنى من المتطلبات ما يلي:

8 ميغا بايت من الذاكرة (طبعا المزيد أفضل ..)

100 ميغا بايت من مساحة القرص الحرة

40 ميغابايت لشفرة المصدر (والتي يمكنك تجاهلها إذا قمت فقط بتثبيت ثنائيات Linux)

؟ للبيانات (يمكن ملء الحفرة الحقيقية بالبيانات ، إذا اخترت ذلك)

يعمل GRASS على إصدارات Linux kernel القديمة مثل 1.2.13 (انظر المزيد من المعلومات في الملاحق لمختلف الثنائيات المحددة).

سيتم تشغيل GRASS في وضع النص. ومع ذلك ، لعرض البيانات ، ستحتاج إلى X. إذا كنت لا تزال تستخدم إصدارًا من X ، فمن المحتمل أن يعمل مع GRASS.

إذا وجدت أي متطلبات أخرى للأجهزة / أنظمة التشغيل يجب ذكرها ، فيرجى إبلاغي بذلك!

كان GRASS متاحًا على شريط من شركات مختلفة وقعت اتفاقيات توزيع مع USA / CERL. تدعم هذه الشركات عادةً بيئات منصات معينة ، مثل Masscomp و Sun و DEC و Hewlett Packard و IBM (risc) وأجهزة الكمبيوتر (تعمل ببعض نكهات UNIX) و Macintosh (تشغيل AUX). حتى وقت قريب ، كانت نكهات UNIX التي تعمل على أجهزة الكمبيوتر بشكل عام منخفضة للغاية ، أو تتطلب الكثير من دعم البرمجة الإضافي (مثل محركات البرمجة للوحات الرسوم عالية الجودة مثل لوحات Number Nine التي تعود إلى عدة سنوات) لتكون مستقرة أو كاملة. ومع ذلك ، مع أنظمة قوية مثل Linux ، فإن هذه المشكلة هي التاريخ. وبالمثل ، فإن قلة من الناس يحصلون على GRASS على شريط ، على الرغم من أن القليل منهم يفعل ذلك على قرص مضغوط.

الطريقة الرئيسية للحصول على GRASS هي الحصول عليها عبر بروتوكول نقل الملفات المجهول من:

اعتبارًا من تاريخ هذا الإصدار من mini-HOWTO ، تمتلك Baylor كود مصدر لـ GRASS 4.1 و 4.2 ، بالإضافة إلى ثنائيات Sun Solaris المجمعة. تم ربط Blackland GRASS لنظام التشغيل Windows 95 / NT من هذا الموقع. تفكر Baylor أيضًا في ثنائيات Linux و Windows NT الخاصة بها. يجب أن تكون قادرًا على تجميع شفرة مصدر Baylor ضمن Linux بنفسك ، باستخدام المعلومات الموجودة في HOWTO المصغر هذا.

يصف الملحق أ كيفية الحصول على ثنائيات مجمعة GRASS4.13 من USA / CERL وتثبيتها. (انظر القسم 6 قبل تثبيت GRASS!)

يصف الملحق ب كيفية الحصول على ثنائيات مجمعة GRASS4.15 من USA / CERL وتثبيتها. (انظر القسم 6 قبل تثبيت GRASS!)

يصف الملحق C كيفية الحصول على شفرة المصدر GRASS4.14 و GRASS4.15 من الولايات المتحدة الأمريكية / CERL ، بالإضافة إلى كود المصدر GRASS4.2 من جامعة بايلور. (انظر القسم 6 قبل تثبيت GRASS!)

مطورو توزيع Linux! هل أنت مهتم بتضمين GRASS مع التوزيع الخاص بك؟ تذكر أن شفرة مصدر GRASS موجودة في المجال العام غير المقيد تمامًا وخالي من حقوق النشر. قد يكون التوزيع الخاص بك أكثر قيمة إذا كان يحتوي على كود مصدر و / أو ثنائيات مجمعة لـ GRASS.

تصف الملاحق A و B و C كيفية الحصول على GRASS وتثبيته. قبل تثبيت GRASS فعليًا ، سيتعين عليك تحديد مكان وضع ثلاثة أجزاء من النظام:

ثنائيات GRASS وشفرة المصدر (إذا قمت بتثبيت هذا) وصفحات الدليل والوثائق وما شابه. يضع العديد من الأشخاص هذه الأشياء خارج / usr / local (على سبيل المثال / usr / local / grass / bin، / usr / local / grass / src).

الأدوات المساعدة GRASS القابلة للتنفيذ و gmake. قام بعض الأشخاص بإيقاف هذه الأشياء / usr / local (على سبيل المثال /usr/local/grass/grass4.1 و gmake4.1 أو /usr/local/bin/grass4.1 و gmake4.1).

أدلة بيانات GRASS. هذه يمكن أن تذهب إلى أي مكان ، كما هي محددة في ملفات التكوين.

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

/user/grass4.1/bin (عادةً ما أضع هنا grass4.1 و gmake4.1) / data / dev / etc / man / src /src.alpha /src.contrib

أقوم حاليًا ببناء موقع GRASS5.0 ، والذي ينتقل بعد ذلك إلى:

/ user / grass5 / bin / data (تغيرت بعض تنسيقات بيانات GRASS5.) / dev / etc

يعد دليل تثبيت GRASS (الموضح في القسم 10 والملحق C) مفيدًا لتشغيل GRASS ، حتى إذا قمت فقط بتثبيت الثنائيات كما هو موضح في الملحقين أ و ب. يرجى عدم التغاضي عن أحد التفاصيل المهمة: معظم عمليات تثبيت GRASS مستخدم منفصل من حسابات مدير البرامج وأذونات UNIX. يجب عليك إنشاء حساب مستخدم "عشب" (علامات الاقتباس هنا للتأكيد ، ويجب ألا تكون جزءًا من حساب المستخدم الفعلي للمستخدم) على محطة العمل الخاصة بك. يجب أن يتم تنفيذ جميع عمليات التثبيت والتهيئة الخاصة بالعشب بواسطة "عشب" المستخدم. قم بإلغاء تحديد (أو ملفات "cpio" ، قم بتشغيل أدوات تكوين الإعداد ، وقم بتشغيل ملفات Gmakefiles (إصدارات GRASS من ملفات makefiles) ، وقم بتحرير ملفات التكوين كمستخدم "عشب". ثم نادرًا ما شغّل GRASS كمستخدم "عشب". (أنا فقط أشغل GRASS كـ المستخدم "عشب" عندما أقوم بإنشاء ملفات بيانات أرشيفية في مجموعة الخرائط الدائمة.) يتم ذلك لنفس السبب إلى حد كبير مثل عدم تشغيل برنامج المستخدم مثل "جذر" المستخدم. يمكنك أن تفعل الكثير من الضرر مثل المستخدم "العشب"!

بالإضافة إلى التعليمات الواردة في هذه الملاحق ، والمعلومات الواردة في دليل تثبيت GRASS ، لديك بعض التدبير المنزلي الإضافي الذي يجب القيام به ، مثل تطوير قاعدة بيانات. يمكنك الحصول على قواعد بيانات نموذجية من USA / CERL (دليل pub / grass / grass4.1 / data at مجهول "ftp moon.cecer.army.mil") ، ابدأ من نقطة الصفر باتباع الإرشادات الواردة في دليل مبرمج GRASS (وإلى درجة أقل ، مدفونة في الأوصاف الوظيفية للدليل المرجعي لمستخدم GRASS).

أنا شخصياً أوصي بأن تبدأ بقواعد البيانات العالمية و Spearfish المتاحة من USA / CERL:

تغطي قاعدة بيانات سبيرفيش صفحتين طوبوغرافيتين مدة كل منهما 7.5 دقيقة في شمال بلاك هيلز في ساوث داكوتا بالولايات المتحدة الأمريكية. إنه في الإسقاط العالمي المستعرض مركاتور. تم إنشاؤه في الأصل من قبل لاري باتن (الآن من مكتب معهد أبحاث النظم البيئية في بولدر ، كولورادو) بينما كان يعمل مع مركز بيانات EROS التابع للمسح الجيولوجي الأمريكي في ساوث داكوتا. تم تعزيز قاعدة البيانات من قبل USA / CERL والمتعاونين. إنه مثال ممتاز وجيد الاستخدام (هناك العديد من المواد التدريبية المتاحة لـ GRASS مع قاعدة البيانات هذه) لمشروع GIS على مستوى المقاطعة في إسقاط UTM.

تم تطوير قاعدة البيانات العالمية بواسطة Bob Lozar من USA / CERL لنموذج أولي لقاعدة بيانات "إسقاط" خطوط الطول والعرض في GRASS للدراسة البيئية العالمية ودعم القرار.

بدءًا من هذين المثالين ، يمكنك بناء قواعد البيانات الخاصة بك في توقعات UTM وخطوط الطول والعرض. (لاحظ أن الكثير من الناس لا يسمون خطوط الطول والعرض إسقاطًا. ويختلف آخرون ، قائلين إن أي شيء ينقل سطح الأرض إلى بعدين هو إسقاط .. سنبتعد عن هذا النقاش هنا. وغني عن القول ، lat- يتم التعامل مع lon مثل الإسقاطات الأخرى بواسطة برنامج الكمبيوتر.)

دعم لبرنامج المجال العام؟ يقولون بأي حال من الأحوال! في الواقع ، بصفتك مستخدمًا لنظام Linux ، فمن المحتمل أنك تعرف أفضل.

بدأت GRASS بإنشاء مكتب معلومات GRASS في USA / CERL. كان هناك أيضًا مستخدمون نشطون جدًا خارج الولايات المتحدة الأمريكية / CERL ، والذين قدموا دعمًا قيِّمًا للمستخدم. عقدت GRASS اجتماعات المستخدمين السنوية ، وخوادم القوائم للمستخدمين والمطورين ، إلخ. قدمت الشركات خدمات دعم ذات قيمة مضافة على أساس تعاقدي أو رسوم.

طور العديد من الأشخاص كتبًا ومواد تدريبية قيمة على GRASS. اعتادت العديد من الجامعات إجراء دورات تدريبية في GRASS. لا أعرف كم من هؤلاء مستمرون. إذا كانت الدورات التدريبية تهمك ، فحاول أن تسأل عن مجموعة أخبار usenet comp.infosystems.gis (انظر أدناه للحصول على المزيد حول مجموعة الأخبار هذه).

"الكتب" القيمة المتوفرة على الإنترنت مذكورة في المراجع (القسم 10).

يتم تسليط الضوء على المواد التدريبية المستندة إلى شبكة الويب العالمية ، بما في ذلك التدريب في GRASS ، في الدورة التدريبية القصيرة لـ CyberInstute في GIS (ثم قم بالمسح بحثًا عن رابط (روابط) إلى البرامج التعليمية المستندة إلى الويب في GIS).

One of the better GRASS tutorials is Project Assist's - Intro to GRASS

After getting trained by the books and Web-based tutorials noted just above, where do you turn to for specific advice.

"how do I find data on this topic for this area?"

"how do I convert these data for use in my Aardvark GIS?"

"how do I get this function to work in my Aardvark GIS?"

"which GIS can I use to solve my particular problem?"

GRASS used to be one of the top GISs discussed on this group. Traffic in GRASS is dropping slightly, as its user community matures. However, there are usually answers to your questions, if you post them. You might also do a "power search" on subject:GRASS [& your own subject of interest here?] and newsgroup:comp.infosystems.gis in DejaNews to see what might appear from the usenet archives.

Excellent question! Several possible answers have been thrown out:

USA/CERL's announced intention is to use GRASS and COTS (commercial off-the-shelf software) for internal uses, to leave the GRASS public web- and ftp-site on its system indefinitely, and to sign cooperative research and development agreements with three companies: (1) the Environmental Sciences Research Institute (ESRI), (2) Intergraph, and (3) Logiciels et Applications Scientifiques (L.A.S.) Inc. The first two agreements encouraged the incorporation of GRASS concepts into ESRI's and Intergraph's commercial GISs. The third encouraged the adaptation of GRASS' concepts and code into a new commercial GIS by L.A.S. L.A.S. also offered to encourage the continuation of a public domain GRASS, as a viable stand-alone system and as a potential source of new ideas and code for L.A.S.'s GRASSLAND. One observer noted that the first two agreements might be akin to someone signing Linux over to Microsoft. The same observer considers the experiment by/with L.A.S. to be an interesting possibility - an attempt to keep viable public domain and commercial versions of GRASS.

Some people believe that GRASS will wither without USA/CERL's central management. Some believe that the Open GIS Consortium will successfully guide industry into an open architecture that will benefit all developers and users. Others believe that OGIS' effort will lead to a cacophony of almost similar (but not quite interoperable) vendor-specific "standards," so the loss of GRASS as an open development platform will be felt sorely.

Some people believe that developments on some campuses and other sites may result in those institutes keeping GRASS for awhile, but in non-standard forms. In short, GRASS will undergo "cell division" and lead to a cacophony of internally valuable, but externally unused, GISs.

Others hope that GRASS' previous management model under USA/CERL has left it ready for a new model. Perhaps:

Under a new mentor, such as NASA (which needs an open, powerful and scientific, GIS integrated with image processing system for its Earth Observing System).

Under a distributed management model. perhaps somewhat like Linux?

Perhaps a bit of a hybrid? Perhaps a Web-based effort could spawn a series of usenet discussion groups beginning with

comp.infosystems.gis.grass, and evolving to:

Clearly the topics are a bit tongue-in-cheek. However, under this model, a Central Committee (including representation of academic, public service [government and nongovernmental organizations], commercial distributors and value added firms, programmers, and users) would guide overall grass development and testing. The other special interest groups would serve their user communities. Academics, for example, would involve GIS and GRASS education, but would also try to pull GRASS development in its direction. Value added commercial developers would serve their own interests, including trying to pull GRASS development in a direction that would help their businesses. Users would help each other learn GRASS, develop workarounds to bugs, etc.

GRASS offers considerable potential for:

Use as a scientific, as well as a traditional graphically oriented GIS. Many GISs can make pretty maps. Many of those GISs cannot easily perform certain scientific analytical functions as easily or powerfully as GRASS. GRASS was designed and developed in response to a perceived need for scientific GIS, specifically for environmental analysis, and the environmental management/protection of public lands. Incidentally, there is at least one Web-based GRASS version. GRASSLINKS , developed at The University of California at Berkeley , uses Web forms to submit commands to the server, which creates .gif-based display output, places the images into pages, and serves them up to the requester. More on that later.

Education. GRASS is easier to teach and learn than some other GISs. It is easier to modify (for those that want to learn GIS as computer science, rather than as "geography") than most other GISs that come without source code and treat the program as a magical black box. And, of course, it is more affordable for the student of GIS than many other GISs.

Applications research and development. Many universities have used GRASS. Its available source code, easy modification, easy scriptability, etc., give it distinct advantages over some more closed systems.

Public Service. GRASS has been used as a scientific GIS for many public service applications. There is considerable value in continuing a robust GIS that can ba packaged with any UNIX workstation. There is considerably more value if that UNIX workstation universe can include Linux (but is not constrained only to Linux).

GIS research and development. For example - do you want to experiment with a different data model? Add it to GRASS!

Commercialization. This document gives contact information for a commercial version of GRASS. That company (and perhaps others?) may welcome your help in enhancing/supporting their product.

Who would be the Linus Torvalds equivalent in this management model? Perhaps no single person. I have been involved in GRASS for about a decade, when GRASS was the only GIS that satisfied my needs in scientific data management and GIS application. Indeed, I had been a dedicated avoider of the user-unfriendly UNIX environment until GRASS forced me to learn it. Several senior GRASS developers are active in GRASS-related activities and would like to see the continued vitality of an open GRASS. It's likely that a reborn GRASS would attract a new crop of friends. Thus the concept of a "Central Committee" to collectively lead GRASS' transition to a more open management and development style.

In short, the Linux community has an opportunity to take under its wing a killer ap. GRASS' current public domain status is slightly different from Linux's. However, that status could be discussed.

Comments would be appreciated!

This document was prepared by a Federal civil servant in support of his work (but mostly on his own time). It is NOT SUBJECT TO COPYRIGHT.

I believe that the contents of this document are accurate. However, if you use this document, you accept the risks for any errors in this document (and in any documents that are cited here).

I would greatly appreciate help in correcting any errors, or in enhancing this document. However, "my time is limited" in dealing with this issue. Any help that you can provide, that also helps me to more efficiently respond to your interest, is more likely to be responded to quickly. A complaint might be appreciated, but a suggested improvement that includes draft wording might be REALLY appreciated.

For general reference material on GIS, try a very good technical bookstore (in many cases these are campus bookstores at schools with good GIS programs or top-notch technical or general bookstores - you know that ones are near you..), or the following URL for the CyberInstitute Short Course on Geographic Information Systems (convened by myself):

For a good collection of references on GRASS, try this procedure, to load up on reference goodies from USA/CERL:

ftp moon.cecer.army.mil login: anonymous password: your email address cd pub/grass/grass4.1/outgoing image get grassman.ps.Z (or grassman.txt.Z, or grassman.wp.Z) cd ../documents/programmer/postscript image get progman.ps.Z cd ../../user/postscript image get refman.ps.Z cd ../.. image get installGuide.ps.Z bye uncompress grassman.ps.Z uncompress progman.ps.Z uncompress refman.ps.Z uncompress installGuide.ps.Z lpr *.ps (or whatever is appropriate for your environment)

installGuide => The GRASS Installation Guide (you need this to compile GRASS source code)

grassman => The GRASS Beginner's Manual (intro to GRASS)

refman => The GRASS User's Reference Manual (function guide)

progman => The GRASS Programmer's Manual (and administrator's guide - this is valuable for info about data formats, etc.)

Browse around the ftp site noted just above, and you may find more stuff of interest. Particularly in the pub/grass/grass4.1/documents directory, there are tutorials on advanced GRASS functions such as r.mapcalc (think of this as math applied to raster arrays), r.combine and r.weight (think of this as how to combine spatial submodels into one type of model), and others.

This appendix describes how to acquire and install Linux binaries for GRASS4.13 (the 3rd update to the last full release of GRASS, version 4.1).

ftp moon.cecer.army.mil login: anonymous password: your email address cd pub/grass/grass4.1/release/binaries/linux image mget grassa* bye Installation instructions: ******************************************************************** * GRASS 4.1 Update 3 for Linux * * This package contains GRASS programs only, *NO* GIS * data is included. You can find example GRASS data at * moon.cecer.army.mil * * Compiled by: Andy Burnett - [email protected] * compiled on: April 7, 1994 ******************************************************************** System Requiremnts: 35 MB disk space to hold the binary distribution System library requirements: libc4.5.21 or greater libX.so.3.1.0 or greater If you are running libraries that are older than these, this binary distribution will *NOT* run on your linux system. -------------------------------------------------------------------------- Files in this release: README_4.1.3 what you are currently reading ginstall simple grass installation script grassaa --------| grassab | grassac | grassad | grassae |-- the linux GRASS binaries grassaf | grassag | grassah | grassai | grassaj | grassak --------| INSTALLATION: To install this binary distribution of grass for linux, you can simply run the ginstall script or you can unpack the files by hand. I recommend using the ginstall script . it's very simple and should be bullet proof. To run the ginstall script, you will need gawk (gnu awk) installed on your system and it needs to be in your PATH. If, however, you want to do things by hand, here's what you need to do: o make the destination directory (/usr/grass, /usr/local/grass, whatever) This will become your GISBASE for grass. ********************* LOOK HERE ************************************** from here on, replace $GISBASE with the name of the directory you just created ********************* LOOK HERE ************************************** o cat grassa? | gzip -d | (cd $GISBASE tar xvf -) This will unpack all the grass binaries into the $GISBASE directory o copy $GISBASE/etc/moncap.sample to $GISBASE/etc/monitorcap and edit it. o change all occurrences of GBASE in that file to $GISBASE o copy $GISBASE/etc/grass4.1 into a public directory (I suggest /usr/bin) o edit the copy you just made: change all occurrences of GBASE to $GISBASE

This appendix describes how to acquire and install Linux binaries for GRASS4.15 (the 5th and last update to the last full release of GRASS, version 4.1).

ftp moon.cecer.army.mil login: anonymous password: your email address cd pub/grass/grass4.1/release/binaries/linux image mget linuxa* bye Installation instructions: * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Files in this release: README_4.1.5 what you are currently reading install.sh simple grass installation script linuxaa --------| linuxab | linuxac | linuxad | linuxae |-- the linux GRASS binaries, version 4.1.5 linuxaf | linuxag | linuxah | linuxai --------| * * * * * * * * * * *** * * * * * * * * * * * * * * * * * * * * * * * * The GRASS4.15 for Linux was compiled in my Linux box with the following configuration: Slackware 3.0 kernel 1.2.13 gcc 2.7.0 libc 5.0.9 flex 3.5.2

THE LINUX GRASS 4.15 BINARIES ONLY WORK ON ELF-LINUX. THE BINARIES MAY NOT WORK WITH EARLY VERSION OF KERNEL AND/OR GCC AND FLEX. The binaries was tared and gziped, then split into 9 (close to 1.3 MB - 1200 x 1K block) files named from linuxg.aa to linuxg.ai. You should ftp all the linuxg.a* in binary mode and also get this readme file and an installation script - install.sh. Please put all of these files in the same directory - source directory. At the source directory under the UNIX prompt, type sh ./install.sh full_path_to_the_destination_directory and it should automatically unzip and untar the linuxg.a* files to the destination directory and also edit several site-specific files. The total space your need is about 26 MB. At the destination directory, your can find the grass4.1 script. It should have been modified to reflect your installation directory. Now, either move/copy the grass4.1 file to one of your PATH or use the link command as below: cd /usr/local/bin ln -s destination_directory/etc/grass4.1 grass4.1 Now, you are ready to start GRASS by typing grass4.1 and you should know how to run GRASS afterward. There is a readme directory in the destination_directory/etc directory. This directory has several readme files that come with some incoming commands. You can find all the compiled commands of this binaries in the commands.readme file. I can't guarantee that all of them work but I have tested lots of them. If you find some commands that don't work, please post a message on the grass user group and we can solve it all together. Yung-Tsung Kang, Michigan State University

The GRASS binaries for Linux tend to work. Why would anyone want to mess with the source code?

Let's try to answer this with another question: "Why can't I get the source code to my GIS, so I can see how it works, and maybe fix some things to work the way I like them?" (You probably know the answers to this question, at least for many commercial software packages.)

Add any of the numerous existing alpha and contributed GRASS functions,

Understand how a function works (did any programming shortcuts or performance enhancements affect the accuracy of a function? Can I improve the performance of a function?)

Revise or enhance the code (if you do this, please see Appendix D!),

Try compiling several tens of megabytes of source code, this appendix is for you. Also check Appendix E.

First, you need to acquire the source code, and the GRASS Installation Guide. You may also want to get the GRASS Programmer's Manual and User's Reference Manual. To do this:

ftp moon.cecer.army.mil login: anonymous password: your email address cd pub/grass/grass4.1/release/source get README.4 get README.5 image mget s4* (or s5*, your choice) cd ../../documents get installGuide.ps.Z cd /manuals/programmer/postscript get progman.ps.Z cd ../../user/postscript get refman.ps.Z bye

Don't forget this site. There are several tutorials on some of GRASS' more advanced programs in the pub/grass/grass4.1/document directory. There are two options for source code (I'm only discussing GRASS version 4.14 here, though version 4.15 is also available) The pub/grass/outgoing directory contains many contributed functions (and many other candidates for enhancing your system).

Follow the README.4 file for installing GRASS version 4.14 (which is sometimes called version 4.1.4) source code. Follow the README.5 file for installing GRASS version 4.15 (which is sometimes called version 4.1.5) source code.

After installing the source code, uncompress and print installGuide.ps.Z (or the troff version, if you prefer that and got it from a neighboring directory). You might also want to uncompress and print refman.ps.Z and progman.ps.Z at the same time. Note that progman.ps.Z is called the programmer's manual, but also contains valuable information about data formats and directory structures. Advanced users may also want to know the GRASS system utilities, even if they won't be calling them in code.

Now, use the GRASS Installation Guide (from installGuide.ps.Z) to guide yourself through the installation. The thickness of this document may at first be intimidating. However, if you installed Linux yourself, you should be ready to tackle a GRASS installation. Don't be surprised if a function or two does not compile on your system. I have a couple of uncompiled functions on my own Linux system. Fortunately, these are functions that I don't use. Some day I'll get back to them, fix them, and compile them!?

These instructions pertain to the 4.2 release of GRASS. Users are urged to consult the complete installation guide for more detailed instructions.

$GIS/src - This directory contains scripts and files used to compile GRASS. By running scripts and changing lists of programs you generate GRASS binaries for your system. You may mount a disk containing GRASS source on different types of machines and compile without making source code copies. You follow the following instructions for each machine. WARNING: These instructions presume that you have familiarity with UNIX, C, make, and shell scripting. Murphy's law visits GRASS regularly and your expertise in these matters will be the best defense against Mr. Murphy. WARNING: These instructions and scripts have been used to compile GRASS on various machines. Please mail results of using this information for compiling GRASS on your platforms and operating system to: [email protected] DIRECTORY CONTENTS GISGEN script which will compile GRASS MAKELINKS script used after GISGEN to establish the user executable commands VERSION current version number and date of the GRASS release generic/ system independent files need by gmake gmake shell script which does compilations make.def make variables make.tail some additional make rules head/ gmake header file(s) for this site. Header files are created by running the utils/setup command. lists/ lists of programs to be compiled GRASS standard GRASS programs local site specific GRASS programs . architecture dependent GRASS programs next_step/ files used by GISGEN to keep track of how far along it is in the compilation. Used to restart GISGEN (after a failure) where it left off. utils/ contains the 'setup' script and all support scripts and files needed by 'setup' COMPILATION STEPS OVERVIEW (1) Generate files that contain location and machine specific make information. (2) Edit files containing lists of location and machine specific programs to be compiled (generally printer, digitizer, and graphics drivers). (3) Run GRASS compilation script (4) Run GRASS program linking script (5) Edit device driver configuratin files (6) Compile GRASS contributed, alpha programs. (7) Compile GRASS related and hybrid programs. COMPILATION STEPS (DETAILS) (1) Generate make support files Each machine and location needs to have GRASS compiled in ways that specify different: compilation and load flags system libraries installation directories idefault data bases and locations The shell script utils/setup assists you in define many of the make options and definitions that will become part of every compile-time generated makefile (about 350). It also creates your shell script for compiling individual GRASS programs - gmake4.2. Run "utils/setup" and answer the questions. The makefile portions are placed in the head/ under a name which you specify/approve in the utils/setup process. The executable shell script which directs compilation is placed in (by default) /usr/local/bin. Examine the just created file in head/ to make sure things are ok. A brief description for each defined variable follows: ARCH = Key name identifying the architecture of the machine on which you are compiling GRASS. GISBASE = Directory into which compiled GRASS will be contained UNIX_BIN = Local directory where the GRASS entry program and gmake will be contained DEFAULT_DATABASE= Directory where local GRASS data bases are contained DEFAULT_LOCATION= GRASS data base that users get as the first default COMPILE_FLAGS = Compilation flags LDFLAGS = Load flags TERMLIB = System library containing low-level cursor movement CURSES = System library that supports screen cursor control MATHLIB = System math library LIBRULE = Method for archiving and randomizing libraries USE_TERMIO = Flag to use the termio library if available USE_MTIO = Flag to use the mtio library if available CAN_CLEAR = Flag indicating that the terminal screen can be cleared DIGITFLAGS = Flags to set owner and priority of the v.digit program (2) Edit files containing lists of location and machine specified programs The directory lists/ contains files that list directories that will be compiled. Directory names are relative to the GRASS src directory. The file lists/GRASS lists all basic GRASS programs that get compiled at every site. The file lists/local and lists/$ARCH. ----------------------------------------------------------------- $ARCH is the architecture name you approved while running the utils/setup script. You can determine this by running: gmake4.2 -sh | grep ARCH ----------------------------------------------------------------- There man not be a lists/$ARCH file, but you are free to create it to add names of programs you want compiled specifically for this architecture. It is an architecture-specific list which allows NFS linked source code to compile one set of programs for one machine, and another set for another machine. All machines that share the same source code via NFS mounts will compile the directories listed in lists/local. All lists may contain comment lines - indicated by a # as the first character in the line. The lists/local file contains lists of all digitizer, graphics, and paint (hard-copy map) drivers. All machine specific devices are commented out - you must uncomment those that are particular to your site or architecture. You are encouraged to move the graphics driver items to the appropriate lists/$ARCH file. (3) Run GRASS compilation program The script GISGEN drives the compilation process. If all goes well you will be able to simply enter the command GISGEN and wait. The entire compilation process takes from about 1/2 hour on the faster workstations to about 8 hours on the slower workstations. GISGEN collects all of the directory names to be compiled from lists/GRASS lists/$ARCH and lists/local and begins running gmake4.2 in each directory. Screen output is a collection of messages from GISGEN and from the UNIX make program. Failure at any step will halt compilation. On failure you might do one of the following things: 1 - Fix a compilation problem by modifying code in the directory that failed. After modification, return to this directory and rerun GISGEN. Compilation will pick up at the failed directory and continue down the list of directories if successful. 2 - Restart GISGEN. If the failure requires modifications to code already compiled, or the compilation options you set in step 1, you must remove next_step/$ARCH (or next_step/next_step if ar architecture name was not specified in step 2. You may then rerun GISGEN. 3 - Skip the failed directory. In this case you must seek through the files list/GRASS lists/$ARCH and lists/local to determine the directory name that follows the failed directory name. The failed name is in next_step/$ARCH and must be replaced in that file with the next name. After editing, rerun GISGEN When complete GISGEN will put the word DONE into the next_step file and will print the phrase "DONE generating GIS binary code" to the screen. (4) Run GRASS program linking script The GISGEN directs a compilation process that stashes the GRASS programs away in directories unavailable to the user community. Most user commands are actually links to a single program called "front.end". Links to this program must be made for every actual GRASS program. This is done AFTER GISGEN is finished. To make (or re-make) links for all user programs run the script MAKELINKS. (5) Edit device driver configuratin files Your compiled system may any combination of several graphics, paint, and digitizer drivers. Refer to the GRASS installation instructions for details. NOTE: If you have trouble compiling your graphics driver, go to the directory $GIS/src/display/devices and compile the proper drivers manually using gmake4.2. (6) Compile GRASS contributed, alpha programs. GRASS programs come in three flavors: MAIN - The programs are those compiled in step 3. They have stood the test of time and are generally reliable programs. ALPHA - Alpha programs are intended to be included with the MAIN programs in the next release. CONTRIB - Sites generate lots of special purpose programs in GRASS to get some job done, but do not polish the effort sufficiently to even be considered alpha code can be distributed in this category. ALPHA programs are found in the directory src.alpha. You, the installer may visit these programs and compile any that you desire. In directories that contain Gmakefile files, simply run: gmake4.2 CONTRIB programs are in the directory src.contrib. The state of these programs are varied. Some programs may compile with gmake4.2 others are suitable as a starting point for programmers who will be writing new software. (7) Compile GRASS related and hybrid programs. The GRASS user community has discovered that there are several public-domain programs that are very useful in conjunction with GRASS. These are found in the directory src.related. Compile these programs based on instructions (or lack of instructions) in the individual directories. Hybrid programs are those that mix the capabilities of GRASS with the capabilities of one or more of the "related" programs. These are found in the src.garden directory. They require successful compilation of the "related" programs and generally compile using the gmake4.2 and the included Gmakefile files. The rest of the compilation should just take some time. If you have already installed GRASS binaries, you should back up your system (or at least get the working binaries out of the way of your compilation!). Good Luck! And be secure in the likelihood that you can use the compiled binaries if you bail out of a full compilation of the source code.

GRASS has been developed for over a decade as completely unrestricted public domain source code and executables. Though there was initial resistance to the existence of such robust software in the public domain, many competitors learned to take advantage of GRASS. It has reputedly been the intellectual stimulus for several enhancements to other GISs. Several companies conducted business by installing and customizing public domain GRASS for customers, and by providing other value-added services such as data base development.

As USA/CERL no longer supports the public version of GRASS, users are free to use what currently exists. They're also currently completely on their own. At least where the public domain version is concerned.

This appendix is the home of Linux-specific examples of selected GRASS configuration files. Currently, only several examples of a single file are offered. However, this is the most important file for configuration! Later, examples of database configuration files (e.g. DEFAULT_WIND) and other files may appear.

In the Installation Guide (pp. 10-11) you will see mention of the [header] file in directory $GIS/src/CMD/header (where $GIS is the directory in which you place GRASS - some folks put this in /usr/local - I put everything in a GRASS' own filesystem/directory /user/grass4.1). The installation guide favors Sun systems, as these were the development environment for GRASS4. (In case you cared, Masscomp workstations were earlier development environments.) Below are examples of this <header> file for linux (which you might want to name linux in your $GIS/src/CMD/header directory. You may want to refer to this section when running the setup ($GIS/src/CMD/utils/setup) command.

CC = gcc ARCH = GISBASE = /user/grass4.1 UNIX_BIN = /user/grass4.1/bin DEFAULT_DATABASE = /user/grass4.1/data DEFAULT_LOCATION = china COMPILE_FLAGS = -O2 LDFLAGS = -s XCFLAGS = -D_NO_PROTO -DXM_1_1_BC XLDFLAGS = XINCPATH = XMINCPATH = XLIBPATH = XTLIBPATH = -L/usr/lib XMLIBPATH = -L/usr/lib XLIB = -lX11 XTLIB = -lXt XMLIB = -lXm XEXTRALIBS = TERMLIB = CURSES = -lcurses $(TERMLIB) MATHLIB = -lm # LIBRULE = ar ruv [email protected] $? # LIBRULE = ar ruv [email protected] $? ranlib [email protected] # LIBRULE = ar ruv [email protected] $? ar ts [email protected] # LIBRULE = ar rc [email protected] `lorder $(OBJ) | tsort` LIBRULE = ar ruv [email protected] $? USE_TERMIO = -DUSE_TERMIO USE_MTIO = -DUSE_MTIO USE_FTIME = -DUSE_FTIME DIGITFLAGS = -DUSE_SETREUID -DUSE_SETPRIORITY VECTLIBFLAGS = GETHOSTNAME = -DGETHOSTNAME_OK

#CC = gcc #CC = gcc -ggdb -traditional CC = gcc -traditional #CC = gcc -static ARCH = linux GISBASE = /usr2/local/grass/grass4.1 UNIX_BIN = /usr/local/bin DEFAULT_DATABASE = /usr2/local/grass DEFAULT_LOCATION = grass4.1 COMPILE_FLAGS = #COMPILE_FLAGS = -O LDFLAGS = -s XCFLAGS = -D_NO_PROTO XLDFLAGS = XINCPATH = -I$GISBASE/xgrass #XINCPATH = XMINCPATH = XLIBPATH = -L/usr/lib XTLIBPATH = -L/usr/lib XMLIBPATH = -L/usr/lib XLIB = -lX11 XTLIB = -lXt XMLIB = -lXm XEXTRALIBS = TERMLIB = CURSES = -lcurses $(TERMLIB) MATHLIB = -lm # LIBRULE = ar ruv [email protected] $? # LIBRULE = ar ruv [email protected] $? ranlib [email protected] # LIBRULE = ar ruv [email protected] $? ar ts [email protected] # LIBRULE = ar rc [email protected] `lorder $(OBJ) | tsort` LIBRULE = ar ruv [email protected] $? ranlib [email protected] USE_TERMIO = -DUSE_TERMIO USE_MTIO = -DUSE_MTIO USE_FTIME = -DUSE_FTIME DIGITFLAGS = -DUSE_SETREUID -DUSE_SETPRIORITY VECTLIBFLAGS = GETHOSTNAME = -DGETHOSTNAME_OK

#CC = gcc -traditional -ggdb CC = gcc -traditional -m486 #CC = gcc ARCH = linux GISBASE = /usr/local/grass/grass4.1 UNIX_BIN = /usr/local/bin DEFAULT_DATABASE = /usr/local/grass DEFAULT_LOCATION = grass4.1 COMPILE_FLAGS = -O2 LDFLAGS = -s XCFLAGS = -D_NO_PROTO -DXM_1_1_BC XLDFLAGS = XINCPATH = XMINCPATH = XLIBPATH = -L/usr/lib XTLIBPATH = -L/usr/lib XMLIBPATH = -L/usr/lib XLIB = -lX11 XTLIB = -lXt XMLIB = -lXm XEXTRALIBS = -lXmu TERMLIB = CURSES = -lcurses $(TERMLIB) MATHLIB = -lm # LIBRULE = ar ruv [email protected] $? # LIBRULE = ar ruv [email protected] $? ranlib [email protected] # LIBRULE = ar ruv [email protected] $? ar ts [email protected] # LIBRULE = ar rc [email protected] `lorder $(OBJ) | tsort` LIBRULE = ar ruv [email protected] $? ranlib [email protected] #USE_TERMIO = #-DUSE_TERMIO USE_TERMIO = -DUSE_TERMIO USE_MTIO = -DUSE_MTIO USE_FTIME = -DUSE_FTIME DIGITFLAGS = -DUSE_SETREUID -DUSE_SETPRIORITY VECTLIBFLAGS = GETHOSTNAME = -DGETHOSTNAME_OK

CC = cc ARCH = linux GISBASE = /usr/local/grass4.15/linux UNIX_BIN = /usr/local/grass4.15/linux DEFAULT_DATABASE = /data/grassdata DEFAULT_LOCATION = # -fwritable-strings - for ps.map only #COMPILE_FLAGS = -O -m486 -fwritable-strings COMPILE_FLAGS = -O -m486 LDFLAGS = -s XCFLAGS = -D_NO_PROTO XLDFLAGS = XINCPATH = XMINCPATH = XLIBPATH = -L/usr/X11R6/lib XTLIBPATH = -L/usr/lib XMLIBPATH = -L/usr/lib XLIB = -lX11 XTLIB = -lXt XMLIB = -lXm XEXTRALIBS = TERMLIB = CURSES = -lcurses $(TERMLIB) MATHLIB = -lm # LIBRULE = ar ruv [email protected] $? # LIBRULE = ar ruv [email protected] $? ranlib [email protected] # LIBRULE = ar ruv [email protected] $? ar ts [email protected] # LIBRULE = ar rc [email protected] `lorder $(OBJ) | tsort` LIBRULE = ar ruv [email protected] $? USE_TERMIO = -DUSE_TERMIO USE_MTIO = -DUSE_MTIO USE_FTIME = -DUSE_FTIME DIGITFLAGS = -DUSE_SETREUID -DUSE_SETPRIORITY VECTLIBFLAGS = -DPORTABLE_3 GETHOSTNAME = -DGETHOSTNAME_OK

Intimidating? It probably shouldn't be if you've configured X Windows on your Linux box. These examples should give you patterns to look for when running the setup utility in GRASS (described in the Installation Guide).


EXAMPLES

Convert r.watershed streams map output to a vector map

Set a different color table for the accumulation map:

Create a more detailed stream map using the accumulation map and convert it to a vector output map. The accumulation cut-off, and therefore fractal dimension, is arbitrary in this example we use the map's mean number of upstream catchment cells (calculated in the above example by ص) as the cut-off value. This only works with SFD, not with MFD.

Create watershed basins map and convert to a vector polygon map

Display output in a nice way


General GRASS GIS Features

GRASS GIS contains over 350 modules to render maps and images on monitor and paper manipulate raster, and vector data including vector networks process multispectral image data and create, manage, and store spatial data. GRASS GIS offers both an intuitive graphical user interface as well as command line syntax for ease of operations. GRASS GIS can interface with printers, plotters, digitizers, and databases to develop new data as well as manage existing data.


Raster to vector conversion¶

In our discussion of vector data, we explained that often raster data are used as a backdrop layer, which is then used as a base from which vector features can be digitised.

Another approach is to use advanced computer programs to automatically extract vector features from images. Some features such as roads show in an image as a sudden change of colour from neighbouring pixels. The computer program looks for such colour changes and creates vector features as a result. This kind of functionality is normally only available in very specialised (and often expensive) GIS software.


GRASS GIS 6: Text based location wizard

When starting GRASS GIS 6 in text mode, you can also create a new location within the terminal console.

في ال startup text screen enter a new location name, and then continue by pressing "ESC"-"RETURN" - i.e. press (NOT hold) the ESC key, and then press the RETURN key on your keyboard.

The you will be asked "Would you like to create location <newLocation> ? (y/n) [y]": confirm with the RETURN key on your keyboard. Now you reach:

Confirm with the RETURN key on your keyboard.

Next you will need to assign parameters to the location such as the coordinate system and datum you want to use, the project area's boundary coordinates, and the default resolution for raster data:

  • Start by chosing between, X,Y, Latitude-Longitude, UTM, or "other" coordinate system. This choice depends on your data and the use you will make of it
  • You are then prompted for a single line of text describing the project area, for example "Topo Map of the Alps".

Next you are requested for some more information about the projection. Note that the prompts vary from projection to projection, an example follows:

  • (if you chose "D - Other Projection") "specify projection name": "list" gives you the list of all available projections, examples are "tmerc" for Transverse Mercator, "lcc" for Lambert Conformal Conic, "moll" for Mollweide, etc.
  • specify datum name: again use "list" to get a list of available datums, examples are "wgs84", "nad27", "eur79", etc.
  • Enter Central Parallel: 0 if you want the Equator as the central parallel
  • Enter Central Meridian: 0 if you want the Greenwich meridian as central meridian
  • Enter Scale Factor at the Central Meridian
  • Enter plural form of map units: for example, meters .

The next step is the description of the project area's boundary coordinates and the definition of the default raster resolution:

The default raster resolution (GRID RESOLUTION) has to be chosen according to your needs. Generally, it is advisable to work in steps of 0.25 (0.25, 0.5, 1.75, 2.00, 12.25 etc.). This resolution does not concern vector and site data since these are stored with their exact coordinate values. Note that every raster map may have its own resolution. You can leave this screen with "ESC"-"RETURN" and then if everything is correct accept the list of parameters that appears.

You will then be back to the startup screen to enter the mapset's name (if not already entered). Another "ESC"-"RETURN" will finally let you leave this screen. This mapset is created within the new location by answering "yes" to the next question. The mapset will use the parameters of the location (such as the region and resolution definitions) as its default parameters.

Now the project area, i.e. the location including a mapset, has been created. You have "arrived" in the GRASS GIS system and can start working within this new location.


MapWindow 6 Alpha Desktop GIS is a lightweight open source geographic information system (GIS) built using C# and the open source DotSpatial library (see DotSpatial on CodePlex.com). MapWindow 6 Alpha Desktop GIS is intended to be a complete implementation of DotSpatial and su.

The Visualization Toolkit (VTK) is an open-source, freely available software system for 3D computer graphics, image processing and visualization. VTK supports a wide variety of visualization algorithms including: scalar, vector, tensor, texture, and volumetric methods and advanced modeling techniques such as: implicit modeling, polygon reduction, mesh smoothing, cutting, contouring, and Delaunay triangulation.


NCSU GIS/MEA582:Geospatial Modeling and Analysis

When I open GRASS, nc_spm_08_grass7 doesn't show up under "Project Locations", although it is downloaded and unzipped on my computer. Make sure that when you unzip your nc_spm_08_grass7 is not hidden under another nc_spm_08_grass7 . Some zip software tools create an extra directory by default, so you need to specify that you do not want a new directory created. Your directory structure should look something like: C:UsersusernameDocumentsgrassdata c_spm_08_grass7PERMANENT How do I run the commands in GUI? You can copy and paste the commands into Layer Manager command console and press Enter to execute. Copy and execute each command separately one after each other. Alternatively, you can use the module dialogs, you can find the modules in Modules tab, or menu, or you can type the module name in command console. See documentation how to use module dialogs. When I run GRASS command for the second time, it gives me an error?
ERROR: option <aspect> <aspect> exists. To overwrite, use the --overwrite flag You probably already created the raster or vector maps by the first run and now GRASS doesn't want you to overwrite the already created data. Give your output a new name or you can force overwrite by adding --o to your command (this applies to practically all GRASS commands). There is an equivalent overwrite checkbox in each module's GUI. Is there a way to reorder the layers? yes - just grab a layer with the mouse and move it where you want it to be. Image rendering in GRASS GIS is slow. Do not keep large number of layers in the Layer Manager, start each assignment with empty list and if you accumulate many layers, remove those that you don't need. Can I use data with different projections at the same time? GRASS GIS manages integrity of the data by allowing to work with data in one projection at the time (i.e. it considers on-the-fly projection as such a bad practice, that it doesn't allow it at all) and it also requires you to import the data, to have all the data in one format, e.g. to store vector data in GRASS topological format. The image I see in 3D in GRASS GIS is just a lot of spikes or outliers, no digital elevation model.
When visualizing rasters in GRASS GIS 3D view, you have to switch off aspect and any other raster map layers which you don't want to show as surface. You can however, show any raster by draping it over a surface in 3D (by selecting method of coloring for a surface). For example, to show aspect draped over elevation, you have to have elevation layer in Layer Manager (not aspect layer), and in 3D view properties, select aspect layer as color. When I show the raster map in GRASS GIS 3D view as a surface, I cannot see much detail and the view seems not precise, coarse or blurry. Set fine mode resolution in 3D view tab, in the Surface part to 1 to get the surface in the actual (full, native) resolution of the raster. What does the fine mode resolution in GRASS GIS 3D mean? Fine mode resolution in 3D is resolution of resampling when using the raster in 3D, for example fine mode resolution 2 means that raster with resolution 3 is shown as if it would have resolution 6. This is for performance purposes. To see raster in its full (native) resolution, use fine mode resolution 1. I cannot change or create data in my other Mapsets, only in the current one. That's how it should be. GRASS GIS is always connected to one GRASS Location inside a GRASS Database. GRASS Location contains multiple GRASS Mapsets and you can access data in any of these Mapsets. However, you can change (create, modify, delete) the data only in a current Mapset. Data can be copied into current Mapset using g.copy if you need to modify them (e.g. attributes of a vector map). By default, you see data only in the current Mapset and in the PERMANENT Mapset (that's the special thing about PERMANENT Mapset). يستخدم Data tab in Layer Manager to manage your data, you can "unlock" the functionality to be able to change data outside of your current mapset. When using GRASS GIS, can I access data in different Mapset or Location? If desired, you can show data from other Mapsets (in the current Location) using Settings > GRASS working environment > Mapset access. This helps to maintain safety of data and gives a system to organize the data. Data in other Locations are accessible only if you start GRASS session in the Location. Accessing data from multiple Location wouldn't be safe because data in different Locations are (can be) in different coordinate systems (while all Mapsets in one Location contains data in one particular coordinate system). What is happening when (computational) region is set? It sets the spatial extent AND resolution at which all raster operations are done. If any of the rasters has different resolution, it is quietly resampled using nearest neighbor. It also sets the viewing area of the Map Display when the option Zoom into computational region is selected. It does not affect vector operations, so vector data need to be clipped if the operation is to be performed on a subset of the data. However, some vector modules can work with the region when it is advantageous or when rasters are involved.

شاهد الفيديو: An Introduction to GRASS GIS