|
This is a question about Sheffield. For some time now it's happily existed in OSM as a relation: http://www.openstreetmap.org/browse/relation/106956/history with the "Sheffield City Centre" node (which has been tagged as a suburb) as an admin centre: http://www.openstreetmap.org/browse/node/266155142 Recently a new "Sheffield" node has been created: http://www.openstreetmap.org/browse/node/2494466157 and at the same time "place=city" was removed from the relation. Other than the name, there's nothing to connect the new "Sheffield" node with the wider Sheffield area which is encompassed by the relation. Would I be correct to delete the new "Sheffield" node and re-add place=city to the relation, i.e. put the situation back how it was before the most recent edit? What's the "usual practice" elsewhere? |
|
They are also important for navigation, they need to be a sensible place that someone who just wants to go to Sheffield is likely to want to arrive at, i.e. the city centre. This really is a matter for the mappers judgment. In the case of an inland city it may well be the geographical centre that can be worked out from border relations, but for a coastal city such as Brighton that will break down as the geographical centre is likely to be in a housing or industrial estate. 2
The wiki states, "it is preferred to place it where the city hall is located."
(17 Nov '13, 03:34)
he_the_great
5
The wiki is (as ever) wrong. City halls can often be in fairly arbitrary locations: for example, in Burton-on-Trent, the town hall was built out-of-town in the 19th century, in a failed attempt to establish a new town centre. Generally the decision should be taken by local mappers, who will know better than others where the city's centre is.
(24 Nov '13, 11:37)
Richard ♦
|
|
For my Garmin OSM maps (and many other renderers) a node with place=city and population=* is important, without this a big city like Sheffield would be invisible until you zoom in really far (until you see Sheffield City Centre which is tagged as suburb). So please do not restore the former situation. Why can't you add that city node to the relation with role=admin centre? ... also Osmand app makes use of single nodes for each city and place, so please keep unique nodes according to http://wiki.openstreetmap.org/wiki/Key:place And these city nodes are also importand if any application is used to create an overview map of a country, a continent or even the whole planet.
(16 Nov '13, 19:31)
stephan75
2
I don't see why any of these applications can't use the relation instead of the node.
(16 Nov '13, 20:31)
scai ♦
|
|
I don't know in UK. But in France, I would certainly keep one node tagged as "place=city" as member of the admin boundary relation with a role "admin_centre". I see the "place=suburb" as a subset of the whole city. The wiki page about "suburb" is also saying "Use place=suburb to identify a major area in a place=town or place=city with a distinct and recognised local name and identity.". So the suburb node is not replacing the city or town place element. Note that the "place" tag is not necessarily a node. It could be a huge polygon representing the urbanized area (but this is not something usual, I agree). Identifying the city centre or the urbanized area is obviously a valuable information. The admin boundary is just showing the municipality borders. But it's not telling where the city/town "centre" (downtown) itself is. This can be the centroid of the admin polygon or somewhere else. 2
it seems like role=admin_centre and role=label could often be located at the same node--is there a preference on which to use? are they both used by the renderers?
(18 Nov '13, 16:01)
neuhausr
1
I know that admin_centre is used by nominatim, the OSM name finder (geocoding) but not by renderers. I'm not sure that the role "label" is used at all today (since it is quite rare). Both roles are optional in the relation. And we still have many cities/towns without admin boundaries in OSM.
(19 Nov '13, 10:33)
Pieren
|
Thanks to all who replied. Now changed in:
http://www.openstreetmap.org/browse/changeset/19082723