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
"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
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
I would like to add a new status to
https://wiki.openstreetmap.org/wiki/Approval_status and to Tag and Key
pages in the wiki
The value "import" would be used for tags that were used in a large
import, but are no longer commonly being added.
The misunderstanding about "object:street" has
On 18/3/20 10:17 am, Joseph Eisenberg wrote:
Unlike some of those who responded, I was not intending this status to
be a "mark of shame", but rather informative.
A 'mark of shame"? These are neither people or animals.
While a contributor may feel some attachment, once it is in OSM it is OSMs
See, data always have a backstory. Thinking you know what it is, or that you
can improve upon OSM by erasing existing data that has a backstory, hmmm, give
that one a good, long think first before you do anything. Discuss with others,
research, think about past, present and even future
> I don't think that swiching from addr:* to object:* on these objects is
> correctly described by the term "mechanical edit".
Yes it was a mechanic/automated edit, because you switched all the tags at once
Not all mechanical edits are bad:
Hello,
the creation of the object:* tagging was the result of many remarks and
disscussions. Most people agreed that the addr:* tag should be used
only for buildings, shps, offices, etc.
I thought that there was a need for an alternative addresing scheme that could
be used without conflicting
Dear Joseph, dear readers of this list,
as you mention the street lamps of Düsseldorf here and thinking that they were
an import to the OSM-database,
I can tell you that this was not the case.
Many of he streets of Düsseldorf, city of about 600_000 inhabitants, capital of
Northrhine-Westfalia,
I would like to stress once again how easily it is for intended semantics of
what is meant to be tagged, "improve-tagged" or "tag-modernized so that people
understand the historical context of this tag" to diverge from the semantics
that OTHER volunteers / contributors to OSM glean from these.
Unlike some of those who responded, I was not intending this status to
be a "mark of shame", but rather informative.
As mentioned, some imported tags like "gnis:feature_id=*" are useful
to keep the Openstreetmap database object directly linked to an object
in an external database.
That's why I
On 3/17/2020 10:52 AM, Wayne Emerson, Jr. via talk wrote:
However, among your examples you cite "gnis:feature_id=*" The wiki
page for this key notes:
"Unlike other imported tags such as gnis:created=* and
gnis:import_uuid=*, gnis:feature_id=* is meaningful beyond the import.
In fact, some
I think it's reasonable to mark something as
this was used by an import long ago, isn't used by mappers now, and
the existence of it shouldn't be taken as a clue that it's current
good practice
but I think this should also be done in a way that is not unkind to or
judgemental about
Some other possible values:
undesirable
unnecessary
unwanted
unneeded
undiscussed
disapproved
clutter
However, among your examples you cite "gnis:feature_id=*" The wiki page
for this key notes:
"Unlike other imported tags such as gnis:created=* and
gnis:import_uuid=*, gnis:feature_id=* is
"unmaintained"?
On 17 March 2020 10:52:39 CET, Warin <61sundow...@gmail.com> wrote:
>On 17/3/20 8:22 pm, Marc M. wrote:
>> Hello Joseph,
>>
>> it may give the impression that this is the way it should be done.
>> I agree to identify these "Noise" or poor quality tags, but with a
>> keyword to
The one I am thinking of comes from HOT activity. There is no link to an
import proposal, they just use 'any tag they like' .. and leave it there
undocumented.
On 17/3/20 8:59 pm, François Lacombe wrote:
Hi all
My 2cts : "in use" status and statuslink to the import proposal would
be enough,
Hi all
My 2cts : "in use" status and statuslink to the import proposal would be
enough, right?
Point is to determine where does the tag come from, and it's done by
statuslink, not status which reflect the current state of use.
All the best
François
Le mar. 17 mars 2020 à 10:55, Warin
On 17/3/20 8:22 pm, Marc M. wrote:
Hello Joseph,
it may give the impression that this is the way it should be done.
I agree to identify these "Noise" or poor quality tags, but with a
keyword to show that it's a problem. e.g. status=bad, disputed, error, ...
it would be necessary to find a word
Hello Joseph,
it may give the impression that this is the way it should be done.
I agree to identify these "Noise" or poor quality tags, but with a
keyword to show that it's a problem. e.g. status=bad, disputed, error, ...
it would be necessary to find a word that is not as strong as error,
but
19 matches
Mail list logo
