Hello,
This is a continuation of the discussion started by Minh Nguyen here.
I almost exclusively use multipolygons and multilinestrings. Here are the tags I use for relationship members:
(mandatory) type=geometry - this way is not intended to receive tags other than type and source:geometry (e.g., no highway=* or waterway=*…)
(mandatory) geometry_class=highway/railway OR landuse (building, man_made, propper_landuse, etc.)
This second tag is very useful in JOSM or ID to display only part of the data, typically when your layer looks like this
or this
It has also proven very useful for having my work reviewed by third parties (non-OHM members) via a umap file.
As for §2, I don’t, with multilinestring or multipolygon relationships, we map the geometry using ways and the feature with a relationship.
For the rest, I more or less agree, when the major editors offer full support for displaying data over a given date range, we can remove the geometry_class and type=geometry tags. They are the least worst solution I could find while waiting for full support in JOSM and ID.
Regarding dates support in ID/JOSM, this could be implemented in two ways:
- have a filter that only displays nodes, ways, relationships within a specific date range. We can already do this, but it results in very complex filters for an average user. We need a simpler way of doing things where the user simply enters the desired date once.
- An alternative (or complementary) solution could be to not use a filter for the data but to display a basemap at a given date. But would it be possible to display vector layers as a basemap in JOSM or ID?
I’m not opposing =multilinestring completely, let alone =multipolygon . A geometry is already implicitly defined by the lack of feature tags, ie would you add type=geoemtry to all node of a way ? Furthermore, your geometry_class= describes what feature category it is, which is self-contradicting. There’s no difference if hypothetically OSM uses man_made= or geometry_class= as the feature for *way= and building=
What’s crucial to realize is simply using multilinestring is not the solution to everything. Eg if there’s a railway=rail section with many route=train passing through it, you still have to create a new variant of all thoseroute=train when a new railway=rail is created with some attribute changed, whether name= or electrified= etc. This applies regardless of the railway=rail is a way , or =multilinestring .
Similar problem applies to highway= with route=road . It’s worse with many ref= , and the highway= class possible to change as feature.
Therefore, for both compatibility, and as the ideal solution, I advocate to separate the feature and its attributes. As far as calling it a One set of Attributes, One Object idea. Roads – how to represent evolution? - #33 by Kovoschiz
The feature as physical objects and changes can use way at least for now, for railway= and highway= etc. When a road is widened, or a track doubled etc, you should draw a new way anyway, as its position has moved.
Attributes should be moved to a rel of their own. Preferably not =multilinestring , but something more specific.
highway=
name= : type=street / type=associated_street to be consistent and explicit for addressing (depends on how they should be organized, or type=highway for general namingref= : kept to the route=road
railway=
name= : route=railway or route=tracks as appropriate.electrified= : eg type=power with a new power= similar to power=circuit . * building=name= : Eg type=buildingaddr:housenumber : Moved to address pointsaddr:street= : type=associated_street (again, it seems unnecessary, overcomplicated, and inaccurate to create a new variant simply because the street has been renamed)
What I imagine type= or geometry= can be used is exactly for the data type properly. That could clarify on how its drawn on top of source:geometry= / geometry:source= , and hint at how it might be handled. Similar to placement= for road lane, but somewhat differently. Some ideas on what can be described.
node
=centroid=centre : As in focal or popular center of the community for place==centre_point : The feature is a circle etc=origin / =axis ? : Placed on the intersecting point between some imaginary lines=small ??? (obviously uncertain, as a placeholder): For poles etc small enough to be represented by a point basically perfectly=routing=label=clustered
way
=centre_line: Default and assumed for routable linear highway= , railway= , waterway= , etc=perimeter : When exact (different meaning from perimeter in type=site ; closer to outline in type=building )=bounding+ bounding= =box etc=convex_hull=shrinkwrap=illustrative : Area affected by fire, earthquake, or disasters was discussed somewhere before
For way , line vs area could already be defined explicitly by area= if needed. Otherwise, OHM should simply wait for OSM when it eventually adds an area object type, if it ever happens.
