Re: [Tagging] Deprecate water=pond?

[Joseph Eisenberg]

If anyone wants to map beaver dams, I would suggest natural=beaver_dam
since this would use a common key ("natural") rather than inventing a new
one.

-- Joseph Eisenberg

On Sat, Nov 14, 2020 at 11:10 AM Tom Pfeifer  wrote:

> beaver_made = dam ?
>
> On 14.11.2020 04:02, Kevin Kenny wrote:
> > On Thu, Nov 12, 2020 at 6:22 PM Adam Franco  > wrote:
> >
> >   * origination:natural=beavers
> >
> > Thanks for remembering this one. Around here, beavers are a significant
> sculpting force on the
> > landscape.
> >
> > (And `man_made=dam` is the best tagging that we have for their water
> control structures, which are
> > also often adjusted seasonally)
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - electricity=*

[stevea]

Outstanding!  Here we see Lucas well-separating "meaning spaces" apart at the 
same time he's both looking towards the future as he offers others to sensibly 
extend the table given the structure he has started it with.  Bravo, sir.  Good 
things grow like this, with all the right ingredients in the mix to make it a 
future namespace and tagging scheme we can be proud of:  sensible, concise, 
tag-as-much-as-we-know-now (while there also being structure if there ARE more 
things we know and so can tag specifically).

The 21st century ahead for electricity.  Wow, that's an exciting place we 
imagine in many ways and we don't quite know now how it will unfold.  Tag what 
we know.  Sometimes some restructure happens.

I don't mind that we spell out our good methods as we go about making them.  
Sometimes simply agreeing on the specifics of our intentions (out loud) is a 
good idea.  There are all kinds of good examples in OSM already.

Map well.  I see Lucas mapping well and I am grateful to participate in the 
conversation.  So glad to see things vetted among others.

On Nov 14, 2020, at 5:43 PM, Lukas Richert  wrote:
> I was actually thinking of the type of battery, i.e. flywheel, LiOn, etc. 
> Although it would probably also be interesting to figure out a tagging scheme 
> to classify batteries by type, capacity etc. for the future. And it's true 
> that :grid, :generator, and :battery as second namespaces are redundant if 
> the source keys can be restricted to only being usable if the corresponding 
> infrastructure key is used. 
> 
> The only issue I see with separating the tagging like this if the general 
> source of electricity is advertised (e.g. 'renewable' in a supermarket and 
> you can't determine if that's because they're connected to the grid or they 
> have a small wind turbine out back..rather unlikely but still). I think that 
> it's likely easy to tell or would also be advertised if they had a local 
> generator. Or perhaps would then have to be left untagged.
> 
> If you'd like to add such a table to the wiki, feel free! :)


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

Re: [Tagging] Feature Proposal - RFC - electricity=*

[Lukas Richert]

Hi,

I was actually thinking of the type of battery, i.e. flywheel, LiOn, 
etc. Although it would probably also be interesting to figure out a 
tagging scheme to classify batteries by type, capacity etc. for the 
future. And it's true that :grid, :generator, and :battery as second 
namespaces are redundant if the source keys can be restricted to only 
being usable if the corresponding infrastructure key is used.


The only issue I see with separating the tagging like this if the 
general source of electricity is advertised (e.g. 'renewable' in a 
supermarket and you can't determine if that's because they're connected 
to the grid or they have a small wind turbine out back..rather unlikely 
but still). I think that it's likely easy to tell or would also be 
advertised if they had a local generator. Or perhaps would then have to 
be left untagged.


If you'd like to add such a table to the wiki, feel free! :)

Best regards,

Lukas

On 15.11.20 01:49, François Lacombe wrote:

Lukas,

Le sam. 14 nov. 2020 à 21:00, Lukas Richert > a écrit :


Hi François,

I do actually like the word input for generator and have been
thinking that 'battery:origin' makes no sense either to specify
the type of origin. Keys such as 'electricity:grid:origin=*',
'electricity:generator:input=*', and 'electricity:battery:type=*'
would be more distinct and would separate them. My only problem
with that is that the wikipage would probably need a flowchart to
explain the tagging :/ What do you think?

That's an interesting point.
Do you mean electricity:battery:type should refer to the source of 
electricity that feeds the battery?
Let's keep in mind that batteries are probably charged with the same 
electricity used in place.
It won't change anything regarding origin or local supply source 
quality (electricity won't become greener).


I think electricity:origin is enough, no need to add :grid inside but 
only restrict its usage with electricity:grid=yes, for sake of simplicity.


With a simpler origin definition, a table would be enough.
A table similar to Infrastructure table could be completed to give the 
applicable tagging suitable for each Infrastructure situation


Let me know how do you feel and I could try to propose something for 
this table


All the best

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

Re: [Tagging] Feature Proposal - RFC - electricity=*

[François Lacombe]

Lukas,

Le sam. 14 nov. 2020 à 21:00, Lukas Richert  a écrit :

> Hi François,
>
> I do actually like the word input for generator and have been thinking
> that 'battery:origin' makes no sense either to specify the type of origin.
> Keys such as 'electricity:grid:origin=*', 'electricity:generator:input=*',
> and 'electricity:battery:type=*' would be more distinct and would separate
> them. My only problem with that is that the wikipage would probably need a
> flowchart to explain the tagging :/ What do you think?
>
That's an interesting point.
Do you mean electricity:battery:type should refer to the source of
electricity that feeds the battery?
Let's keep in mind that batteries are probably charged with the same
electricity used in place.
It won't change anything regarding origin or local supply source quality
(electricity won't become greener).

I think electricity:origin is enough, no need to add :grid inside but only
restrict its usage with electricity:grid=yes, for sake of simplicity.

With a simpler origin definition, a table would be enough.
A table similar to Infrastructure table could be completed to give the
applicable tagging suitable for each Infrastructure situation

Let me know how do you feel and I could try to propose something for this
table

All the best

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

Re: [Tagging] How to tag a threshing floor

[António Madeira via Tagging]

Wiki created:
https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dthreshing_floor

Please comment and/or edit accordingly.


Às 17:53 de 12/11/2020, António Madeira via Tagging escreveu:

Thank you, Joseph.

If no one opposes, I'll do just that.
Regards.


Às 16:43 de 12/11/2020, Joseph Eisenberg escreveu:

Since the tag man_made=threshing_floor has already been used 7 times
(https://taginfo.openstreetmap.org/search?q=threshing_floor#values)
you can create a page to document this, however, you would also need
to mention that historic=threshing_floor is much more common
(actually landuse=threshing_floor is also equally common), and it
would probably be fair to create a historic=threshing_floor wiki page
too, in that case.

If you want to suggest deprecating historic=threshing_floor and
replacing it with man_made=threshing_floor, or otherwise changing
existing common usage, you should make a proposal so that the
community can discuss this.

-- Joseph Eisenberg

On Wed, Nov 11, 2020 at 2:53 PM António Madeira via Tagging
mailto:tagging@openstreetmap.org>> wrote:

So, given that most of those who commented this thread agreed
that threshing_floor should be in the man_made scheme, should I
add it to the wiki or create a Feature Proposal?


Às 19:27 de 06/11/2020, Paul Allen escreveu:

On Fri, 6 Nov 2020 at 21:53, Martin Koppenhoefer
mailto:dieterdre...@gmail.com>> wrote:

Am Fr., 6. Nov. 2020 um 13:56 Uhr schrieb Paul Allen
mailto:pla16...@gmail.com>>:

On Fri, 6 Nov 2020 at 09:09, Martin Koppenhoefer
mailto:dieterdre...@gmail.com>>
wrote:

...

To me it doesn't make sense to draw a line, dividing
the same objects having more or less historic value.
If there is something to distinguish at all, my
suggestion would be to add a qualifier to those
objects of exceptional historical value (if this is
verifiable).


We have a way of tagging objects of exceptional
historical value, it's
historic=*.  Objects of unexceptional historical value,
or of no historical
value do not get tagged with historic=*.  That's because
historic is
not a synonym (in the real world or in tagging) for old,
disused or
repurposed.


just that it is not what we are currently doing.

That is not what some of us are currently doing.  Others read
the wiki page
and tag accordingly.

It occurs to me that some of the mis-tagging (as I see it) and
some of the
discussions here may revolve around semantics as interpreted by
those who do not have English as a first language.  There is a
difference between "historical" and "historic."

Historians are concerned with historical data. Old data (about
populations, diseases or whatever) is historical data.  The
assassination of a minor archduke, which seemed unimportant
at the time, quickly turned into a historic event.

When somebody says that "historic" applies to everything that
historians do, that is incorrect.  What historians mostly do is
look at historical data, some small fraction of which is
also historic.

See https://www.grammarly.com/blog/historic-historical/
for a better explanation.

So historic=* really should only apply (as the wiki page states)
to the important
things of the past, not everything some random historian might
happen
to be looking into.

So the question is, do we accept that because some mappers have
misused
the tag we should encourage that misuse or do we discourage it?

--
Paul


___
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 mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging



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


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

Re: [Tagging] Feature Proposal - RFC - electricity=*

[stevea]

Lukas:  Yes, I agree it seems like you are on a good track to thinking through 
the structure (of electricity and how it might be better / best tagged) in a 
deeper way that will allow you to design a robust syntax (tagging) for 
electricity.  However, whether this initial sketch is something that "should 
completely cover all cases..." really falls into the category of "only time 
will tell!"  It's good to be hopeful about one's own designs meeting present 
and future requirements, though it is much better to get other eyes on it (like 
you do here, and why our proposal process exists) so that you might enjoy the 
benefits of crowdsourcing, even when that is the sometimes head-scratching work 
of designing strong, sensible tagging.

I appreciate that you reflect back to the list here that deep thought about a 
rich, full world of possibilities for many, most or even all aspects of the 
semantics that you hope for the syntax to capture is a serious requirement for 
the development of good tagging schemes going forward in OSM.  May all of us 
who develop tags (whether with formal proposals or not by using free-form 
tagging that hasn't been used in OSM before) take the same care to design 
well-constructed syntax / tagging schemes.  Our map data deserve the most crisp 
syntax, fully devoid of ambiguity, that we are able to devise.

SteveA

On Nov 14, 2020, at 9:20 AM, Lukas Richert  wrote:
> I've been thinking more about this and I think the subkeys grid, generator 
> and battery should cover any conceivable method (for now!) to acquire 
> electricity. So a grid is any collection of multiple 
> generators/batteries/substations/transformers, a generator is a device that 
> locally produces electricity and a battery (either chemical or mechanical) is 
> something that locally stores energy for later usage. 
> 
> The possible values for any of these subkeys is then yes/backup/no (i.e. 
> electricity:battery=no), where yes means the device/grid is always connected 
> and it is usually (daily?) used. The term backup then means that the device 
> is only used when the usual device reaches its capacity or fails, so it is 
> not always on/connected. The type of backup, be it UPS or stand-by, and the 
> length of time that it can keep systems running could then also be tagged. To 
> specify exactly which devices are kept running it might then be useful to 
> have a relation-tagging scheme for circuits but I think this would be outside 
> the scope of the electricity tag which should only note the presence of the 
> systems in a building/amenity. This could then be a flag for e.g. firemen. 
> The term no would then just mean that the specified building amenity does not 
> have a grid/generator/battery. If it's unknown, it should be left untagged.
> 
> I think this should completely cover all cases of buildings having 
> electricity? and the specific tagging for backup systems could then be 
> discussed separately. And if a new method of acquiring electricity is 
> introduced (wireless charging?) it could be easily added to the current 
> tagging.



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

Re: [Tagging] Feature Proposal - RFC - electricity=*

[Lukas Richert]

Hi François,

I do actually like the word input for generator and have been thinking 
that 'battery:origin' makes no sense either to specify the type of 
origin. Keys such as 'electricity:grid:origin=*', 
'electricity:generator:input=*', and 'electricity:battery:type=*' would 
be more distinct and would separate them. My only problem with that is 
that the wikipage would probably need a flowchart to explain the tagging 
:/ What do you think?


Regards, Lukas

On 14.11.20 20:07, François Lacombe wrote:

Thank you Lukas for answers

Le sam. 14 nov. 2020 à 17:56, Lukas Richert > a écrit :


Hi François,

the combination of electricity:grid=yes with either
electricity:origin=* or electricity:grid:origin=* would point to
the origin being only about financial flows as advertised
on-the-ground.

Agree with that.
electricity:grid:origin isn't part of the proposal, will we have to 
approve it?


For the purpose of filtering out amenities, e.g. charging
stations, that only use 'green' electricity it is still useful to
tag electricity:origin=* or electricity:generator:origin=* in
combination with electricity:generator=yes.

Don't agree with that :)
This filtering won't be accurate at all and will encourage people to 
think claimed origin through a power grid is equivalent to certainty 
of locally obtained electricity (which isn't)
I'm clearly against any association between a generator device and 
'origin' word. electricity:origin should relate to grid/market only 
and remain a claim with no physical reality.


Alternatively, there would need to be a tagged relation to the
specific generator and the end users it supplies which would be
considerably harder to query and many OSM editers seem to find
relations confusing. Therefore, I think the slight bit of
redundancy is useful to explicitly tag this on the amenity.

Understood, that would enable to check consistency as well.

Furthermore, the word 'origin' is used, not only to avoid two tags
with very similar meanings that can be easily distinguished by
combination with the infrastructure tag

I respectfully disagree, they don't have a similar meaning in many 
situations.
Merging both in a single key will only be accurate when the claim is 
equivalent to local production which isn't necessary: you buy solar 
energy and backup with diesel more often than backup with solar.


, but also since 'electricity:source' would then have a double
meaning with 'the survey/map/place where the knowledge of the
electricity was obtained', which is apparently a problem for some
other tags using source as a keyword.

i'm currently thinking about refine generator:* subkeys and it's sure 
this discussion will be really inspiring.

Indeed source should be avoided and I keep that in mind.
In power context "source" refers to inputs and as we already have 
generator:output, why shouldn't we have generator:input?

generator:input=wind
input:wind=X kW
output:electricity= Y kW

All the best

François

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

Re: [Tagging] Feature Proposal - RFC - electricity=*

[Lukas Richert]

Hi Paul,

I'm not quite sure if I correctly understood what you meant, so 
correct/explain more if I get it wrong! My sole goal with the 
infrastructure part of the tagging is to specify if a connection exists 
sometimes, always or never. In the case of solar panels, even though 
they don't produce electricity at night, they are always connected so 
the building would then be tagged as 'electricity:generator=yes'.


So far, I've not even attempted to incorporate the method with which the 
generator is connected to the grid (if there is a connection). If think 
for that it would be easiest to have a separate tag. Overall, I think I 
mean to only generally cover all cases, but perhaps with not as much 
detail as you envision. I think that needs more and different tags to 
keep things clear.


As to the electric vehicles, I think it would be fine to then tag 
electricity:battery=yes and then have a separate tag like 
battery:type=electric_vehicle or some such.


Cheers, Lukas

On 14.11.20 18:43, Paul Allen wrote:
On Sat, 14 Nov 2020 at 17:24, Lukas Richert > wrote:


The possible values for any of these subkeys is then yes/backup/no
(i.e. electricity:battery=no), where *yes *means the device/grid
is always connected and it is usually (daily?) used. The term
*backup* then means that the device is only used when the usual
device reaches its capacity or fails, so it is not always
on/connected.


I'm not committing to supporting or opposing this scheme, just 
bikeshedding.

But it's a BIG bikeshed.

It isn't as simple as your tagging scheme makes out.

A photovoltaic system for a house may charge batteries, which come into
play when there is no sun (it's night or it's too cloudy).  There is 
no grid

connection at all.

A photovoltaic system for a house may provide electricity when it can,
with the grid providing electricity when the photovoltaic system cannot.
There are no batteries involved.

A photovoltaic system for a house not only provides electricity for the
house, it also feeds electricity into the grid (for which the owner gets
a rebate on the bill) with the grid supplying power when the
photovoltaic system cannot.  There are no batteries involved.

As either of the preceding two cases, but with batteries also involved.

Electric vehicles may be used as storage capacity for the grid.  When
they're on charge (usually at night) they may supply power to the
grid to cope with brief increases in demand (people putting the
kettle on during TV adverts).  I don't know if any current systems
do so, but it would be possible for the car to provide household
electricity for a while during a power outage.

I've probably missed something.  Your tagging either needs to
cover less cases or more.

--
Paul

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

Re: [Tagging] Feature Proposal - RFC - electricity=*

[François Lacombe]

Thank you Lukas for answers

Le sam. 14 nov. 2020 à 17:56, Lukas Richert  a écrit :

> Hi François,
>
> the combination of electricity:grid=yes with either electricity:origin=*
> or electricity:grid:origin=* would point to the origin being only about
> financial flows as advertised on-the-ground.
>
Agree with that.
electricity:grid:origin isn't part of the proposal, will we have to approve
it?

> For the purpose of filtering out amenities, e.g. charging stations, that
> only use 'green' electricity it is still useful to tag electricity:origin=*
> or electricity:generator:origin=* in combination with
> electricity:generator=yes.
>
Don't agree with that :)
This filtering won't be accurate at all and will encourage people to think
claimed origin through a power grid is equivalent to certainty of locally
obtained electricity (which isn't)
I'm clearly against any association between a generator device and 'origin'
word. electricity:origin should relate to grid/market only and remain a
claim with no physical reality.

> Alternatively, there would need to be a tagged relation to the specific
> generator and the end users it supplies which would be considerably harder
> to query and many OSM editers seem to find relations confusing. Therefore,
> I think the slight bit of redundancy is useful to explicitly tag this on
> the amenity.
>
Understood, that would enable to check consistency as well.

> Furthermore, the word 'origin' is used, not only to avoid two tags with
> very similar meanings that can be easily distinguished by combination with
> the infrastructure tag
>
I respectfully disagree, they don't have a similar meaning in many
situations.
Merging both in a single key will only be accurate when the claim is
equivalent to local production which isn't necessary: you buy solar energy
and backup with diesel more often than backup with solar.

> , but also since 'electricity:source' would then have a double meaning
> with 'the survey/map/place where the knowledge of the electricity was
> obtained', which is apparently a problem for some other tags using source
> as a keyword.
>
i'm currently thinking about refine generator:* subkeys and it's sure this
discussion will be really inspiring.
Indeed source should be avoided and I keep that in mind.
In power context "source" refers to inputs and as we already have
generator:output, why shouldn't we have generator:input?
generator:input=wind
input:wind=X kW
output:electricity= Y kW

All the best

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

Re: [Tagging] Deprecate water=pond?

[Tom Pfeifer]

beaver_made = dam ?

On 14.11.2020 04:02, Kevin Kenny wrote:

On Thu, Nov 12, 2020 at 6:22 PM Adam Franco mailto:adamfra...@gmail.com>> wrote:

  * origination:natural=beavers

Thanks for remembering this one. Around here, beavers are a significant sculpting force on the 
landscape.


(And `man_made=dam` is the best tagging that we have for their water control structures, which are 
also often adjusted seasonally)


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

Re: [Tagging] Feature Proposal - RFC - electricity=*

[Paul Allen]

On Sat, 14 Nov 2020 at 17:24, Lukas Richert  wrote:

The possible values for any of these subkeys is then yes/backup/no (i.e.
> electricity:battery=no), where *yes *means the device/grid is always
> connected and it is usually (daily?) used. The term *backup* then means
> that the device is only used when the usual device reaches its capacity or
> fails, so it is not always on/connected.
>

I'm not committing to supporting or opposing this scheme, just bikeshedding.
But it's a BIG bikeshed.

It isn't as simple as your tagging scheme makes out.

A photovoltaic system for a house may charge batteries, which come into
play when there is no sun (it's night or it's too cloudy).  There is no grid
connection at all.

A photovoltaic system for a house may provide electricity when it can,
with the grid providing electricity when the photovoltaic system cannot.
There are no batteries involved.

A photovoltaic system for a house not only provides electricity for the
house, it also feeds electricity into the grid (for which the owner gets
a rebate on the bill) with the grid supplying power when the
photovoltaic system cannot.  There are no batteries involved.

As either of the preceding two cases, but with batteries also involved.

Electric vehicles may be used as storage capacity for the grid.  When
they're on charge (usually at night) they may supply power to the
grid to cope with brief increases in demand (people putting the
kettle on during TV adverts).  I don't know if any current systems
do so, but it would be possible for the car to provide household
electricity for a while during a power outage.

I've probably missed something.  Your tagging either needs to
cover less cases or more.

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

Re: [Tagging] Feature Proposal - RFC - electricity=*

[Lukas Richert]

Hi Steve,

I've been thinking more about this and I think the subkeys grid, 
generator and battery should cover any conceivable method (for now!) to 
acquire electricity. So a *grid* is any collection of multiple 
generators/batteries/substations/transformers, a *generator* is a device 
that locally produces electricity and a *battery* (either chemical or 
mechanical) is something that locally stores energy for later usage.


The possible values for any of these subkeys is then yes/backup/no (i.e. 
electricity:battery=no), where *yes *means the device/grid is always 
connected and it is usually (daily?) used. The term *backup* then means 
that the device is only used when the usual device reaches its capacity 
or fails, so it is not always on/connected. The type of backup, be it 
UPS or stand-by, and the length of time that it can keep systems running 
could then also be tagged. To specify exactly which devices are kept 
running it might then be useful to have a relation-tagging scheme for 
circuits but I think this would be outside the scope of the electricity 
tag which should only note the presence of the systems in a 
building/amenity. This could then be a flag for e.g. firemen. The term 
*no* would then just mean that the specified building amenity does not 
have a grid/generator/battery. If it's unknown, it should be left untagged.


I think this should completely cover all cases of buildings having 
electricity? and the specific tagging for backup systems could then be 
discussed separately. And if a new method of acquiring electricity is 
introduced (wireless charging?) it could be easily added to the current 
tagging.


Regards,

Lukas

On 12.11.20 02:15, Lukas Richert wrote:
If it's unclear I would just leave electricity:grid untagged as 
there's no way to know if it's yes or no (another advantage of the 
namespace tagging). In some areas, I think one could relatively safely 
assume that if all other houses are connected to the grid, that one 
likely is too. However,  Tagging the presence of a generator is 
definitely easier to see and would be more important for firefighters 
to know (islanding).


Mostly I would probably say that the vast majority of private houses 
probably don't need to be tagged in this detail and it definitely is 
they type of information I've seen advertised at hotels and camp sites 
where one wouldn't have to get all creepy to figure it out.


Also, if I understood https://en.wikipedia.org/wiki/Solar_inverter 
correctly, all of the different inverter types you mentioned are, one 
way or another, connected to the grid. That might be another level of 
detail one wants to map, but doesn't need to be worked into 
electrical:grid I think? (I don't own either solar panels or a house 
that they could go on though, so I'm not completely informed on this 
topic!)


Luke


On 12.11.20 01:59, stevea wrote:
That IS what I mean.  However, STILL left unsaid is that short of 
ringing the doorbell and asking the home / business owner "are your 
solar panels grid-tied, battery-feed, directly converted to an 
inverter...?" you don't really know.


How will you tag those buildings?  (I feel a nose sniffing up my, um, 
house).  Really, there isn't any way to know, without getting creepy 
- snoopy.


SteveA


On Nov 11, 2020, at 3:45 PM, Lukas Richert  wrote:

If I understood you correctly, this would fall under grid-connected 
houses that I mentioned in the last example. This was the specific 
reason why I think namespace tagging seems to be clearer. The house 
would then be tagged with:


building=house
electricity=yes
electricity:generator=yes
electricity:grid=yes
electricity:generator:origin=solar
electricity:access=no

By tagging both electricity:grid=yes and electricity:generator=yes 
this specifies that the building is connected to both and both are 
routinely used. In contrast, it would also be possible to tag 
electricity:generator=backup if the generator is only on when the 
grid fails.


Is this what you meant by grid-tie?

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

Re: [Tagging] Feature Proposal - RFC - electricity=*

[Lukas Richert]

Hi François,

the combination of electricity:grid=yes with either electricity:origin=* 
or electricity:grid:origin=* would point to the origin being only about 
financial flows as advertised on-the-ground.


For the purpose of filtering out amenities, e.g. charging stations, that 
only use 'green' electricity it is still useful to tag 
electricity:origin=* or electricity:generator:origin=* in combination 
with electricity:generator=yes. Alternatively, there would need to be a 
tagged relation to the specific generator and the end users it supplies 
which would be considerably harder to query and many OSM editers seem to 
find relations confusing. Therefore, I think the slight bit of 
redundancy is useful to explicitly tag this on the amenity. Furthermore, 
the word 'origin' is used, not only to avoid two tags with very similar 
meanings that can be easily distinguished by combination with the 
infrastructure tag, but also since 'electricity:source' would then have 
a double meaning with 'the survey/map/place where the knowledge of the 
electricity was obtained', which is apparently a problem for some other 
tags using source as a keyword.


Cheers,

Lukas
On 14.11.20 17:15, François Lacombe wrote:

Hi Lukas

Le jeu. 12 nov. 2020 à 00:48, Lukas Richert > a écrit :


electricity:generator:origin

=solar

I didn't get in details what leads to this association between local 
supply with a generator and origin and it's not correct.


Origin is only financial/market flows (in association with according 
communication claiming for environmental benefits). A particular trade 
to pay for a certain kind of electricity production.
When electricity is locally produced, for a given building, it's not 
about origin, it's only about source.
As we already define the source on the generator itself, this would be 
redundant to explicitly define it on the building as well.


"Origin" is a term that should only be related with grid power supply 
as everyone consumes the same electricity but can pay for particular 
origins.


All the best

François

___
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] Feature Proposal - Voting - parking=street_side​

[Alex]

Hey all,

voting has started for street_side parking:
https://wiki.openstreetmap.org/wiki/Proposed_features/parking%3Dstreet_side

We propose to introduce "street_side" as a new value for parking=* and
parking:lane=*. It is intended for parking areas/bays, which are
directly adjacent to the carriageway of a road (but not lane parking on
the carriageway) and can be reached directly from the roadway without
having to use an access way. If approved, this tagging could resolve
some existing ambiguities in the mapping of such parking facilities (see
proposal).

Thanks for your previous comments and your future votes.

Alex (and Jeroen Hoek, the other author of this proposal)

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

Re: [Tagging] Feature Proposal - RFC - electricity=*

[François Lacombe]

Hi Lukas

Le jeu. 12 nov. 2020 à 00:48, Lukas Richert  a écrit :

> electricity:generator:origin
> 
> =solar
>
I didn't get in details what leads to this association between local supply
with a generator and origin and it's not correct.

Origin is only financial/market flows (in association with according
communication claiming for environmental benefits). A particular trade to
pay for a certain kind of electricity production.
When electricity is locally produced, for a given building, it's not about
origin, it's only about source.
As we already define the source on the generator itself, this would be
redundant to explicitly define it on the building as well.

"Origin" is a term that should only be related with grid power supply as
everyone consumes the same electricity but can pay for particular origins.

All the best

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

Re: [Tagging] Questions about public transport tagging

[80hnhtv4agou--- via Tagging]

https://wiki.openstreetmap.org/wiki/Talk:Tag:railway%3Dstop
 
https://wiki.openstreetmap.org/wiki/Tag:railway%3Dstop
  
>Saturday, November 14, 2020 5:08 AM -06:00 from Alan Mackie 
>:
I think under PTv2 the point you board/alight is meant to be marked as a 
platform even when it's just a pole in muddy ground. I have also seen recent 
proponents say that stop positions are not compulsory although I think on one 
of the first things I saw on PTv2 was strongly of the view that mainly using 
stops over platforms was one of its main advantages.
 
For the 66/66A question: I think under PTv2 each direction for each variant is 
meant to have its own route relation which is then combined into a route_master 
relation. I would assume that if you have an interval that applies across 
variants you would put that in the route_master rather than the individual 
route.
 
Take what I say with a grain of salt though, while I do my best to map/update 
stops I find it very difficult to stitch information displayed on stops into 
meaningful relations, especially when I've looked at the various stops on 
different days.
> 
>On Fri, 13 Nov 2020 at 22:54, ipswichmapper--- via Tagging < 
>tagging@openstreetmap.org > wrote
> 
>>Hello, I have quite a few questions about Public Transport related tagging in 
>>Openstreetmap.
>>*  My first question is about the "interval:conditional" & "opening_hours" 
>>tag for bus routes. The "Bus Route" page on the OSM wiki mentions this tag, 
>>but the train route or "public transport" route page does not mention this 
>>tag at all. So I wanted to ask, is this tag discouraged?
>>
>>The disadvantage of this tag, obviously, is that it is quite difficult to 
>>maintain. However, I think it is possible. My method would be to make a table 
>>which contains all the public transport route relations in an area, and add a 
>>column for "last checked". This would display the last date that this public 
>>transport route was checked. Regular mappers can do a check of a bunch of 
>>public transport routes every few months to see if the opening_hours or 
>>interval:conditional has changed. (I plan on including this on a guide to 
>>mapping public transport routes that I will be making).
>>
>>Here is the table for Ipswich:
>>
>>https://wiki.openstreetmap.org/wiki/Ipswich#Public_Transport_Version_2
>>
>>Note currently, this is not formatted how I described. The reason for this is 
>>because not every bus routes has been added, so instead of having a "last 
>>checked" column, there are four columns ("interval", "interval:conditional", 
>>"duration", "opening_hours"). This is because some of the unfinished routes 
>>still don't have these tags.
>>*  Second question is about mapping train route stops. If I understand 
>>correctly, you are meant to add the platform at which people wait with role 
>>"platform" as well as the stop position of the train with role "stop".
>>
>>I see issue with this. Firstly, none of this is clarified on the wiki under 
>>train routes. Secondly, what if you don't know what platform the train will 
>>leave from? What if there is no platform? In the UK this isn't a problem as 
>>all train stations have platforms. However, in other countries, in rural 
>>areas, train stations may not have any built up platform, you just wait by 
>>the side of the railway.
>>
>>Secondly, why do you have to map stops and not platforms? Again, if the train 
>>goes at different platforms, then the stop position will also be different. 
>>You may not know what the stop position is, in which case you chose a random 
>>point on the railroad. Instead, it would be much better if you could just 
>>mark the "station" as a member of the relation. However, there is no 
>>"station" role, so adding a station creates a role verification problem.
>>*  Last question is about "combining intervals". This is something that, if 
>>needed, can be asked about in another thread (as it needs more discussion). 
>>In many cases, multiple bus routes go down the same path for a significant 
>>section of their journey, and split near the end of their journey.  An 
>>example of this is route 66 & route 66A in Ipswich. [1][2][3]
>>
>>For most of their journey, these buses have the same route. Combined, their 
>>interval is "every 20 minutes". The interval of 66A is every hour. The 66 has 
>>a 20 minute interval, then a 40 minute one, then a 20 min one, etc.
>>
>>If these were mapped separately, you a routing software wouldn't be able to 
>>compute that the interval is 20 minutes. So how can this be fixed?
>>
>>The solution I can think of is to map a separate relation called ("66/66A") 
>>which is the combined route and give it a interval of 20 minutes. However, 
>>I'm pretty sure some tags would be needed to be made for this, because 
>>otherwise it breaks the ground rule (as there is no bus called "66/66A" in 
>>real life).
>>
>>Another interesting idea was suggested in this Reddit post:
>>
>>https://old.reddit.com/r/openstreetmap/comme

Re: [Tagging] Questions about public transport tagging

[Alan Mackie]

On Fri, 13 Nov 2020 at 22:54, ipswichmapper--- via Tagging <
tagging@openstreetmap.org> wrote:

> Hello, I have quite a few questions about Public Transport related tagging
> in Openstreetmap.
>
> My first question is about the "interval:conditional" & "opening_hours"
> tag for bus routes. The "Bus Route" page on the OSM wiki mentions this tag,
> but the train route or "public transport" route page does not mention this
> tag at all. So I wanted to ask, is this tag discouraged?
>
> The disadvantage of this tag, obviously, is that it is quite difficult to
> maintain. However, I think it is possible. My method would be to make a
> table which contains all the public transport route relations in an area,
> and add a column for "last checked". This would display the last date that
> this public transport route was checked. Regular mappers can do a check of
> a bunch of public transport routes every few months to see if the
> opening_hours or interval:conditional has changed. (I plan on including
> this on a guide to mapping public transport routes that I will be making).
>
> Here is the table for Ipswich:
>
> https://wiki.openstreetmap.org/wiki/Ipswich#Public_Transport_Version_2
>
> Note currently, this is not formatted how I described. The reason for this
> is because not every bus routes has been added, so instead of having a
> "last checked" column, there are four columns ("interval",
> "interval:conditional", "duration", "opening_hours"). This is because some
> of the unfinished routes still don't have these tags.
>
> Second question is about mapping train route stops. If I understand
> correctly, you are meant to add the platform at which people wait with role
> "platform" as well as the stop position of the train with role "stop".
>
> I see issue with this. Firstly, none of this is clarified on the wiki
> under train routes. Secondly, what if you don't know what platform the
> train will leave from? What if there is no platform? In the UK this isn't a
> problem as all train stations have platforms. However, in other countries,
> in rural areas, train stations may not have any built up platform, you just
> wait by the side of the railway.
>
> Secondly, why do you have to map stops and not platforms? Again, if the
> train goes at different platforms, then the stop position will also be
> different. You may not know what the stop position is, in which case you
> chose a random point on the railroad. Instead, it would be much better if
> you could just mark the "station" as a member of the relation. However,
> there is no "station" role, so adding a station creates a role verification
> problem.
>
> Last question is about "combining intervals". This is something that, if
> needed, can be asked about in another thread (as it needs more discussion).
> In many cases, multiple bus routes go down the same path for a significant
> section of their journey, and split near the end of their journey.  An
> example of this is route 66 & route 66A in Ipswich. [1][2][3]
>
> For most of their journey, these buses have the same route. Combined,
> their interval is "every 20 minutes". The interval of 66A is every hour.
> The 66 has a 20 minute interval, then a 40 minute one, then a 20 min one,
> etc.
>
> If these were mapped separately, you a routing software wouldn't be able
> to compute that the interval is 20 minutes. So how can this be fixed?
>
> The solution I can think of is to map a separate relation called
> ("66/66A") which is the combined route and give it a interval of 20
> minutes. However, I'm pretty sure some tags would be needed to be made for
> this, because otherwise it breaks the ground rule (as there is no bus
> called "66/66A" in real life).
>
> Another interesting idea was suggested in this Reddit post:
>
>
> https://old.reddit.com/r/openstreetmap/comments/jkdsjr/common_area_of_bus_routes/
>
> That is that roads with multiple bus routes can be tagged with the bus
> route, instead of the other way route (to cut down on repetition).
>
> Thanks,
>
> IpswichMapper
>
> [1]: https://www.openstreetmap.org/relation/190701
> [2]: https://www.openstreetmap.org/relation/9984463
> [3]:
> https://www.firstgroup.com/uploads/maps/FEC-Ipswich%20Reds%2066%20-%20Bus%20Times%20from%2025-10-20.pdf
>
>
> I think under PTv2 the point you board/alight is meant to be marked as a
platform even when it's just a pole in muddy ground. I have also seen
recent proponents say that stop positions are not compulsory although I
think on one of the first things I saw on PTv2 was strongly of the view
that mainly using stops over platforms was one of its main advantages.

For the 66/66A question: I think under PTv2 each direction for each variant
is meant to have its own route relation which is then combined into a
route_master relation. I would assume that if you have an interval that
applies across variants you would put that in the route_master rather than
the individual route.

Take what I say with a grain of salt though, while I do my

Re: [Tagging] Deprecate water=pond?

[Martin Koppenhoefer]

sent from a phone

> On 14. Nov 2020, at 08:05, Joseph Eisenberg  
> wrote:
> 
[canal areas]
> There was never a standard way to tag this before


I thought it was waterway=riverbank?

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

Re: [Tagging] Deprecate water=pond?

[Steve Doerr]

On 12/11/2020 01:29, Joseph Eisenberg wrote:

if a reservoir is thought to be larger and must have a dam on one side


That's certainly not implicit in the use of the word in British English. 
Some reservoirs are formed by damming a river, but most are not like that.


--
Steve

--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

Re: [Tagging] Deprecate water=pond?

[Martin Koppenhoefer]

sent from a phone

> On 14. Nov 2020, at 04:05, Kevin Kenny  wrote:
> 
> Around here, beavers are a significant sculpting force on the landscape.
> 
> (And `man_made=dam` is the best tagging that we have for their water control 
> structures, which are also often adjusted seasonally) 


frankly, tagging beaver made structures as man_made=dam (or waterway=dam) feels 
like tagging model / rc airplane strips as airports. Or adding railway=station 
objects to a model railway

I guess you meant waterway? 
https://wiki.openstreetmap.org/wiki/Tag:waterway%3Ddam



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

Re: [Tagging] Deprecate water=pond?

[stevea]

Joseph, Kevin, Paul, Clifford, Martin, Peter, Tom, Brian, Andy, 
Graeme...everybody else here:  I love these conversations, thank you.
SteveA

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