[Tagging] MAST RELATION

[Christian Müller]

> Gesendet: Freitag, 7. März 2025 um 21:03
> Von: Kevin <ga_kevin_tagging at fastmail.com>
> An: Tagging <tagging at openstreetmap.org>
> CC: "Christian Müller" <cmue81 at gmx.de>
> Betreff: Re: [Tagging] MAST RELATION
>
> I'm maybe not quite following you here but this is aiming to address where you want to tag the elements on a pole, or mast, not just the pole/mast itself. These can be of many different types: traffic signals, surveillance cameras, signs, advertisements, pedestrian crossing buttons, electric / communication wires, etc. not just simple guideposts. Each could be valuable to add to the database (and indeed, already have tags) but cannot be accurately captured with the current scheme.

Yes, I actually have anticipated the points made,
no need to iterate:  the argument was logically
split into the homogenous and heterogeneous attach-
ments to a pole or mast.

The guidepost tagging illustrates this.  There are
simple guideposts and more complex ones.  Only for
the complex ones, where attachments are non-uniform
(type-wise) it actually makes sense to employ
relations to 'map' reality.

Please compare e. g. the image material
in category

https://commons.wikimedia.org/wiki/Category:Cycle_node_network_signs_in_Lower_Saxony

These mostly adhere to a common pattern
and it does not make sense to describe
the common properties of all of these
more than once.  All you need for these
is a good, discriminating tag that says
(defines) a node to represent an object
belonging to this group  and  then it
suffices to tag only the information
that _differs_ between them.

The discriminating tag will let humans
and machines know what group of objects
the node belongs to, it will set it a-
part from other nodes mapping different
objects/aspects of what's on ground.

In Germany there are multiple networks
of guideposts, so for example a proper
discrimination to group a network does
_not_ end at tagging

information=guidepost

If the guidpost to be mapped belongs to
a specific (and systematic) network the
wiki suggests to add e. g. network=* or
similar tags to further specify the type
of guidepost.

All generic information of how the posting
signs are shaped, their size, the color
they have, etc. are usually _not_ part of
the database (unless maybe they deviate
from the standard set up by the organisation
that operates the guideposts network).


The last five paragraphs describe the homo-
geneous variant of poles, i.e. where the
attachments do not differ in size, shape
or color, but merely by the content
printed on them.  For these type of objects,
by all means, the creation of relations is
_rarely_ necessary, as the key-value tagging
on the node (or maybe an osm-way, if the
signs are attached to a kiosk or small box
building..) does the job.


Yes, I've understood you, that this homo-
geneous setting is not the use-case you're
primarily aiming at, but it helps to differ-
entiate anything more complex, when the
attachments are neither uniform nor necess-
arily present in the same manner from pole
to pole.

Still focusing on the above, there is lots
of sample data that references these 'simple'
objects, e.g. if you've multiple cycling
routes refering to a single guideposts, that
guidepost _may_ be a member of all the cycling
routes it relates to.  (comparable to a train
station in the public transport tagging; it may
be referenced by the multiple train routes
passing the station).


Although OSM holds to some degree 3d-data, most
editors map from a birds-eye view and overlapping
nodes are (for mappers) mostly a maintenance night-
mare, even if the reasons to employ them are topo-
logically sound.

For example, OSM does not map bricks in the wall,
it maps the wall, using corner nodes and connecting
lines.  This is an abstraction of reality, mostly
the attributes height=* and width=* will abstract
away a lot of wall details, and if the data is re-
played in a 3d viewer, there is loss of information.
This is acceptable and in harmony with the project
scope.

Although some have used OSM data for flight simu-
lator games, the project itself does not have the
goal to house data to give a photorealistic re-
production of the world.  Instead it orients to
support a number of use cases in civil engineering
and private and commercial routing/pathfinding.

That said, your proposal needs to account for
tag-economic aspects of the data to be held in
the osm database.  For example, automated tools
added non-descriptive tags to database objects
in the past, i.e. the software revision used to
edit an object.  Later it was realized that this
information was not only a resource hog but use-
less for most practical applications and thus,
subsequently removed (again, by edit bots..).


Roughly spoken, anything that adheres to a pattern
and would lead to lots of repetition in object tags
is a target of later removal.  Its simply not worth
the effort, most of the time, to tag repeating parts
of a system or subsystem that are inherent to its
design.  The approach osm has dealt with this in
the past was to assume reasonable defaults, as per
aspect of a subsystem, and then omit the tag fully,
as long as an instance on ground does not deviate
from this default.


Again, imho, your proposal will get disapproval
if you stick to overlapping nodes (for this pur-
pose) and take into account to complicate data
user's as well as human contributor's lives.  Is
it possible to do it this way?  Of course, abso-
lutely, but it is not the best approach.  There
is lot of precedence in the data, and in the
wiki illustrating this.


Greetings