[Tagging] iD presets
kevin.b.kenny+osm at gmail.com
Fri Jun 22 17:44:13 UTC 2018
On Fri, Jun 22, 2018 at 7:45 AM Martin Koppenhoefer
<dieterdreist at gmail.com> wrote:
> I really welcome this discussion about these procedures, and the participation of Bryan. It is clear that any more rules or policies mean more work and less time for the fun things, and a slow down in development in general, but I feel it is important to have many eyes on this process, because it is at the core of our project (tags are everything when it comes to the meaning of things in the database). To keep it short, I have not commented on everything.
Yes, it's good that people are engaging. While "any tag you like" is
wonderful advice when tagging something that hasn't been tagged
before, it starts to fall down when you expect that the data will be
of general interest and that there will be objects all over that have
the property you're trying to tag.
When trying to make tagging decisions, I accord much greater weight to
the opinions of data consumers, be they the developers of routers,
navigation aids, renderers, statistical analyses, or whatever.
Ultimately, anything that is tagged is for the consumers, or else it
is ultimately meaningless: what is the point of tagging data that
nobody will read? It's better to choose tags that will make the job of
consuming the data easier, even if that makes for a small amount of
additional work for the mapper. (Within reason, of course!)
Second only to comprehensibility to a data consumer is integrity of
the data model. A tagging system that, for instance, requires vast
numbers of tags to be repeated among objects that should instead be
grouped in a relation is going to be difficult both to abstract for
consumption and for mappers to maintain.
Providing excruciating detail about individual objects is by far the
least important to me. Unless some set of data consumers have a plan
to deal with that detail, it's highly likely to be wasted effort. It's
also likely to go stale faster, because there will be fewer mappers
interested in maintaining it.
Intelligent defaults matter. I use iD very seldom, so I can't really
address Martin's arguments about what should and should not be broken
out there, in terms of accessibility to the layman. It appears that
the choice is being made to target a skill level below my own, and
that's fine, even if some of his specific recommendations miss a few
things that I care about. (Example: For a coniferous wood, I care if
the dominant species is Pinus strobus, Pinus rigida, a combination of
Abies spp,/Picea spp., or Larix laricena. That's because I will find
very different conditions underfoot - white pine and tamarack both
favour wetlands, pitch pine will have a fairly open understory because
pitch pine forests burn frequently, spruce/fir at elevation grows in
dense thickets) But that's fine, as long as iD doesn't mess with the
underlying tagging; I'm happy to use JOSM or Meerkartor or external
scripts to get the tagging I want, and do my own rendering at need.
Bryan's choices may seem arbitrary, but this follows a general tenet
of open-source development: "he who does the work makes the rules."
More information about the Tagging