I often see in my region places have an OSM way an OSM node with the same name and place tags.
For example (not from my region), Maisenbachsiedlung has a node and a closed way that have the same place and name tags:
name = Maisenbachsiedlung
place = hamlet
As far as I understand, this mapping approach does not follow the “One feature, one OSM element” principal, and the case of Villages under “Situations where multiple elements may be needed” in particular. In the wiki, there is a clear distinction between the tags placed in nodes (place and name) and the tag used in way (landuse).
This question here is what should be done for places where the same place and name tags are used on both a node and a way/relation representing its area.
I wonder if Overpass/-Turbo is able to find all nodes and closed ways that overlap them such that each node has the same “place” and “name” tag values as its overlapping way. This could help in understanding the extent of this question.
Yes, you can find these in overpass. I would suggest to add the place nodes with role=label to place relations (or admin_centre to administrative boundary relations). At least “label” seems the mostly used role, although it is controversial because labeling is done in map producing, not when collecting geodata, so a different name (e.g. “centre”) for the role could maybe find more support.
As mentioned there, the area likely should be changed to landuse=residential . There’s no obvious reason why the =farmlandWay: 352327143 | OpenStreetMap or =water_tankNode: 10665468237 | OpenStreetMap next to it shouldn’t be considered part of that place= , resulting in such a weird shape , raising suspicion it should be landuse=residential instead of place= .
In this case, you should definitely detach the area from the highway=residential . Same should be done for other landuse= and natural= around it.
Ideally we find that it actually exists as an official entity, that it can be converted to boundary=administrative . The place= can be linked by being a label of the =boundary . The common situation of having place= tagged on boundary=administrative is bad.
However, in the event that there’s really a verifiable extent for a non-administrative community, boundary=place may be used. This can still be exempted by the “Object oriented vs functional oriented mapping” criteria , as the place= point is the concept of the recognized center of the community, and boundary=place may be interpreted as a definable border for it.
Using boundary=place instead of place= avoids double-counting. This further prevents any conflict in info from the point and an inaccurate centroid automatically generated from the area when processing.
if we agree that the place describes the settlement, the reason the farmland is not part of it is that it is a farmland and not built up area, and it also isn’t an “island”, but is followed by other farmland (in the case of an “island” of differently used land inside a settlement, I agree it could be discussed), so there is no reason (at least from looking at the map) that it should be part of the settlement
Ok it was only a starting issue. This treatment is still inconsistent. What if a riverside or lakeside field is surrounded by houses on 3 sides? If that’s a =pond , is it considered part of the community?
In the question, there are these parts:
Trees on the SE corner
Narrow strip of land (may even be covering the field) along the road between NW part and center, which only seems to exist to connect them avoiding a =multipolygon
=pond and land on the south
There is not much meaningful differences in them. Adding addresses would be more reliable to tell the extent. There are certainly better methods at distinguishing built-up areas, which can yet have many definitions.
Many cases nearby are even place= + landuse=residential without name= . And then this one actually splits it by postal_code= … Way: 51497529 | OpenStreetMapWay: 605584492 | OpenStreetMap
Others further look entirely arbitrary Way: Eßfeld (23901105) | OpenStreetMap
If you add boundary=place, you at least add more guarantee this means an area in addition to a place= point. There exists some wrong place= areas without place= points (obviously not =plot , =borough etc) inside. But yes, this shows a problem with using boundary=place, which I still dislike. Changing meaning and duplicating of a feature tag in different object types makes poor data.
The label role means the same thing on a boundary=administrative relation as it does on a boundary=place relation. admin_centre is for clarifying that one particular place within an administrative area’s boundary serves as the administrative area’s administrative center (in other words, the seat of government or capital city).
I agree that both label and admin_centre are confusingly named. I think label was originally coined as a hint to renderers, as an override for when the default centroid calculation looks wonky, but that isn’t generally what it’s used for today. Meanwhile, admin_centre gets misused a lot because mappers think it means “the center of the admin[istrative boundary]” rather than “the center of admin[istration]”. Remember this point the next time someone promotes a shorter tag spelling because it requires less typing.
There have been proposals to rename these roles, but so far nothing has caught on. The existing roles have already “found support” among data consumers. The root of the problem is that we’re talking about two different notions of a “center” that can exist simultaneously: the cultural/demographic/economic/logical center of the place itself, versus a different place that serves as the place’s administrative center. It’s difficult to describe these relationships succinctly.
Technically, admin_centre isn’t really a geospatial relationship. Rather, it falls in the same category of basic place facts as a country’s flag or coat of arms, or a city’s twin cities/sister cities. But there’s a natural tendency to want to map this kind of information. If we say a place is a capital, then naturally the next question is what the place is the capital of.
I understand the alternative mapping with a boundary=place relation, and it may be the goal for a future bulk edit.
In the meantime, I would like to understand if it is also fine to keep only the landuse tag on the area, and keep the place, 'name*`, and similar tags on the node.
Both possibilities are valid, but with different emphases and different consequences. If the landuse area remains named, then its shape is constrained to whatever people consider that name to represent. This is useful information. On the other hand, if the landuse area loses the name tag, then it can be broken up further according to whatever people consider the landuse to be – also useful information – without having to nest one landuse area inside another. (This is a nonissue for a place as small as Maisenbachsiedlung, but you can imagine larger cases where it might become more relevant.)
The landuse could have been mapped with the help of maps4bw, then a valid source. If you have a look at Kartenbasierte Suche - LEO-BW, based on the replacement that not can be used for mapping anymore it seems to be very similar to the mapped landuse. Some small changes that nobody had mapped until last years end of Maps4BW.
The split is along the stream, both parts have the same postal code.
That’s a diffeent story because we crossed the border to the federal state of Bavaria. No such nice sources as in Baden-Württemberg and other rules for the use of admin_levels: DE:Grenze - OpenStreetMap Wiki
Since Eßfeld is only part of Giebelstadt - Wikipedia it can’t have it’s own administrative border. The name key was once a place_name key and changed to name because of validator results.
Oh sorry, I got thrown off by the mere existence of postal_code= on them. Still, the critical problem is there are 2 unnamed place= duplicating the same concept. Besides for that matter, there is already a boundary=postal_code covering it now, meaning the postal_code= is not absolutely necessary. Relation: 3353593 | OpenStreetMap
place= without a name= is IMO always an error and should be flagged by validators. Place is a social construct, denoting how people refer to a certain area, and should always be given a name.
There are perhaps some gray-ish areas such as place=islet, but I don’t see the need to tag unnamed ones: a small land area surrounded by water is obviously an islet, nobody needs a tag to tell them that.
Similarly, if you see a group of dozen houses in a remote area, do map a landuse=residential, but if you don’t know if it’s named, do not invent a place=hamlet.
are remains from old tagging and should be reduced to simple landuse=residential. Wenkheim itself could probably have its own administrative boundary, but there’s the need for a source that could be used in OSM. And there’s the question of the right admin level too, probably 10.
removing the place tag from the place area would not be acceptable, even if it is only approximative it is still bearing different information (size, extent, shape, orientation) than just a node. If I found an area tagged like this, I’d rather remove the landuse=residential and tag it on the effective residential landuse, not the whole settlement
Is it possible that this area is conflating multiple concepts, and that we shouldn’t try to conflate it with even more concepts? Does the postal code of 97956 strictly correspond to a village that is strictly residential? If not, maybe the postal code, village, and residential landuse could all be separate features. Of these features, the village is the most likely one to have a name.
We’re discussing mainly about hamlets and small villages, which in most cases only have an easily identifiable residential area. Therefore, landuse=residential is the correct and verifiable tag. If you also spot a sawmill or a farm around, by all means split it off from the residential area with an appropriate landuse.
However, keeping only the place= tag at an area is most likely wrong: place polygons should have verifiable boundaries in some manner (legally or by tradition) , and I doubt that information exists for most small villages, particularly if the houses are dispersed. Keeping it is doubly wrong if a named place node already exists: the node identifies a general location, with vague boundaries (as they probably are in the real life).