Building versus parcel

183 viewscadaster cadastral maps OpenStreetMap
0

In this picture you can see part of a cadastral map of Amsterdam in 1832. You can see the full image on https://beeldbank.cultureelerfgoed.nl/rce-mediabank/detail/a7600248-94d7-11e5-a533-bf111696f08c/media/39be07ff-860e-ace5-5d62-87c6ad68a9b4 

The bottom block starts on the right with parcel number 1121, and then continues through to the top-left of the block with parcels 1131, 1132 and 1134. Parcel 1132 is numbered on the map as “32” to save space. This relates to the question of FREDERIC 

The specific point I want to raise is that some parcels are in their entirety a building. Others overlap for the most part, such as parcel number 1124; the building does not span the entire parcell. Most often this arises when large sheds are built behind the actual house. The part on the side, most often is a wood-storing-place or some other type of shed. So, this is not necessarily a roman atrium (besides being open on 1 end).

Do mind parcel 1127, that contains an arrow to the part on the left. In Dutch we call this “bijpijlen” (something like add-by-an-arrow in english), and is jargon for the cadastre. So, parcel 1127 is 1 parcel, with 1 building on top (as far as we can tell from the scanned map, leaving aside the interpretation of the “parts” of the building).

The red markings under the numbers are some sort of check-marks for contemporary operational processes; that contains no information in this case. As you may notice, the buildings are hatched, and not fully filled. But that’s only a minor inconvenience of automatic processes.

Also note the building on parcel 1121, which is blue. This is not because the parcel is water (although the water itself is also blue, as can be seen in the very bottom of the crop), but because public buildings were coloured in blue.

You can take a look at the joining Original Appointing Table (Oorspronkelijk Aanwijzende Tafel in Dutch) or OAT in short at https://beeldbank.cultureelerfgoed.nl/rce-mediabank/detail/ebfb1212-94d7-11e5-b618-cfdefd61c55b/media/434a39d0-d912-3877-e2ca-c9e27b38f79f . There you find all of the data for those parcels. As you can see, parcel 1121 is a church. All of the other parcels are mentioned as “house” (with two of them as warehouse). As you can see, they are not rendered red. The obvious reason could be (there were no strict orders to do so) that the map would become “unreadable” by making them all red. So they clearly chose some alternating colour-scheme. There is a lot of extra information we derive from those OAT’s, but that gets very complicated, extremely soon. Simply said: based on the taxation, there are other registers that describe more in detail what kind of houses those are. The easiest proxy-parameter of this can be seen in the register in column 20, mentioning the “klasse” (ordered class) of the building, lower being better, and thus very specifically defined to what that class means.

The point I want to raise is this: how do these buildings pertain to the parcels?

There is something to be said for a model where buildings are “on top” of parcels. In classical desktop-GIS, this most often is translated to separate layers, with buildings in 1 layer, on top of parcels. This holds some weight, but isn’t the entire story. This model requires you to first draw a parcel, and then draw a building on top. This conflicts with principles of linked data. There, the type of an entity can be derived as an emergent property from all of the statements about (and logically reasoned by inference) that subject.

That’s a bit abstract. More hands-on: we draw polygons for parcels and buildings in 1 datalayer. Buildings overlap the parcel, if they only overlap part of it. A polygon can be a building and a parcel at the same time. Establishing if an entity is a building or a parcel (and how it should be displayed, for example) should be determined from all of the propositions about that subject, als subject – predicate – object triples. So, in order to avoid duplication and achieve the most basal form of data, to be flexible for all possible applications, we need this abstraction, and all statements about geometries, should be stored als data-triples. That can be in a genuine triple store, or in a relational environment in which all of the data is compiled from a triple-table, having three columns: the subject to which the statement is referring (the geometry), the proposition about the subject (the property) and then as the third column, the object of the statement (the value of the property).

The OpenStreetMap system implements this exact model in a relational (postgres) context for manageability, but thus also achieves linked-data triples in doing so, although not really a triple store per se. It is the only “tool” that does that, and therefore is the only (Open Source) tool capable to do so, besides custom built software and notepad. But writing triples with notepad isn’t a real use-case I suppose.

So, going back to the question: are buildings located on top of parcels as separate entities? I think not, and feel they are all part of of the map-geometry, with semantic properties (such as being a building or not) being able to be derived from the image (colour-identification), but also sometimes needing other confirming data, as for example with the OAT-data. We thus need to be aware that (semi-) automatic processing of cadastral maps will miss-identify some of the entities, and the RFC will need to sketch out the frame in which these kinds of corrections can be applied.

Asked question
Add a Comment
Write your answer.