OpenStreetMap Forum

The Free Wiki World Map

You are not logged in.

Announcement

A fix has been applied to the login system for the forums - if you have trouble logging in please contact support@openstreetmap.org with both your forum username and your OpenStreetMap username so we can make sure your accounts are properly linked.

#1 2017-11-12 01:35:03

zstadler
Member
Registered: 2012-05-05
Posts: 286
Website

One feature, one OSM element

I stumbled upon One feature, one OSM element best practice.

In short, the rule says:

Don't place nodes in identically tagged areas just to see some icon appear on the map. The renderers will display icons on areas as well and there's no need to have every parking-lot, soccer-ground, etc., duplicated in the database.

It seems like this rule has not been followed well in mapping of many cities in Israel. For example, Haifa was mapped as place=city by relation 1387888 and by node 1656107649

Offline

#2 2017-11-12 07:43:52

SafwatHalaby
Member
Registered: 2017-04-10
Posts: 387
Website

Re: One feature, one OSM element

Specifically for places, I've mentioned similar concerns here.

There are worldwide differences in place tagging. I've tried summarizing the major different ways to tag places in this wiki draft (I'd appreciate if you review it) but I got busy and it's currently an incomplete draft.

Although conflicting with the rule above, it is unfortunately common in some places to use a place label/admin_centre node and also a place relation.

However, the practice of tagging an area and a node with the same place is quite rare and yet used in Israel. This causes *many* problems such as double-name rendering in osm.org.

Last edited by SafwatHalaby (2017-11-12 07:51:37)

Offline

#3 2017-11-12 10:05:00

wowik
Member
From: Zelenograd
Registered: 2009-09-29
Posts: 7,164

Re: One feature, one OSM element

place node and place border are different features. But its are closely linked. Manually this lis is made by dupplicating 2 tags on it.
In some countries (for example Russia and some other countries of exUSSR) places (hamlet,vilages,cities) has non administrative border but these borders are needed for address porpuses to avoid setting of addr:city on every object.
http://wiki.openstreetmap.org/wiki/RU:A … 1.82.D0.BE

shortly in English
http://wiki.openstreetmap.org/wiki/Addresses#Russia

Last edited by wowik (2017-11-12 10:22:40)

Offline

#4 2017-11-12 10:20:01

zstadler
Member
Registered: 2012-05-05
Posts: 286
Website

Re: One feature, one OSM element

SafwatHalaby wrote:

Although conflicting with the rule above, it is unfortunately common in some places to use a place label/admin_centre node and also a place relation.

The is no problem with having a nodes with label and admin_center roles in a relation. These are standard members of boundary relations.

On the other hand, like any relation member, the relation's tags should not be duplicated in it, and such nodes should therefore have no tags.

Offline

#5 2017-11-12 10:34:10

zstadler
Member
Registered: 2012-05-05
Posts: 286
Website

Re: One feature, one OSM element

Hi wowik,

https://wiki.openstreetmap.org/wiki/Places says:

A place can also be defined using an area.

When the border of a place (hamlet, vilage, city) is mapped as an area, using either a closed way or a multypolygon, the "place" tag should be put on this area without duplicating it in a node.

Last edited by zstadler (2017-11-12 12:28:53)

Offline

#6 2017-11-12 12:40:38

wowik
Member
From: Zelenograd
Registered: 2009-09-29
Posts: 7,164

Re: One feature, one OSM element

How you can "link" place border and place node?
At present time its are linked together by equal name and place tag values.
For multipolygon border only inner and outer members allowed by wiki. Some people add label role and include node to multypolygon.
For example in Belarus almost all hamket/village/city mapped that way. But it is not described in wiki and JOSM validator generate a message.

Offline

#7 2017-11-12 16:49:13

zstadler
Member
Registered: 2012-05-05
Posts: 286
Website

Re: One feature, one OSM element

What is the purpose of having a place node when the place has a border/area?
I'm sure no one likes seeing duplicate labels...
This is exactly what the "One feature, one OSM element" best practice is trying to avoid.

From a mapping perspective, the geographic location of the place is defined precisely by the border/area.

Offline

#8 2017-11-12 16:54:38

SafwatHalaby
Member
Registered: 2017-04-10
Posts: 387
Website

Re: One feature, one OSM element

zstadler wrote:
SafwatHalaby wrote:

Although conflicting with the rule above, it is unfortunately common in some places to use a place label/admin_centre node and also a place relation.

The is no problem with having a nodes with label and admin_center roles in a relation..

What is the purpose of having a place node when the place has a border/area?

I think there's a slight misunderstanding. I believe Wowik and I are both talking about:

  • node with a place tag

  • relation with a place tag

  • The node is a label or admin_centre of the relation

  • If it's an adminstrative boundary relation, then the relation also has the boundary member ways.

  • If there is no adminstrative boundary, then the relation is multi-polygon with a single untagged outer way.

This scheme conflicts with "one element, one tag" and yet is a common solution to the place mess worldwide. It does not render twice nor does it show in Nominatim twice. Double-rendering and double results only occurs because we have a place node + landuse=residential area with the same name.

See this for the multipolygon style, when there is no admin boundary.

https://www.openstreetmap.org/relation/6722597

See this for the admin boundary style:

https://www.openstreetmap.org/relation/1403095

Note that a "place" tag is not present for the relation in this case, and that's because I tagged this and I prefer not having double-places and this works for the admin boundary variation, but I don't think it works for multipolygon variation. But some people do add the "place" tag for either variation (e.g. your Haifa example).

What is the purpose of having a place node when the place has a border/area?

Deciding where the label will show, simplifying some data consumers. I think Carto does not even render place areas, making this essential.

Edit: I fixed some details.

Last edited by SafwatHalaby (2017-11-12 17:16:35)

Offline

#9 2017-11-12 17:19:55

SafwatHalaby
Member
Registered: 2017-04-10
Posts: 387
Website

Re: One feature, one OSM element

And by the way, Haifa does not render twice. We have far worse tagging examples, e.g. Bet Oren:

https://www.openstreetmap.org/relation/ … 91/35.0093

Place: https://www.openstreetmap.org/node/278473938
landuse: https://www.openstreetmap.org/way/94521581

It seems no programs treat those as a single place, and they are not linked internally. Thus the double rendering and double Nominatim/Osmand search results.

Last edited by SafwatHalaby (2017-11-12 17:20:16)

Offline

#10 2017-11-12 20:43:49

zstadler
Member
Registered: 2012-05-05
Posts: 286
Website

Re: One feature, one OSM element

Offline

#11 2017-11-12 22:34:39

SafwatHalaby
Member
Registered: 2017-04-10
Posts: 387
Website

Re: One feature, one OSM element

Sorry! my bad.

It's also rendered twice (but the second one is a little hard to spot due to the text density in the area).

Offline

#12 2017-11-13 08:27:56

zstadler
Member
Registered: 2012-05-05
Posts: 286
Website

Re: One feature, one OSM element

These are separate issues where a duplicate name is put (wrongly IMO) on the landuse area creating label duplication.

Offline

#13 2017-11-14 15:42:59

dsh4
Member
Registered: 2017-06-24
Posts: 40

Re: One feature, one OSM element

zstadler wrote:

I stumbled upon One feature, one OSM element best practice.

That principle is even more generally applicable:

https://en.wikipedia.org/wiki/Don%27t_repeat_yourself
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system

This implies, for example, that names shouldn't be duplicated between a relation and a member thereof.

Offline

Board footer

Powered by FluxBB