From an OSM perspective, it is a mare coincidence that in in a small place the postal code is the same as the entire landuse=residential. This is clearly not the case in larger places.
In addition, if the place also had a dairy plant complex, or another agriculture facility with a mailbox, I’m sure it would have had the same postal code, although that area could not be considered residential.
Therefore, the “One feature, one OSM element” rules call for:
A place node with its name
A landuse=residential area - a closed way or a relation. Without a name
The postal code approach should probably be aligned with the country-wide practices, such as the use of boundary relation in Germany. That approach would surely use the “One feature, one OSM element” rule.
For example, the boundary of the 97956 postal code is relation 3353578, not only the residential area of one of its hamlets.
When a named place has a single postal code, that postal code may added to the place element. In that case, the postal code tag does not define the OSM element. It becomes another piece of information about the place, much like population.
I should have mentioned, @dieterdreist, that this is the complete tagging of the two areas - and both together are the landuse residential of the village Wenkheim (without its isolated dwellings and hamlets) with a place node of its own, the main problem of this topic.
Back to the topic: A named place as area can avoid the assignment of a wrong place node in a Nominatim search, i.e if you search for Siedlung Mehlen | OpenStreetMap you get the village Brunntal but it would be correct to have Wenkheim instead.
We’re discussing mainly about hamlets and small villages, which in most cases only have an easily identifiable residential area.
it is not uncommon in villages and hamlets to find workplaces, e.g. farmyards or workshops, you should not assume that only because it is small there is just residential landuse
An average agriculture-oriented village is a mixture of housing, farm amenities, animal shelters, backyard gardens, with an occasional shop or pub mixed in. We do not normally micromap those into plots and subplots; we map a dominant landuse, which is residential for a better part of the village. Particularly, a small workshop or a grocery store within a residential area should not be tagged as industrial or commercial. I don’t have much problem with religious for the churchyard or education for the schoolyard, but those plots tend to be sizable. And I don’t bother cutting those out from the surrounding residential area, because I regard them as special amenities in service of the residents.
Overall, it’s all about good measure. But generally, ultra-fine division of landuse is frowned upon.
In my city, previous mappers added polygons for named areas tagged place=neighborhood + landuse=residential (example history). For each of these I’ve been creating a new boundary=place relation made up of the original way and a new place node with the label role. I tag both the relation and the node with place and name, but remove those tags from the way. This is slightly duplicative, but it was the only way I could come up with to add the places as nodes without removing the work of the previous mapper who added the polygons (I don’t wish to get into the whole verifiability conversation). This allows these places to show up in data consumers that don’t process place polygons (like the standard layer) while linking the node and relation together so they can be processed as one object by other data consumers. I’m not entirely sure how Nominatim processes this data, but it appropriately displays just a single result when I search for these places by name.
Overall, it’s all about good measure. But generally, ultra-fine division of landuse is frowned upon.
it is discussed, there are forces of inertia to surmount, but I think it is inevitable in the long run. It will provide more information and make more interesting use cases possible, at the cost of making clean looking mid zoom levels more difficult (fragmentation)
Let’s agree to disagree, then. In the approach of excluding residential roads and small amenities from residential landuse, I see about zero advantages and many disadvantages: from complicated landuse-based queries [which triggered the thread I linked above], through increased tile size, complicating rendering, and inconvenience for the mappers (performance degradation and overall mess on the map). Why use a simple solution when a complicated one will do?
Can you explain what’s “complicated” to query there? You shouldn’t Map For geoprocessing. A competent user should be able to accept the data in higher level-of-detail. It’s up to that user, or other services, to generalize or simplify detailed data to what they need. We aren’t expected to fit into how they work. On the contrary, doing that makes retrieving land at block level impossible. Such removal of info is irreversible.
As mentioned there, buffer then dissolve can be used in QGIS. In ArcGIS Pro, there is “aggregated polygons”. Depending on what is wanted, it may even rasterized, to be examined in cells.
Anyway, your previous comment was about land lots, but that post is about blocks, which is even more acceptable. Land use is commonly examined by street blocks. landuse=highway does exist, and there’s nothing preventing anyone to draw it for every public street.
For your listed disadvantages:
Reality and datasets are expected to be “complicated”, usually not coming in exactly the format you want. It’s one’s job to work with them.
Umm, are we using storage size to ban adding details?
I believe generalization and simplification is a standard part of cartography and rendering
Who are “the mappers”? I don’t find any micromapping inconveniencing me. Including when I do find some “messes” of unsatisfactory indoor= features, which means they should be improved, not removed and banned forever.
4.1. You can ignore them if you don’t like working on them. No one is forcing you.
4.1. I find block-by-block landuse= nicer. It also provides a consistent standard of size to draw to.
I think we’re getting rather off-topic for a topic that was originally about how to model places. Relatively few places would represent a uniform landuse, even if modeled as an area or boundary. There’s a lot to discuss about landuse and landcover granularity, but it would benefit from a new topic centered around examples of common and challenging situations.
Same here! I’m looking at an area where neighbourhoods have been mapped twice - as areas, for geocoding, and as nodes. I’ve been trying to figure out what to do with it, because some renderers will show the place name twice.
The solution you have described sounds good, because it should allow data consumers to deduplicate. It is sort of documented on the Wiki, under the boundary=place page, but the main Key:place page just talks about nodes or areas but not both.
I am thinking of adding something like the following:
When a settlement is mapped both as an area and as a node, the two can be combined into a relation: When the place corresponds to an administrative boundary, the place node can be added to the relation with role=label. When the boundary is not an administrative boundary (but can still be verified), use boundary=place instead.
Does that sound good to everyone?
It seems to be a not uncommon scenario. Of 135,988 suburb nodes, 9,547 or so duplicate an area, at least as far as I can see (same name, same place value, and the node is within the area). In 4,179 cases the node isn’t part of any relation.
I think the suggested guidance is an accurate reflection of current practice. However, I don’t think the combination of place points and place boundaries completely obviates the need for named landuse areas. I don’t want to derail this thread any further, but suffice it to say that a place boundary is a very uncommon approach to mapping an apartment complex or mobile home park. We shouldn’t have a completely different approach to modeling those planned residential communities as we have for a subdivision (estate) of single-family homes, especially since a given neighborhood can be a mix of housing styles.
To conclude, I will point to previous posts on this topic, including my view on why place= is not the same as them, and landuse= + name= should have an actual feature as shop=mall , man_made=works , amenity=school are for landuse==retail , =industrial , =education (ignoring the latter two’s debate or chronological order) Add a Residential Property area-type for individual properties - #23 by Kovoschiz
I agree, the neighbourhoods and suburbs I am looking at (that are mapped as place node and area) are much bigger than the average housing estate, they can consist of multiple housing estates (which can be mapped as named residential landuses), as well as other landuses (e.g. an industrial estate) and mixed-use historical centres / high streets because they often grew as villages before being amalgamated into the city.
Named landuse areas sort of do the job, and I’ve used them myself… however, I find this approach inconsistent with our general principle that a named human settlement should get a place tag. We have a plethora of place tags, including some quite exotic such as isolated_dwelling or farm (why don’t you draw a building or a farmyard instead?) as well as a city_block or, god forbid, plot. So what would be wrong with something like place=estate (insert a better name) for similar gated communities, sub-neighborhoods and like?
I’m not even against double tagging, but I’d really prefer to have: name=Arbor Oaks; landuse=residential
accompanied with place=estate
Imagine that you’re developing a mobile app for taxi or delivery purposes, and you’d like to display a map that facilitates navigation. So at minimum, you’d need to download only the information about highways, places and addrs, perhaps buildings… but suddenly, you also need to query for landuse=residentials you normally don’t care about so that you have those gated communities mapped. Yeah, OSM is chaotic and inconsistent, but here we have inconsistency for no good reason (except for *we’ve always done it this way”).
Ok I will continue here for cohesiveness, until someone moves these. =estate doesn’t fit into place= . As mentioned in my linked reply, a housing estate can be any size, from below =plot , to a =subrub and even close to a =town . Now you don’t know how to address it among other levels, navigate to it, or cartographically present it for viewing, search, and rendering.
A housing estate usually has well-defined extents, while most other place= don’t as abstract concepts of communities. On a minor note, industrial parks were called industrial “estates”, or trading “estates”, in UK, so this isn’t intuitively restricted to residential.
You could point to =island and =islet etc, but fundamentally looking they aren’t the best choice, besides not referring to communities. These two in particular seem to facilitate “double-tagging” 2 different meaning feature tags on natural=coastline , strictly speaking a violation of One Feature One Object, worsened by the linear vs area feature difference.
Of course, =plot has the same problem, as it too can vary size. boundary=lot isn’t more popular yet, but the vast majority of =plot are imported as seen from the jumps in number. place=farm you mentioned is another oddity that should really be moved, which again can be in different scales. However for =isolated_dwelling , it has a different meaning specifically for lone homes posing as an addressed or navigable settlement of its own, a 1 or 2 house village-equivalent so to speak. It isn’t used for any random building= home. This basically has a fixed size, while housing estates don’t.
To work in an application, I’m sure you do need to have boundary=administrative as well… And most industrial facilities are landuse=industrial lacking a feature tag, which there have been debates and proposals trying to fix that (viz usage of industrial= vs clearly establishing man_made=works ) .
I don’t see it that way, sorry. While I agree that an “estate” (maybe “complex” is more appropriate) is a) named, b) has clearly defined extents, and c) may be residential, industrial or commercial [and d) usually has been built and maintained by a single operator, I would add] I don’t think it can be just any size. Most complexes of this type I’m having in mind are size of a neighbourhood or smaller. Actually, I’d say that “neighbourhood” might fit in many cases, if it wasn’t already used for older, larger, informal surroundings of such complexes.
If you have a place larger than that, go ahead and tag it as quarter or even a town; those are generic tags which can be applied by any mapper’s best judgment. I foresee that this place=estate/complex tag, if we ever introduce it, will end up with slightly different interpretations across the world, since the world is a colo(u)rful place.
The first example that crossed my mind was New York City’s famous block called World Trade Center, so I went ahead to check how it’s tagged… and it is not. While there are several things having “World Trade Center” in the title, the closest thing is this place=localitynode which doesn’t do it justice. And I would argue that the thing called “World Trade Center” occupies a well-defined couple of blocks between West Street, Church Street, Vesey Street and Liberty Street, with a mixed commercial and memorial landuse.
In the early days, I used to use place=subdivision exactly like this. (I didn’t know the British term “housing estate” yet.)
I don’t have a problem with this approach per se, but I do find named landuse areas to be a closer reflection of what these planned suburban developments are intended to be: a homogeneous area of land use, big or small, that is strongly associated with a particular name. These developments constitute an alternative for finding your way around a typical American suburb, parallel to any system of neighborhood names.
Moreover, as weird as it may seem that there are brands of apartment complexes in the U.S., I think it would be even weirder to brand places than landuse areas.
And what about =city_block , and =plot ? How can the larger ones as =quarter be indicated as a housing estate, with something else that’s different from place=estate ? What you suggest means place=estate counterintuitively doesn’t handle all housing estates. That’s misleading and a fragmented solution. Housing estate, gated community, whatever else is a concept orthogonal to the place= hierarchy. Mixing them isn’t a good solution from start.
What I may have said elsewhere, shop=mall and man_made=works are used for malls and factories besides landuse==retail and =industrial , not some place= as awkward as =farm . I don’t see why should place= be expanded to more things covering different aspects.