Some places have both a node and a way

wambacher · 2024-06-07T14:23:18.492Z

Vinzenz_Mai:

The postal code area of 97956 does correspond to the municipality Relation: ‪Werbach‬ (‪401805‬) | OpenStreetMap, but that is not always the case.

see: OSM Postcode Map

dieterdreist · 2024-06-07T16:04:26.000Z

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

Duja · 2024-06-07T17:13:42.810Z

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.

ezekielf · 2024-06-07T17:52:26.472Z

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.

dieterdreist · 2024-06-07T20:47:06.000Z

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)

Duja · 2024-06-10T10:56:06.340Z

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?

Kovoschiz · 2024-06-10T19:42:59.306Z

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.

Minh_Nguyen · 2024-06-10T20:48:35.272Z

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.

osmuser63783 · 2024-06-12T17:43:02.260Z

Zeke Farwell:

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.

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.

Minh_Nguyen · 2024-06-12T17:59:34.898Z

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.

Kovoschiz · 2024-06-13T07:53:51.247Z

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

(re)define the residential tag list
Tagging solution for gated housing estates

osmuser63783 · 2024-06-13T17:49:24.821Z

Minh_Nguyen:

However, I don’t think the combination of place points and place boundaries completely obviates the need for named landuse areas

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.

Duja · 2024-06-14T09:54:43.673Z

Minh_Nguyen:

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.

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”).

Kovoschiz · 2024-06-14T11:07:33.812Z

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 ) .

Duja · 2024-06-14T11:36:30.964Z

Kovoschiz:

=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.

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=locality node 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.

Minh_Nguyen · 2024-06-14T14:22:07.575Z

Duja:

I’m not even against double tagging, but I’d really prefer to have:
name=Arbor Oaks; landuse=residential
accompanied with
place=estate

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.

Kovoschiz · 2024-06-14T15:17:48.739Z

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.

Kovoschiz · 2024-06-14T15:20:46.311Z

Branded apartment is a mainstay in Korea. It even indicates social status, and is played out by chaebol controlling much part of everyday life.

Duja · 2024-06-14T15:42:43.037Z

Kovoschiz:

How can the larger ones as =quarter be indicated as a housing estate, with something else that’s different from place=estate ?

But it was you who claimed that estates as large as a quarter or even a town exist in the first place, without giving an example that I’ve seen. In my view, an “estate” is smaller than or equal to a “neighbourhood”, depending on situation.

Kovoschiz:

Housing estate, gated community, whatever else is a concept orthogonal to the place= hierarchy. Mixing them isn’t a good solution from start.

No, I don’t think that place= is a strict hierarchy in the first place, so you can’t be “orthogonal” to it. I see it as a dictionary of common types of (un)populated places, roughly scaled by size and characteristics, and where we are forced to find best fits. And currently I don’t see a slot there for named, planned-construction small residential blocks, gated or not.city_block is the nearest, but not quite adequate fit.

Kovoschiz · 2024-06-14T19:28:35.020Z

I’m asking if you suggest housing estates of larger sizes can use =quarter etc, isn’t it that they can’t be indicated as housing estates first, which is using place=estate . So we shouldn’t try to use place= for something that can exist in different corresponding place= scale. They have highly varying quantitative and qualitative aspects that aren’t “roughly scaled by size and characteristics” .
Orthogonality is not the same as whether is a hierarchy. It’s means whether something can be considered as both things somehow. You said =neighbourhood “might fit” in theory. Doesn’t that mean they are comparable enough? But the complex is a housing estate, the surrounding isn’t.
Your idea about =complex applying to WTC shows neither what use it is, nor what scale and importance it is. A office park or business park can be very large, an industrial park larger yet. One such “complex” feature that already exists is shop=mall . It doesn’t use place= .