Talk:Ireland/Mapping Townlands

Hamlet node in middle of townland?

Wondering if it is correct to map townlands with a place->hamlet node in the middle? Presumably this is so that the name shows up in the display of the map?

Example: https://www.openstreetmap.org/relation/2438828#map=15/53.6100/-7.7687

There is an extra hamlet node in the middle of it: https://www.openstreetmap.org/node/1931557168#map=15/53.6105/-7.7620

This looks like the standard for the surrounding area.

Is there any documentation on whether this is correct or not?

EoghanM (talk) 14:25, 4 March 2018 (UTC)

Hamlets within towns (or villages, or suburbs) are perfectly correct. Both can be represented as (place=*) nodes, and as areas (or boundary relations). This is a very common situation everywhere in the world (not specific to Ireland).

The condition is that hamlets must be inhabited, otherwise they are just place=locality nodes (normally without boundary relations, but possibly within a delimiting area or multipolygon relation not necessarily tagged with any place=* which is used essentially for islands or lakes, rarely for forests.

Notes:

• multipolygons don't have any "admin_centre" or "label" member nodes (only "outer/inner" member ways), as they are not boundaries which are more formally defined (but boundaries may in some cases not be so precisely defined in terms of geometry for the surface they are supposed to enclosed, frequently boundaries are approximations, while multipolygons and other closed ways used as areas should be geometrically precise);
• so your place=hamlet node will be associated in this case with the multipolygon or closed way area only because it is found within it, and the place node should be fully tagged for itself (independantly of multipolygons, closed ways, and boundary relations that enclose it and that may be named and tagged differently than the place node;
• that place node may eventually be used to position the "label" for a boundary, but the boundary object will not use any one of its tags which may be conflicting: a "label" node in a boundary relation is only used for the coordinates of the node as a hint specifying an "optimal" position the label for the boundary relation, but renderers may then adjust this position
• renderers should then use only the names tagged in the boundary relation but not any tags of the referenced node with "label" role in the boundary relation: the boundary relation controls everything;
• but this is not the case for multipolygon relations which are only defined by their inner/outer member ways and their own tags, and have no suggestion at all given to renderers for placing their label, because any subarea in the multipolygon is valid and may be rendered with a label).

In your case, you defined a boundary (not a multipolygon) for the hamlet, the place node in the middle is OK but may be referenced as the "label" node member of that relation (I don't think it is an accurate "admin_centre").

That node does not need to be named (the names are defined by the boundary relation), and this node is then only used as a substitute of the boundary relation when the zoom scale is two low, or is rendered separately at high zoom scale (in which case it has to have a name to be rendered: using it as the "label" member of the relation should indicate to renderers that they should not render BOTH the relation label, AND the place node label, it should be the same one.

The classification as place=townland for the larger admin boundary type, and as place=hamlet for the small inhabited place node in the middle is correct, they don't have to match the same place=* tag value. The values of place=* tags are treated differently for boundaries (notably the boundary relations with boundary=administrative) than for other objects (nodes, closedways/areas, multipolygons), because place=* tags in boundaries are not necessarily linked to the population but to the type of admin boundary. place=* tags in other objects (nodes, closedways/areas, multipolygons) are linked to their population independantly of the administrative status of boundaries enclosing them.

In your case, you just have a small hamlet named "Lislea" which is just a place node (without any boundary, but it could have a virtual/unofficial one as a landuse=residential or landuse=farmyard polygon or multipolygon), enclosed in a townland boundary which just happens to have the same name (this situation allowed and in fact very common in the world, but that townland could also be named differently than the hamlet, such as "Lislea Townland" to make the distinction clearer between the two distinct objects where the townland encloses the hamlet, but the hamlet does not cover the full townland; but appropriately the two objects are not the same type of place even if they just happen to share the same name... If you search "Lislea" in Nominatim, you'll correctly get two results, one for the hamlet node, another for the larger townland; Nominatim will display the same name for both, but should not display the same type of place; if you click on the hamlet proposed the map will zoom in to that small node, if you click on the townland, the map will zoom out to show you the full townland).

Now which label will be displayed on the map ? There's a name defined for the object with standard place=hamlet tag, but place=townland is undocumented and will likely not be recognized and so the name defined for it will probably not be rendered at all (but renderers could display both labels, one centered on the hamlet and styled like other hamlets, and another label for the townland, anywhere inside it, with a default style or an appropriate style for townlands which could be using different color or font size; if the two labels collide, one of them will be eliminated and not rendered according to priorities: a renderer may choose to render the label for the standard place=hamlet and discard the other, or could choose to give priority to labels for larger boundaries before labels for nodes: this choice of priority will be dependant on the zoom level because labels for boundaries at high zoom levels are preferably rendered along the boundary outlines and because there are different priorities for rendering centered labels for boundaries depending on their admin_level or other admin_type). — Verdy_p ^(talk) 16:35, 4 March 2018 (UTC)

I think there are at least two cases:

• An original imported GNIS node never got deleted when the townland boundary was created. (Not the case with your Lislea example). These are usually place=locality and in the absence of the same name appearing in italic Mixed Case on GSGS3906 I think they should be deleted. In most cases these are just nodes corresponding to the (now mapped) townlands.
• Places added manually by a mapper, which may be townlands, actual inhabited settlements which share a name with the townland, or other localities. Again checking against GSGS3906 is a useful way of seeing if a given use of a name has a long-standing history. Your Lislea example is in this category. Many localities have been mapped as subtownlands in some parts of Ireland, but I'm not familiar enough with the concept and usage to say more.

Townlands cannot really be said to have an administrative centre, so I see no role for this type of mapping in OSM. Howwever quite a few do exist because GNIS data and townlands were not conflated as the townlands were mapped.

In summary: I would expect a place node with a name identical to the townland name will ony exist when it refers to some specific other locality. SK53 (talk) 12:50, 5 March 2018 (UTC)