This is an oversimplification that would exacerbate the tensions around place classification.
As things stand, a place=* point represents one of two things:
- The geometric centroid of an administrative area
- The conventionally accepted centerpoint of a human settlement that has no formal boundaries (e.g., an urbanized area, a neighborhood)
Data consumers are largely capable of computing the centroid automatically, so we should deprecate this usage as redundant. If we were to eliminate these points en masse today, some data consumers would break, but surprisingly not the usual suspects. (OSM Carto prepared for that many years ago.) I think it would be safe to delete centroid points for very local administrative areas, such as barangays in the Philippines, but we should wait a while longer for more prominent features like states and countries until stragglers like OpenMapTiles switch to using the boundary relation.
On the other hand, in many countries, the place point of a named settlement only has a tenuous relationship with an administrative area by the same name. We need to keep these concepts separate to prevent confusion. The boundary should not have a place=* tag, and the place=* point needs to reflect the settlement more holistically. Renderers can avoid duplicate labels by prioritizing the label member when present. (OpenHistoricalMap’s main renderer has implemented this approach, and database cleanup is underway.)
Several related issues are explained in more detail in these conversations:
- How is place=municipality used correctly and are there country/state-specific rules not to use it at all?
- Acknowledging provinces in website search results
- Toward a national system for functionally classifying populated places
- ke9tv's Diary | New York minor civil subdivisions - status and progress | OpenStreetMap
