Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

Multipart points, lines, and polygons are implemented in nearly every GIS, but what benefits, if any, do they provide?

In a relational database attributes shared by different features can be stored once, and IDs used to link them to separate geometry records. So are multipart features a legacy of flat file data storage?

alt text

share|improve this question

2 Answers 2

up vote 26 down vote accepted

If your software doesn't support multi-part features you may have to go to extraordinary and complicated lengths to execute spatial operations. For example, the intersection of two polygons can, in general, have more than one connected component. It is convenient, both algorithmically and conceptually, to suppose that such an intersection returns a single object (a multipart polygon) rather than an arbitrary number of polygons. (For the same reasons it is helpful to support various forms of null and degenerate features--for example, polygons having an extent but zero area or even polygons with locations but neither extent nor area. These things can arise from geometric operations; supporting them eliminates a lot of fussy case-by-case post-processing and can prevent useful information from disappearing.)

From a relational database point of view, multipart features make normalization possible: when an attribute is inseparable from a collection of polygons, you want to represent that collection as a single object. A good example would be a feature representing almost any country in the world having a coastline, because the country probably includes some islands. Do you really want to force your RDBMS to make one copy of the country's attributes for every little island? Most likely not. You don't even want (or need) to maintain multiple copies of a pointer to the attributes, either.

How would you represent a network or a branching tree if not as a coordinated multi-polyline?

From the point of view of mathematics or algorithmic data structures, allowing a multipart feature is a simplification, not a complication. In order to support multiply connected polygons (rings and polygons with "holes") you already need the apparatus for representing multi-part polygons.

Finally, "vector" objects and their typical "spaghetti representation" have their origin in the theory of simplicial complexes. (It is only through this somewhat tenuous connection to the theory of topology that the term "topology" made it into GIS, which otherwise uses essentially nothing from that theory.) That theory requires, and benefits from, multi-part features. In fact, having just a single component is not part of the definition of a simplicial complex, but rather turns out to be a special property enjoyed by some of them (as detected by the rank of their zeroth homology group). As such, "single part" is not a defining property, but is just a topological quality in the same sense that having a ring or a "hole" in a polygon is a topological quality (related to the rank of the first homology group).

share|improve this answer
1  
Very nice answer. I'm not 100% convinced about using multipart features to normalise a database - each polygon still has unique properties such as area and length, and a query such as "how much of Greece's area is made up of islands" becomes hard to answer without giving each polygon attributes. –  geographika Nov 22 '10 at 19:51
2  
@geographika Yours is a good example of why one needs flexibility in representing entities (spatial or not) with databases. To stretch it further, one could also argue that individual polygons need to be "exploded" into their outer and inner rings in order to answer questions like "how much of Greece's area is made of up lakes?" Any given database structure will make certain queries easy and other ones harder; part of good database design therefore must include considering the intended uses of the database. A good (spatial) DBMS will provide mechanisms to convert among different structures. –  whuber Nov 22 '10 at 19:59
2  
+1 Great answer. It might be worth discussing performance drawbacks to multipart features though. Take a polyline featureclass of US highways where highway features are split at state boundaries. Create a second featureclass by dissolving on highway name, resulting with I-10 spanning the continent. Now compare performance of the Identify tool. Unless ESRI's spatial indexing strategy has changed, it will be slower on the multipart featureclass since there are a lot more MBRs that overlap each other. Each coordinate of each feature whose MBR overlaps the point is examined. –  Kirk Kuykendall Nov 22 '10 at 23:12
    
@Kirk Good point. Your examples point to deficiencies in ESRI's technology more than they highlight problems in principle, though. Identification of a feature by means of a reasonably efficient but simple spatial data structure, such as a quadtree, should have O(log(N)) performance (after initial caching of a stored data structure). Splitting each of N features (presumed large) into an average of K pieces (presumed moderate or small compared to N) increases log(N) to log(N) + log(K), which--given the presumptions--is practically unnoticeable. –  whuber Nov 23 '10 at 15:48
1  
@Dandy Thank you for highlighting the distinction between a multi-part geometry and a mere collection of pieces. I don't think all multi-part feature types necessarily "constrain" their components; this is likely implementation-dependent--which points out that the concept of "multi-part" contains some subtle variations. –  whuber Dec 6 '10 at 20:44

Imagine joining population data to a table of single-part polygons representing countries. Depending on how you do the join, either every island would get the full population of that country or only one polygon of the set would get the full population. Without representing the country as a multi-part polygon you have to either apportion the population (needlessly complex and inaccurate) or collect the polygons together before joining in which case you essentially end up with a multi-part polygon again.

share|improve this answer
    
+1. Good example. –  whuber Dec 7 '10 at 21:12

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.