On 19/3/20 4:52 pm, stevea 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.
Agreed on the iceberg! The world is a large place for view points and
usage.
However the beginning mapper may have no knowledge of the tools
available and count on the status as a primary indicator.
As such the status needs to distinguish those tags that are questionable
for further use. And probably other flavors of 'status'.
SteveA
On Mar 18, 2020, at 10:37 PM, Roland Olbricht <roland.olbri...@gmx.de> 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
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
_______________________________________________
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
