Summit:cross=yes and separately mapped crosses

[Luzandro]

Following up on this github issue: the tag summit:cross is currently only rudimentarily documented as

Describes whether a summit cross is built on that peak. Add a summit:cross=yes to the peak natural=peak, if there is a summit cross build on that peak.

In many cases the cross itself is additionally mapped as a separate object as man_made=cross - should summit:cross=yes in this cases be considered as incorrect, duplicate entries or as different levels of abstraction, similar to bin=yes where the wiki says

bin=yes: there is a waste basket. Additionally, it may or may not be mapped as a nearby node with amenity=waste_basket.

What about cases, where man_made=cross and natural=peak + summit:cross=yes share the same node? While the position may be the same, the peak and the cross are different objects and can have different names or other attributes. Two nodes at the same position on the other hand can be irritating and difficult to work with.

[crodthauser]

Not answering your question, but I would vote for introducing bin=separate and summit:cross=separate for situations in which the object is mapped separately. For a summit cross it may be reliable to assume that there is only one, but there may very well be two bins, one separate and one attached to the shelter of a bus station. bin=separate is currently used 837 times, compared to bin=yes with 424,276 instances.

[IanH]

My understanding is that a node represents a single point. In practice it is usually an single object. So all the attributes for that object should end up on the node. Anything attach to that object should be described by that object.

If that node contains information about a cross on a peak, that each tag describes that central object. That is unless tag the presence of a subobject.

It is generally assumed that when you add an different item to the same node, that one is atteched to the other. I routinely do this with street lights that are mounted to power poles.

[wolfgang8]

@Luzandro

What about cases, where man_made=cross and natural=peak + summit:cross=yes share the same node? While the position may be the same, the peak and the cross are different objects and can have different names or other attributes. Two nodes at the same position on the other hand can be irritating and difficult to work with.

In cases of tagging conflicts (e.g. name) I would use two or more nodes wich are close to each other.

[Luzandro]

So it’s only a problem if there are two conflicting values, but as long as there is for example only one wikidata entry, it’s negligible if this represents the cross or the peak as it’s seen as one location?

Consequently for cases where the summit cross is located on the highest point, it’s valid and also recommended to set summit:cross=yes as well as man_made=cross together with natural=peak all on the same node

[Mateusz_Konieczny]

@crodthauser

Not answering your question, but I would vote for introducing bin=separate and summit:cross=separate for situations in which the object is mapped separately. For a summit cross it may be reliable to assume that there is only one, but there may very well be two bins, one separate and one attached to the shelter of a bus station. bin=separate is currently used 837 times, compared to bin=yes with 424,276 instances.

this is problematic as it would mean that

• you cannot add bin tag without checking what is mapped around
• you cannot map bin without checking all nearby objects for bin=yes

In practice people will not be doing it anyway.

[wolfgang8]

@Luzandro

Consequently for cases where the summit cross is located on the highest point, it’s valid and also recommended to set summit:cross=yes as well as man_made=cross together with natural=peak all on the same node

From my point of view summit:cross can be an attribute of both - natural=peak and man_mad=cross. So it’s possible to tag a summit cross nearby the highest point with man_mad=cross + summit:cross=yes and the summit with natural=peak and additional with summit:cross=separate.

As natural=peak + man_mad=cross implies summit:cross=yes, it would not be necessary to put all three together, but it’s quite valuable for clarification.

[crodthauser]

@Mateusz_Konieczny

this is problematic as it would mean that

• you cannot add bin tag without checking what is mapped around
• you cannot map bin without checking all nearby objects for bin=yes

Checking that what you map has not been mapped already should be the norm. If you refer to automatization in terms of StreetComplete: I don’t think that we should limit ourselves – i.e., capturing duplicates – just to simplify the gathering process for bins. As soon as a bin=yes is asked for, show all icons of mapped bins in the vicinity of X meters and maybe also indicate that “Warning, there is a bin already mapped X meters away. Are you sure there is second one?”. So it’s the task of the editing software to assist the mapper in not creating duplicates.

[Mateusz_Konieczny]

@crodthauser

Checking that what you map has not been mapped already should be the norm.

it is reasonable to expect to check whether POI was mapped

it is not reasonable to check property on all nearby object, for minor objects like bins

[Helium314]

In practice, even when adding sidewalks people often don’t check nearby objects, roads in this case (iD’s refusal to acknowledge sidewalks tagged on roads also isn’t helping here).
So while it “should be the norm”, it simply isn’t.

In the case of bin=yes, the wiki is very clear that adding this tag to some object does not create a duplicate if the bin is mapped separately.

[crodthauser]

@Mateusz_Konieczny

it is not reasonable to check property on all nearby object, for minor objects like bins

That is quite subjective, don’t you think?

Also: Should it not be easy for the editing software, as I’ve suggested above? Accepting inferior data quality, if a (seemingly) simple fix exists, seems strange to me.

[crodthauser]

@Helium314

In practice, even when adding sidewalks people often don’t check nearby objects, roads in this case (iD’s refusal to acknowledge sidewalks tagged on roads also isn’t helping here).
So while it “should be the norm”, it simply isn’t.

I agree. But I feel like, we’re falling in the trap of the KISS principle due to a lack of editing software support. Handling of relations could also be much easier for new mappers if the editing software made them more accessible. As a result, we accept a loss in data quality and try to stay away from relations as much as we can.

With respect to the bin/cross situation from above: Perhaps I’m mistaken, but it seems that it should be simple for a software to check whether a feature already exists in the vicinity. That check doesn’t have to be perfect but in the sense of “Did you see this? Are you creating a duplicate?”.

@Helium314

In the case of bin=yes, the wiki is very clear that adding this tag to some object does not create a duplicate if the bin is mapped separately.

That could be changed to say anything. So we should instead discuss what we think is best. As the information is captured twice (if the bin is mapped additionally as a separate node), by definition, it is a duplicate: We cannot determine anymore if there is one or if there are two bins (let’s stick to the situation of one/two bins).

We could modify the mapping process: bin=yes only requires there to be any bin in the vicinity. What the vicinity is, is subjective. But that is fine. If you want more granularity, map all the bins separately. Making clear that bin=yes is only a simple approach (which does not tell you anything about the number of bins) that needs to be expanded via separate nodes for all bins (or sth. like amenity=waste_basket, count=3) to obtain a count, should then be mentioned explicitly. Currently, however, the Wiki is not asking you to add a separate node. It reads as if it doesn’t matter at all.

[Mateusz_Konieczny]

hmm, it may be useful to extract this to separate thread

@crodthauser

Currently, however, the Wiki is not asking you to add a separate node. It reads as if it doesn’t matter at all.

Edited Key:bin - OpenStreetMap Wiki

@crodthauser

That is quite subjective, don’t you think?

Preferring significantly more complicated tagging scheme and mass-invalidating what is tagged correctly, to achieve better results with something extremely specific is also quite subjective.

@crodthauser

Also: Should it not be easy for the editing software, as I’ve suggested above? Accepting inferior data quality, if a (seemingly) simple fix exists, seems strange to me.

Deprecating/redefining widely used tagging scheme is not a simple fix.

And this data is noticeably inferior - into taking into account that you would need years or rather decades (if ever) before you can rely on yes and separate having meaning you want.

@crodthauser

but it seems that it should be simple for a software to check whether a feature already exists in the vicinity.

and for cases where it is true that is why value separate has limited utility, despite making editing much more complicated

@crodthauser

That could be changed to say anything.

well, but if wiki would claim that bin=yes means standalone bin then

• it would be false claim
• would not prevent double counting (you could have single bin not mapped as own object and for example three nearby highway=bus_stop on bus terminal)

@crodthauser

As the information is captured twice (if the bin is mapped additionally as a separate node), by definition, it is a duplicate

not really, by that logic lit=yes on roads duplicated highway=street_lamp

[Luzandro]

I’ve now updated the wiki to reflect what seems to be the current usage. IMHO it’s still a bit of a mess, but at least it’s documented

[SomeoneElse (Andy Townsend)]

@crodthauser

but it seems that it should be simple for a software to check whether a feature already exists in the vicinity

Perhaps you could have a go at doing that with (some software) that “ought to be able to check that a feature exists nearby”?

If you’d like a concrete example to work on, the pub here isn’t visible due to the bicycle parking outside. I’d probably fix that using layers, but a demonstration of a proximity-based check would be great.The changelog linked at the top of the screen has links to all the project files.

[crodthauser]

@Mateusz_Konieczny

@crodthauser

Currently, however, the Wiki is not asking you to add a separate node. It reads as if it doesn’t matter at all.

Edited Key:bin - OpenStreetMap Wiki

Thanks. That is a good addition.

Before I go on, let me mention that we’re now mixing up the discussion about using bin=separate and bin=yes as per your Wiki edit.

@Mateusz_Konieczny

@crodthauser

That is quite subjective, don’t you think?

Preferring significantly more complicated tagging scheme and mass-invalidating what is tagged correctly, to achieve better results with something extremely specific is also quite subjective.

See below. My gripe with your answer was that you phrased it as a fact. But I’m sure I have fallen victim to such phrasing as well, so we don’t have to engage in that discussion.

@Mateusz_Konieczny

@crodthauser

Also: Should it not be easy for the editing software, as I’ve suggested above? Accepting inferior data quality, if a (seemingly) simple fix exists, seems strange to me.

Deprecating/redefining widely used tagging scheme is not a simple fix.

In my experience, bin=yes is used as I have described it in my last comment (“Is there a bin nearby”). So from the data, I would not be able to reliably determine, whether there is a bin that is part of a bus stop, or if there happens to be a bin 10 meters away. Perhaps that level of detail is achieved elsewhere, but that would actually surprise me. Switching to bin=separate wouldn’t improve the situation, but it would also not remove information. But going forward, it allows to improve the data. However: Your change in the Wiki effectively achieves the same. It’s just not using the word separate.

@Mateusz_Konieczny

And this data is noticeably inferior - into taking into account that you would need years or rather decades (if ever) before you can rely on yes and separate having meaning you want.

If StreetComplete asked whether the bin — that is mapped 20 meters next to a bus stop with bin=yes — is a duplicate or, preferably, asked how many bins there are, I doubt it would take decades to get better data.

@Mateusz_Konieczny

@crodthauser

but it seems that it should be simple for a software to check whether a feature already exists in the vicinity.

and for cases where it is true that is why value separate has limited utility, despite making editing much more complicated

Yes, of course. There are only two cases. Either it’s a duplicate or it isn’t. If we are only considering one case, then we don’t need to make any distinction in the data.

@Mateusz_Konieczny

@crodthauser

That could be changed to say anything.

well, but if wiki would claim that bin=yes means standalone bin then

• it would be false claim
• would not prevent double counting (you could have single bin not mapped as own object and for example three nearby highway=bus_stop on bus terminal)

Unfortunately, I don’t understand what you mean. As for proximity and double counting: Couldn’t that be solved similarly to what I suggested above; i.e., “Is there already an object with bin=yes in the vicinity?”. Perhaps I misunderstood you.

@Mateusz_Konieczny

@crodthauser

As the information is captured twice (if the bin is mapped additionally as a separate node), by definition, it is a duplicate

not really, by that logic lit=yes on roads duplicated highway=street_lamp

If bin=yes means that there is a bin and that bin is also mapped separately, then, yes it is, by definition, a duplicate information. I’m not opposed to that per se: With your edit of the Wiki, it is clear that by using bin=yes, information is missing, which can be mapped additionally. In that sense, bin=yes can serve as a simplification for a mapper and for an algorithm (if bin=yes is set, the algorithm doesn’t have to look around if there is a bin mapped close by).

lit=yes on roads is an attribute of a path as opposed to a street lamp, which is only a node. Judging by a street lamp node how effective it illuminates a road, is a lot of guesswork. So lit=yes on the entire way actually gives additional information. If it didn’t, then yes, it would be a duplicate.

[crodthauser]

@SomeoneElse

@crodthauser

but it seems that it should be simple for a software to check whether a feature already exists in the vicinity

Perhaps you could have a go at doing that with (some software) that “ought to be able to check that a feature exists nearby”?

Unfortunately, I have no experience with programming such software. I do have minor programming experience, so if I ever do find enough time to familiarize myself with such a software project, I would be happy to contribute.

My idea was not much different to what an Overpass query does: Check the bounding box of a certain diameter for the attribute you’re looking for. The rest would be GUI work.

@SomeoneElse

If you’d like a concrete example to work on, the pub here isn’t visible due to the bicycle parking outside. I’d probably fix that using layers, but a demonstration of a proximity-based check would be great.The changelog linked at the top of the screen has links to all the project files.

Great example. In this case, a does-it-exist-nearby query would help. However, I was referring to an (interactive) editing software, not the display on a noninteractive map.

[Mateusz_Konieczny]

@crodthauser

If StreetComplete asked whether the bin — that is mapped 20 meters next to a bus stop with bin=yes — is a duplicate or, preferably, asked how many bins there are, I doubt it would take decades to get better data.

1. yes it would take decades. StreetComplete is not used so widely. surface=cobblestone is being deprecated as not clear (not only in SC) and it will take decades to get rid of it (at current rate, about 18 years with crude linear approximation, but such retagging requiring survey initially goes faster then slows down, see surface=cobblestone | Tags | OpenStreetMap Taginfo and waterway=wadi | Tags | OpenStreetMap Taginfo for slow down example)

2. it would require silly extra tags for answer like “yes there is a bin not mapped as a separate object”

3. this quest would not collect useful data, or at most marginally useful not worth implementation and mapping effort

@crodthauser

Unfortunately, I don’t understand what you mean. As for proximity and double counting: Couldn’t that be solved similarly to what I suggested above; i.e., “Is there already an object with bin=yes in the vicinity?”. Perhaps I misunderstood you.

you can have three highway=bus_stop with bin=yes and no mapped separate bin. You would triiple count it.