Re: [Tagging] Verifiability wiki page: "Geometry" section added

[Joseph Eisenberg]

Re: a hamlet with houses several (=3) km away from the center of
hamlet. I was thinking of a place like Horse Creek, California. This
cemetery is at the northwest end of the valley
((https://www.openstreetmap.org/node/358805720/)), 4 km away from the
center of the hamlet (https://www.openstreetmap.org/node/147133592/).
And there are houses even further up the hills that would be
considered part of the community.

This is common is sparsely settled parts of the American west.

Joseph

On 4/29/19, Greg Troxel  wrote:
> Paul Allen  writes:
>
>> On Sun, 28 Apr 2019 at 21:23, Martin Koppenhoefer 
>> wrote:
>>
>>> I cannot imagine houses that are several kilometers away being part
>>> of a hamlet, in a settlement sense. Can you give an example please,
>>> maybe this can occur in very low density areas?

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Verifiability wiki page: "Geometry" section added

[Joseph Eisenberg]

I would guess that they could be:
Austinville -  place=hamlet
Springbrook - place=village

On 4/29/19, Graeme Fitzpatrick  wrote:
> On Mon, 29 Apr 2019 at 06:23, Martin Koppenhoefer 
> wrote:
>
>> I cannot imagine houses that are several kilometers away being part of a
>> hamlet, in a settlement sense. Can you give an example please, maybe this
>> can occur in very low density areas?
>>
>
> I mentioned these the other week in discussions about place=locality.
>
> https://www.openstreetmap.org/node/4313816641 is the area known as
> Austinville, which is spread out over ~20 sq km along Austinville Rd &
> surrounding area, & has a population of ~360. There is no "town centre" as
> such - no shop, no service station, no pub, no church which are the usual
> defining features. The only similar thing is the Community Hall. The area
> is currently listed in OSM as place=locality, should it be a hamlet, either
> as a node or an area?
>
> Springbrook
> https://www.openstreetmap.org/node/4316622215#map=15/-28.2069/153.2700 has
> a population of ~600 & is the plateau on top of Springbrook Mountain. It
> has a general store, State (Primary) School, a pub & a few cafes, but, once
> again, no real "centre". It's also a place=locality, so should it be a
> hamlet?
>
> Thanks
>
> Graeme
>

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki page for natural=mountain_range

[Joseph Eisenberg]

> It's not mapping the entire range as such, but would is_in work here?
> https://wiki.openstreetmap.org/wiki/Key:is%20in?uselang=en-AU

> natural=mountain_range
> name=Main Range
> is_in=Great Dividing Range

Yes, that makes sense to me

On 4/29/19, Graeme Fitzpatrick  wrote:
> On Mon, 29 Apr 2019 at 08:09, Joseph Eisenberg 
> wrote:
>
>> Yes, make 2 separate ways.
>>
>
> Thanks!
>
>
>> I think it’s reasonable to map a mountain range as a linear way when this
>> can follow a continuous series of ridge crests. But a mountain range that
>> is split in 2 by a valley should be considered 2 local features that
>> share
>> a name.
>>
>
> Yep, makes sense.
>
>
>> For this reason, large and complex mountains ranges, like the Rocky
>> Mountains, cannot be mapped as a single linear or area feature: they
>> consist of many smaller ranges which spread over a wide area, with vague
>> boundaries.
>>
>
> It's not mapping the entire range as such, but would is_in work here?
>
> https://wiki.openstreetmap.org/wiki/Key:is%20in?uselang=en-AU
>
> natural=mountain_range
> name=Main Range
> is_in=Great Dividing Range
>
> Thoughts?
>
> Thanks
>
> Graeme
>

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki page for natural=mountain_range

[Graeme Fitzpatrick]

On Mon, 29 Apr 2019 at 08:09, Joseph Eisenberg 
wrote:

> Yes, make 2 separate ways.
>

Thanks!


> I think it’s reasonable to map a mountain range as a linear way when this
> can follow a continuous series of ridge crests. But a mountain range that
> is split in 2 by a valley should be considered 2 local features that share
> a name.
>

Yep, makes sense.


> For this reason, large and complex mountains ranges, like the Rocky
> Mountains, cannot be mapped as a single linear or area feature: they
> consist of many smaller ranges which spread over a wide area, with vague
> boundaries.
>

It's not mapping the entire range as such, but would is_in work here?

https://wiki.openstreetmap.org/wiki/Key:is%20in?uselang=en-AU

natural=mountain_range
name=Main Range
is_in=Great Dividing Range

Thoughts?

Thanks

Graeme
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Verifiability wiki page: "Geometry" section added

[Graeme Fitzpatrick]

On Mon, 29 Apr 2019 at 06:23, Martin Koppenhoefer 
wrote:

> I cannot imagine houses that are several kilometers away being part of a
> hamlet, in a settlement sense. Can you give an example please, maybe this
> can occur in very low density areas?
>

I mentioned these the other week in discussions about place=locality.

https://www.openstreetmap.org/node/4313816641 is the area known as
Austinville, which is spread out over ~20 sq km along Austinville Rd &
surrounding area, & has a population of ~360. There is no "town centre" as
such - no shop, no service station, no pub, no church which are the usual
defining features. The only similar thing is the Community Hall. The area
is currently listed in OSM as place=locality, should it be a hamlet, either
as a node or an area?

Springbrook
https://www.openstreetmap.org/node/4316622215#map=15/-28.2069/153.2700 has
a population of ~600 & is the plateau on top of Springbrook Mountain. It
has a general store, State (Primary) School, a pub & a few cafes, but, once
again, no real "centre". It's also a place=locality, so should it be a
hamlet?

Thanks

Graeme
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Verifiability wiki page: "Geometry" section added

[Greg Troxel]

Paul Allen  writes:

> On Sun, 28 Apr 2019 at 21:23, Martin Koppenhoefer 
> wrote:
>
>> I cannot imagine houses that are several kilometers away being part
>> of a hamlet, in a settlement sense. Can you give an example please,
>> maybe this can occur in very low density areas?
>
> Remote farms have to be somewhere.  At least as far as the postal
> service goes.  Well, that's true of the UK, maybe not in other
> countries.  We don't have addresses like "Womble Cottage, Middle of
> Nowhere, UK," even if the cottage is, in fact, in the middle of
> nowhere.

We have multiple separate concepts:

  postal addresses (where what the post office says is your address is
  what it is)

  legal addresses (according to the government, and perhaps what shows
  up for 911/999 purposes; in my state it is legally required to display
  your house number)

  admin boundaries

  geography of populated places (hamlet, village, town, usually as
  points)

It can certainly make sense to draw fuzzy lines for the hierarchy of
populated places, but of course they remain fuzzy.  This is quite
separate from the other 3 things.

Presumably the addr:foo tags are about legal addresses.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Verifiability wiki page: "Geometry" section added

[Paul Allen]

On Sun, 28 Apr 2019 at 23:09, Wolfgang Zenker 
wrote:

The most difficult thing here is probably finding a good name for that
> relation type and for the "inside" and "near by but outside" roles.
>

multifuzzygon

I'm not being entirely serious...

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki page for natural=mountain_range

[Joseph Eisenberg]

> You've suggested that when drawing a way that "The way should not cross
streams, rivers or valleys".

>
> > How then do you handle gaps in the range? eg Main Range stretches from
> here, south to there, & is crossed here by Cunningham's Gap, which includes
> the east-west highway. Split the way, so that the range is shown each side
> of the gap?
>

Yes, make 2 separate ways.

I think it’s reasonable to map a mountain range as a linear way when this
can follow a continuous series of ridge crests. But a mountain range that
is split in 2 by a valley should be considered 2 local features that share
a name.

For this reason, large and complex mountains ranges, like the Rocky
Mountains, cannot be mapped as a single linear or area feature: they
consist of many smaller ranges which spread over a wide area, with vague
boundaries.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Verifiability wiki page: "Geometry" section added

[Wolfgang Zenker]

* Tobias Knerr  [190428 14:31]:
> On 28.04.19 13:51, Mateusz Konieczny wrote:
>> "A place=hamlet often lacks verifiable borders. Hamlets in farming areas
>> often have scattered houses and farms extending outward for several
>> kilometers. In this case the approximate center of the place may be
>> well-know, but the outer limits are not clearly determined,
>> so mapping as an area is not verifiable."

>> is a good description of a common situation. Are you claiming that it
>> never happens?

> I agree that this is a common situation. However, I'm claiming that we
> actually know _more_ than just the hamlet's center in that situation.
> There will often be houses that are well known to be part of that
> hamlet, and other houses (in fact, almost 100% of the world's houses)
> that everyone will agree are not part of that hamlet.

> So the world's houses and farms can be (somewhat simplistically) divided
> into 3 sets:
> A: Verifiably part of the hamlet.
> B: Verifiably not part of the hamlet.
> C: May or may not be part of the hamlet.

> In my opinion, verifiability is not a valid reason to stop people from
> attempting to map the sets A and/or B.

Let me suggest a way to map features with "fuzzy" borders based on A and
B as defined above: We could use a relation that contains one ore more
objects (nodes/ways/relationjs) that are "inside" or "part of" our
feature and zero or more objects that are "near by but outside" our
feature. Features defined in this way could be used for basically two
things only, labelling that feature on a rendered map, and searching for
objects "in" or "near" that feature (where "in" and "near" could return
the same result, as the exact border is "fuzzy" anyway).
Examples: A valley could have a river or stream "inside" and maybe
another river at its mouth or mountains around it as "nearby but
outside". A mountain range could have some peaks "inside" and maybe
valleys outside.
The most difficult thing here is probably finding a good name for that
relation type and for the "inside" and "near by but outside" roles.

Wolfgang

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - tag:Police

[Graeme Fitzpatrick]

On Mon, 29 Apr 2019 at 04:18, Jan S  wrote:

>
> So, I'm looking forward to your votes


Done! Good luck :-)

Thanks

Graeme
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki page for natural=mountain_range

[Graeme Fitzpatrick]

On Sun, 28 Apr 2019 at 22:39, Joseph Eisenberg 
wrote:

> I was considering making a proposal for natural=mountain_range, but
> this tag is already in use over 603 times by over 84 different mappers
> (for the nodes and ways; I didn't download relations). So I've made a
> wiki page to describe the current use.
>
> But if there are people who would prefer I make a proposal page and
> redirect to that, I can do this instead.
>

Good on you, Joseph.

I'd agree that seeing it is already in wide=spread use, it shouldn't need a
proposal, then voting.


> I've tried to recommend mapping as a node in most cases, or a linear
> way when this can be done a reasonable way, by following natural=ridge
> lines to connect the main natural=peak and natural=saddle points of
> the mountain range.


One question though, please.

You've suggested that when drawing a way that "The way should not cross
streams, rivers or valleys".

How then do you handle gaps in the range? eg Main Range stretches from
here, south to there, & is crossed here by Cunningham's Gap, which includes
the east-west highway. Split the way, so that the range is shown each side
of the gap?

Thanks

Graeme
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Verifiability wiki page: "Geometry" section added

[Kevin Kenny]

On Sun, Apr 28, 2019 at 5:16 PM Daniel Koć  wrote:
> I think there is a quite universal problem with mixing verifiability
> with level of accuracy. You might not be able to show accurate borders,
> but you can clearly verify that this is an area and not the node, for
> example.

This is why I'm trying to be careful with language, and use
'indefinite' rather than 'imprecise' or 'inaccurate' for the cases
where the margin of an area feature is not 'unsurveyed' or 'surveyed
badly' but actually not well established.

Indefinite margins, for some types of feature, comprise only
relatively small portions of the features' margins. We discard much
useful information by making no distinction between 'area feature
about which less than everything is well defined' and 'putative area
feature about which nothing is defined.'

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Verifiability wiki page: "Geometry" section added

[Daniel Koć]

W dniu 28.04.2019 o 11:43, Joseph Eisenberg pisze:
> "Linear ways and areas can be non-verifiable if the geometry cannot be 
> demonstrated to be true or false by another mapper.

It sounds like for some reason nodes are more verifiable. I believe this
does not work that way.

I see an assumption that verification is easy: you should just ask local
"where is it?" or "what is the name of this?", then you get the simple
answer (presumably "here" for some node) and act accordingly. But this
lacks some other important questions.

The most basic question could be "is it a point?" - and for many objects
you will hear it's not (at least the true/false category applies here
the best). You can ask then "what borders does it have then?" and you
will get some more complex (and I think more accurate) answer.

I think there is a quite universal problem with mixing verifiability
with level of accuracy. You might not be able to show accurate borders,
but you can clearly verify that this is an area and not the node, for
example. The bigger object, the more I think nodes are just "tagging for
searching/rendering" etc.


-- 
"I see dead people" [Sixth Sense]



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Verifiability wiki page: "Geometry" section added

[Paul Allen]

On Sun, 28 Apr 2019 at 22:02, Martin Koppenhoefer 
wrote:

>
> postal address and administrative belonging are one (or two ;-) ) things,
> being part of a settlement another. Every place will be inside an
> administrative entity, but in doesn’t necessarily mean it is also part of
> the settlement. If it is kilometers away, it is „outside“ (the hamlet).
>

 Postally it is.  In terms of a residential area, it isn't.  So I didn't
extend the residential area to
include the farm (that would be silly).  Nor did I turn the residential
area into a multipolygon
so I could include the farm that way (equally silly, in my opinion).  But
in the farm's address, it
says Blaenannerch.

Question would be for a few scattered houses/farms that together identify
> as „hamlet“ (not sure this would be a sensible way to see it).
>

There are many hamlets in this part of the world that consist of a handful
of houses.  But the houses
within the hamlet are relatively close.  And there are usually road signs
identifying the hamlet.

The real world is messy...

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Verifiability wiki page: "Geometry" section added

[Martin Koppenhoefer]

sent from a phone

> On 28. Apr 2019, at 22:36, Paul Allen  wrote:
> 
> In the UK, historic (and perhaps no longer existent) parish boundaries play a 
> part in determining
> which hamlet/village/town an isolated farm is regarded as being part of.  At 
> least as far as its
> postal address goes.



postal address and administrative belonging are one (or two ;-) ) things, being 
part of a settlement another. Every place will be inside an administrative 
entity, but in doesn’t necessarily mean it is also part of the settlement. If 
it is kilometers away, it is „outside“ (the hamlet).

Question would be for a few scattered houses/farms that together identify as 
„hamlet“ (not sure this would be a sensible way to see it).


Cheers, Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Verifiability wiki page: "Geometry" section added

[Martin Koppenhoefer]

sent from a phone

> On 28. Apr 2019, at 14:46, Christoph Hormann  wrote:
> 
> the aim of this would need to be to allow limiting 
> the recorded information to exactly what can verifiably be said about a 
> feature, not to add more non-verifiable data to disguise the 
> non-verifiable nature of the whole thing.  


+1, a polygon is often not the right representation because the details are 
quite arbitrary (corner positions) in case of unclear borders


> I have thought about this 
> quite a bit and came to the conclusion that the answer to this is 
> usually that using a node rarely misses any verifiable information that 
> cannot most efficiently be recorded in the form of tags or that is not 
> already recorded implicitly in the form of other features that are on 
> their own much better verifiable.


what about several nodes, combined by a relation? They could have roles like is 
in or is out, and the processing software of the user could convert them to the 
geometry that suits (or drop them). 

As long as the nodes don’t get dragged very far it probably wouldn’t matter 
that they are moved. It could start with very few nodes and as people locally 
experience problems they could enhance the relations by adding another is 
inside or is outside node.

For representing islands of “outside“ or several disjunct insides, there should 
maybe be an explicit grouping of these.

Cheers, Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Verifiability wiki page: "Geometry" section added

[Paul Allen]

On Sun, 28 Apr 2019 at 21:23, Martin Koppenhoefer 
wrote:

>
> I cannot imagine houses that are several kilometers away being part of a
> hamlet, in a settlement sense. Can you give an example please, maybe this
> can occur in very low density areas?
>

Remote farms have to be somewhere.  At least as far as the postal service
goes.   Well, that's
true of the UK, maybe not in other countries.  We don't have addresses like
"Womble Cottage,
Middle of Nowhere, UK," even if the cottage is, in fact, in the middle of
nowhere.

In a few minutes I'm going to map a farm that's approximately 1 km from the
outskirts of a village
(I just took a break from mapping to check mail).  From all I can tell, the
postal address for
Trefwtial is Blaenannerch, despite being approx 1 km from it, and the
hamlet of Tremain being
maybe half that distance.

In the UK, historic (and perhaps no longer existent) parish boundaries play
a part in determining
which hamlet/village/town an isolated farm is regarded as being part of.
At least as far as its
postal address goes.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Verifiability wiki page: "Geometry" section added

[Martin Koppenhoefer]

sent from a phone

> On 28. Apr 2019, at 13:51, Mateusz Konieczny  wrote:
> 
> "A place=hamlet often lacks verifiable borders. Hamlets in farming areas
> often have scattered houses and farms extending outward for several
> kilometers. In this case the approximate center of the place may be
> well-know, but the outer limits are not clearly determined,
> so mapping as an area is not verifiable."


I cannot imagine houses that are several kilometers away being part of a 
hamlet, in a settlement sense. Can you give an example please, maybe this can 
occur in very low density areas?

Cheers, Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Verifiability wiki page: "Geometry" section added

[Kevin Kenny]

On Sun, Apr 28, 2019 at 3:24 PM Colin Smale  wrote:
> How about taking the maritime baseline (according to UNCLOS) as the location 
> of the rivermouth? Then it becomes both credible and verifiable, as the 
> baselines are deposited at the UN for the purposes of determining the limits 
> of territorial waters.

The hard-liners would, if I am not misinformed, argue that the UNCLOS
maritime baseline is not verifiable, since it cannot be ascertained by
direct observation in the field. It's not obvious that it's what we'd
want to follow in any case - it doesn't make sense to me to say that
Connecticut has no 'coastline', yet the Long Island Sound is a
'juridical bay' and the US 'coastline' follows the south shore of Long
Island only.

> Don't we already (grudgingly) allow polygons to indicate maritime areas with 
> fuzzy boundaries, such as bays and straits? Why should that be tolerated 
> while the same concept on land is frowned upon?

The same hard-liners have argued specifically that the practice you
mention is not allowed and has never been allowed, and that all such
features that are in OSM are in OSM in contravention of clearly
established policy. The example that I gave of the Red Sea, for
instance, cannot have a (multi)polygon because of the uncertainty
about the boundary between it and the Gulf of Aden.

While the fire rages, I've refrained from mapping any such feature,
even though I would very much like to have them in the database so as
to be able to label the features on large-scale paper maps that show
only a portion of the larger areas, not including any point features
near their (necessarily approximate) centroids. Without having areas
in the database, it's surely unclear how to go about labeling
incomplete features. Having a separate data store to maintain the
'forbidden' multipolygon relations is fraught, owing to the fact that
for similar reasons, anything in OSM resembling a 'foreign key' and
allowing OSM objects to be associated with an external database is
also strongly deprecated. (Wikidata references appear to be tolerated,
but the hard-liners are against them as well.)

By 'hard-liner' I do not mean disparagement. (I disagree with them,
but try to respect them.) In fact, I mean 'hard-liner' in two senses:
holding a hard line on the admission of indefinite features, and
demanding that area features be bounded with hard lines. One phrase
does double duty here.

Everyone appears to tolerate the presence of feature names in OSM. It
is unclear whether any of the hard-liners would argue that a
natural=peak, for instance, ought to have its name omitted if there is
no sign giving it. 'Look the name up on an existing
(license-compatible) map,' is clearly an unacceptable practice in the
hard-line world, but it's not clear whether 'ask a few locals what the
name is' would be depending on unverifiable external information,
since it's not the mapper's personal local knowledge, and it's even
more unclear how personal local knowledge of the name of a feature
could ever be acquired other than by transmission of someone else's
knowledge. How do you learn the name of something without someone
telling you? The only exception would be if the mapper were the person
who named it, and I think there's a broad consensus that we don't want
mappers naming things arbitrarily! Most of us would call that
'vandalism.'

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Verifiability wiki page: "Geometry" section added

[Colin Smale]

On 2019-04-28 20:25, Kevin Kenny wrote:

> Precisely the same quest for topologic perfection is responsible for the rule 
> that fixes the mouth of a river at its tidal limit - which gives rise to the 
> absurd result that the mouth of the Hudson River is at 
> https://www.openstreetmap.org/way/90929525, or of the Connecticut River at 
> https://www.openstreetmap.org/way/22889153, while the reaches below are part 
> of the ocean. This absurdity arises directly from the concept that what the 
> locals would call the river's mouth, being perforce represented by an 
> imaginary line across otherwise unmarked water, is not verifiable.

Although the definition of "coastline" giving rise to the Hudson
situation, I don't think anybody would argue that what this line
represents is the location of the mouth of the river. Obviously that
would be somewhere below NYC where you would expect it to be. How about
taking the maritime baseline (according to UNCLOS) as the location of
the rivermouth? Then it becomes both credible and verifiable, as the
baselines are deposited at the UN for the purposes of determining the
limits of territorial waters. 

Don't we already (grudgingly) allow polygons to indicate maritime areas
with fuzzy boundaries, such as bays and straits? Why should that be
tolerated while the same concept on land is frowned upon?___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Verifiability wiki page: "Geometry" section added

[Kevin Kenny]

On Sun, Apr 28, 2019 at 7:39 AM Tobias Knerr  wrote:
> Yes, it's often not possible to agree on a precise border for these
> features. But nevertheless, there are typically areas that are
> definitely part of them, and other areas there are definitely not part
> of them.
>
> The above is verifiable geographic information, so it ought not be
> off-limits for OSM. I've always thought of mapping features with fuzzy
> boundaries as an unsolved challenge for our data model, not as something
> that should be categorically excluded from OSM.

Exactly this.

It's 100% verifiable that Port Sudan lies on the Red Sea. It's 100%
verifiable that the Red Sea is longer than it is wide, and that it lies in
a generally north-south direction. An enormous majority of its shoreline
can be mapped, and the locals would agree that the body of water beyond the
shore is the Red Sea. None of that information is non-verifiable, and none
of that portion of its margin is ambiguous, except for potential arguments
over which point in the twice-daily and monthly tidal cycles determines it.

That information is there, in the field, and we can't map it.

Essentially, our data model quests for mathematical perfection. Because the
boundary is indefinite at the strait at the sea's southern margin, some
argue, topology implies that the entire interior must be ambiguous, because
that boundary could be drawn anywhere - from excluding the entire sea by
bending it north to the entrance to the Suez Canal, to stretching it east
until it encompasses the entire Indian Ocean - or even all the
non-landlocked waters of the globe. That's absurd. Nobody would argue that
Mumbai or Dar-as-Salaam lie on the Red Sea; in fact, nobody would argue
that Djibouti lies on the Red Sea, and by the same token nobody would argue
that Port Sudan or Jeddah do not.

Precisely the same quest for topologic perfection is responsible for the
rule that fixes the mouth of a river at its tidal limit - which gives rise
to the absurd result that the mouth of the Hudson River is at
https://www.openstreetmap.org/way/90929525, or of the Connecticut River at
https://www.openstreetmap.org/way/22889153, while the reaches below are
part of the ocean. This absurdity arises directly from the concept that
what the locals would call the river's mouth, being perforce represented by
an imaginary line across otherwise unmarked water, is not verifiable.

I am NOT arguing here that we should open the door to utter chaos. The bad
examples that people like to trot out, such as the Drake Passage or the
Amazon rain forest, are just that - bad examples. Their margins are
verifiable nowhere, or only on a relatively small portion of the object,
rather than nearly the entirety of the margin.

Note that in this argument I've consistently used the word, 'indefinite'
rather than 'imprecise' or 'inaccurate'. 'Imprecise' means that either the
measurement technology or the quantity asserted have limits to how finely
they can determine a quantity. 'Inaccurate' means that owing to some
influence, the measurement differs from the true value, generally by an
amount that exceeds the precision. 'Indefinite,' by contrast, denotes that
the quantity in question is unknowable exactly - a better measurement will
not help.

If the quantum mechanicians are to be believed, every quantity that we can
measure is indeterminate at some level. Moreover, the things we measure are
referred to abstractions that are indeterminate, such as geoid models that
try to describe the Earth's gravitational equipotential while ignoring
'local gravitational anomalies'. Nothing that we map is a Platonic ideal,
because all of us inhabit Plato's cave.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - Voting - tag:Police

[Jan S]

Hi everyone,

since the police facilities proposal had already been widely discussed, I 
hadn't expected much further comment on the stripped-down version consisting 
only of the police tag. That's why I'm already putting it to vote again.

So, I'm looking forward to your votes and expect heavy participation :)

Please vote here: 
https://wiki.openstreetmap.org/wiki/Proposed_features/tag:Police

Best, Jan

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Verifiability wiki page: "Geometry" section added

[Christoph Hormann]

On Sunday 28 April 2019, Christoph Hormann wrote:
> [...]
>
> Seriously?
>
> Because one polygon is not a verifiable representation of a certain
> feature you want to replace it with - drumroll - two polygons?

I am sorry if that came across more dismissive than necessary - i was 
just quite taken aback by the suggestion which from my perspective 
pretty much flies into the face of the idea of verifiability.

But i understand the underlying thought process and see that it is not 
trivial at all why this makes very little sense and goes in the 
opposite direction of what might make sense.  And entertaining the idea 
for a moment and considering why you might think this helps but why it 
ultimately does not is a useful approach.

-- 
Christoph Hormann
http://www.imagico.de/

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Verifiability wiki page: "Geometry" section added

[Christoph Hormann]

On Sunday 28 April 2019, Joseph Eisenberg wrote:
>
> Is this first line a clear definition, or can it be improved?
>
> "Linear ways and areas can be non-verifiable if the geometry cannot
> be demonstrated to be true or false by another mapper."

While that is a correct statement it also applies to nodes and tags and 
does not add any additional information to what is already stated in 
the text before, namely:

> At the core, "verifiability" is that everything you do can be 
demonstrated to be true or false

What would be useful additional information on the verifiability of 
geometries is the distinction between the ability to verifiably 
localize something and the ability to precisely measure its location.  
However i am kind of inclined to agree not to overburden the 
explanation of the basic concept of verifiability with that much 
detail.  And of course the suggestion that proper and precise 
documentation helps applies to recording of geometries as well - not 
only to tags.

-- 
Christoph Hormann
http://www.imagico.de/

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Baby changing table

[Paul Allen]

On Sun, 28 Apr 2019 at 09:20, bkil  wrote:

>
> Our word for changing_table=* is something like "diaper changer
> [place]" ("pelenkázó") or more like "a place where you change
> diapers", the word itself weakly implicates a separate room, although
> this should not cause confusion. Interestingly, the dictionary
> definition suggests a translation "pelenkáz" = "changing the baby",
> but the term itself does not narrow this down to babies and it is
> applicable to all age groups.
>
> Do you know a language where this could cause an issue for real?
>

Magyar might be one.  :)  I have been led to believe that in Magyar the
term for this facility
loosely translates as "diaper changer [place]."  I do not know what
percentage of
Hungarian mappers would infer, without looking it up, that "changing table"
meant
"diaper changer [place]."

I would guess that any language that refers to such facilities by including
that language's words
for "baby," "diaper," or "napkin" might have that problem.  In English,
through common usage,
we just use "changing table" but 20 years ago (when it wasn't common usage)
I would have
wondered what it meant and what was being changed (I still feel a little
uneasy with it).

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Verifiability wiki page: "Geometry" section added

[Joseph Eisenberg]

On 4/28/19, Christoph Hormann  wrote:
> I don't really like the extension Joseph wrote on the Verifiability page
> but not because i disagree with the general idea but because for my
> taste it is too much *definition by example* which is a poor way of
> communicating the concept in general.  Examples are useful and needed
> to clarify the meaning (and they have been used as such on that page
> for a long time) but they are no replacement for formulating the
> general abstract idea behind verifiability in a compact form that is
> not tied to specific examples.  Andy's idea of creating subpages
> explaining how to practically apply verifiability to tags and
> geometries is probably the right approach.

Is this first line a clear definition, or can it be improved?

"Linear ways and areas can be non-verifiable if the geometry cannot be
demonstrated to be true or false by another mapper."

I've removed one of the examples to get it a little more compact after
Andy Townsend's criticism above, and I've tried to tighten up the
phrasing some.

But it would be great is someone can improve the style further and
figure out how to break it up.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Verifiability wiki page: "Geometry" section added

[Christoph Hormann]

On Sunday 28 April 2019, Tobias Knerr wrote:
>
> Yes, it's often not possible to agree on a precise border for these
> features. But nevertheless, there are typically areas that are
> definitely part of them, and other areas there are definitely not
> part of them.

I'd like to emphasize once more that verifiability has absolutely 
nothing to do with mapping precision or measurement errors.

It is the nature of every geographic feature (in the sense of something 
with at least limited localizability) that you can specify locations 
that are definitely not part of it.  That does not mean you can create 
a verifiable polygon geometry for them.

OTOH just because the only information source you have for example about 
a lake is a poor quality GPS track from a walk around it does not mean 
you cannot map that lake with a polygon based on that information.  
Because the problem here is not your limited ability to localize the 
shore of the lake but the ability to precisely measure it.

Getting this difference is key to understanding the essence of 
verifiability on OSM.

> The above is verifiable geographic information, so it ought not be
> off-limits for OSM.

So you think "The Amazon Rainforest" should be mappable with a polygon 
in OSM because you can make a verifiable statement that it does not 
extend to Asia?

> [...] One could
> imagine, for example, a relation containing two polygons for the
> feature's "minimum" and "maximum" extent (describing the parts of the
> world that are verifiably part of/not part of the feature), with a
> grey area of uncertainty in between.

Seriously?

Because one polygon is not a verifiable representation of a certain 
feature you want to replace it with - drumroll - two polygons?

The idea of developing new data objects for selectively documenting 
verifiable information of objects with limited localizability is not 
necessarily bad but the aim of this would need to be to allow limiting 
the recorded information to exactly what can verifiably be said about a 
feature, not to add more non-verifiable data to disguise the 
non-verifiable nature of the whole thing.  I have thought about this 
quite a bit and came to the conclusion that the answer to this is 
usually that using a node rarely misses any verifiable information that 
cannot most efficiently be recorded in the form of tags or that is not 
already recorded implicitly in the form of other features that are on 
their own much better verifiable.

> With your recommended solution of placing a node "near the center of
> the feature", capturing this useful knowledge is not possible. It
> also doesn't make logical sense to me: If it were indeed impossible
> to verifiably establish even an approximate boundary of the feature,
> how can we verifiably establish the feature's center?

I have had this discussion plenty of times in the past - the 
verifiability of a node localizing a feature is much easier to achieve 
(through a clear rule where to place the node) and demonstrate than for 
a polygon.  Verifiability of a node location means nothing more than 
that qualified independent placements of the node converge to a single 
location.  This is a completely scale independent condition - it can be 
fullfilled with a standard derivation of less than a meter (for 
something like a power=pole) but might also be many kilometers.  For a 
polygon that is not the case.

I don't really like the extension Joseph wrote on the Verifiability page 
but not because i disagree with the general idea but because for my 
taste it is too much *definition by example* which is a poor way of 
communicating the concept in general.  Examples are useful and needed 
to clarify the meaning (and they have been used as such on that page 
for a long time) but they are no replacement for formulating the 
general abstract idea behind verifiability in a compact form that is 
not tied to specific examples.  Andy's idea of creating subpages 
explaining how to practically apply verifiability to tags and 
geometries is probably the right approach.

-- 
Christoph Hormann
http://www.imagico.de/

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Verifiability wiki page: "Geometry" section added

[Joseph Eisenberg]

I could remove some of my examples and some of the other that have
been added since 2015, but I wonder if the page will still be
understood by most people without examples?

Perhaps we could move all the examples to a later section, so that the
first part is relatively short and to the point?

On 4/28/19, Andy Townsend  wrote:
> On 28/04/2019 10:43, Joseph Eisenberg wrote:
>> Please suggest any improvements to the wording or corrections:
>> https://wiki.openstreetmap.org/wiki/Verifiability#Geometry
>>
> Thanks for trying to improve the documentation, but unfortunately,
> trying to add more detail (including specifics about particular tags)
> makes the page more complicated and more difficult to understand for new
> mappers (who are usually the people I'd point at that page with a DWG
> hat on).
>
> For example, compare the current version of the page with this one from
> 2015:
>
> https://wiki.openstreetmap.org/w/index.php?title=Verifiability=1141651
>
> The 2015 version contains a definition, an example and short "what to
> do" and "what not to do" sections.
>
> The current one simply doesn't do that.  Obviously there are 20 edits
> since that example that I picked out pretty much at random from 2015, of
> which yours is only the last, and the authors of each of those have seen
> an edge case that wasn't quite covered by the documentation, which led
> to them adding their new section. The problem is that while all of those
> extra little bits on their own have value, taken together they do make
> the page less useful as a summary of a key concept in OpenStreetMap.
>
> Maybe what would be better would be to try and reduce the
> "Verifiability" page to its original summary status but to break out
> some of the detail into linked sub-pages?  The whole "geometry" section
> would be a good candidate for that (the page already contains an
> example, two paragraphs above).  Also "story-telling" content such as
> "Someone might do this" is probably better elsewhere too.
>
> Best Regards,
>
> Andy
>
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Wiki page for natural=mountain_range

[Joseph Eisenberg]

I was considering making a proposal for natural=mountain_range, but
this tag is already in use over 603 times by over 84 different mappers
(for the nodes and ways; I didn't download relations). So I've made a
wiki page to describe the current use.

But if there are people who would prefer I make a proposal page and
redirect to that, I can do this instead.

I've tried to recommend mapping as a node in most cases, or a linear
way when this can be done a reasonable way, by following natural=ridge
lines to connect the main natural=peak and natural=saddle points of
the mountain range. This only works for small mountain ranges, not
huge massifs or long ranges with multiple smaller ranges within.

The new wiki page discourages mapping mountain ranges as areas (closed
ways or multipolygon relations) because the shape and size of these
are not consistent between different mappers. It's usually quite
debatable which valleys and foothills to include in a mountain range.
Unfortunately there are a growing number of natural=mountain_range
mapped as areas.

https://wiki.openstreetmap.org/wiki/Tag:natural%3Dmountain_range

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Verifiability wiki page: "Geometry" section added

[Mateusz Konieczny]

28 Apr 2019, 14:31 by o...@tobias-knerr.de:

> So the world's houses and farms can be (somewhat simplistically) divided
> into 3 sets:
> A: Verifiably part of the hamlet.
> B: Verifiably not part of the hamlet.
> C: May or may not be part of the hamlet.
>
> In my opinion, verifiability is not a valid reason to stop people from
> attempting to map the sets A and/or B.
>

Is there some existing method used in OSM that works well
in such situation?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Verifiability wiki page: "Geometry" section added

[Tobias Knerr]

On 28.04.19 13:51, Mateusz Konieczny wrote:
> "A place=hamlet often lacks verifiable borders. Hamlets in farming areas
> often have scattered houses and farms extending outward for several
> kilometers. In this case the approximate center of the place may be
> well-know, but the outer limits are not clearly determined,
> so mapping as an area is not verifiable."
> 
> is a good description of a common situation. Are you claiming that it
> never happens?

I agree that this is a common situation. However, I'm claiming that we
actually know _more_ than just the hamlet's center in that situation.
There will often be houses that are well known to be part of that
hamlet, and other houses (in fact, almost 100% of the world's houses)
that everyone will agree are not part of that hamlet.

So the world's houses and farms can be (somewhat simplistically) divided
into 3 sets:
A: Verifiably part of the hamlet.
B: Verifiably not part of the hamlet.
C: May or may not be part of the hamlet.

In my opinion, verifiability is not a valid reason to stop people from
attempting to map the sets A and/or B.

Tobias

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Verifiability wiki page: "Geometry" section added

[Andy Townsend]

On 28/04/2019 10:43, Joseph Eisenberg wrote:

Please suggest any improvements to the wording or corrections:
https://wiki.openstreetmap.org/wiki/Verifiability#Geometry

Thanks for trying to improve the documentation, but unfortunately, 
trying to add more detail (including specifics about particular tags) 
makes the page more complicated and more difficult to understand for new 
mappers (who are usually the people I'd point at that page with a DWG 
hat on).


For example, compare the current version of the page with this one from 
2015:


https://wiki.openstreetmap.org/w/index.php?title=Verifiability=1141651

The 2015 version contains a definition, an example and short "what to 
do" and "what not to do" sections.


The current one simply doesn't do that.  Obviously there are 20 edits 
since that example that I picked out pretty much at random from 2015, of 
which yours is only the last, and the authors of each of those have seen 
an edge case that wasn't quite covered by the documentation, which led 
to them adding their new section. The problem is that while all of those 
extra little bits on their own have value, taken together they do make 
the page less useful as a summary of a key concept in OpenStreetMap.


Maybe what would be better would be to try and reduce the 
"Verifiability" page to its original summary status but to break out 
some of the detail into linked sub-pages?  The whole "geometry" section 
would be a good candidate for that (the page already contains an 
example, two paragraphs above).  Also "story-telling" content such as 
"Someone might do this" is probably better elsewhere too.


Best Regards,

Andy




___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Verifiability wiki page: "Geometry" section added

[Mateusz Konieczny]

28 Apr 2019, 13:38 by o...@tobias-knerr.de:

> It also
> doesn't make logical sense to me: If it were indeed impossible to
> verifiably establish even an approximate boundary of the feature, how
> can we verifiably establish the feature's center?
>
I think that examples given in this edit are good one. I can confirm that

"A place=hamlet often lacks verifiable borders. Hamlets in farming areas
often have scattered houses and farms extending outward for several
kilometers. In this case the approximate center of the place may be
well-know, but the outer limits are not clearly determined,
so mapping as an area is not verifiable."

is a good description of a common situation. Are you claiming that it
never happens?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Verifiability wiki page: "Geometry" section added

[Tobias Knerr]

On 28.04.19 11:43, Joseph Eisenberg wrote:
> Please suggest any improvements to the wording or corrections:
> https://wiki.openstreetmap.org/wiki/Verifiability#Geometry

I'm afraid I can't support the addition of this new rule.

Yes, it's often not possible to agree on a precise border for these
features. But nevertheless, there are typically areas that are
definitely part of them, and other areas there are definitely not part
of them.

The above is verifiable geographic information, so it ought not be
off-limits for OSM. I've always thought of mapping features with fuzzy
boundaries as an unsolved challenge for our data model, not as something
that should be categorically excluded from OSM. One could imagine, for
example, a relation containing two polygons for the feature's "minimum"
and "maximum" extent (describing the parts of the world that are
verifiably part of/not part of the feature), with a grey area of
uncertainty in between.

With your recommended solution of placing a node "near the center of the
feature", capturing this useful knowledge is not possible. It also
doesn't make logical sense to me: If it were indeed impossible to
verifiably establish even an approximate boundary of the feature, how
can we verifiably establish the feature's center?

Tobias

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Verifiability wiki page: "Geometry" section added

[Mateusz Konieczny]

+1

28 Apr 2019, 12:25 by bkil.hu...@gmail.com:

> 
>
>
> On Sun, Apr 28, 2019 at 11:44 AM Joseph Eisenberg <> 
> joseph.eisenb...@gmail.com > > wrote:
>
>> I've added a new section to the Verifiability wiki page about mapping
>>  features with ways or areas when these geometries are not verifiable.
>>

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Verifiability wiki page: "Geometry" section added

[bkil]




On Sun, Apr 28, 2019 at 11:44 AM Joseph Eisenberg <
joseph.eisenb...@gmail.com> wrote:

> I've added a new section to the Verifiability wiki page about mapping
> features with ways or areas when these geometries are not verifiable.
>
> This has been discussed here several times in the past few months, in
> regards to tags like natural=bay, natural=strait, place=*, and
> proposals like natural=mesa.
>
> Please suggest any improvements to the wording or corrections:
> https://wiki.openstreetmap.org/wiki/Verifiability#Geometry
>
> "Linear ways and areas can be non-verifiable if the geometry cannot be
> demonstrated to be true or false by another mapper.
>
> "For example, a valley can be thought to refer to the whole area
> between mountain ridges, or only to the flat bottom of the valley. In
> this case, drawing the natural=valley as an area will usually not be
> verifiable, because two different mappers would draw a very different
> geometry for the same feature. Many settlements have non-verifiable
> borders, especially in rural areas.
>
> "A place=hamlet often lacks verifiable borders. Hamlets in farming
> areas often have scattered houses and farms extending outward for
> several kilometers. In this case the approximate center of the place
> may be well-know, but the outer limits are not clearly determined, so
> mapping as an area is not verifiable.
>
> "A natural=ridge can be often be verifiably mapped as a linear way
> along the line of the ridge crest. It cannot be verifiably mapped as
> an area, because it would not be clear how far down the slopes the
> area of the ridge extends.
>
> "Many features which are not verifiable as ways or areas can be mapped
> with a single node near the center of the feature instead. In this
> case it can be agreed that this node is within the feature, even
> though the outer limits of the feature cannot be precisely
> determined."
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Verifiability wiki page: "Geometry" section added

[Joseph Eisenberg]

I've added a new section to the Verifiability wiki page about mapping
features with ways or areas when these geometries are not verifiable.

This has been discussed here several times in the past few months, in
regards to tags like natural=bay, natural=strait, place=*, and
proposals like natural=mesa.

Please suggest any improvements to the wording or corrections:
https://wiki.openstreetmap.org/wiki/Verifiability#Geometry

"Linear ways and areas can be non-verifiable if the geometry cannot be
demonstrated to be true or false by another mapper.

"For example, a valley can be thought to refer to the whole area
between mountain ridges, or only to the flat bottom of the valley. In
this case, drawing the natural=valley as an area will usually not be
verifiable, because two different mappers would draw a very different
geometry for the same feature. Many settlements have non-verifiable
borders, especially in rural areas.

"A place=hamlet often lacks verifiable borders. Hamlets in farming
areas often have scattered houses and farms extending outward for
several kilometers. In this case the approximate center of the place
may be well-know, but the outer limits are not clearly determined, so
mapping as an area is not verifiable.

"A natural=ridge can be often be verifiably mapped as a linear way
along the line of the ridge crest. It cannot be verifiably mapped as
an area, because it would not be clear how far down the slopes the
area of the ridge extends.

"Many features which are not verifiable as ways or areas can be mapped
with a single node near the center of the feature instead. In this
case it can be agreed that this node is within the feature, even
though the outer limits of the feature cannot be precisely
determined."

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Baby changing table

[bkil]

As a non-native speaker, I did need to look up bureau_de_change before
first using it back then, but it does not cause confusion for me
anymore. The most common word in Hungarian for this is "money
exchanger"/"money exchange" ("pénzváltó"/"pénzváltás"), and the clerks
usually sit at a desk behind a glass wall with a little opening or
bars, not around a table. Other words to describe this might be
"currency exchange booth" (probably a bit more official) or "cash
exchange window".

Our word for changing_table=* is something like "diaper changer
[place]" ("pelenkázó") or more like "a place where you change
diapers", the word itself weakly implicates a separate room, although
this should not cause confusion. Interestingly, the dictionary
definition suggests a translation "pelenkáz" = "changing the baby",
but the term itself does not narrow this down to babies and it is
applicable to all age groups.

Do you know a language where this could cause an issue for real?

On Fri, Apr 26, 2019 at 2:25 PM Martin Koppenhoefer
 wrote:
>
>
>
> sent from a phone
>
> > On 26. Apr 2019, at 11:52, Michael Brandtner via Tagging 
> >  wrote:
> >
> > I’m against the tag baby_changing_table. As I have already written, 
> > changing_table is unambiguous and the most common word for this thing. No 
> > need for such a long key.
>
>
> I’m not insisting, but I believe for non-natives the prefix would help. E.g. 
> it could be confused with exchange tables ;-)
>
> Cheers, Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging