طوّر اتحاد Open Geospatial Consortium (OGC) معيار Simple Features Access (SFA) لتوفير نموذج للبيانات الجغرافية المكانية. ويُعرّف هذا المعيار النوع المكاني الأساسي Geometry، إلى جانب العمليات التي تعالج قيم الأشكال الهندسية وتحوّلها لإنجاز مهام التحليل المكاني. ويطبّق PostGIS نموذج OGC Geometry في صورة نوعَي البيانات geometry وgeography في PostgreSQL.

النوع Geometry نوع مجرّد. وتنتمي قيم الأشكال الهندسية إلى أحد أنواعه الفرعية الملموسة التي تمثّل أصنافًا وأبعادًا مختلفة من الأشكال الهندسية. ومنها الأنواع الذرّية Point وLineString وLinearRing وPolygon، وأنواع المجموعات MultiPoint وMultiLineString وMultiPolygon وGeometryCollection. ويضيف معيار Simple Features Access - Part 1: Common architecture v1.2.1 أنواعًا فرعية للبنى PolyhedralSurface وTriangle وTIN.

يمثّل النوع Geometry الأشكال في المستوى الديكارتي ثنائي الأبعاد. ويمكن للأنواع PolyhedralSurface وTriangle وTIN أن تمثّل أيضًا أشكالًا في الفضاء ثلاثي الأبعاد. ويُحدَّد حجم الأشكال وموقعها بواسطة إحداثياتها. ولكل إحداثية قيمتا إحداثي X وY تحددان موقعها في المستوى. وتُبنى الأشكال من نقاط أو قطع مستقيمة، إذ تُحدَّد النقطة بإحداثية واحدة، والقطعة المستقيمة بإحداثيتين.

قد تحتوي الإحداثيات على قيمتَي الإحداثي الاختياريتين Z وM. يُستخدم الإحداثي Z غالبًا لتمثيل الارتفاع. ويحتوي الإحداثي M على قيمة قياس، قد تمثّل الزمن أو المسافة. وإذا وُجدت قيم Z أو M في قيمة شكل هندسي، فيجب أن تكون معرّفة لكل نقطة في الشكل. وإذا كان للشكل الهندسي إحداثي Z أو M فإن بُعد الإحداثيات يكون 3D؛ وإذا كان له Z وM معًا فبُعد الإحداثيات 4D.

ترتبط قيم الأشكال الهندسية بـنظام مرجعي مكاني يدل على نظام الإحداثيات الذي تقع فيه. ويُعرَّف النظام المرجعي المكاني برقم SRID الخاص بالشكل الهندسي. ويحدد النظام المرجعي المكاني وحدات المحورين X وY. ففي الأنظمة المرجعية المستوية تمثّل الإحداثيات X وY عادةً الإزاحة شرقًا والإزاحة شمالًا، بينما تمثّل في الأنظمة الجيوديسية خط الطول ودائرة العرض. ويمثّل SRID 0 مستوًى ديكارتيًا لا نهائيًا بلا وحدات لمحاوره. راجع قسم 4.5, “الأنظمة المرجعية المكانية”.

بُعد الشكل الهندسي خاصية من خصائص أنواع الأشكال الهندسية. فبُعد أنواع النقاط 0، وبُعد الأنواع الخطية 1، وبُعد الأنواع المضلعية 2. وبُعد المجموعات هو أكبر أبعاد عناصرها.

قد تكون قيمة الشكل الهندسي فارغة. والقيم الفارغة لا تحتوي على رؤوس (في أنواع الأشكال الذرّية) أو على عناصر (في المجموعات).

من الخصائص المهمة لقيم الأشكال الهندسية امتدادها المكاني أو المستطيل المحيط بها، الذي يسميه نموذج OGC الغلاف. وهو الصندوق ثنائي أو ثلاثي الأبعاد الذي يحيط بإحداثيات الشكل الهندسي. ويُعد وسيلة فعّالة لتمثيل امتداد الشكل في فضاء الإحداثيات وللتحقق مما إذا كان شكلان هندسيان يتفاعلان.

يتيح نموذج الأشكال الهندسية تقييم العلاقات المكانية الطوبولوجية كما هو موضّح في قسم 5.1.1, “نموذج التقاطعات التسعة الموسّع بالأبعاد”. ولدعم ذلك تُعرَّف مفاهيم الداخل والحد والخارج لكل نوع من أنواع الأشكال الهندسية. والأشكال الهندسية مغلقة طوبولوجيًا، لذا فهي تحتوي دائمًا على حدها. والحد شكل هندسي بُعده أقل بواحد من بُعد الشكل نفسه.

يُعرّف نموذج OGC للأشكال الهندسية قواعد صلاحية لكل نوع من أنواعها. وتضمن هذه القواعد أن تمثّل قيم الأشكال الهندسية حالات واقعية (فمثلًا يمكن تحديد مضلع فيه ثقب يقع خارج الغلاف الخارجي، لكن هذا لا معنى له هندسيًا ولذا فهو غير صالح). ويسمح PostGIS أيضًا بتخزين قيم الأشكال الهندسية غير الصالحة ومعالجتها، مما يتيح اكتشافها وإصلاحها عند الحاجة. راجع قسم 4.4, “التحقق من صلاحية الأشكال الهندسية”

POINT (1 2)
POINT Z (1 2 3)
POINT ZM (1 2 3 4)

LINESTRING (1 2, 3 4, 5 6)

LINEARRING (0 0 0, 4 0 0, 4 4 0, 0 4 0, 0 0 0)

POLYGON ((0 0 0,4 0 0,4 4 0,0 4 0,0 0 0),(1 1 0,2 1 0,2 2 0,1 2 0,1 1 0))

MULTIPOINT ( (0 0), (1 2) )

MULTILINESTRING ( (0 0,1 1,1 2), (2 3,3 2,5 4) )

MULTIPOLYGON (((1 5, 5 5, 5 1, 1 1, 1 5)), ((6 5, 9 1, 6 1, 6 5)))

GEOMETRYCOLLECTION ( POINT(2 3), LINESTRING(2 3, 3 4))

POLYHEDRALSURFACE Z (
  ((0 0 0, 0 0 1, 0 1 1, 0 1 0, 0 0 0)),
  ((0 0 0, 0 1 0, 1 1 0, 1 0 0, 0 0 0)),
  ((0 0 0, 1 0 0, 1 0 1, 0 0 1, 0 0 0)),
  ((1 1 0, 1 1 1, 1 0 1, 1 0 0, 1 1 0)),
  ((0 1 0, 0 1 1, 1 1 1, 1 1 0, 0 1 0)),
  ((0 0 1, 1 0 1, 1 1 1, 0 1 1, 0 0 1)) )

TRIANGLE ((0 0, 0 9, 9 0, 0 0))

TIN Z ( ((0 0 0, 0 0 1, 0 1 0, 0 0 0)), ((0 0 0, 0 1 0, 1 1 0, 0 0 0)) )

يوسّع معيار ISO/IEC 13249-3 SQL Multimedia - Spatial (SQL/MM) معيار OGC SFA بتعريف أنواع فرعية من Geometry تحتوي على منحنيات ذات أقواس دائرية. وتدعم أنواع SQL/MM الإحداثيات 3DM و3DZ و4D.

	تُجرى جميع مقارنات الأعداد العشرية في تطبيق SQL-MM ضمن تفاوت محدد، قيمته حاليًا 1E-8.

CIRCULARSTRING(0 0, 1 1, 1 0)

CIRCULARSTRING(0 0, 4 0, 4 4, 0 4, 0 0)

COMPOUNDCURVE( CIRCULARSTRING(0 0, 1 1, 1 0),(1 0, 0 1))

CURVEPOLYGON(
  CIRCULARSTRING(0 0, 4 0, 4 4, 0 4, 0 0),
  (1 1, 3 3, 3 1, 1 1) )

CURVEPOLYGON(
  COMPOUNDCURVE( CIRCULARSTRING(0 0,2 0, 2 1, 2 3, 4 3),
                 (4 3, 4 5, 1 4, 0 0)),
  CIRCULARSTRING(1.7 1, 1.4 0.4, 1.6 0.4, 1.6 0.5, 1.7 1) )

MULTICURVE( (0 0, 5 5), CIRCULARSTRING(4 0, 4 4, 8 4))

MULTISURFACE(
  CURVEPOLYGON(
    CIRCULARSTRING( 0 0, 4 0, 4 4, 0 4, 0 0),
    (1 1, 3 3, 3 1, 1 1)),
  ((10 10, 14 12, 11 10, 10 10), (11 11, 11.5 11, 11 11.5, 11 11)))

تُعرّف مواصفة OGC SFA صيغتين لتمثيل قيم الأشكال الهندسية للاستخدام الخارجي: Well-Known Text (WKT) وWell-Known Binary (WKB). وتتضمن كلتا الصيغتين WKT وWKB معلومات عن نوع الكائن والإحداثيات التي تعرّفه.

توفّر صيغة Well-Known Text (WKT) تمثيلًا نصيًا قياسيًا للبيانات المكانية. ومن أمثلة تمثيلات WKT للكائنات المكانية:

يتوفر إدخال WKT وإخراجه عبر الدالتين ST_AsText وST_GeomFromText:

text WKT = ST_AsText(geometry);
geometry = ST_GeomFromText(text WKT, SRID);

على سبيل المثال، هذه تعليمة لإنشاء كائن مكاني من WKT وSRID وإدراجه:

INSERT INTO geotable ( geom, name )
  VALUES ( ST_GeomFromText('POINT(-126.4 45.32)', 312), 'A Place');

توفّر صيغة Well-Known Binary (WKB) تمثيلًا محمولًا وكامل الدقة للبيانات المكانية في صورة بيانات ثنائية (مصفوفات من البايتات). ومن أمثلة تمثيلات WKB للكائنات المكانية:

يتوفر إدخال WKB وإخراجه عبر الدالتين ST_AsBinary وST_GeomFromWKB:

bytea WKB = ST_AsBinary(geometry);
geometry = ST_GeomFromWKB(bytea WKB, SRID);

على سبيل المثال، هذه تعليمة لإنشاء كائن مكاني من WKB وإدراجه:

INSERT INTO geotable ( geom, name )
  VALUES ( ST_GeomFromWKB('\x0101000000000000000000f03f000000000000f03f', 312), 'A Place');

لم تكن مواصفات OGC SFA تدعم في البداية إلا الأشكال الهندسية ثنائية الأبعاد، ولا يُضمَّن SRID الشكل الهندسي في تمثيلات الإدخال/الإخراج. وتضيف مواصفة OGC SFA 1.2.1 (المتوافقة مع معيار ISO 19125) دعم الإحداثيات ثلاثية الأبعاد (ZYZ) والمقيسة (XYM وXYZM)، لكنها لا تزال لا تتضمن قيمة SRID.

بسبب هذه القيود عرّف PostGIS الصيغتين الموسّعتين EWKB وEWKT. وهما توفّران دعم الإحداثيات ثلاثية الأبعاد (XYZ وXYM) ورباعية الأبعاد (XYZM) وتتضمنان معلومات SRID. ويتيح تضمين جميع معلومات الشكل الهندسي لـ PostGIS استخدام EWKB صيغةً معتمدة للتسجيل (مثلًا في ملفات DUMP).

تُستخدم EWKB وEWKT في "الصيغ القانونية" لكائنات بيانات PostGIS. ففي الإدخال، الصيغة القانونية للبيانات الثنائية هي EWKB، أما البيانات النصية فتُقبل فيها EWKB أو EWKT. ويتيح ذلك إنشاء قيم هندسية بتحويل قيمة نصية بصيغة HEXEWKB أو EWKT إلى قيمة geometry باستخدام ::geometry. وفي الإخراج، الصيغة القانونية للبيانات الثنائية هي EWKB، وللنصية HEXEWKB (EWKB مرمّزة ست عشريًا).

على سبيل المثال، تنشئ هذه التعليمة شكلًا هندسيًا بالتحويل من قيمة نصية بصيغة EWKT، وتُخرجه بالصيغة القانونية HEXEWKB:

SELECT 'SRID=4;POINT(0 0)'::geometry;
  geometry
  ----------------------------------------------------
  01010000200400000000000000000000000000000000000000

يختلف إخراج EWKT في PostGIS عن OGC WKT في بضعة أمور:

تتجنب EWKT الإفراط في تحديد الأبعاد وحالات عدم الاتساق التي قد تقع مع صيغة OGC/ISO، مثل:

	الصيغ الموسّعة في PostGIS حاليًا مجموعة شاملة لصيغ OGC، بحيث تكون كل قيمة WKB/WKT صالحة وفق OGC صالحةً أيضًا بوصفها EWKB/EWKT. غير أن ذلك قد يتغيّر مستقبلًا إذا وسّع OGC صيغةً ما بطريقة تتعارض مع تعريف PostGIS. لذا يجب ألا تعتمد على هذا التوافق!

من أمثلة التمثيل النصي EWKT للكائنات المكانية:

يتوفر الإدخال والإخراج بهذه الصيغ عبر الدوال التالية:

bytea EWKB = ST_AsEWKB(geometry);
text EWKT = ST_AsEWKT(geometry);
geometry = ST_GeomFromEWKB(bytea EWKB);
geometry = ST_GeomFromEWKT(text EWKT);

على سبيل المثال، هذه تعليمة لإنشاء كائن مكاني في PostGIS باستخدام EWKT وإدراجه:

INSERT INTO geotable ( geom, name )
  VALUES ( ST_GeomFromEWKT('SRID=312;POINTM(-126.4 45.32 15)'), 'A Place' )

يمكنك إنشاء جدول لتخزين بيانات geography باستخدام تعليمة SQL CREATE TABLE مع عمود من النوع geography. ينشئ المثال التالي جدولًا فيه عمود geography يخزّن خطوطًا ثنائية الأبعاد في نظام الإحداثيات الجيوديسي WGS84 (SRID 4326):

CREATE TABLE global_points (
    id SERIAL PRIMARY KEY,
    name VARCHAR(64),
    location geography(POINT,4326)
  );

يدعم النوع geography مُعدِّلَي نوع اختياريين:

أمثلة على إنشاء جداول بأعمدة geography:

تُسجَّل حقول geography في عرض النظام geography_columns. ويمكنك الاستعلام من العرض geography_columns لترى أن الجدول مُدرج فيه:

SELECT * FROM geography_columns;

إنشاء فهرس مكاني يتم بالطريقة نفسها المتبعة مع أعمدة geometry. سيلاحظ PostGIS أن نوع العمود هو GEOGRAPHY وسينشئ فهرسًا مناسبًا قائمًا على الكرة بدلًا من الفهرس المستوي المعتاد المستخدم مع GEOMETRY.

-- Index the test table with a spherical index
CREATE INDEX global_points_gix ON global_points USING GIST ( location );

يمكنك إدراج البيانات في جداول geography بالطريقة نفسها المتبعة مع geometry. وستُحوَّل بيانات geometry تلقائيًا إلى النوع geography إذا كان SRID الخاص بها 4326. ويمكن أيضًا استخدام الصيغتين EWKT وEWKB لتحديد قيم geography.

-- Add some data into the test table
INSERT INTO global_points (name, location) VALUES ('Town', 'SRID=4326;POINT(-110 30)');
INSERT INTO global_points (name, location) VALUES ('Forest', 'SRID=4326;POINT(-109 29)');
INSERT INTO global_points (name, location) VALUES ('London', 'SRID=4326;POINT(0 49)');

يمكن تحديد أي نظام مرجعي مكاني جيوديسي (خط الطول/دائرة العرض) مُدرج في الجدول spatial_ref_sys بوصفه SRID لبيانات geography. أما أنظمة الإحداثيات غير الجيوديسية فتُطلق خطأً عند استخدامها.

-- NAD 83 lon/lat
SELECT 'SRID=4269;POINT(-123 34)'::geography;
                    geography
----------------------------------------------------
 0101000020AD1000000000000000C05EC00000000000004140

-- NAD27 lon/lat
SELECT 'SRID=4267;POINT(-123 34)'::geography;
                    geography
----------------------------------------------------
 0101000020AB1000000000000000C05EC00000000000004140

-- NAD83 UTM zone meters - gives an error since it is a meter-based planar projection
SELECT 'SRID=26910;POINT(-123 34)'::geography;

ERROR:  Only lon/lat coordinate systems are supported in geography.

تستخدم دوال الاستعلام والقياس وحدة المتر. لذا يجب التعبير عن معاملات المسافة بالأمتار، وتوقّع القيم المُعادة بالأمتار (أو بالأمتار المربعة للمساحات).

-- A distance query using a 1000km tolerance
SELECT name FROM global_points WHERE ST_DWithin(location, 'SRID=4326;POINT(-110 29)'::geography, 1000000);

يمكنك رؤية قوة geography عمليًا بحساب مدى اقتراب طائرة تحلّق في مسار دائرة عظمى من سياتل إلى لندن (LINESTRING(-122.33 47.606, 0.0 51.5)) من ريكيافيك (POINT(-21.96 64.15)) (ارسم المسار على الخريطة).

يحسب النوع geography المسافة الحقيقية الأقصر البالغة 122.235 كم على الكرة بين ريكيافيك ومسار رحلة الدائرة العظمى بين سياتل ولندن.

-- Distance calculation using GEOGRAPHY
SELECT ST_Distance('LINESTRING(-122.33 47.606, 0.0 51.5)'::geography, 'POINT(-21.96 64.15)'::geography);
   st_distance
-----------------
 122235.23815667

أما النوع geometry فيحسب مسافة ديكارتية لا معنى لها بين ريكيافيك ومسار الخط المستقيم من سياتل إلى لندن مرسومًا على خريطة مسطحة للعالم. والوحدات الاسمية للنتيجة هي "الدرجات"، لكن النتيجة لا تقابل أي فرق زاوي حقيقي بين النقاط، لذا فحتى تسميتها "درجات" غير دقيقة.

-- Distance calculation using GEOMETRY
SELECT ST_Distance('LINESTRING(-122.33 47.606, 0.0 51.5)'::geometry, 'POINT(-21.96 64.15)'::geometry);
      st_distance
--------------------
 13.342271221453624

يتيح لك نوع البيانات geography تخزين البيانات بإحداثيات خط الطول/دائرة العرض، لكن بثمن: فالدوال المعرّفة على GEOGRAPHY أقل من تلك المعرّفة على GEOMETRY؛ والدوال المعرّفة منها تستغرق وقت معالجة أطول عند التنفيذ.

ينبغي أن يُحدَّد نوع البيانات الذي تختاره بناءً على منطقة العمل المتوقعة للتطبيق الذي تبنيه. هل ستمتد بياناتك على الكرة الأرضية كلها أو على منطقة قارية واسعة، أم أنها محلية على مستوى ولاية أو مقاطعة أو بلدية؟

راجع قسم 13.11, “مصفوفة دعم دوال PostGIS” للمقارنة بين ما هو مدعوم في Geography مقابل Geometry. وللاطلاع على قائمة موجزة بدوال Geography ووصفها، راجع قسم 13.4, “دوال PostGIS الداعمة لنوع geography”

الشكل الهندسي البسيط هو الذي لا يحتوي على نقاط هندسية شاذة، مثل التقاطع الذاتي أو التماس الذاتي.

النقطة POINT بسيطة بطبيعتها بوصفها كائنًا هندسيًا صفري البعد.

تكون النقاط المتعددة MULTIPOINT بسيطة إذا لم تتساوَ أي إحداثيتين (POINT) فيها (أي لم تكن لهما قيم إحداثيات متطابقة).

يكون الخط LINESTRING بسيطًا إذا لم يمر بالنقطة نفسها مرتين، باستثناء نقطتَي الطرفين. وإذا تطابقت نقطتا طرفَي خط بسيط سُمّي مغلقًا وأُشير إليه بالحلقة الخطية (Linear Ring).

(a) و(c) خطان LINESTRING بسيطان. (b) و(d) ليسا بسيطين. (c) حلقة خطية مغلقة.

(a)	(b)
(c)	(d)

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

(e) و(f) خطوط متعددة MULTILINESTRING بسيطة. (g) ليس بسيطًا.

(e)

(f)

(g)

تتكوّن المضلعات POLYGON من حلقات خطية، لذا فالأشكال الهندسية المضلعية الصالحة بسيطة دائمًا.

لاختبار ما إذا كان شكل هندسي بسيطًا استخدم الدالة ST_IsSimple:

SELECT
   ST_IsSimple('LINESTRING(0 0, 100 100)') AS straight,
   ST_IsSimple('LINESTRING(0 0, 100 100, 100 0, 0 100)') AS crossing;

 straight | crossing
----------+----------
 t        | f

بوجه عام، لا تشترط دوال PostGIS أن تكون الوسائط الهندسية بسيطة. وتُستخدم البساطة أساسًا قاعدةً لتعريف الصلاحية الهندسية. وهي أيضًا شرط لبعض أنواع نماذج البيانات المكانية (فمثلًا كثيرًا ما تمنع الشبكات الخطية الخطوط المتقاطعة). ويمكن جعل النقاط المتعددة والأشكال الخطية بسيطة باستخدام ST_UnaryUnion.

تنطبق صلاحية الأشكال الهندسية أساسًا على الأشكال ثنائية الأبعاد (POLYGON وMULTIPOLYGON). وتُعرَّف الصلاحية بقواعد تتيح للأشكال المضلعية نمذجة المساحات المستوية دون لبس.

يكون المضلع POLYGON صالحًا إذا:

(h) و(i) مضلعان POLYGON صالحان. (j-m) غير صالحة. ويمكن تمثيل (j) بوصفه MULTIPOLYGON صالحًا.

(h)	(i)	(j)
(k)	(l)	(m)

يكون المضلع المتعدد MULTIPOLYGON صالحًا إذا:

(n) مضلع متعدد MULTIPOLYGON صالح. (o) و(p) غير صالحين.

(n)

(o)

(p)

تعني هذه القواعد أن الأشكال المضلعية الصالحة بسيطة أيضًا.

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

SELECT
   ST_IsValid('LINESTRING(0 0, 1 1)') AS len_nonzero,
   ST_IsValid('LINESTRING(0 0, 0 0, 0 0)') AS len_zero,
   ST_IsValid('LINESTRING(10 10, 150 150, 180 50, 20 130)') AS self_int;

 len_nonzero | len_zero | self_int
-------------+----------+----------
 t           | f        | t

لا توجد قواعد صلاحية للأشكال الهندسية POINT وMULTIPOINT.

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

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

إذا واجهت رسائل خطأ غير متوقعة عند استدعاء دوال PostGIS (مثل "GEOS Intersection() threw an error!")، فعليك أولًا التأكد من صلاحية وسائط الدالة. فإن لم تكن صالحة، ففكّر في استخدام إحدى التقنيات أدناه لضمان صلاحية البيانات التي تعالجها.

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

لاختبار ما إذا كان شكل هندسي صالحًا استخدم الدالة ST_IsValid:

SELECT ST_IsValid('POLYGON ((20 180, 180 180, 180 20, 20 20, 20 180))');
-----------------
 t

توفّر الدالة ST_IsValidDetail معلومات عن طبيعة عدم صلاحية الشكل الهندسي وموقعها:

SELECT valid, reason, ST_AsText(location) AS location
    FROM ST_IsValidDetail('POLYGON ((20 20, 120 190, 50 190, 170 50, 20 20))') AS t;

 valid |      reason       |                  location
-------+-------------------+---------------------------------------------
 f     | Self-intersection | POINT(91.51162790697674 141.56976744186045)

في بعض الحالات يُستحسن تصحيح الأشكال الهندسية غير الصالحة تلقائيًا. استخدم الدالة ST_MakeValid لذلك. (ST_MakeValid مثال على دالة مكانية تسمح فعلًا بمدخلات غير صالحة!)

افتراضيًا، لا يتحقق PostGIS من الصلاحية عند تحميل الأشكال الهندسية، لأن اختبار الصلاحية قد يستغرق وقت معالجة طويلًا للأشكال المعقدة. فإن لم تكن تثق بمصادر بياناتك، فيمكنك فرض التحقق من الصلاحية على جداولك بإضافة قيد تحقق (check constraint):

ALTER TABLE mytable
  ADD CONSTRAINT geometry_valid_check
        CHECK (ST_IsValid(geom));

الجدول SPATIAL_REF_SYS الذي يستخدمه PostGIS جدول قاعدة بيانات متوافق مع OGC يُعرّف الأنظمة المرجعية المكانية المتاحة. ويحتوي على أرقام SRID وأوصاف نصية لأنظمة الإحداثيات.

تعريف الجدول spatial_ref_sys هو:

CREATE TABLE spatial_ref_sys (
  srid       INTEGER NOT NULL PRIMARY KEY,
  auth_name  VARCHAR(256),
  auth_srid  INTEGER,
  srtext     VARCHAR(2048),
  proj4text  VARCHAR(2048)
)

الأعمدة هي:

عند استرجاع تعريفات الأنظمة المرجعية المكانية لاستخدامها في التحويلات، يتّبع PostGIS الاستراتيجية التالية:

يحتوي الجدول spatial_ref_sys في PostGIS على أكثر من 3000 من تعريفات الأنظمة المرجعية المكانية الأكثر شيوعًا التي تتعامل معها مكتبة الإسقاط PROJ. لكن هناك أنظمة إحداثيات كثيرة لا يحتويها. ويمكنك إضافة تعريفات SRS إلى الجدول إذا توفرت لديك المعلومات اللازمة عن النظام المرجعي المكاني. أو يمكنك تعريف نظامك المرجعي المكاني المخصص إذا كنت على دراية ببُنى PROJ. وتذكّر أن معظم الأنظمة المرجعية المكانية إقليمية ولا معنى لها عند استخدامها خارج الحدود التي وُضعت لها.

من الموارد المفيدة للعثور على أنظمة مرجعية مكانية غير معرّفة في المجموعة الأساسية http://spatialreference.org/

من الأنظمة المرجعية المكانية الشائعة الاستخدام: 4326 - WGS 84 Long Lat، و4269 - NAD 83 Long Lat، و3395 - WGS 84 World Mercator، و2163 - US National Atlas Equal Area، ونطاقات WGS84 UTM الستون. وتُعد نطاقات UTM من أنسب الأنظمة للقياس، لكنها لا تغطي إلا مناطق بعرض 6 درجات. (لتحديد نطاق UTM المناسب لمنطقة اهتمامك، راجع الدالة المساعدة utmzone المكتوبة بـ plpgsql في PostGIS.)

تستخدم الولايات الأمريكية الأنظمة المرجعية المكانية State Plane (القائمة على المتر أو القدم) - ويوجد عادةً نظام أو نظامان لكل ولاية. ومعظم الأنظمة القائمة على المتر موجودة في المجموعة الأساسية، لكن كثيرًا من الأنظمة القائمة على القدم أو التي أنشأتها ESRI يجب نسخها من spatialreference.org.

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

فيما يلي مثال على تحميل نظام إحداثيات مخصص باستخدام SRID غير مُعيَّن وتعريف PROJ لإسقاط Lambert Conformal متمركز على الولايات المتحدة:

INSERT INTO spatial_ref_sys (srid, proj4text)
VALUES ( 990000,
  '+proj=lcc  +lon_0=-95 +lat_0=25 +lat_1=25 +lat_2=25 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs'
);

يمكنك إنشاء جدول لتخزين البيانات الهندسية باستخدام تعليمة SQL CREATE TABLE مع عمود من النوع geometry. ينشئ المثال التالي جدولًا فيه عمود geometry يخزّن خطوطًا ثنائية الأبعاد (XY) في نظام الإحداثيات BC-Albers (SRID 3005):

CREATE TABLE roads (
    id SERIAL PRIMARY KEY,
    name VARCHAR(64),
    geom geometry(LINESTRING,3005)
  );

يدعم النوع geometry مُعدِّلَي نوع اختياريين:

أمثلة على إنشاء جداول بأعمدة geometry:

يمكن أن يحتوي الجدول على أكثر من عمود geometry واحد. ويمكن تحديد ذلك عند إنشاء الجدول، أو إضافة عمود باستخدام تعليمة SQL ALTER TABLE. يضيف هذا المثال عمودًا يمكنه حمل خطوط ثلاثية الأبعاد:

ALTER TABLE roads ADD COLUMN geom2 geometry(LINESTRINGZ,4326);

تُعرّف مواصفة OGC Simple Features Specification for SQL جدول البيانات الوصفية GEOMETRY_COLUMNS لوصف بنية الجداول الهندسية. وفي PostGIS يكون geometry_columns عرضًا (view) يقرأ من جداول فهرس نظام قاعدة البيانات. وهذا يضمن أن تكون معلومات البيانات الوصفية المكانية متسقة دائمًا مع الجداول والعروض المعرّفة حاليًا. وبنية العرض هي:

\d geometry_columns

View "public.geometry_columns"
      Column       |          Type          | Modifiers
-------------------+------------------------+-----------
 f_table_catalog   | character varying(256) |
 f_table_schema    | character varying(256) |
 f_table_name      | character varying(256) |
 f_geometry_column | character varying(256) |
 coord_dimension   | integer                |
 srid              | integer                |
 type              | character varying(30)  |

الأعمدة هي:

من الحالات التي قد تحتاج فيها إلى ذلك حالتا عروض SQL (views) والإدراج المجمّع. ففي حالة الإدراج المجمّع، يمكنك تصحيح التسجيل في الجدول geometry_columns بتقييد العمود أو بتنفيذ alter table. أما في العروض، فيمكنك الكشف عن العمود باستخدام عملية CAST. لاحظ أنه إذا كان عمودك قائمًا على typmod، فإن عملية الإنشاء ستسجّله تسجيلًا صحيحًا، فلا حاجة إلى فعل أي شيء. كما أن العروض التي لم تُطبَّق فيها أي دالة مكانية على الشكل الهندسي ستُسجَّل بالطريقة نفسها التي سُجّل بها عمود geometry في الجدول الأساسي.

-- Lets say you have a view created like this
CREATE VIEW public.vwmytablemercator AS
        SELECT gid, ST_Transform(geom, 3395) As geom, f_name
        FROM public.mytable;

-- For it to register correctly
-- You need to cast the geometry
--
DROP VIEW public.vwmytablemercator;
CREATE VIEW  public.vwmytablemercator AS
        SELECT gid, ST_Transform(geom, 3395)::geometry(Geometry, 3395) As geom, f_name
        FROM public.mytable;

-- If you know the geometry type for sure is a 2D POLYGON then you could do
DROP VIEW public.vwmytablemercator;
CREATE VIEW  public.vwmytablemercator AS
        SELECT gid, ST_Transform(geom,3395)::geometry(Polygon, 3395) As geom, f_name
        FROM public.mytable;

--Lets say you created a derivative table by doing a bulk insert
SELECT poi.gid, poi.geom, citybounds.city_name
INTO myschema.my_special_pois
FROM poi INNER JOIN citybounds ON ST_Intersects(citybounds.geom, poi.geom);

-- Create 2D index on new table
CREATE INDEX idx_myschema_myspecialpois_geom_gist
  ON myschema.my_special_pois USING gist(geom);

-- If your points are 3D points or 3M points,
-- then you might want to create an nd index instead of a 2D index
CREATE INDEX my_special_pois_geom_gist_nd
        ON my_special_pois USING gist(geom gist_geometry_ops_nd);

-- To manually register this new table's geometry column in geometry_columns.
-- Note it will also change the underlying structure of the table to
-- to make the column typmod based.
SELECT populate_geometry_columns('myschema.my_special_pois'::regclass);

-- If you are using PostGIS 2.0 and for whatever reason, you
-- you need the constraint based definition behavior
-- (such as case of inherited tables where all children do not have the same type and srid)
-- set optional use_typmod argument to false
SELECT populate_geometry_columns('myschema.my_special_pois'::regclass, false); 

مع أن الطريقة القديمة القائمة على القيود لا تزال مدعومة، فإن عمود geometry القائم على القيود والمستخدم مباشرةً في عرض (view) لن يُسجَّل تسجيلًا صحيحًا في geometry_columns، بخلاف العمود القائم على typmod. في هذا المثال نعرّف عمودًا باستخدام typmod وآخر باستخدام القيود.

CREATE TABLE pois_ny(gid SERIAL PRIMARY KEY, poi_name text, cat text, geom geometry(POINT,4326));
SELECT AddGeometryColumn('pois_ny', 'geom_2160', 2160, 'POINT', 2, false);

إذا نفّذنا في psql

\d pois_ny;

نلاحظ أنهما معرّفان بطريقتين مختلفتين -- أحدهما بـ typmod والآخر بقيد

Table "public.pois_ny"
  Column   |         Type          |                       Modifiers

-----------+-----------------------+------------------------------------------------------
 gid       | integer               | not null default nextval('pois_ny_gid_seq'::regclass)
 poi_name  | text                  |
 cat       | character varying(20) |
 geom      | geometry(Point,4326)  |
 geom_2160 | geometry              |
Indexes:
    "pois_ny_pkey" PRIMARY KEY, btree (gid)
Check constraints:
    "enforce_dims_geom_2160" CHECK (st_ndims(geom_2160) = 2)
    "enforce_geotype_geom_2160" CHECK (geometrytype(geom_2160) = 'POINT'::text
        OR geom_2160 IS NULL)
    "enforce_srid_geom_2160" CHECK (st_srid(geom_2160) = 2160)

في geometry_columns، يُسجَّل كلاهما تسجيلًا صحيحًا

SELECT f_table_name, f_geometry_column, srid, type
        FROM geometry_columns
        WHERE f_table_name = 'pois_ny';

f_table_name | f_geometry_column | srid | type
-------------+-------------------+------+-------
pois_ny      | geom              | 4326 | POINT
pois_ny      | geom_2160         | 2160 | POINT

لكن -- إذا أنشأنا عرضًا (view) كهذا

CREATE VIEW vw_pois_ny_parks AS
SELECT *
  FROM pois_ny
  WHERE cat='park';

SELECT f_table_name, f_geometry_column, srid, type
        FROM geometry_columns
        WHERE f_table_name = 'vw_pois_ny_parks';

يُسجَّل عمود العرض geom القائم على typmod تسجيلًا صحيحًا، أما القائم على القيد فلا.

f_table_name   | f_geometry_column | srid |   type
------------------+-------------------+------+----------
 vw_pois_ny_parks | geom              | 4326 | POINT
 vw_pois_ny_parks | geom_2160         |    0 | GEOMETRY

قد يتغيّر هذا في الإصدارات المستقبلية من PostGIS، لكن حاليًا لإجبار عمود العرض القائم على القيد على التسجيل الصحيح، عليك فعل ما يلي:

DROP VIEW vw_pois_ny_parks;
CREATE VIEW vw_pois_ny_parks AS
SELECT gid, poi_name, cat,
  geom,
  geom_2160::geometry(POINT,2160) As geom_2160
  FROM pois_ny
  WHERE cat = 'park';
SELECT f_table_name, f_geometry_column, srid, type
        FROM geometry_columns
        WHERE f_table_name = 'vw_pois_ny_parks';

f_table_name   | f_geometry_column | srid | type
------------------+-------------------+------+-------
 vw_pois_ny_parks | geom              | 4326 | POINT
 vw_pois_ny_parks | geom_2160         | 2160 | POINT

إذا أمكن تحويل البيانات المكانية إلى تمثيل نصي (WKT أو WKB)، فقد يكون استخدام SQL أسهل طريقة لإدخال البيانات إلى PostGIS. يمكن تحميل البيانات دفعةً واحدة إلى PostGIS/PostgreSQL بتحميل ملف نصي يتضمن تعليمات INSERT في SQL باستخدام أداة SQL المسماة psql.

قد يبدو ملف تحميل SQL (مثل roads.sql) على النحو الآتي:

BEGIN;
INSERT INTO roads (road_id, roads_geom, road_name)
  VALUES (1,'LINESTRING(191232 243118,191108 243242)','Jeff Rd');
INSERT INTO roads (road_id, roads_geom, road_name)
  VALUES (2,'LINESTRING(189141 244158,189265 244817)','Geordie Rd');
INSERT INTO roads (road_id, roads_geom, road_name)
  VALUES (3,'LINESTRING(192783 228138,192612 229814)','Paul St');
INSERT INTO roads (road_id, roads_geom, road_name)
  VALUES (4,'LINESTRING(189412 252431,189631 259122)','Graeme Ave');
INSERT INTO roads (road_id, roads_geom, road_name)
  VALUES (5,'LINESTRING(190131 224148,190871 228134)','Phil Tce');
INSERT INTO roads (road_id, roads_geom, road_name)
  VALUES (6,'LINESTRING(198231 263418,198213 268322)','Dave Cres');
COMMIT;

يمكن تحميل ملف SQL إلى PostgreSQL باستخدام psql:

psql -d [database] -f roads.sql

يحوّل مُحمِّل البيانات shp2pgsql ملفات Shapefile إلى SQL مناسب للإدراج في قاعدة بيانات PostGIS/PostgreSQL بصيغة geometry أو geography. للمُحمِّل عدة أوضاع تشغيل تُختار بواسطة خيارات سطر الأوامر.

توجد أيضًا واجهة رسومية shp2pgsql-gui تتضمن معظم خيارات مُحمِّل سطر الأوامر. قد تكون أسهل استخدامًا للتحميل لمرة واحدة دون نصوص برمجية أو إذا كنت جديدًا على PostGIS. ويمكن أيضًا إعدادها كإضافة لـ PgAdminIII.

قد تبدو جلسة نموذجية تستخدم المُحمِّل لإنشاء ملف إدخال ثم تحميله على النحو الآتي:

# shp2pgsql -c -D -s 4269 -i -I shaperoads.shp myschema.roadstable 
> roads.sql
# psql -d roadsdb -f roads.sql

يمكن إجراء التحويل والتحميل في خطوة واحدة باستخدام أنابيب UNIX:

# shp2pgsql shaperoads.shp myschema.roadstable | psql -d roadsdb

أبسط طريقة لاستخراج البيانات المكانية من قاعدة البيانات هي استخدام استعلام SQL SELECT لتحديد مجموعة البيانات المراد استخراجها وتفريغ الأعمدة الناتجة في ملف نصي قابل للتحليل:

db=# SELECT road_id, ST_AsText(road_geom) AS geom, road_name FROM roads;

road_id | geom                                    | road_name
--------+-----------------------------------------+-----------
          1 | LINESTRING(191232 243118,191108 243242) | Jeff Rd
          2 | LINESTRING(189141 244158,189265 244817) | Geordie Rd
          3 | LINESTRING(192783 228138,192612 229814) | Paul St
          4 | LINESTRING(189412 252431,189631 259122) | Graeme Ave
          5 | LINESTRING(190131 224148,190871 228134) | Phil Tce
          6 | LINESTRING(198231 263418,198213 268322) | Dave Cres
          7 | LINESTRING(218421 284121,224123 241231) | Chris Way
(6 rows)

ستحتاج أحيانًا إلى قيد ما لتقليل عدد السجلات المُعادة. في حالة القيود المبنية على السمات، استخدم صيغة SQL نفسها المستخدمة مع الجداول غير المكانية. أما في حالة القيود المكانية، فالدوال الآتية مفيدة:

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

SELECT road_id, road_name
  FROM roads
  WHERE roads_geom='SRID=312;LINESTRING(191232 243118,191108 243242)'::geometry;

سيُعيد الاستعلام أعلاه السجل الوحيد من الجدول "ROADS_GEOM" الذي يساوي فيه الشكل الهندسي تلك القيمة.

للتحقق مما إذا كان بعض الطرق يمر في المنطقة المحددة بمضلع:

SELECT road_id, road_name
FROM roads
WHERE ST_Intersects(roads_geom, 'SRID=312;POLYGON((...))');

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

عند استخدام العامل "&&"، يمكنك تحديد BOX3D أو GEOMETRY كعنصر للمقارنة. لكن عند تحديد GEOMETRY، سيُستخدم المستطيل المحيط به للمقارنة.

باستخدام كائن "BOX3D" للإطار، يبدو هذا الاستعلام على النحو الآتي:

SELECT ST_AsText(roads_geom) AS geom
FROM roads
WHERE
  roads_geom && ST_MakeEnvelope(191232, 243117,191232, 243119,312);

لاحظ استخدام SRID 312 لتحديد إسقاط الغلاف.

يتصل مُفرِّغ الجداول pgsql2shp بقاعدة البيانات ويحوّل جدولًا (قد يكون معرّفًا باستعلام) إلى ملف Shapefile. الصيغة الأساسية هي:

pgsql2shp [<options
>] <database
> [<schema
>.]<table>

pgsql2shp [<options
>] <database
> <query>

خيارات سطر الأوامر هي:

GiST اختصار لـ "Generalized Search Tree" (شجرة البحث المعمّمة)، وهي شكل عام من الفهرسة للبيانات متعددة الأبعاد. يستخدم PostGIS فهرس R-Tree مبنيًا فوق GiST لفهرسة البيانات المكانية. وGiST هي طريقة الفهرسة المكانية الأكثر شيوعًا وتنوعًا، وتوفر أداءً جيدًا جدًا للاستعلامات. وتُستخدم تطبيقات أخرى لـ GiST لتسريع البحث في جميع أنواع بنى البيانات غير المنتظمة (مصفوفات الأعداد الصحيحة، والبيانات الطيفية، وغيرها) التي لا تناسبها فهرسة B-Tree العادية. لمزيد من المعلومات انظر دليل PostgreSQL.

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

صيغة بناء فهرس GiST على عمود "geometry" هي كالآتي:

CREATE INDEX [indexname] ON [tablename] USING GIST ( [geometryfield] ); 

ستبني الصيغة أعلاه دائمًا فهرسًا ثنائي الأبعاد. للحصول على فهرس n-الأبعاد للنوع geometry، يمكنك إنشاؤه باستخدام هذه الصيغة:

CREATE INDEX [indexname] ON [tablename] USING GIST ([geometryfield] gist_geometry_ops_nd);

بناء فهرس مكاني عملية كثيفة الحساب. كما أنها تمنع الكتابة في جدولك طوال مدة الإنشاء، لذا قد ترغب في نظام الإنتاج في تنفيذها بطريقة أبطأ تراعي CONCURRENTLY:

CREATE INDEX CONCURRENTLY [indexname] ON [tablename] USING GIST ( [geometryfield] ); 

بعد بناء فهرس، يكون من المفيد أحيانًا إجبار PostgreSQL على جمع إحصاءات الجدول، التي تُستخدم لتحسين خطط الاستعلام:

VACUUM ANALYZE [table_name] [(column_name)];

BRIN اختصار لـ "Block Range Index" (فهرس نطاق الكتل). وهي طريقة فهرسة عامة الغرض قُدّمت في PostgreSQL 9.5. BRIN طريقة فهرسة فاقدة (lossy)، أي أنها تتطلب تحققًا ثانويًا لتأكيد مطابقة السجل لشرط بحث معين (وهذا هو الحال في جميع الفهارس المكانية المتوفرة). توفر إنشاءً أسرع بكثير للفهرس وحجم فهرس أصغر بكثير، مع أداء قراءة معقول. والغرض الأساسي منها دعم فهرسة الجداول الكبيرة جدًا على الأعمدة التي ترتبط بموقعها الفعلي داخل الجدول. وإضافة إلى الفهرسة المكانية، يمكن لـ BRIN تسريع البحث في أنواع مختلفة من بنى بيانات السمات (الأعداد الصحيحة، والمصفوفات، وغيرها). لمزيد من المعلومات انظر دليل PostgreSQL.

حين يتجاوز جدول مكاني بضعة آلاف من الصفوف، ستحتاج إلى بناء فهرس لتسريع عمليات البحث المكاني في البيانات. فهارس GiST عالية الأداء ما دام حجمها لا يتجاوز مقدار ذاكرة RAM المتاحة لقاعدة البيانات، وما دمت قادرًا على تحمّل حجم تخزين الفهرس وتكلفة تحديثه عند الكتابة. وإلا، يمكن النظر في فهرس BRIN كبديل للجداول الكبيرة جدًا.

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

بناء فهرس BRIN أقل استهلاكًا للمعالج بكثير من بناء فهرس GiST. ومن الشائع أن يكون بناء فهرس BRIN أسرع بعشر مرات من بناء فهرس GiST على البيانات نفسها. ولأن فهرس BRIN يخزّن مستطيلًا محيطًا واحدًا فقط لكل نطاق من كتل الجدول، فمن الشائع أن يستهلك مساحة قرص أقل بما يصل إلى ألف مرة من فهرس GiST.

يمكنك اختيار عدد الكتل التي تُلخَّص في النطاق الواحد. إذا قلّلت هذا العدد، فسيكون الفهرس أكبر لكنه سيوفر على الأرجح أداءً أفضل.

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

CREATE TABLE table_sorted AS
   SELECT * FROM table  ORDER BY geom;

بدلًا من ذلك، يمكن ترتيب البيانات في مكانها باستخدام GeoHash كفهرس (مؤقت)، ثم إجراء التجميع (clustering) على ذلك الفهرس:

CREATE INDEX idx_temp_geohash ON table
    USING btree (ST_GeoHash( ST_Transform( geom, 4326 ), 20));
CLUSTER table USING idx_temp_geohash;

صيغة بناء فهرس BRIN على عمود geometry هي:

CREATE INDEX [indexname] ON [tablename] USING BRIN ( [geome_col] ); 

تبني الصيغة أعلاه فهرسًا ثنائي الأبعاد. لبناء فهرس ثلاثي الأبعاد، استخدم هذه الصيغة:

CREATE INDEX [indexname] ON [tablename]
    USING BRIN ([geome_col] brin_geometry_inclusion_ops_3d);

يمكنك أيضًا الحصول على فهرس رباعي الأبعاد باستخدام فئة العوامل 4D:

CREATE INDEX [indexname] ON [tablename]
    USING BRIN ([geome_col] brin_geometry_inclusion_ops_4d);

تستخدم الأوامر أعلاه العدد الافتراضي للكتل في النطاق، وهو 128. لتحديد عدد الكتل التي تُلخَّص في النطاق، استخدم هذه الصيغة

CREATE INDEX [indexname] ON [tablename]
    USING BRIN ( [geome_col] ) WITH (pages_per_range = [number]); 

تذكّر أن فهرس BRIN يخزّن مُدخلًا واحدًا فقط في الفهرس لعدد كبير من الصفوف. إذا كان جدولك يخزّن أشكالًا هندسية بأعداد أبعاد مختلطة، فمن المرجح أن يكون أداء الفهرس الناتج ضعيفًا. يمكنك تجنّب هذا التراجع في الأداء باختيار فئة العوامل ذات أقل عدد من الأبعاد بين الأشكال الهندسية المخزّنة

نوع البيانات geography مدعوم في فهرسة BRIN. صيغة بناء فهرس BRIN على عمود geography هي:

CREATE INDEX [indexname] ON [tablename] USING BRIN ( [geog_col] ); 

تبني الصيغة أعلاه فهرسًا ثنائي الأبعاد للكائنات الجغرافية المكانية على الشكل الإهليلجي (spheroid).

حاليًا، لا يتوفر سوى "دعم الاحتواء"، أي أنه لا يمكن استخدام سوى العوامل && و~ و@ في الحالات ثنائية الأبعاد (لكل من geometry وgeography)، والعامل &&& فقط للأشكال الهندسية ثلاثية الأبعاد. ولا يوجد حاليًا دعم لعمليات بحث kNN.

من الفروق المهمة بين BRIN وأنواع الفهارس الأخرى أن قاعدة البيانات لا تصون الفهرس ديناميكيًا. إذ تُلحق التغييرات على البيانات المكانية في الجدول بنهاية الفهرس فحسب. وسيؤدي ذلك إلى تراجع أداء البحث في الفهرس بمرور الوقت. يمكن تحديث الفهرس بتنفيذ VACUUM، أو باستخدام دالة خاصة هي brin_summarize_new_values(regclass). لهذا السبب قد يكون BRIN أنسب للاستخدام مع البيانات المخصصة للقراءة فقط أو التي نادرًا ما تتغير. لمزيد من المعلومات راجع الدليل.

خلاصة استخدام BRIN للبيانات المكانية:

SP-GiST اختصار لـ "Space-Partitioned Generalized Search Tree" (شجرة البحث المعمّمة المقسّمة مكانيًا)، وهي شكل عام من الفهرسة لأنواع البيانات متعددة الأبعاد يدعم أشجار البحث المقسّمة، مثل أشجار quad-tree وأشجار k-d وأشجار radix (tries). والسمة المشتركة لهذه البنى أنها تقسّم فضاء البحث مرارًا إلى أقسام لا يلزم أن تكون متساوية الحجم. وإضافة إلى الفهرسة المكانية، تُستخدم SP-GiST لتسريع البحث في أنواع كثيرة من البيانات، مثل توجيه الهاتف، وتوجيه IP، والبحث عن السلاسل الجزئية، وغيرها. لمزيد من المعلومات انظر دليل PostgreSQL.

كما هو الحال مع فهارس GiST، فإن فهارس SP-GiST فاقدة (lossy)، بمعنى أنها تخزّن المستطيل المحيط بالكائنات المكانية. ويمكن اعتبار فهارس SP-GiST بديلًا لفهارس GiST.

حين يتجاوز جدول بيانات GIS بضعة آلاف من الصفوف، يمكن استخدام فهرس SP-GiST لتسريع عمليات البحث المكاني في البيانات. صيغة بناء فهرس SP-GiST على عمود "geometry" هي كالآتي:

CREATE INDEX [indexname] ON [tablename] USING SPGIST ( [geometryfield] ); 

ستبني الصيغة أعلاه فهرسًا ثنائي الأبعاد. ويمكن إنشاء فهرس ثلاثي الأبعاد للنوع geometry باستخدام فئة العوامل 3D:

CREATE INDEX [indexname] ON [tablename] USING SPGIST ([geometryfield] spgist_geometry_ops_3d);

بناء فهرس مكاني عملية كثيفة الحساب. كما أنها تمنع الكتابة في جدولك طوال مدة الإنشاء، لذا قد ترغب في نظام الإنتاج في تنفيذها بطريقة أبطأ تراعي CONCURRENTLY:

CREATE INDEX CONCURRENTLY [indexname] ON [tablename] USING SPGIST ( [geometryfield] ); 

بعد بناء فهرس، يكون من المفيد أحيانًا إجبار PostgreSQL على جمع إحصاءات الجدول، التي تُستخدم لتحسين خطط الاستعلام:

VACUUM ANALYZE [table_name] [(column_name)];

يمكن لفهرس SP-GiST تسريع الاستعلامات التي تتضمن العوامل الآتية:

لا يوجد دعم لعمليات بحث kNN في الوقت الحالي.

عادةً ما تُسرّع الفهارس الوصول إلى البيانات بشكل غير مرئي: فبمجرد بناء الفهرس، يقرر مخطِّط الاستعلامات في PostgreSQL تلقائيًا متى يستخدمه لتحسين أداء الاستعلام. لكن توجد حالات لا يختار فيها المخطِّط استخدام الفهارس الموجودة، فتنتهي الاستعلامات إلى استخدام مسح تسلسلي بطيء بدلًا من الفهرس المكاني.

إذا وجدت أن فهارسك المكانية لا تُستخدم، فهناك بعض الأمور التي يمكنك فعلها:

لمزيد من المعلومات انظر قسم دليل Postgres الخاص بـ تخطيط الاستعلامات.