Re: [Tagging] Annual Shows

[Warin]

Some questions... and observations.


On 28/2/20 10:48 am, John Willis via Tagging wrote:

I can’t see why we can’t create a simple tourism=outdoor_event pin at the 
location of the event and list it’s time in something like
event=seasonal/ date / existing time mapping, and could use admin_level for 
scale - and use additional tags ina relation for larger events or micromapping.


Why limited to outdoor only?



we have huge city / regional summer festivals in Japan that are held in the same place on 
the same day every year (some on the same calandar date "august 1-3" or on the 
same “first friday-sunday in August”. It would be easy to map the boundary and location 
of amenities and the extent of closures of the roads for the events, as they haven’t 
changed in decades.

A simple pin might be just fine for small seasonal outdoor events , mapping the 
extended details of the event should be expanded into a relation, such as a 
boarder of the known area (role=boundary), especially since for many outdoor 
events the areas and roads are “normal” most of the year.


Where an area has more than one event? Humm each one could be a separate 
relation with the same members.



normally mapped Ways & areas could be tagged with 
outdoor_event:highway=pedestrian or outdoor_event:amenity=parking (or whatever it 
is during the event) to show their role during the event - yet be mapped normally 
the rest of the time -  and added as regular members of the relation.
this would interfere the least with existing mapping.


I think existing mapping would ignore the tagging completely.



the tag scheme outdoor_event:foo=bar could be used on new pins/ways/areas to 
map any other “permanent” items of the event (stages, pavillions, parking, 
toilets, paths, etc) that are normally not present.

this would keep the “event” pobjects out of the regular map data until the 
event date could trigger the changed rendering if they wanted to support it. If 
renderers ignored that extended data, they could still render the tourism=event 
pin with the name of the event easily (and the boundary as well) - which would 
probably be enough for most events.


Renders will do what they want to do. Tagging should just present the data, 
hopefully in a usable way for both mappers and renders.

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

Re: [Tagging] Annual Shows

[John Willis via Tagging]

I can’t see why we can’t create a simple tourism=outdoor_event pin at the 
location of the event and list it’s time in something like
event=seasonal/ date / existing time mapping, and could use admin_level for 
scale - and use additional tags ina relation for larger events or micromapping. 

we have huge city / regional summer festivals in Japan that are held in the 
same place on the same day every year (some on the same calandar date "august 
1-3" or on the same “first friday-sunday in August”. It would be easy to map 
the boundary and location of amenities and the extent of closures of the roads 
for the events, as they haven’t changed in decades.  

A simple pin might be just fine for small seasonal outdoor events , mapping the 
extended details of the event should be expanded into a relation, such as a 
boarder of the known area (role=boundary), especially since for many outdoor 
events the areas and roads are “normal” most of the year. 

normally mapped Ways & areas could be tagged with 
outdoor_event:highway=pedestrian or outdoor_event:amenity=parking (or whatever 
it is during the event) to show their role during the event - yet be mapped 
normally the rest of the time -  and added as regular members of the relation. 
this would interfere the least with existing mapping. 

the tag scheme outdoor_event:foo=bar could be used on new pins/ways/areas to 
map any other “permanent” items of the event (stages, pavillions, parking, 
toilets, paths, etc) that are normally not present. 

this would keep the “event” pobjects out of the regular map data until the 
event date could trigger the changed rendering if they wanted to support it. If 
renderers ignored that extended data, they could still render the tourism=event 
pin with the name of the event easily (and the boundary as well) - which would 
probably be enough for most events. 


Javbw


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

Re: [Tagging] Clarify explicit abstention when voting on a proposal

[Paul Allen]

On Thu, 27 Feb 2020 at 18:56, Markus  wrote:

> On Thu, 27 Feb 2020 at 15:06, Paul Allen  wrote:
> >
> > However, despite the option being labelled an abstention, it is NOT an
> abstention.
> > Technically, it is a "spoiled ballot."  Spoiled ballots DO contribute to
> a quorum in
> > most voting systems. [...]
>
> Really? Wikipedia says [1]:
>
> In voting, a ballot is considered spoilt, spoiled, void, null,
> informal, invalid or stray if a law declares or an election authority
> determines that it is invalid and thus **not included in the vote
> count**.
>

Wikipedia is not noted for its consistency.  From
https://en.wikipedia.org/wiki/Abstention

Abstentions do not count in tallying the vote negatively or positively;
when members abstain, they are in effect attending only to contribute to a
quorum . White votes, however, may be
counted in the total of votes, depending on the legislation.

Note that abstentions can only contribute to a quorum in things like
parliamentary
votes where people are required to attend.  As far as ordinary voters in
elections
go, there may be no requirement to attend or vote (depending on
legislation) and
no quorum.

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

Re: [Tagging] Clarify explicit abstention when voting on a proposal

[Markus]

On Thu, 27 Feb 2020 at 15:06, Paul Allen  wrote:
>
> However, despite the option being labelled an abstention, it is NOT an 
> abstention.
> Technically, it is a "spoiled ballot."  Spoiled ballots DO contribute to a 
> quorum in
> most voting systems. [...]

Really? Wikipedia says [1]:

In voting, a ballot is considered spoilt, spoiled, void, null,
informal, invalid or stray if a law declares or an election authority
determines that it is invalid and thus **not included in the vote
count**.

[1]: https://en.wikipedia.org/wiki/Spoilt_vote

I can confirm this for Switzerland (for elections and votings by the
people and in the parliaments).

> As I see it, we have three options:
>
> 1. Treat it as an abstention, and continue to call it an abstention.  It does
> not count towards the quorum.  In which case it should appear separately
> from the yes/no votes (or at least placed before yes/no votes) to avoid 
> confusion.
> The talk page would theoretically be the best place for abstentions, but
> practically would mean that any points raised would be less likely to be
> seen by other voters.  Approval would be based on total yes/no votes
> and ratio of yes to no votes.

+1 for option 1

Markus aka SelfishSeahorse

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

Re: [Tagging] Feature Proposal - RFC - Food sharing

[Hauke Stieler]

Hi,

sometimes people just use boxes or the basket of an old bicycle for food
sharing purposes. Because they are usually not inside a building or
something, I would add the "covered=*" tag to your list.

I also would use the "contact:*" keys (for the website, facebook, other
social media channels, etc.). The "contact:facebook" key is also used
more often and I personally like the contact scheme. Some boxed may also
have other contact options (email, phone, instagram, twitter, ...). I
know the whole contact-scheme-thing might end up in a large discussion,
but I just wanted to mention it.

But the general proposal looks good, the tagging is simple and
everything is straight forward :)

Hauke

On 26.02.20 09:47, Markus Peloso wrote:
> https://wiki.openstreetmap.org/wiki/Proposed_features/food_sharing
> 
>  
> 
> «A shelf/box/fridge where people drop off and pick up food in the sense
> of free sharing and/or to reduce food waste.»
> 
>  
> 
> Hi
> 
>  
> 
> I added the current proposal for food sharing I made to the wiki.
> 
>  
> 
> What do you think about it?
> 
>  
> 
> Best regards
> 
> Markus
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
> 



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Clarify explicit abstention when voting on a proposal

[Paul Allen]

On Thu, 27 Feb 2020 at 08:34, Martin Koppenhoefer 
wrote:

>
> I see, so now the abstentions will not count for the voting result in any
> way, not even for the quorum.
>

That is the technical meaning of "abstention."
https://en.wikipedia.org/wiki/Abstention
An abstention is when no vote is cast even though one has the opportunity
to do so.
Many readers of this list abstain from one vote or another.  An abstention,
in the
technical meaning, cannot contribute to the quorum (except in a voting
system where
physical attendance is required, such as parliamentary votes).

However, despite the option being labelled an abstention, it is NOT an
abstention.
Technically, it is a "spoiled ballot."  Spoiled ballots DO contribute to a
quorum in
most voting systems.  If we treat it as a spoiled ballot, we get a
different result
if we set the approval bar as the ratio of yes to no votes or as the ratio
of yes
votes to the quorum.

As I see it, we have three options:

1. Treat it as an abstention, and continue to call it an abstention.  It
does
not count towards the quorum.  In which case it should appear separately
from the yes/no votes (or at least placed before yes/no votes) to avoid
confusion.
The talk page would theoretically be the best place for abstentions, but
practically would mean that any points raised would be less likely to be
seen by other voters.  Approval would be based on total yes/no votes
and ratio of yes to no votes.

2. Treat it as a spoiled ballot, and give it a name other than "abstention"
(maybe "comment").  It DOES contribute to the quorum.  Approval would
be based on total number of votes (yes/no/spoiled) and ratio of yes to
no + spoiled votes.

3.  Continue with the current confusion (or invent new confusion) where
"abstain" is neither fish nor fowl.  Those assuming "abstain" has its
technical interpretation will sometimes be surprised by the outcome
of a vote.

There are probably other options, too.

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

Re: [Tagging] man_made=gas_well Was man_made=petroleum_well vs man_made=pumping_rig

[François Lacombe]

Le jeu. 27 févr. 2020 à 08:34, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> a écrit :

>
> +1 There are some ultra-deep drillings for water, but are functionally
> different both from water well and petroleum wells.
>
> Single tag for petroleum wells and water wells seems to me
> an overgeneralizing of presets.
>

I feel a bit uncomfortable with such hypothesis: a single word to deal with
two apparently different things doesn't sound as an overgeneralizing of
language.

Note that I'd rather agree (depending on man_made values chosen) on
distinguishing between "open" wells to collect fluids with buckets located
just under the surface and digged wells to collect (eventually pressurized)
fluids.
My point is to not add substance indication in man_made values as wells
structure doesn't depend on collected fluid but on geology and environment
(and substance goes in existing and established substance=* key with
appropriate validation and documentation)

All the best

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

Re: [Tagging] Sorting waterway relations?

[Colin Smale]

On 2020-02-27 10:04, Mateusz Konieczny via Tagging wrote:

> 27 Feb 2020, 09:55 by colin.sm...@xs4all.nl: 
> 
>> If it was semantically important, we should be scanning for and flagging up 
>> waterways with out-of-order ways.The fact that we are not, shows that the 
>> ordering of the ways is not essential for a correct geometrical 
>> interpretationQED
> 
> This proof assumes that OSM validators 
> are completed and detecting all possible 
> semantic issues. 
> 
> This is not true, just look at 
> JOSM/osmose/iD issue tracker, every 
> one has plenty of open issues suggesting 
> new validator checks.

I'm sure there are thousands of ideas for validators. But this one has
apparently never been thought important enough - if it is indeed buried
in the issue trackers somewhere. Anyway, the validators should ideally
follow the agreed rules, not create them. 

>> it is possible that re-ordering the members of one relation, causes the 
>> members of another relation to become out-of-order.
> 
> Why reordering members in one relation would 
> reorder members of other relation?

You are right, I retract this statement. Sorry, I hadn't thought it
through and was thinking of the order of the nodes in a way.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] man_made=gas_well Was man_made=petroleum_well vs man_made=pumping_rig

[Steve Doerr]

On 26/02/2020 23:22, Joseph Eisenberg wrote:

According to these sources, the term "petroleum" can include both
natural gas and crude oil:


Someone had better tell the Oxford English Dictionary they've got it 
wrong then:


'petroleum, n. [..] A viscous liquid, consisting chiefly of a mixture of 
hydrocarbons and varying in colour from black or dark brown to light 
yellow, that is formed by the decomposition of organic matter buried in 
sediments, is present in some rock formations (sometimes seeping out on 
to the ground), and is extracted and refined to produce fuels (esp. 
petrol, paraffin, and diesel) and other substances; mineral oil.'


--
Steve


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

Re: [Tagging] Sorting waterway relations?

[Mateusz Konieczny via Tagging]

27 Feb 2020, 09:55 by colin.sm...@xs4all.nl:

>
> If it was semantically important, we should be scanning for and flagging up 
> waterways with out-of-order ways.> The fact that we are not, shows that the 
> ordering of the ways is not essential for a correct geometrical 
> interpretationQED
>
>
This proof assumes that OSM validators
are completed and detecting all possible
semantic issues.

This is not true, just look at 
JOSM/osmose/iD issue tracker, every
one has plenty of open issues suggesting
new validator checks.


>  it is possible that re-ordering the members of one relation, causes the 
> members of another relation to become out-of-order.
>
Why reordering members in one relation would
reorder members of other relation?___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] man_made=gas_well Was man_made=petroleum_well vs man_made=pumping_rig

[Martin Koppenhoefer]

Am Do., 27. Feb. 2020 um 01:33 Uhr schrieb Joseph Eisenberg <
joseph.eisenb...@gmail.com>:

> > Christmas trees are intended to regulate the well pressure or manage
> filling product injection to raise field pressure.
> > You'll find them independently on oil or water wells depending on the
> pressure.
>
> Very few water wells have high enough pressure to require such a
> device. 99.9% of water wells are a few meters to a few tens of meters
> deep, and most of those that are mapped in Openstreetmap are in
> low-income countries where they will have a manual pump on top, or a
> bucket that goes into a hand-dug well.
>


pumps and buckets are typical for all smaller water wells, and from looking
at the map, it doesn't seem a tag that is used more in lower income
countries than in richer countries.
https://taginfo.openstreetmap.org/tags/man_made=water_well#map
Water wells are typical for all areas where the people want or have to be
independent from the public water supplies (e.g. in private gardens where
the public aqueduct is too far away), or where it is the only source of
water (no aqueducts).



>
> Tags in Openstreetmap are designed by ordinary people for mapping the
> usual situation. They do not need to cover the 0.1% of cases that are
> strange exceptions or outliers.
>


tags in OSM are designed to be universally applicable. A tag for a water
well would usually apply to all kinds of water wells, including those with
higher pressure and regulating devices, unless it would have been excluded
in the definition (or we all agree that it is fundamentally differerent and
not covered by the definition / expectation).
The current water well definition states: "A water well is a structural
facility created to access ground water from an aquifer. It is a vertical
or sometimes horizontal excavation, shaft or structure created in the
ground by digging, driving, boring or drilling. The subsurface water is
usually drawn by pumping or raising containers, such as buckets."
so it seems it would apply to the above wells as well.

Note that it says "to access", which would IMHO include accessing water for
monitoring it, rather than extracting it. Do you agree?

It also says: "from an aquifer", which seems to include deep aquifers, but
then mentions "subsurface" which is a term I would usually understand as
close to the surface (or am I misguided)?

https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dwater_well




>
> "The same applies on geothermal wells with substance=steam or
> substance=water + utility=heating
>
> https://www.slb.com/drilling/rigs-and-equipment/wellhead-systems/geothermal-wellhead-system
> "
>
> I agree, and I would not use man_made=water_well for a geothermal
> energy facility.



+1, I agree, because the intention is not to get water but to get heat.

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

Re: [Tagging] Sorting waterway relations?

[Colin Smale]

On 2020-02-27 01:47, Joseph Eisenberg wrote:

> When you make or sort a relation of type=waterway, do you check if the
> source or mouth of the river is first on the list of ways?
> 
> Another user just suggested that the spring/source of the waterway
> should start the list, then the mouth of the river at the ocean (or
> where it empties into a larger waterway) should be last. This practice
> has not been followed in the areas where I have mapped.
> 
> https://wiki.openstreetmap.org/wiki/Talk:Relation:waterway#Sort_order.3F
> 
> Is this done in your area?

In general there is no real need to sort the members as the geometry can
be reconstructed by chaining the end nodes. If it was semantically
important, we should be scanning for and flagging up waterways with
out-of-order ways. The fact that we are not, shows that the ordering of
the ways is not essential for a correct geometrical
interpretationQED 

As a consequence of some mappers desire to share ways between relations
of unrelated types (e.g. waterway and admin boundary) it is possible
that re-ordering the members of one relation, causes the members of
another relation to become out-of-order. If we all use separate ways
with shared nodes, the relations can be re-ordered without causing
collateral damage. 

It is accepted that a way has a direction, which is sometimes
semantically significant (water flow direction, one-way streets etc) and
sometimes not. Getting the ways into a particular order is of course a
different subject to pointing the way in the right direction. Once again
I appeal to mappers to use separate ways (with shared nodes) for
different concepts, even if they are co-linear, to allow for the
direction of the ways to mean different things in different contexts.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] man_made=gas_well Was man_made=petroleum_well vs man_made=pumping_rig

[Martin Koppenhoefer]

Am Do., 27. Feb. 2020 um 00:23 Uhr schrieb Joseph Eisenberg <
joseph.eisenb...@gmail.com>:

> Different tags are used for petroleum wells vs water wells because
> they look totally different



do they? Have a look at this short clip that shows a water well:
https://www.youtube.com/watch?v=2lkoCCCQytc




> and their function for the general map
> user is quite distinct.



indeed




>
> An oil or gas well has a fire-hydrant like structure on top called a
> "Christmas tree" or a pumping rig like a "pump jack" - you will not
> mistake them for a water well.
>


You will use a pump jack for the extraction of liquids, so I would say
their presence will exclude a gas-only well.



>
> According to these sources, the term "petroleum" can include both
> natural gas and crude oil:
>
>
> http://energy4me.org/all-about-energy/what-is-energy/energy-sources/petroleum/
>
> "Oil and natural gas together make petroleum. Petroleum, which is
> Latin for rock oil, is a fossil fuel, meaning it was made naturally
> from decaying prehistoric plant and animal remains. It is a mixture of
> hundreds of different hydrocarbons molecules containing hydrogen and
> carbon that exist sometimes as a liquid (crude oil) and sometimes as a
> vapor (natural gas)."
>
> https://www.appea.com.au/oil-gas-explained/oil-and-gas/what-is-petroleum/
>
> "Petroleum is a general term for oil and natural gas."
>
> So a man_made=petroleum_well is a natural gas or crude oil well, but
> many (most?) petroleum wells produce both oil and gas.
>


this is fine, so we already have it structured nicely ;)
For oil wells, gas will usually also be extracted (but not always used),
but for gas only wells we could have a subtag to man_made=petroleum_well
Is there something in use? Otherwise we would be loosing information
compared to man_made=gas_well.

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

Re: [Tagging] Clarify explicit abstention when voting on a proposal

[Martin Koppenhoefer]

Am Do., 27. Feb. 2020 um 08:34 Uhr schrieb Andrew Davidson <
thesw...@gmail.com>:

> On Thu, 27 Feb. 2020, 08:22 Martin Koppenhoefer, 
> wrote:
>
>>
>> can you explain with the amended rules what the outcome would be for
>>
>> 8 votes yes, 0 no, 1 abstention
>>
>
> That is 8 unanimous approval votes so it is passed.
>
> 8 votes yes, 1 no, 1 abstention
>
>
> Didn't reach the required quorum of 10 votes for a majority based count so
> not passed.
>
> 8 yes, 2 no and any number of abstentions would be passed.
> 8 yes, 3 no would not pass.
>



I see, so now the abstentions will not count for the voting result in any
way, not even for the quorum.
Is this a shared interpretation?

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