"Subtleties" not "subtitles." Dang auto-correct! Also, I was sloppy with "data are plural, datum is singular."
Roland's "true, excellent point" (period, not colon) is that sometimes this becomes a "cost-benefit evaluation" where the trouble to "fix" (modify) data may likely be higher-cost than the benefit of what might be determinable directly from the data (anyway, presently). SteveA > On Mar 18, 2020, at 10:52 PM, stevea <[email protected]> wrote: > > Even the "let's not misunderstand" posts might even contain slight > misunderstandings. As Roland mentions tiger:cfcc tags, there is an argument > (and documented wiki) that suggests they might still yield some underlying > structure of the TIGER rail import in the USA which can provide useful data > (in constructing route=railway relations, for example) still today, even as > they have become somewhat smeared since their import. It is virtually > impossible to recognize all such subtitles of all such structured data that > is now in OSM. To say "this import seems to have 'grey' (old, misunderstood, > seems to be 'noise in place') data, we should structurally treat it like x, y > and z" REALLY must have some deep treatment about what these data were, are > and might be before some wholesale data manipulation occurs. > > I'm not saying some of these (clean up our data sub-projects) aren't good > ideas, just that we MUST look at the whole iceberg rather than only its tip. > Usually, what appears to be is only the tip and the iceberg is bigger than > one might realize. > > SteveA > >> On Mar 18, 2020, at 10:37 PM, Roland Olbricht <[email protected]> wrote: >> ..."stale": Tags that came with an import, are not, and can not be used by >> general mappers, and are not expected to be updated. "tiger:cfcc" is >> currently the most numerous. The low number of values of "tiger:cfcc" >> makes it unlikely that it is carrying any meaning. >> >> Another final question is whether it makes sense to refine the system at >> all. Much of the information of the tagging classes is available via >> taginfo, and some more can be automatically computed from the database, >> although it is it done today. Having this is as explicit information >> instead is the either redundant (if in line with actual database >> content) or misleading (if in contradiction to the actual database content). > > This is a true, excellent point: _______________________________________________ talk mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk
