Talk:One feature, one OSM element

removing Essay lable

Although written by one user, User:Chriscf, I can't really see anything which represents a "minority viewpoint" on this page. So I'm going to remove Template:Essay label from here. If there's anything people disagree with on the page, I'd be interested to know why. It all looks good and sensible to me. Discuss here, and let's tweak the page if necessary, rather than labelling this as an essay.

-- Harry Wood

the statement on the template did not say it represented a minority viewpoint, but that it might represent either a mainstream or a minority viewpoint. I've killed the template and associated category by tagging for deletion because it's obvious that if you are focusing on 'minority viewpoint' when it clearly isn't only for that, then someone else will. enough said - it's being killed. --Ceyockey 00:04, 23 December 2010 (UTC)

This is interesting from a wiki-psychological point of view. Here's what I'm thinking.

My eye was drawn to the "minority viewpoint", which perhaps was a misinterpretation, but I'm also uncomfortable with the some of the psychology of essay label. We want people to be bold, and make corrections. If content appears to contradict the community consensus, then that's a problem which should be tackled. Labelling a whole page as an individual's essay could be a useful first step in finding fixing these issues. I'm sure that's how you intended it. But I think actually it could have the opposite effect. People could see the page and be discouraged from modifying it because they may feel it is "owned" by somebody. Also people could get the idea that they want to write some of their own individual essays (which is bad).

Over the years various people have tried to start writing their own individual "introduction to the project". This presents terrible problems in terms of wiki mess, since they're essentially duplicating a concept which is already bagged by Beginners' guide. This has been an ongoing cleanup issue discussed at Talk:Beginners' guide#wiki organisation. But in a more recent case I fixed it by moving someone's introduction into their 'User scratch space' ( User:Johnwhelan/How it works ) Perhaps that could be a good approach for dealing with whole pages which have the feel of individual essays. And perhaps we could have a template to label such pages too.

However I wouldn't want to do that with a page like this page. Even though it is written by one person, it belongs in the main namespace. Why? Because it is not a duplication of other concepts. It can be meshed with other related concepts (needs to be). And finally I believe it is a good faith attempt (and a reasonably successful attempt) by an individual to document things which the community agree upon, or at least things which have settled to community norms and consensus. Now the page is open for input from others to help ensure that it reflects the consensus.

-- Harry Wood 11:19, 5 January 2011 (UTC)

I'll rescue the deleted content. Here's what the template used to look like:

As I say, this, or something similar to it, could be useful in some situations, but I didn't think it was appropriate for this page.

-- Harry Wood 17:30, 9 January 2011 (UTC)

"Once and only once" renamed to "One feature, one OSM element"

We have had a page called good practice for a long time, which summarises this and other similar points.

On that page the corresponding principle is named "One feature, one OSM element" (Actually it was called "One feature, one OSM object", but I've just changed that. "Object" vs "Element" is another discussion) So my suggestion is to rename this page to align with that, and then link from there and back. After all this page is currently an orphan.

It's a better name I think. Currently this page says "'Once and only once' is a principle whose meaning is self-explanatory", but I don't think it actually is very self explanatory. The next sentence goes on to say "A feature should appear on the ground once and only once", which I find confusing / incorrect. As I understood it, our conventional use of the word "feature" in OSM, is to mean a real-world feature ...which we want to map as an element with tags. I'm not disagreeing with any of the principle, just the wording of the introductory sentences.

-- Harry Wood 12:32, 22 December 2010 (UTC)

OK I've done the move, and I'm going reword the top sentences a little -- Harry Wood 17:11, 9 January 2011 (UTC)

Editor support?

Often there is only a node and I want to correct it to a building outline.

There is no tool support for that in Potlatch 1 or 2 as far as I know.

It is only possible to copy tags from a node to a node, not to a way (area).

Is there one for JOSM?

--Lulu-Ann 01:14, 12 January 2011 (UTC)

Well JOSM has a special version of the "paste" command which only pastes tags. So you do "copy" on the node, then select a newly drawn area and do "Paste tags". In fact I've recently decided this is quite handy, and so memorized the keyboard shortcut (Ctrl + Shift + V) - Harry Wood 01:57, 12 January 2011 (UTC)

At least to date you can copy tags from a node to a way with Potlatch2. See Potlatch_2/Shortcuts at letter R. --Aseerel4c26 (talk) 01:12, 18 April 2013 (UTC)

self explanatory

I would say that "self explanatory" is quickly said ;-) ! What is the exact meaning of the "," (coma) in One feature, one OSM element ? Does that mean "for one feature (in the real world) you should only use one node/way/relation" ? (implication) or does that also mean that any one object in OSM should feature one only real thing ? (equivalence) sletuffe 01:21, 22 November 2012 (UTC)

Well it goes on to say "once and only once" i.e. equivalence. In fact the author of this page originally called it "once and only once".

From the way you're asking this question, I imagine you're taking it very literally and treating it as a very concrete rule. It's not. It's good practice principle. There's probably exceptions even in our commonly used mapping approaches.

Anyway. I agree that it's not "self explanatory" actually. Think I will remove that

-- Harry Wood 02:49, 22 November 2012 (UTC)

No problem, I got it that it is a "good practice" with obviously exceptions as well. But I wasn't aware of the "once and only once" meaning. I knew about "if and only if" (=equivalence), but not with once. Thanks for explanations. sletuffe 11:35, 22 November 2012 (UTC)

One feature one osm element is bollocks

The rule is IMHO just pointless in this form. There is no such thing as "one feature" in the real world, it really just depends on your point of view. A tag is defined (in the best of the cases) to describe something / some aspect etc., and as you can use any tag you like in osm I think it is clear that there might be also several osm elements to describe (different aspects) of the "same thing". Take the first example: "A feature consisting of buildings on grounds (e.g. a school), should be mapped as an area object delineating the land with area objects marking the buildings. Tags should be on the area, and not the buildings, unless the buildings are different (e.g. buildings on the school grounds can be assumed to be part of the school)." While I understand what are the intentions behind this text, it still doesn't convince me. A school is not "consisting of buildings", at least no more than for example it consists of power lines. The education might take place inside the buildings, they house it, like the power lines bring electricity, but the school itself is an abstract entity, not the sum of its buildings and open air areas. For osm it is ok to spatially locate the function "school" to some real world place (i.e. the area described in the example), but it is important to realize that this is still only the area the school takes place in, not the school itself. -- Dieterdreist (talk) 17:10, 3 June 2014 (UTC)

"it is important to realize that this is still only the area the school takes place in, not the school itself"... well now you're getting very abstract. Usually a school is a thing. You can go to a place and look at a school. At least I think this text is starting from that assumption.

I guess there are times when a school takes on a more abstract transient form, e.g. an evening class "bob's school language" might take place in a building which is a community centre the rest of the time. In those cases I guess it's debatable whether we should be mapping it as a school at all. In any case that's not what this guideline supposed to be about. We're not discussing school definition edge-cases on this page. We're talking about a school... y'know... one of these things... and we're talking about the case where it's made up of several buildings. And specifically with this guideline we're telling mappers not to place ten schools in a cluster on the map when they're adding the building details.

-- Harry Wood (talk) 00:03, 4 June 2014 (UTC)

Adding points to objets

Some GPS navigation tools, that use OSM as data source can only use point objects as POIs when searching. So I was thinking of marking the entrances of specific locations with additional point objects for navigational purposes. I'm curious about your opinion. --Nice Micro (talk) 03:45, 25 August 2015 (UTC)

It doesn't sound like a good idea, and would be in violation of "One feature, one OSM element" yes. You'll be making things work better for your GPS navigation tool, but breaking it for other people, who will now see the thing doubled-up in the data. Unfortunately the only correct solution is to ask the developers of such tools to fix them. It's a very false assumption that POIs must be done as nodes (well.... It may depend a bit on which type of POI. Something small like an ATM will most appear as a node not an area. But any POI types which occupy a building will very often be done as an area in heavily mapped parts of the world)

Obviously adding the entrance of building as a node is a good idea (Use entrance=main), for helping other kinds of apps, but the POI tag information should not be repeated on that node. That would break things for everyone else

-- Harry Wood (talk) 15:52, 25 August 2015 (UTC)

Even MapCSS, the standard Map point style is not ready to show things as they should. Everybody maps things twice, since not even in JOSM it is rendered correctly. Please may someone change this. There is also a discussion on josm.openstreetmap.de Best, --Maailma (talk) 16:49, 14 January 2017 (UTC)

JOSM is a bit different: It's not supposed to produce a nice-looking map, but makes it very clear how the underlying data looks. For example, you want to be able to distinguish whether the shop tag is on an area or node. If both produced an icon, then these cases would not be visually distinguishable from each other. People might try to select the icon, thinking it's a node.

So even though rendering icons for areas is good for normal maps, it might not be the best choice for an editor. Obviously it's up for the JOSM devs to decide this. --Tordanik 20:03, 14 January 2017 (UTC)

While I understand and agree to your point that JOSM should allow for easy differentiation, it should be possible to switch between the two options of display, so that one can make sure everything IS actually tagged. On the otherside, for display on normal maps, the icon needs to be displayed whenever there is a tag, independently if it is a node, path or area being tagged. -Maailma (talk) 04:43, 15 January 2017 (UTC)

Tag data section does not make much sense

I was trying to translate this page to Czech but the Tag data section does not make much sense to me. Could someone please elaborate on this and possibly add some examples to make it more clear? Thank you. -- Chrabros (talk) 11:38, 25 November 2015 (UTC)

You are right. It appears to have been written by a non-native speaker. I believe it would be best to remove this section, unless we can find out what it means.--Jeisenbe (talk) 04:20, 5 July 2019 (UTC)

Preserving history when Expanding a single node into an outline

Expanding a single node into an outline

When you find a single node for an object, and want to draw the outline of the building or the campus, it is good practice to keep the node (without its tags) prominently in the outline (e.g. as a corner of the building or the campus entrance).

This preserves the history of the information in the "old" node, which is easy to find when somebody inspect such an object.

Example (school node to campus outline):

* move the school node to a corner of the aerial image.
* draw the campus with this node as one of the corners
* copy the tags from the node and delete all its tags
* paste the tags on the campus outline, remove old object source tags
* when uploading, add your source to the changeset (not to the campus object)

I was adding the above recommendation from my current mapping praxis to preserve the history of information previously tagged on the node. User Tordanik removed it because it is not his mapping praxis. Please discuss.--Polarbear w (talk) 11:57, 13 March 2017 (UTC)

Well, I think that the major reason for Tordanik was that this article does not have anything common with One feauture=One element. I quite like it, though I don't do it this way. But I believe it belongs to Good practice. So why don't you move it there? Chrabros (talk) 12:28, 13 March 2017 (UTC)

It's already there Good_practice#Keep_the_history, though not as detailed as described here. So maybe we put the details in the good-practice page and keep a brief line here with a link?--Polarbear w (talk) 12:39, 13 March 2017 (UTC)

But why to link interesting but unrelated topic to here? Chrabros (talk) 13:45, 13 March 2017 (UTC)

A user referred to this page when deleting a node in order to create the outline. However this page was describing situations when both node and outline were already in the database, not when the outline is to be created. --Polarbear w (talk) 17:40, 13 March 2017 (UTC)

Just to confirm this: Yes, I removed it because it's off topic on this page. I also doubt that this is something that more than a small minority of mappers practice or care about, but that's not the main reason for my edit. I agree with Chrabros that if this is documented in the wiki, Good practice would be a good place. --Tordanik 12:38, 14 March 2017 (UTC)

Notable exceptions section

I'd like to remove the "Notable exceptions" section.

The section about Streets was originally added in 2015, but this section isn't a good example: an individual block of a street is a single feature. While a street name may continue for many kilometers, the characteristics of the highway may change many times. Sometimes a single name may be used for a motorway, expressway, major street and minor rural road. These are different features with different main feature tags. In American towns with incomplete street grids, a single street name may be used for a dozen different disconnected segments. So there isn't a verifiable way to confirm that a certain segment of highway is the same as another segment kilometers away, even if it's common to think of a section of highway with one name as a single concept.

Similarly, while long rivers were often given a single name by explorers, the local names for the different parts of a long river like the Amazon will change between regions, and there is often debate about where the "main stream" of the river continues at branch points where the water flow is similar. For these reasons, a verifiable waterway feature should be an individual segment with shared characteristics (fairly constant width, water flow and local name). While many mappers like to create waterway relations, it's impossible to get agreement about the complete route and correct local names of a long river like the Rhine in Europe.

Next, a section about Places was added later. This suggests not removing place nodes, which is excellent advice. However, it's not generally agreed if settlements should every be mapped as areas. See place=* for lots of controversial discussion.

So both of these sections will cause more confusion for new mappers than any benefits they might bring. Since this is a "Good practice" page, it should represent only clear examples of community concensus and ideal practices. There's plenty of room for ambiguity elsewhere in the wiki to represent real-world practices (which often result in multiple database elements for the same feature, and multiple feature tags on one element, unfortunately) and controversies. --Jeisenbe (talk) 04:48, 5 July 2019 (UTC)

One feature per OSM element

I believe that "One feature, one OSM element" also suggests that each OSM element (or database object) should, ideally, represent one main feature.

This means that a single closed way, multipolygon or node should not be tagged with amenity=, shop= and office=, since this would represent 3 different main features on the same object

Commonly, a single area will be tagged with building=yes and a feature such as shop=*, but this leads to ambiguity for tags like name=*, start_date=* and operator=* - do these tags represent the name of the building, the date the building was constructed and the owner of the building, or the name, opening date, and owner of the shop?

A more serious problem occurs when a single closed way is tagged with barrier=hedge or barrier=wall and an area feature tag like landuse=industrial or amenity=school. In this case the mapper probably intends to map a linear hedge or wall which surrounds the area, and the landuse or amenity is meant to fill the area. But database users have no way of confirming this directly. Since closed ways can represent lines or areas, a decision must be made by algorithm whether to import this particular closed way as an area or linear feature: this can lead to rendering or anylizing the whole area as a hedge or wall area, because both hedges and walls can represent lines or areas.

This also happens with highway=pedestrian mapped as a closed way (e.g. a roundabout or circular highway around a small park), double-tagged with landuse=grass or leisure=park: should this be rendered as a linear highway or a pedestrian area similar to a square? While the answer it appears obvious to a human mappers, it's quite difficult for an algorithim to handle properly.

For these reasons, new mappers should be encouraged to use a single, top-level feature tag on a OSM element (database object).--Jeisenbe (talk) 15:39, 5 July 2019 (UTC)

I’m unsure about this rule in general, because what a feature is depends on the people interpreting the situation. A leisure=hotel and amenity=restaurant can be seen as a single feature, but it doesn’t mean this is always the only way of interpretation, it could also be seen as a hotel with a restaurant (or even several restaurants) inside. Or a restaurant and additionally some rooms. Splitting them into a restaurant and a hotel may make sense or sometimes it might be more appropriate to choose a different solution.

With some tags that can stand alone and make sense, it is common to have them together with other such tags on an object, for example the keys building and historic and some other tags. For buildings it is common practice to use a shortcut and mix tags with things in the building. I was for being more explicit always, but I have often seen the following mappers having problems understanding the situation and adding duplicate tags.—Dieterdreist (talk) 16:07, 5 July 2019 (UTC)

School example

We read

A feature consisting of buildings on grounds (e.g. a school), should be mapped as an area object delineating the land with area objects marking the buildings. Tags should be on the whole area, and not the buildings, unless the buildings are different. Buildings within the school grounds can be assumed to be part of the school by database users.

OK, so we make a larger area, tagged with amenity=school, and then smaller areas within it, tagged as building=school . This solution I just "reverse engineered" from the iD editor. Please mention it. Else one has no idea how to tag the buildings, reading the above sentence. Jidanni (talk) 23:33, 26 March 2020 (UTC)

A rack of 20 mailboxes, for example

Mention e.g., how to say there is a rack of 20 Tag:amenity=letter_boxs here, instead of just one. Jidanni (talk) 13:42, 19 August 2021 (UTC)

capacity=20 —Dieterdreist (talk) 17:24, 22 August 2021 (UTC)

There may be possibility of confusing with the physical or legal capacity inside each box for large parcels. 1 amenity=letter_box + capacity=6 (6434647532 6434647532), and 1 letter_box:count=* (6478189437 6478189437) instance. ---- Kovposch (talk) 00:15, 23 August 2021 (UTC)

Why would you ask here, instead of Talk:Tag:amenity=letter box? ---- Kovposch (talk) 00:17, 23 August 2021 (UTC)