[Tagging] How to tag named group of named water areas?
daveswarthout at gmail.com
Thu Nov 8 01:59:29 UTC 2018
To my way of thinking, a tag in the relation implicitly applies to every
member of the relation. It's not "visible" to us mappers but it's there
nonetheless. It's my belief that tagging every way with the identical tags
present on the relation is to ensure that the object will render. If our
software isn't clever enough to understand that each way in a pipeline
route relation should actually be treated (rendered) as though it had the
tag man_made=pipeline, that's a limitation of the software doing the
interpretation. IMO, due to those limitations, people chose an easy
workaround. They applied tags they consider important to each member way.
That practice has become the de facto standard. I've done it myself.
Yesterday Gerd showed me that even mkgmap can be persuaded to render a
pipeline as such even if the ways are untagged (the original cause for this
discussion) but it involves a trick. A directive in the style sheet sets
the man_made=pipeline tag on every way in order to force it to render.
Thus, the software uses the same approach as most OSM mappers have used
over the years.
Yves advises me to keep it simple. That is exactly what I'm trying to do.
Having 280 ways all with the same tags as the top level relation of which
they are members is complicated and totally unnecessary. Keeping the tags
that apply to the entire route, be it a pipeline or a bicycle route, on the
relation and not on every way, is simple and more efficient. Database
developers avoid the sort of data replication we see on the TAPS (and many
other relations) like poison. That's because keeping all those tags
synchronized is arduous and error-prone. Those developers devised schemes
to store data in such a way that no data is duplicated.
If you can bear with me, let's take as an example a database containing a
table of names and addresses. Now we want to include their children in the
database. So we add a table containing a list of those persons' children.
That table must somehow be able to show which child has which parent. The
deceptively simple approach would be to include the parent's name with each
of the children's records. And that approach does work, for a while. But
then a parent remarries and acquires a different surname. The database
maintainer must now find each child record that contains the outdated last
name and edit it. Instead, every database uses a special field called an
index, a number, that gets assigned to each parent. Every child in the
database is linked to her parents via this ID, which never changes. Now,
when a parent's surname changes the maintainer only need to change it in
her record. Her children are still connected to her through her ID. This
is the reasoning behind the "relational database" of which there are
countless examples. OSM "relations" (do any of you think the name
"relation" for this data structure was an accident?) are almost exactly the
same sort of thing and, I believe, serve the same purpose. The relation is
the master of all, the top level data structure for a pipeline or railroad,
what have you. It tells us that all of its members are related in some way,
sort of like the ID in the top-level table, and it also offers an elegant
way maintain the relationship between itself and its members. Adding tags
to every way is exactly the same as adding the parent's name to each
child's record. It's messy, error-prone, and unnecessary.
Another part of the problem is the Wiki that we treat as our bible.
Unfortunately, it doesn't offer us much guidance on topics like this.
Fragments about relations and multipolygons are scattered here and there,
some written fairly well, others not. OSMers aren't technical writers, and
there is no overriding authority to make sure things are written clearly
and concisely. It's written in English, which is a problem for those who
aren't native English speakers. Gerd started a second thread about pipeline
routes yesterday and provided two references to check. Reading through them
leaves me wondering just what was meant.
Neither of those references is very specific or very clearly written. Under
the heading How to Map in reference  is the following:
Create a relation of the type route and add the tag route=pipeline.
You can add additional tags which are used together with man_made=pipeline.
It says "you can add additional tags which are used together with
Additional tags can be added where? The writer doesn't say. And the tag
man_made=pipeline. Where does that go?
I reckon it's up to you. The writer doesn't say.
Reference  is also, not very clearly written and certainly not
definitive in any way. In the section under Route Types the writer gives in
the Comment column as examples for route=pipeline these three:
pipelines, pipeline markers, and pipeline stations. The first one is
obvious but the second and third? What would a route of pipeline markers
be? What about a route of pipeline stations? One wonders where these
examples came from. An email list? Or are they just reasonable guesses made
by someone who was pressed for time and wasn't very thorough in vetting the
choices he left us?
It's no wonder we're confused about pipeline routes.
That said, I need to get back to my mapping projects. I've tried everything
I can think of to justify my actions and it's wearing me out. I promise not
to change any of your previously tagged ways on relations. You guys can
continue to tag the ways on relations if you wish. I'll wait patiently for
the day when map products fully understand what a relation is and can
render it properly without tagging each and every member way.
On Thu, Nov 8, 2018 at 3:55 AM Paul Johnson <baloo at ursamundi.org> wrote:
> On Wed, Nov 7, 2018 at 2:07 PM Yves <yvecai at mailbox.org> wrote:
>> Agreed with Martin here, I would be amazed that the name of a pipeline
>> would contradict the name of one of its section being something else than a
> I'm not super familiar with them compared to railroads, but similar
> naming conventions exist. Branches and trunks often have differing names
> while being part of the same overall pipeline.
> Tagging mailing list
> Tagging at openstreetmap.org
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Tagging