[Tagging] Feature proposal - Voting - Pumping

2020-12-20 Thread François Lacombe
Dear all,

Following an appropriate refactoring of proposed pumping tagging done by
IanVG and I, this proposal is now open for voting until January 4.
https://wiki.openstreetmap.org/wiki/Proposed_features/Pumping_proposal

Despite a complex classification, keep in mind that most of proposed tags
are optional and mappers will still be able to give simple information
about pumping means if they want to.

You may not be able to describe some pumps hidden in restricted areas.
Question asked during this vote is about tagging suitability to describe
pumps with public ground knowledge.

Thank you to ZeLonewolf, Mateusz, Volker, Joseph and Martin for their
involvement during second RFC phase.

All the best

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


Re: [Tagging] Tagging sewage treatment basins

2020-12-17 Thread François Lacombe
Hi Joseph,

Le jeu. 17 déc. 2020 à 20:16, Joseph Eisenberg 
a écrit :

> I don't think mappers can know the maximum volume or capacity of a water
> reservoir or water basin, unless it is written on a public sign somewhere?
> We can map the surface area, but knowing the average depth or maximum depth
> is quite difficult, especially when it is not uniform. However for
> man_made=reservoir_covered and =storage_tank we have capacity=* (in cubic
> meters?) and content=water/sewage/etc.
>

volume, elevation would be optional and mostly got from local signage.
You may have opendata, knowledge or sometimes measurements.
Many tags are already available but not used at the proper extent.
For example, if we add capactiy (in cubic meters) on a waste water basin,
we could do the same for man_made=covered_reservoir or even water=reservoir
(if information is available somewhere)
Look at this water tower hunting website giving many details from ground
http://chateau.deau.free.fr/rdef/PagesHTML/Sommaires/GermanDossiers.html


> The usage is not often tagged yet, since this might be hard for a mapper
> to know.
>

Regarding waste water basins, it could be useful to distinguish
- sand traps
- oil separator
- floccuation
- decanter basins
- aeration tanks
and so on...
https://www.horiba.com/fileadmin/_migrated/pics/Wastewater_Processing_E_.jpg
That looks complex but easilly guessable from aerial imagery or even
clearly explained during public visits of facilities.
We could define simpler values if it helps


> Currently for landuse=reservoir and water=reservoir this is some use of
> reservoir_type= - https://wiki.openstreetmap.org/wiki/Key:reservoir_type
> - with values of water_storage, sewage, tailings, evaporator, tank,
> salt_pan, wastewater, slurry, irrigation, aquicultura, cooling, etc -
> though only the first 4 are at all common.
>
> basin=* is used with landuse=basin or water=basin to describe the form and
> function of the basin:
>
>- basin =infiltration
> - An 
> infiltration
>basin  catches
>storm water and allows it to seep into an aquifer
>.
>- basin =detention
> - A detention
>basin  catches storm
>water and allows it to drain slowly into natural waterways.
>- basin =retention
> - A retention
>basin  catches storm
>water and retains it, forming an artificial pond.
>
>
> And note that salt ponds (used to evaporate salt from sea-water) are
> tagged as landuse =
> salt_pond 
> Pools for swimming are leisure
> =swimming_pool
> 
>
> I don't see many combinations with usage=* or another tag that might
> describe how the reservoir or basin is used, so perhaps this could be
> proposed?
>


That's right, usage=* corresponds to large familiy of activities and more
specific tagging would be more suitable to describe precise purpose of a
particular basin
reservoir_type and basin looks like to refer to reservoir/basin purpose but
mixes may concepts that may collide (irrigation is a water_storage as well)
Only some values would match with usage=* ones: usage=irrigation is used
12k vs reservoir_type=irrigation 50

Waste water processing could be described with less used water_works=*
man_made=basin (An artifical structure designed to store some fluid, you
find basins for storm/rain/radioactive water, sewage, oil, ...)
content=sewage (Let's put waste water inside)
usage=industrial (It's part of an industrial process)
water_works=decanter (It's an actual decanter)
capacity=

I'd find great to use water=* with content=water, substance=water or
natural=water only.

That's my 2 cents, let's refine it

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


Re: [Tagging] Tagging sewage treatment basins

2020-12-17 Thread François Lacombe
Hi all

I'm ashamed to not have enough time to be involved in all discussions
regarding reservoir, ponds, basins and so on... and thank you to make such
a capital topic on the table
I'd be happy with a tagging that separates the structure, the water body
and purpose of a given feature.

Have a look to Storage chapter in this page (probably lacks many thing,
it's just a start)
https://wiki.openstreetmap.org/wiki/Water_management

There are at least 5 ways to tag features involved in (potable) water
storage
What if I'm only interested to find "water storage places" with their
volume, elevation and sometimes particular usage?
Waste water retention basins are a supplementary situation like we could
find dozens of them.
Where will this end?

All discussed features share the "water body" concept (or more generic
fluid-body with substance=water) inside very different structures with even
different purposes.
Why don't we look to describe a generic water body, with a volume,
elevation and usage prior to list every single feature that stores/retain
water?

This said, it's fine to have many different tags to describe very different
structures (building=*, man_made=*, natural=*...)
As such structures tagging should be separated from the water body they
contain, an uniformed semantic for water bodies would make OSM a yet cooler
place than it already is

All the best

François


Le jeu. 17 déc. 2020 à 18:46, Brian M. Sperlongano  a
écrit :

> I knew them as sewage treatment ponds, but apparently there's a name for
> them:
>
> https://en.m.wikipedia.org/wiki/Waste_stabilization_pond
>
> I feel like this a separate class of object that deserves its own tag,
> either within or separate from natural=water, or perhaps even subclassed as
> water=basin+basin=waste?
>
> On Thu, Dec 17, 2020, 12:24 PM Joseph Eisenberg <
> joseph.eisenb...@gmail.com> wrote:
>
>> How should sewage treatment facilities be tagged, then?
>>
>> Isn't sewage 99% water?
>>
>> I think that most sewage treatment facilities in the USA include open
>> settling basins and I would use landuse=basin or water=basin +
>> natural=water for these: https://www.openstreetmap.org/way/420075503
>>
>> -- Joseph Eisenberg
>>
>> On Thu, Dec 17, 2020 at 1:55 AM Mateusz Konieczny via Tagging <
>> tagging@openstreetmap.org> wrote:
>>
>>>
>>>
>>>
>>> Dec 17, 2020, 08:02 by dieterdre...@gmail.com:
>>>
>>>
>>>
>>> sent from a phone
>>>
>>> On 16. Dec 2020, at 17:52, Joseph Eisenberg 
>>> wrote:
>>>
>>> You still have to distinguish marine water (outside of the
>>> natural=coastline) from inland waters, and distinguishing rivers from lakes
>>> is very important for proper rendering of many maps.
>>>
>>>
>>>
>>> and it seems landuse=reservoir is used for sewage as well:
>>> https://taginfo.openstreetmap.org/tags/reservoir_type=sewage
>>>
>>> is this appropriate for natural=water?
>>>
>>> No.
>>>
>>> ___
>>> 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 2 - Pumping proposal

2020-12-16 Thread François Lacombe
Hi Brian

Le mar. 15 déc. 2020 à 00:57, Brian M. Sperlongano  a
écrit :

> The wiki[1] says: "OpenStreetMap does not have 'banned features', as
> anybody is allowed and encouraged to use any tag they think is useful."
> Therefore, deprecating a feature does not "enforce or forbid" the use of a
> tag - all it does is set the tag's status to deprecated on the tag's wiki
> page, and adds an entry to the deprecated features[1] page.
>

Got it thank you
Then I've updated the proposal and changed to pump:type deprecation.

All the best

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


Re: [Tagging] Feature proposal - RFC 2 - Pumping proposal

2020-12-14 Thread François Lacombe
Hi Volker

Le lun. 14 déc. 2020 à 06:58, Volker Schmidt  a écrit :

> My main point got lost: the proposal should explain how the mapping of
> pumps in pumping stations should be handled, short of using indoor mapping,
> especially as your cover photo shows an indoors pump in an industrial
> building.
>

Sorry I didn't got your point

I've added a section about pumping stations here
https://wiki.openstreetmap.org/wiki/Proposed_features/Pumping_proposal#Pumping_stations

Best regards

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


Re: [Tagging] Feature proposal - RFC 2 - Pumping proposal

2020-12-14 Thread François Lacombe
Hi Brian,

Thank you for your comments

Le lun. 14 déc. 2020 à 00:40, Brian M. Sperlongano  a
écrit :

> 1. The proposal states "It is proposed to discourage the use of
> undocumented pump:type=* to state pump mechanisms in favour of new
> pump_mechanism=*."  It is not clear what is meant by "discourage" in this
> context.  Given the other threads today regarding reservoirs, it is
> important to communicate clearly what we mean when we propose to stop using
> a tag.  I would ask that instead of "discourage", that the proposal should
> explicitly say "deprecate" so that there is no confusion that you intend
> for us to stop using pump:type and document it as deprecated in the
> deprecated features list.  Otherwise, I would ask that you clearly and
> explicitly state what you mean by "discourage" and where those words of
> discouragement would go.
>

To me, discourage means provide a better way to describe features and
encourage people to do so. Reviewing a proposal and vote approval is a step
and additional work has to be done in that way.
I remember a discussion in my early OSM years about sense of "deprecated",
"discouraged", "approved", "reviewed"... and I'm now merely in favour of
encouraging and discouraging than enforcing or forbidding
pump:type isn't documented currently, then how could it be added to any
deprecated features list?
The proposal aims to make pump_mechanism approved and then pump:type could
be added to its wiki page as a possible duplicate.

Furthermore, :type suffixes make things complex and don't bring any
additional information as anything is a type or category of something here.
Any opportunity to move them to simpler key should be used.


> 2.  You propose to deprecate man_made=pumping_rig and propose to replace
> it with the (far more popular) man_made=petroleum_well.  Both of these are
> combined with the substance=* key.  I would ask whether there are usages of
> pumping_rig that are being used with substance=* tags for non-petroleum
> products (i.e. not oil/natural gas) which would be lost by abandoning this
> pumping_rig?  If the answer is "yes", then I would support simply changing
> the description of pumping_rig to explicitly exclude petroleum products,
> and if the answer is "no" then I agree with deprecating it.
>

I've updated to proposal to include man_made=water_well if the pumping rig
was intended to get water from ground and i'm not aware of other usage than
petroleum or water currently.
It seems that no information would be lost from such a manual replacement.

By the way, we had a short discussion here about replacing
man_made=petroleum_well and man_made=water_well with a more generic value
for any well to be combined with substance=* to state what the well is
intended for.
As always it's hard to replace widely used tags, but it would improve
semantics and enable to distinguish wells for hot water and geothermal
plants.

All the best

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


Re: [Tagging] Feature proposal - RFC 2 - Pumping proposal

2020-12-13 Thread François Lacombe
Hi Mateusz, Joseph,

You were right, it was mistakes and it's now fixed. Thank you for you
vigilance.

Le dim. 13 déc. 2020 à 23:17, Volker Schmidt  a écrit :

> Missing at first glance: what is the mapper expected to do with pumping
> stations.
>

Hi Volker
Anyone could map man_made=pumping_station only if he/she wants. It's okay.

As you mention, pumps can be added with enough knowledge or public
documentation but it's not mandatory at all.
Goal of proposal isn't to force to map every each pumps but only facilities
that are publicly accessible.
Sometimes, operators could post a tweet showing pumps inside the building
for instance.
https://twitter.com/KSBfrance/status/1337390441000538118?s=20

Anyway man_made=pumping_station won't be replaced by anything in this
proposal and will be used independently.

All the best

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


[Tagging] Feature proposal - RFC 2 - Pumping proposal

2020-12-13 Thread François Lacombe
Dear all,

Following some rework to take care of comments received during the first
voting round of pumping proposal, here is a second proposed version
https://wiki.openstreetmap.org/wiki/Proposed_features/Pumping_proposal

IanVG and I spent time to improve wording and make rationale section
clearer.
Classification of pumps is now done with pump_mechanism and is still
equivalent to which available on Wikipedia. Numerous references are made
toward it.

Additional examples and illustrating gifs have been added at the bottom as
well.

This message opens a second RFC period and is expected to be shorter. Vote
could begin by next Saturday.

Best regards

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


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

2020-11-29 Thread François Lacombe
Hi Lukas

This proposal gets better and better and it's really encouraging, thank you.

Le dim. 29 nov. 2020 à 01:57, Lukas Richert  a écrit :

> Although in the case of the Shoals Laboratory, something like grid:input
> would make sense as well since the grid is well-defined!
>

Then users will have to look to the grid definition.
It's harder to maintain when this information is redundant on the building
I think

All the best

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


[Tagging] Feature Proposal - Vote aborted - Pumping proposal

2020-11-25 Thread François Lacombe
Dear all,

Voting on the pumping proposal has been aborted following several comments
that should be studied for a second version.
https://wiki.openstreetmap.org/wiki/Proposed_features/Pumping_proposal

For now, 11 opposition against 10 approval votes shows that no consensus
could be achieved shortly and improvements have to be made.

A special thank to 21 voters who spent time to give their feedback.

Established tagging qualifications have to be widely discussed at a global
level. Such a question often arises without any agreement on both sides,
every time. It would be more usable to have to-be-defined thresholds above
which a tagging can't be changed, if a significant part of the community
agrees it's desirable.


All the best

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


Re: [Tagging] Feature Proposal - Voting - Pumping proposal

2020-11-22 Thread François Lacombe
Hi Martin, Yves

Usage is a good point, thank you.

Le dim. 22 nov. 2020 à 03:01, Martin Koppenhoefer 
a écrit :

> this would deprecate around 20k pump values describing a pump type, plus
> 15k yes/no.
>

OSM counts 143k water_wells according to taginfo for man_made=water_well.
There are 21k pump occurrences associated with those wells, which means 86%
of them still wait to be completed with pump information.
I don't blame anyone for not completing wells quick enough. 20k occurrences
should be put into perspective of the global feature population.

My small and domain-focused experience shows that such a change could
encourage mappers to increase a lot the amount of described features more
quickly.
https://www.openstreetmap.org/user/InfosReseaux/diary/391058
tower:type=suspension january 2013 => september 2019 : 25k occurrences peak
tower:type=anchor january 2013 => september 2019 : 13k occurrences peak
line_attachment=suspension (exact replacement) july 2019 => december 2020 :
23k occurrences
line_attachment=anchor (exact replacement) july 2019 => december 2020 : 21k
occurrences

Like many other successful moves done by dozens of volunteers.


> Looking at the no-values, 23% are not in combination with man_made
> https://taginfo.openstreetmap.org/tags/pump=no#combinations
> i.e. this is also used on other objects to state buildings there is no
> pump.
>

It's a good point to mention: pump word is actually used elsewhere, which
sounds incorrect according current wiki I intend to extend
https://wiki.openstreetmap.org/wiki/Key:pump
requires : man_made=water_well

All the best

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


Re: [Tagging] Feature Proposal - Voting - Pumping proposal

2020-11-21 Thread François Lacombe
Joseph,

It's true proposed tagging deprecates the current pump=* definition
according to rationale and wishes to use the pump word in a more
appropriate way.

However, it would be ok to define mechanical_driver=powered for situations
when mappers aren't able to determine a more precise value.
That would preserve the current distinction made on HDM render with
mechanical_driver=manual/powered and offer possibilities to define a more
detailed knowledge.

Giving more details about pumping capabilities of water wells would cause
upgrading work for renders anyway: they have to support more pump=* values
or drop it in favour of mechanical_driver=*
I now agree on the ability to state 'this water well has powered pumping
capabilities' in case of no additional knowledge but don't get why limiting
knowledge to manual/powered would be desirable.

All the best

François

Le sam. 21 nov. 2020 à 06:24, Joseph Eisenberg 
a écrit :

> On the Talk page, the proposal author has now ignored two different
> requests to change the new pump=values to a different key like
> pump_mechanism, which would allow the continued use of pump=manual and
> pump=powered.
>
> The author claims: "I find current tagging meaningless (with all due
> respect to people who created it in the past)"
>
> This is absolutely disrespectful to the current mappers using this tag to
> specify the type of water well found in lower-income countries.
>
> Perhaps you have never lived in a place where people get their drinking
> and washing water from public or semi-public wells. In these places it is
> quite important to know if a well is just a hole in the ground where you
> need to use a bucket and rope to draw out water (pump=no), or if there is a
> mechanical pump handle which you can physically operate, with some amount
> of force, to pump out bursts of water (pump=manual).
>
> And the other type of well is "a well that is attached to pipes and a
> motorized pump", which is usually powered by electricity but sometimes by a
> diesel motor. In this type of well you don't have to use any physical
> effort at all, you just flip a switch or open a faucet and water comes out
> - as most Westerners are accustomed to enjoy in their own homes.
>
> But you will need electricity or fuel to operate it. So usually a
> man_made=water_well + pump=powered is much more convenient, but when the
> power goes out or there is no fuel, it can be nearly useless, while a
> pump=manual is now much more helpful.
>
> I am quite frustrated that this proposal has gone forward even though
> these concerns were brought up months ago on the Talk page.
>
> -- Joseph Eisenberg
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - Voting - Pumping proposal

2020-11-20 Thread François Lacombe
Dear Mateusz,

Proposal goes through different stages and I was proposing simpler driver=*
instead of mechanical_driver. Comments have been made about the possible
confusion with human drivers driving cars.
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Pumping_proposal#Consider_drivers_as_pump_specific_devices
However, drivers aren't specific to pumps at all.

Current pump=* doesn't deal with pumps but with water wells and possible
motors/engines installed to get water. I was confused by this in the very
beginning.
pump=powered mixes electric motors and gasoline engines which are way
different. Situations may occur with emergency services coming with
gasoline to run an electric motor for instance.
The opportunity (not an obligation) to replace this particular value with
more detailed and useful information is the goal of the proposal.

One possible way to state the isn't manually operable is to use handle=no
without any mechanical_driver (waiting to be defined by knowledgeable
people)

All the best

François

Le ven. 20 nov. 2020 à 12:22, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> a écrit :

> I am not a fan of deprecating
> pump=manual and replacing it with nearly impossible to remember and less
> clear
> mechanical_driver=manual
>
> Also, this proposal deprecates pump=powered without providing replacement
>
> Now to tag this info one is supposed to select value from
> reciprocating_solenoid
> combustion_engine
> electric_motor
> cylinder
> turbine
>
> and no way to tag equivalent of pump=powered is provided.
>
> Mapper may be uninterested in or unable to get info about technical detail,
> but they should be still able to tag info that pump is not manually
> operated.
>
> Nov 19, 2020, 20:05 by fl.infosrese...@gmail.com:
>
> Hi all
>
> Tonight I'm pleased to announce the start of voting for the tagging
> proposal about pumps
> https://wiki.openstreetmap.org/wiki/Proposed_features/Pumping_proposal
>
> A lot of comments lead us to an interesting tagging for pumps devices,
> water wells and wind pumps. Thank you to anyone involved in this review.
> Some values are proposed to be deprecated as to classify pumps according
> to their technologies and capabilities.
>
> Several contributors tested the proposed tags in real conditions and no
> problem seems to remain.
>
> Feel free to give your opinion until December 3
>
> 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 - Pumping proposal

2020-11-19 Thread François Lacombe
Hi all

Tonight I'm pleased to announce the start of voting for the tagging
proposal about pumps
https://wiki.openstreetmap.org/wiki/Proposed_features/Pumping_proposal

A lot of comments lead us to an interesting tagging for pumps devices,
water wells and wind pumps. Thank you to anyone involved in this review.
Some values are proposed to be deprecated as to classify pumps according to
their technologies and capabilities.

Several contributors tested the proposed tags in real conditions and no
problem seems to remain.

Feel free to give your opinion until December 3

All the best

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


Re: [Tagging] power lines/cables power

2020-11-19 Thread François Lacombe
Hi André

It's great to have such a discussion here as to move forward on power
routing.
Answers below

Le mer. 18 nov. 2020 à 02:38, André Pirard  a
écrit :

>
> Haille François,
>
> Merci pour ta réponse.
> So, I was told that 7,5 GW rating by an ALEGrO engineer but I didn't see
> it on OSM. He didn't mention 1 GW.
>

7.5 GW is really huge for a single system.
This : https://www.amprion.net/Grid-expansion/Our-Projects/ALEGrO/ states
1000 MW only.


> So I looked all over the wiki.
> Passing an accepted proposal that should say that it is overridden by
> another one, typical wiki, I saw no mention of power rating except for
> generators. And that cable has dead ends.
>
Rating was proposed for power transformers
https://wiki.openstreetmap.org/wiki/Proposed_features/Transformer_extension_proposal
https://wiki.openstreetmap.org/wiki/Tag:power%3Dtransformer#Tagging
Generators got an output value with generator:output:electricity

Which proposal is overridden please?

And in the proposal you show, I see no mention of power rating either, esp.
> in the relation.
>
That's right, the proposal introduces a new relation formalism to put
properties on power systems (ALEGrO is a power system, composed of a line
and other components)
We will be able to add ratings, like frequency or operating voltage on that
system.


> A typical OSM browser needs to be an expert already to know how to look at
> tags and do so.
> Let alone guessing that what he does not find could be in a relation.
>
We're not responsible for world complexity and we need reliable models to
describe what actually exists.
Editors, tools, render, documentation are here to help to do so.
i.e. that's counterproductive to make things more intuitive than they
actually are for sake of edition ease.

Furthermore, I don't see at all how a relation could indicate the
> operational *power ratings of branches*.
>
It can't indeed.
It's the same as voltage: some branches could be designed up to 400 kV but
the whole system will be operating at 220 kV
So power lines branches will get voltage=40 and the system relation
will get voltage=22
Is this difference clearer?
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Power_routing_proposal#Splitting_logical_from_physical_infrastructure

Puting system rating on physical route is the same as marking public
transport buses capacity on osm highway ways
We actually have public transport relations for that


> All in all, I continue to believe that a cable or line should indicate
> their power ratings.
>
Yes, but that's not what we discuss about here since ALEGrO is a power
system
Public documentation will give the system rating, not the cable design in
detail (I think but change my mind)

power:maximum=7.5 GW
> power:used=1 GW
>

That's a nice try thank you
Those values should be on two separate osm features according to what we
intend to do regarding power systems
I have doubts on the sense of "used": used values change every second.
Don't we deal with operated value instead?


> Quite self-describing and friendly.
> Please discuss this matter and warn me of any change.
>

Power routing proposal is still in RFC and its author is waiting for API
0.7 to start voting.
It's a pity since this topic deserve a clear and reliable tagging to
provide a better understanding to everyone
Our discussion (and many before and certainly many in the future) help to
refine wording and improve docs and explanations

All the best

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


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

2020-11-15 Thread François Lacombe
Hi Lukas,

Le dim. 15 nov. 2020 à 02:46, Lukas Richert  a écrit :

> 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.
>
That's a good topic
However be careful to not extend the proposal too much. Classification of
batteries would deserve a dedicated document and vote.

> 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.
>
Great

> 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 such a situation occurs, you'll have to tag both grid and generator
with two separate tags.

> If you'd like to add such a table to the wiki, feel free! :)
>
I'll take time to do so shortly

All the best

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


Re: [Tagging] power lines/cables power

2020-11-15 Thread François Lacombe
Hi André,

That's an interesting question.
Power transformers can have rating=* to state how many power they can
transmit.
I see no problem to add it to a power relation like the one involving the
line you mention
https://www.openstreetmap.org/relation/8193755#map=11/50.7528/6.0606

Can you explain the difference between your value (7.5 GW) and the value
already visible on the relation (1 GW) please?

Difference between rating on a power=line/cable and rating on a power
relation is a follow:
- On a line/cable, it's the maximum capacity the line/cable is designed for
- On a relation, it's the rating the whole link is operating at

Power circuits relations :
https://wiki.openstreetmap.org/wiki/Proposed_features/Power_routing_proposal

All the best

François

Le dim. 15 nov. 2020 à 16:45, André Pirard  a
écrit :

> Hi,
>
> A group of friends were discussing the first electricity power link
> between Germany and Belgium.
> And I was kinda proud to show them this
> 
> where the only line across the border
>  clearly shows.
> Well done, guys (and gals?)!
>
> Way 578137663  Tags 7
>
>- cables=1
>- circuits=1
>- frequency=0
>- location=underground
>- name=Alegro Interconnector
>- power=cable
>- voltage=32
>
> Their concern was interstate power transfers and a maximum of 7,5 GW was
> mentioned (more than the 6 GW Belgian deprecated nuclear capacity,
> effectively running at 4,5 GW).
> So then I was surprised that a power cable or line does not indicate that
> power.
> I looked trough the wiki and all I found as power was an unsuitable
> generator:rating:...
> So, as power:power=* seems weird, I added *power:maximum=7.5 GW*,
> allowing for power:mean=* or he like.
> As I don't want to get into propositions, I let specialists discuss that.
> Let me know if and how I should change that tag.
>
> Envoyé de mon immobile Thunderbird, et *sans virus* non plus grâce à
> seulement Ubuntu,
>
> All the best,
>
> André.
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2020-11-14 Thread 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] Feature Proposal - RFC - electricity=*

2020-11-14 Thread 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] Feature Proposal - RFC - electricity=*

2020-11-14 Thread 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] Feature Proposal - RFC - electricity=*

2020-11-05 Thread François Lacombe
Hi all,

Le jeu. 5 nov. 2020 à 20:00, Joseph Eisenberg 
a écrit :

> Perhaps someday the community of mappers will be vibrant enough that we
> could imagine updating tags every month or every week, but at this point
> such a situation is very far away. So for now we should encourage mappers
> to focus on permanent or semi-permanent characteristics which are unlikely
> to change in the next few months.
>

More and more often we find up to date official public data suitable to
complete osm.
Recently in France we had terrible floods in three southern valleys and osm
community was the first (and still the only) source of data for qualified
destroyed houses, football fields and power substations.

Consider this discussion on Talk
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/electricity#Required_top-level_tagging

All the best

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


Re: [Tagging] Proposal to change key:man_made to key:human_made

2020-10-19 Thread François Lacombe
Hi

I second the comments of Topographe below. Continuous improvement is a
major challenge.

Le dim. 18 oct. 2020 à 23:09, Martin Koppenhoefer 
a écrit :

> And once we have done it, we could do it again and again, for all kinds of
> reasons.
>
Not all kinds of reasons: once the change has been reviewed, voted,
discussed by the community for a significant amount of time.
Providing a technical efficiency or a given tool doesn't mean we should
overuse that tool.


> The problem is not the data at the origin, it is the system around the
> database.
>

If the system isn't suitable enough, let's improve it.
For instance: among other things, versions keep a record of a manual edit
of a particular user and allow change reversal.
Once a big change like man_made => human_made has been reviewed and
acknowledged by the community, do we need a formal version to reverse it?
How many DWG changesets have been reversed in the past?
I think the need to create versions for this particular kind of change is
very low.

All the best

François

Le lun. 19 oct. 2020 à 08:55, Topographe Fou  a
écrit :

> Putting appart this 'man' vs 'human' debate...
>
> This reminds me a thinking I regularly have in minds: OSM shall have a way
> to tell all (registered) data users that "starting from /mm/dd
> following major change in the database will be applied following vote xxx
> from OSM community. Please see drawbacks, workarounds and recommandations
> for editors in wiki page www" . The idea would not be to trigger this
> mechanism every week but to be able to schedule few data scheme
> improvements in concertation with (and supervized by) a dedicated Working
> Group (DWG ? Or a contiunuous improvement wg ?). I think OSM already did it
> in the past and the wellspreading of its data shall not block us for
> improvements. Keys can be seen as arbitrary strings from a sw point of view
> but I think there is a benefit to have consistent keys, which may imply
> from time to time to review 10 years old tagging schemes. It can even
> simplify life of editors and data consumers.
>
>
> LeTopographeFou
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Proposal to change key:man_made to key:human_made

2020-10-18 Thread François Lacombe
Hi

Le dim. 18 oct. 2020 à 16:25, Martin Koppenhoefer 
a écrit :

>
>
> sent from a phone
>
> > On 18. Oct 2020, at 12:39, Rory McCann  wrote:
> >
> > Yeah changing this is a multi-year project,
>
>
> generations...
>

Certainly, with the current tagging control plane.

That would only took ~3 or 4 months with more streamed practices and
appropriate communication.
This point reminds us we're not able to change tagging because consumers
are using it, whatever the input question was.
Such an argument never was and won't ever be a legit reason for me to
oppose to a change.

All the best

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


Re: [Tagging] Feature Proposal - RFC - electricity:source

2020-10-04 Thread François Lacombe
Hi all

Thank you Lukas or this interesting proposal.
I second all comments about power physical source and origin distinction :
we're dealing with financial flows only. Using source for that may confuse
mappers and consumers.

As mentioned on
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/electricity:source,
original question is not about power source but its origin
See https://en.wikipedia.org/wiki/Guarantee_of_origin (didn't see this link
here so far).

All the best

François

Le ven. 2 oct. 2020 à 08:56, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> a écrit :

> In that case you want to tag what is signed,
> not actual electricity source.
>
> marked_as_green_energy=*
>
> marked_as_renewable_energy=*
>
> is verifiable and does not require
> - impossible for mapper - verification
> of an actual energy source
>
>
> 29 wrz 2020, 22:28 od lrich...@posteo.de:
>
> Hi Colin,
>
> I agree that while a few suppliers source all of their electricity from
> renewable sources, most simply add a surcharge which is used to fund the
> growth of renewable energy infrastructure and price the electricity as if
> it were coming from solely renewable energy sources. I'm working on an
> article for Wikipedia that will explain green pricing tariffs in detail as
> this seems to be lacking in English.
>
> Arguing if the definiton of 'green electricity' is actually 'green' is not
> the point, this is already a term that is explicitly advertised at the
> charging stations or camp sites (see images in proposal) and also something
> that consumers look for as they want to fund renewable energies in the hope
> that all grid energy will be completely 'renewable' in future. While this
> obviously won't be for at least 15-50 years depending on who you ask, I
> think it is a worthwhile attribute to map as some people are conscious of
> what types of electricity generation they wish to support.
>
> Best, Lukas
>
>
> On 29/09/2020 16:56, Colin Smale wrote:
>
> Hi Lukas,
>
> You do realise that all electricity is the same, irrespective of how it is
> generated? The "greenness" or otherwise is not determined by the
> connection, but by the subscription/contract that the consumer has with
> their supplier.
>
> UNLESS they have a standalone generating capability, like PV or wind
> turbine that is not connected to the grid.
>
> On 2020-09-29 16:00, Lukas Richert wrote:
>
> Hi,
>
> I'd like to propose a new tag that defines the source of publicly
> available electricity: electricity:source
> 
>
> This could be used as an additional information tag on amenities that
> provide electricity for public consumption, such as bike/car charging
> stations or camp sites. Many charging stations have nearby solar or use
> green pricing tariffs. I've also seen camp sites and harbours advertise
> this.
>
> This topic came up as a group wanted to plan a bike tour using e-bikes but
> only with renewable energy. I noticed that there appears to be no easy way
> to filter for the source of the electricity provided.
>
> Potential discussion: It's not quite clear to me whether power_supply or
> electricity is preferred for this type of application. It might also be
> interesting for consumers to see which buildings are powered by green
> electricity if this is something a store or similar advertises. So it may
> be worth expanding the proposal to electricity used by the public even if
> not directly available (e.g. lighting in a store).
>
> Best regards,
> Lukas
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://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] Best practices regarding implied tags

2020-09-20 Thread François Lacombe
Thank you all for replies

Then the current proposal sounds to be ok regarding what is said upside.
I admit to automatically adding implied tags when importing data covered by
the proposal, so no apparent problem is mappers add them explicitly.

All the best

François

Le jeu. 17 sept. 2020 à 15:11, Kevin Broderick  a
écrit :

> +1.
>
> Explicit tagging indicates a level of confidence not generally associated
> with implicit tagging. While there's certainly an 'ad nauseum' level of
> doing so (e.g. adding surface=paved, motor_vehicle=yes to highway=motorway
> in the U.S. would be kinda silly, IMO), there are plenty of cases where a
> primary tag generally implies something about the tagged object but doesn't
> guarantee it. I'd point to the recent discussion of access= on driveways as
> an example; while most driveways allow for certain types of access by
> default, it's far from guaranteed—there may be a no-trespassing sign or a
> locked gate, and explicitly indicating the lack of such in the access
> tagging is helpful. (Adding the implied value without survey or other
> definitive knowledge is not, as then you express a higher degree of
> confidence than actually exists in the data).
>
> On Wed, Sep 16, 2020 at 6:34 PM Paul Johnson  wrote:
>
>> On Wed, Sep 16, 2020 at 5:20 PM François Lacombe <
>> fl.infosrese...@gmail.com> wrote:
>>
>>> Is that completely wrong or mappers could eventually add implied tags if
>>> they want to?
>>> The proposal currently states they are optional and it won't raise an
>>> error if mappers add them beside mandatory tags.
>>>
>>
>> No, it's not wrong to add implied tags explicitly.  It's actually
>> encouraged in some cases where the implicit tag is not consumable by
>> automated system (such as the "none" default for turn:lanes tends to be
>> ambiguous between "you can't turn from this lane" and "you can't use this
>> lane" and "there's an implicit but unspecified implication that isn't
>> painted on the ground"), or access defaults (such as in the US where
>> bicycle=* and foot=* varies a lot on highway=motorway)
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> --
> Kevin Broderick
> k...@kevinbroderick.com
> ___
> 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] Best practices regarding implied tags

2020-09-16 Thread François Lacombe
Hi all,

This proposal is currently in RFC
https://wiki.openstreetmap.org/wiki/Proposed_features/Utility_poles_proposal

It proposes among other points to make man_made=utility_pole +
utility=power implied by power=pole (for sake of consistency with telecom
utility poles which won't get a telecom=pole because they're not a telecom
feature)

A good point is raised in Talk regarding this implication.
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Utility_poles_proposal
It's clear that implied tags won't be mandatory on osm features but what
about actually adding them ?
Is that completely wrong or mappers could eventually add implied tags if
they want to?
The proposal currently states they are optional and it won't raise an error
if mappers add them beside mandatory tags.

Let me know if a common practice is already established.

All the best

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


[Tagging] Feature Proposal - RFC - Utility poles

2020-09-07 Thread François Lacombe
Hi everyone,

Following this sunny summer, sometimes cycling along country roads, here
comes the need to reinforce the tagging of utility poles holding telecom
lines.

OSM already has power=pole and past proposals have shown it's not necessary
to change it.
Poles don't always support power lines and tagging is needed for other
utilities.
Existing man_made=utility_pole sounds to be the most meaningful and this
proposal is now looking for your comments about it
https://wiki.openstreetmap.org/wiki/Proposed_features/Utility_poles_proposal

See this French example taking advantage of proposed tagging to show power
and telecom utilities on the same map
http://www.gespot.fr/#12.7/46.04989/6.13389
On this particular place, it was possible to make low voltage power
distribution poles support an overhead transmission fibre optic cable:
http://www.gespot.fr/#17.84/46.066428/6.140358

I'm not sure to cover all existing situations to describe other-than-power
poles with the 4 combinations I propose to replace.
Feel free to complete the list here or on Talk page please

All the best

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


[Tagging] Feature proposal - Approved - Line management

2020-06-12 Thread François Lacombe
Hi all,

The voting of Line management proposal is over since last week and 20 pros
reviews make it approved.
https://wiki.openstreetmap.org/wiki/Proposed_features/Lines_management

Thank you to voters :)

Wiki cleanup is almost done :
https://wiki.openstreetmap.org/wiki/Key:line_management
https://wiki.openstreetmap.org/wiki/Tag:power%3Dtower (you're more than
welcome to update translations)
https://wiki.openstreetmap.org/wiki/Key:tower:type (no more power)

https://wiki.openstreetmap.org/wiki/Tag:power%3Dpole remains to be updated
accordingly.

It's a real satisfaction to get this tower:type cleanup project done.
Towers/pole documentation is now more accessible and meaningful.
https://www.openstreetmap.org/user/InfosReseaux/diary/391058
I'm on my way to show this collective achievement to some French power
distribution operators seeking for their poles in lacunary and proprietary
GIS.

All the best

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


Re: [Tagging] Feature proposal - Lines management - Voting

2020-06-05 Thread François Lacombe
Hi all,

This little reminder is about the voting stage of Line management proposal
which ends tomorrow evening.
https://wiki.openstreetmap.org/wiki/Proposed_features/Lines_management

20 people already took time to give their opinion, which is comparable to
the previous Line attachment proposal last year. Thank you.
Feel free to complete the list if you want to.

All the best

François

Le ven. 22 mai 2020 à 23:18, François Lacombe  a
écrit :

> Hi all,
>
> The RFC on Lines management proposal is now over and here starts the vote
> for 15 days.
> https://wiki.openstreetmap.org/wiki/Proposed_features/Lines_management
>
> As explained previously, it's the second stage of tower:type refinement
> project for power/utility supports.
> The point is to document particular situations of lines topology around
> their supports and free :type keys
> https://www.openstreetmap.org/user/InfosReseaux/diary/391058
> Tagging has been mainly experienced on power lines but suitable on many
> other kinds if comparable topologies are found.
>
> Many discussions lead to valuable tagging solutions despite a very
> technical topic. Thank again to anyone involved in this.
> As shown on examples, it's about visible properties of power lines and
> obviously not a mandatory tagging.
> Don't be afraid about 12k object to edit, there are about dozen of
> millions of poles/towers remaining to map out there.
>
> Feel free to put your opinion about this proposal at the bottom of the
> page, all the best
>
> François
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] line=* tag on railway lines

2020-05-29 Thread François Lacombe
Hi

Le ven. 29 mai 2020 à 00:03, Jack Armstrong  a
écrit :

>
> I think naming the same thing two times is not a best practice?
>
> Indeed
I'd use name=* on rails only if rails actually have a name.

According to this discussion, may I remove the line=* railway chapter on
wiki?
https://wiki.openstreetmap.org/wiki/Key:line

All the best

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


Re: [Tagging] line=* tag on railway lines

2020-05-28 Thread François Lacombe
Hi

Le jeu. 28 mai 2020 à 21:14, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> a écrit :

>
> Yes, name tag is for name of the object.
>

I agree
I'd be in favour of removing such mention on wiki wouldn't you?

Le jeu. 28 mai 2020 à 21:56, Jack Armstrong  a
écrit :

> If the rail is tagged name=* but the railway also has a relation with the
> same name, isn't this naming something twice? it seems to me the relation
> is sufficient and the rail itself should not be named?
>

We had the question on power lines as well.
At least it's not the same name : name of the physical line, the rails
versus the name of the commercial service

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


[Tagging] line=* tag on railway lines

2020-05-28 Thread François Lacombe
Hi all,

On the line=* wiki page, it is mentioned this key is used to give railway
lines names in combination with branch=*
https://wiki.openstreetmap.org/wiki/Key:line

Shouldn't name=* be used instead?

I don't know the use case precisely, may someone more familiar with railway
lines could give us more information please?
Should we encourage this usage or discourage it?

Didn't found anything on https://wiki.openstreetmap.org/wiki/Key:railway

All the best, thank you

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


Re: [Tagging] Feature proposal - Lines management - Voting

2020-05-22 Thread François Lacombe
Le ven. 22 mai 2020 à 23:34, Joseph Eisenberg 
a écrit :

> I've never really understood this section of the proposal. I was hoping
> this would be clarified since it still seemed to be under discussion:
>

Answers are available on Talk
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Lines_management#Level_composition_matrix_confusion

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


[Tagging] Feature proposal - Lines management - Voting

2020-05-22 Thread François Lacombe
Hi all,

The RFC on Lines management proposal is now over and here starts the vote
for 15 days.
https://wiki.openstreetmap.org/wiki/Proposed_features/Lines_management

As explained previously, it's the second stage of tower:type refinement
project for power/utility supports.
The point is to document particular situations of lines topology around
their supports and free :type keys
https://www.openstreetmap.org/user/InfosReseaux/diary/391058
Tagging has been mainly experienced on power lines but suitable on many
other kinds if comparable topologies are found.

Many discussions lead to valuable tagging solutions despite a very
technical topic. Thank again to anyone involved in this.
As shown on examples, it's about visible properties of power lines and
obviously not a mandatory tagging.
Don't be afraid about 12k object to edit, there are about dozen of millions
of poles/towers remaining to map out there.

Feel free to put your opinion about this proposal at the bottom of the
page, all the best

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


Re: [Tagging] Permanent ID/URI --- off topic email

2020-05-19 Thread François Lacombe
Hi all

As OSM id isn't a stable id (and will never be I think), the only way to
reliably achieve what you want Stuart is to proceed with a ref tag.
It's a long term job and often questioned/refined to best match
codification scheme rolled out on a specific place/local level.

We may take advantage that two nodes can't overlap on OSM, eventually for
nodes but it won't work for ways.

My 2 cts
François

Le mar. 19 mai 2020 à 10:04, Philip Barnes  a écrit :

> On Tue, 2020-05-19 at 09:43 +0200, European Water Project wrote:
>
> Dear All,
>
> I am looking for a way to create permanent links  to specific objects
> (fountains and cafés) with images within our application ... and I have a
> couple of questions.
>
> How quickly do OSM node and ways numbers mutate ?  What percentage should
> I expect to change each year.  If the percentage of ids mutates slowly
> enough .. maybe this is still the best bad short term option ?
>
> I was pointed to this wiki :
> https://wiki.openstreetmap.org/wiki/Permanent_ID
>
> On the discussion page, it is mentioned that a solution is being targeted
> for end 2020 . Will there be a tool to translate actual osm node and ways
> numbers to the new permalink ids.
>
> Apparently Mangrove uses GEO URI to create perma links towards objects.
> https://en.wikipedia.org/wiki/Geo_URI_scheme. How do they deal with node
> repositioning ?  I could create a link name with first 5 latitude num
> followed by first 5 longitude num... but as soon as someone moves the node
> I would get a broken link...
>
>
> I think that will depend very heavily on what the object is. Something
> like a drinking fountain that is mapped as a single node and is too small
> to be improved into a way will be quite stable as there is no reason to
> improve it.
>
> Other nodes may change, shops/pubs/restaurants mapped as nodes can
> obviously be improved and the tags transferred to a building object.
>
> Although relying on a node id is not the best way, something based on
> maybe overpass that finds the tags seems a far more stable way to me.
>
> Phil (trigpoint)
> ___
> 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] Tag:amenity=motorcycle_taxi not approved

2020-05-09 Thread François Lacombe
Le sam. 9 mai 2020 à 19:20, Phake Nick  a écrit :

>
> What you said doesn't make sense.
> The existence of a space within the word doesn't inherently make them
> separateable.
> Like for the tag amenity=charging_station, do you think the space mean ot
> make sense to change the tagging scheme into amenity=station +
> station=charging ?
>

It depends on what your definition of station is.


>
> Your interpretation on public transit service is incorrect.
> When you board a plane from London to Paris, you didn't fly to Paris
> because they told us they would fly to Paris. You're going to Paris because
> you have expressed interest in going to Paris. Same with rideshareing or
> other rented mobility services.
>

You're lucky enough to take on planes you define your own destination first.
"Going to Paris" doesn't mean the same for a taxicab and for a plane.
Even in ridesharing, destination is given by passengers and driver doesn't
know it before meeting them (face to face or with an app, same actually).
You don't define the destination reached by plane, by train or by bus. This
is the difference I make.


>
>
>> We agree on that particular point.
>> Neverthess that doesn't make a second value of amentiy legit.
>> OSM would only have one key grouping all possible values if it was
>> relevant.
>>
>
> I am not aware of such requirement on value ever existing in OSM.
>

This was actual irony.

Le sam. 9 mai 2020 à 20:45, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> a écrit :

>
> Neverthess that doesn't make a second value of amentiy legit.
>
> Why?
>

Both have taxi service in common but the vehicle is different (and implies
really different experiences indeed)
amenity=* represents the taxi service and I find relevant to describe the
different vehicle in another key.


> OSM would only have one key grouping all possible values if it was
> relevant.
>
> Why?
>

If you accept to merge similarities and differences in values you don't
need different keys.
Who need operator key for instance?
amenity=taxi_with_cars_operated_by_Acompany
amenity=taxi_with_motorbikes_operated_by_anotherCompany
Hey it's way different things, Acompany is really bad compared to
anotherCompany.

Finally, Paul, I find your point about taxonomy thinking interesting and
will try to develop it a bit in future.
Get me well, I don't intend to ban anyone from anything.
Query tools are really important to consume data and my point wasn't to
downgrade tagging readability in general (nor to encourage K9842=V2179).
To me tourists and query tools users can only be the same persons at
different time. I've never used overpass to locate myself in any train
station, that's all.

In proposal, arguing amenity=taxi/amenity=motorbike_taxi will better
prevent errors than amenity=taxi + vehicle=* doesn't convince me : mappers
are always able to confuse two services, whatever the tagging they use can
be.

That was my 2 cts, good night

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


Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

2020-05-09 Thread François Lacombe
Hi Paul,

Le sam. 9 mai 2020 à 02:29, Paul Allen  a écrit :

>
> This isn't just about optimizing the number of tags used, it's about
> aligning with
> how most people's mental models work.  And not just the mental models
> of local mappers but also the mental models of tourists: locals don't refer
> to maps as often as tourists do.
>

Tourists aren't supposed to refer to tags to know which kind of taxi
service they can use.
Renders, tools, apps are here to ease this for them. Are you aware of
Google Maps data model when browsing it?
Even local mappers can use tools focused on a specific topic which makes
tagging less important to master to contribute.

Nevertheless, we're are discussing about things like amenity=taxi +
vehicle=* which doesn't sound that complex.
Even common language using two words "motorcycle" and "taxi" could mean we
have something to do with several keys.

Le sam. 9 mai 2020 à 06:38, Shawn K. Quinn  a écrit :

> taxi=* is already used as an access tag, so I think taxi:type=* should
> be considered instead. Perhaps amenity=taxi can default to motorcar if
> there is no taxi:type=* tag.
>

Beware of :type disadvantages.
Things like vehicle=* sounds better (or another word referring to vehicle
used).

Default to motorcar can lead to mistakes for consumers.
It's more valuable to consider vehicle unknown if absent (and encourage
mappers to explicitly define it)

Le sam. 9 mai 2020 à 08:01, Phake Nick  a écrit :

>
> "I pay a driver to take me where I want to with his vehicle" is something
> that would also be true for any other public transit vehicles.
>

I respectably disagree regarding public transit: you're not asking them to
take you where YOU want but if they actually go where THEY told us they
will.
Every word counts here.


> Motorcycle taxi is different from 4-wheeled taxi because they provide a
> different experience with different speed, charge different fare, have
> different level of convenience, can access different area, and various
> other factors.
>

We agree on that particular point.
Neverthess that doesn't make a second value of amentiy legit.
OSM would only have one key grouping all possible values if it was relevant.



> In addition to them being different kind of services, for the purpose of
> openstreetmap tagging, it's better to remember that a motorcycle taxi stand
> would look quite different from a taxi stand, use the streetspace
> differently, and thus mixing them together would also hurt any downstream
> data user who might wish to understand the situation of 4-wheeled taxi
> penetration in certain geographical area due to conflating the data with
> others that aren't of the same type. They're often regulated by different
> laws and face different operational restrictions also.
>

That could eventually be a point if all those differences were known
precisely and described.
There are many many kind of public transit stations but we're still calling
them stations and platforms.

All the best

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


Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

2020-05-08 Thread François Lacombe
Hi Joseph,

Le sam. 9 mai 2020 à 01:28, Joseph Eisenberg  a
écrit :

> François,
>
> Have you personally hired a motorcycle before, or is the assumption that
> this is the same service based on theory rather than experience?
>

I've hired some before lockdown, independently as cars when alone.
I've paid someone to take me somewhere with a vehicle.

The proposal gave several reasons that using amenity=taxi was not a good
> idea, including these:
>
> "Motorcyles have different abilities.
>
> "In contrast to a family or group which needs a 4 to 6 seat taxicab,
> single travelers may strongly prefer to hire motorcycles when available,
> due to their lower cost and ability to fit through smaller spaces in
> congested cities and rural areas with narrow roads and paths.
>
> "Motorcar taxicabs with 4 wheels in 2 tracks cannot access highway=path
> features and narrow roads, but motorcycles may be permitted and feasible
> due to their narrow width and single track."
>
> So a different tag is proposed to avoid confusion and more precisely tag
> these features."
>

I agree on those points and they legit the use of vehicle=motorcycle vs
vehicle=car imho.
As said, we always hire a driver to get us where we want in his vehicle,
whatever the vehicle is (chosen according to punctual needs)


> A taxi can carry 4 or more passengers, with their luggage or shopping, and
> they are enclosed, heated and perhaps air conditioned, and protected from
> weather. When you are traveling with your elderly mother-in-law and her
> luggage in a rainstor, a taxicab stand and an "ojek" queue are quite
> different amenities.
>

We're not having an argument about making a difference or not between
motorcycles or cars
We're opposing on how making this difference.
Enumerating relevant differences between both won't lead us to valuable
tagging I'm afraid.

As shown in 2009 discussion amenity=taxi definition is not as clear as we
may think now.
This proposal would have been an occasion to make it explicit and separate
concepts (service, vehicle, activity, whatever) which is IMHO more valuable
in tagging than having less tags on a single feature.

"using amenity=taxi for other vehicles than car could lead to errors"
Then add proper vehicle=* value on it, problem solved.


> However, taxis  use much more gasoline and the vehicle is more expensive
> to buy and maintain, so the price is higher than a motorcycle. Since they
> are 1.5 meters wider, they cannot fit though spaces less than 2.5 meters
> wide, which is a big disadvantage in cities in Asia with narrow streets or
> high traffic. Often only a motorcycle can get through traffic jams and
> narrow streets. In rural areas, only motorcycles are used to access many
> mountain villages, where 4-wheel-drive motorcars would be hard-pressed to
> travel.
>
> Equating these features would be like using one tag to for moving truck
> rental ("U-Haul" in the USA), motorcycle rental, bike rental, and
> kick-scooter rental.
>

Truck rental, motorcycle rental, bike rental and flying saucer rental all
have "rental" in their name.
I would use two tags respectively for rental and for the vehicle.

All the best

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


Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

2020-05-08 Thread François Lacombe
Hi

Le ven. 8 mai 2020 à 20:48, Phake Nick  a écrit :

> motorcycle are not the same type of service as regular taxi.
>

Then may I ask you why ?
I pay a driver to take me where I want to with his vehicle.


> The reaso  why you get the feeling of people saying "you don't understand"
> to you is because you couldn't tell others why your concern is legitimate,
> thus making it read like nonsense, even if they might make sense to you,
> thought I am still not sure about how the distinction of electric power or
> not is going to on the same level as different types of services.
>

There is a lack of understanding in both sides here because I don't get why
having two different amenity values is a benefit.

Back in 2009 a wiki contributor explained he's using amenity=taxi +
motorcycle=yes. Despite motorcycle=yes can be awkward as it is used as an
access tag, the idea to complete taxi service with explicit vehicle
definition is useful.
https://wiki.openstreetmap.org/wiki/Talk:Tag:amenity%3Dtaxi#Motorcycles.3F
As I assume motorcycle taxi service is the same as taxicab service (change
my mind upside), I find convenient to only define extra vehicule types
instead of the whole service we already have in amenity=taxi.

All the best

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


Re: [Tagging] Feature Proposal - RFC - Pumps (wells and many other things)

2020-04-16 Thread François Lacombe
Hi all,

As explained here
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Pumping_proposal#Consider_drivers_as_pump_specific_devices

motion_driver=* is the best term I found to make a distinction with actual
(human) drivers and prevent to use "pump" word as it have to be suitable
for fans and compressors at least.
Any better possibility is acceptable unless it involves "pump".

Le jeu. 16 avr. 2020 à 21:44, Martin Koppenhoefer 
a écrit :

>
> aren’t manual pumps powered as well? (human powered?)
> Manual means by hand, or is it meant to extend to horse powered?
>

I agree, any pump requires mechanical power to work.
That's why manual is a possible value of motion_driver.
Is it possible to add motion_driver=horses if necessary.


> I agree discouraging these unclear tags seems to make sense.
>

Thank you

All the best

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


Re: [Tagging] Feature Proposal - RFC - Pumps (wells and many other things)

2020-04-12 Thread François Lacombe
Hi all

RFC on pumping proposal is went really well, with significant progresses
made these past weeks thanks to useful comments received (see Talk).
https://wiki.openstreetmap.org/wiki/Proposed_features/Pumping_proposal

Tagging has been adapted to take care of several concerns regarding
windpumps, wells and semantic complexity relative to benefits it brings.
It is still proposed to discourage pump=powered/manual as they're at least
redundant with proposed classification of pumps/drivers technologies.
Important distinction between manual and powered pumps is still possible
with the help of motion_driver key.

I'm now looking for more examples with increased diversity of situations.
Due to covid lockdown I'm not able to get pictures of pumps in place. It
would be a pleasure to give a try to proposed tagging if someone has
existing pictures to challenge it.
Wikimedia commons will also be a privileged source of pictures as well.

Thank in advance for any additional input, all the best

François

Le jeu. 19 mars 2020 à 22:51, François Lacombe 
a écrit :

> Hi Joseph and thank you for such a quick and complete comment session
>
> That 7 points allowed to change the proposal a bit and include
> man_made=windmill, watermill instead of actuator.
> Answers are available in Talk :
> https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Pumping_proposal
> I hope lacks of clarity are now fixed.
> In case an answers solve a problem, don't hesitate to use {{Resolved|
> comment}} template to close it.
>
> Again, anyone would be welcome to propose situations involving pumps to
> complete example sections.
>
> All the best
>
> François
>
> Le jeu. 19 mars 2020 à 03:27, Joseph Eisenberg 
> a écrit :
>
>> I oppose deprecating pump=powered, pump=manual, and pump=no. This is a
>> simple, clear system for use with water wells, and it is widely
>> supported.
>>
>> 1) Clarify use with man_made=water_well
>>
>> Currently 88% of uses of pump=* are with man_made=water_well (the rest
>> are with amenity=drinking_water) and with the 3 values: pump=powered,
>> pump=manual, pump=no. This is a simple and intuitive system for
>> mapping wells in developing countries and rural areas.
>>
>> Please clarify if you are asking mappers to add a separate
>> man_made=pump feature or if that should only be used when there is no
>> man_made=water_well feature.
>>
>> Why should we drop the use of pump=powered, pump=manual, pump=no?
>> Distinguishing pump=powered, pump=manual is easy: you can hear the
>> sound of an electric or diesel motor, and a manual pump has an obvious
>> handle or similar. And pump=no is a well with a bucket or similar.
>>
>> 2) How can mappers figure out the technology of the pump?
>> How are mappers expected to find out the pump technology mechanism?
>> Most pumps are located deep inside the well, or hidden in a service
>> building or structure next to the well. And why would this information
>> be worth mapping?
>>
>> 3) Key:actuator
>> The proposal mentions: actuator=windmill, actuator=watermill, and
>> actuator=beam_engine. What do these have to do with pumps?
>>
>> The current use of the key actuator is quite rare, but the documented
>> values are: actuator=manual, actuator=electric_motor,
>> actuator=pneumatic_cylinder, actuator=hydraulic_cylinder - these don't
>> seem to have anything to do with windmills and watermills?
>>
>> What about the exiting tags man_made=windpump, man_made=windmill,
>> man_made=watermill? Are you proposing to deprecate these common tags?
>>
>> (also in the examples "actuator=manual" is mentioned, but it isn't in the
>> list)
>>
>> -- Joseph Eisenberg
>>
>> On 3/19/20, Joseph Eisenberg  wrote:
>> > François,
>> >
>> > Could you please simplify the "==Proposal==" section and make it 100%
>> > clear:
>> >
>> > 1) What new Keys and Tags (Key=Value) are being approved by the proposal
>> > 2) What old Keys and Tags are being deprecated
>> > 3) Move the Proposal section to the top, before Rationale, so people
>> > will be clear on what the proposal is going to do if it is approved.
>> >
>> > This is the current "==Proposal==" section. It's not clear what new
>> > tags are being proposed and what old tags are being deprecated.
>> >
>> >
>> > "It is proposed to complete OSM tagging for pumps used in any domain
>> > with the following tags :
>> >
>> > man_made=pump
>> > pump:output=*
>> > pump=* is currenlty established to state if a water well runs wit

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

2020-04-05 Thread François Lacombe
Hi,

+1 with Joseph, proposed values are more usable than digits.

Le dim. 5 avr. 2020 à 20:02, Kevin Kenny  a écrit :

> I'm a little intimidated by the process, particularly the
> administration of the vote (Who's a qualified elector? Who can serve
> as scrutineer?) and the need to stitch the result into the Wiki.  Some
> of what's needed for the latter seems to require knowledge of the
> Wiki's templating conventions, which appear to be obscurely documented
> at best, and with which I'm unfamiliar. (Also, it brings up unpleasant
> memories. I've burnt my fingers on Wikipedia in the past.)
>

No problem : voting is a pretty simple phase :
Open the vote, announce it on mailing list (here), wait 15 days to have
some opinions and close it
Any wiki user can vote, cons vote should come with a little explanations.
If you get at least 74% of pros (without counting abstain as cons), the
proposal is adopted and cleanup can begin. Anyone can help you to move what
is proposed in tagging pages.
It is recommended to prepare this cleanup with a section like this one,
showing affected pages and replaced keys (if applicable) :
https://wiki.openstreetmap.org/wiki/Proposed_features/Lines_management#Edition_management

We are here to help if needed, keep going !

All the best

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


Re: [Tagging] Feature proposal - RFC - Overhead lines management (consecutive to line_attachment)

2020-03-27 Thread François Lacombe
Hi and thank you Joseph,

Answers are on the Talk page
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Lines_management

All the best

François

Le ven. 27 mars 2020 à 01:55, Joseph Eisenberg 
a écrit :

> The explanation of line_management=branch is not very clear:
>
> "==Loops are actual branches==
> Former undocumented key {{Tag|branch:type}} had a value for
> connections between several power lines coming from the same
> direction: ''loop''.
>
> "It is proposed to consider them as branches due to
> [http://osm.janos-koenig.de/IMG_0046.JPG such situations] where 3
> lines connect to the same support and look like a loop but shouldn't
> be described this way."
>
> What does this mean?
>
> Another part says:
>
> tower:type=branch ( + branch:type=loop) -> to be replaced by
> line_management=branch
>
> "Two or more independent circuits are connected in the same direction
> to maintain a dead part of the network under a positive voltage"
>
> What's a dead part of the network? What do you mean by positive
> voltage, can voltage be negative?
>
> Also, it's mentioned that tower:type=crossing (where a power line
> crosses a river or canyon) should be replaced by height=* + designe=*
> where "A support is significantly higher and stronger to allow a line
> to cross an obstacle like rivers"
>
> Are you proposing any new values of "design=*" for this, or should
> existing values be used?
>
> -- Joseph Eisenberg
>
> On 3/27/20, François Lacombe  wrote:
> > Hi all,
> >
> > The line_management=* proposal vote will be open starting on next Monday.
> > https://wiki.openstreetmap.org/wiki/Proposed_features/Lines_management
> >
> > Clarifications and improvements have been made as follow :
> > * Focus on power only and remove telecom usecase. Proposed terminology is
> > generic enough to be used in telecom sector in a further proposal to give
> > better solutions to tag telecom supports.
> > * Remove line_management=loop and consider them as line_management=branch
> >
> > Proposed key has been used by 6 people on ~450 features already without
> big
> > problems it seems.
> >
> > Feel free to raise concerns or wait next week to vote on the document.
> >
> > All the best
> >
> > François
> >
> > Le jeu. 9 janv. 2020 à 01:08, François Lacombe <
> fl.infosrese...@gmail.com>
> > a écrit :
> >
> >> Hi all,
> >>
> >> This proposal is still in RFC and may be voted in a couple of weeks as
> >> evaluation shown no issue so far, at least on transmission power lines.
> >> line_management tag is used carefully for testing.
> >> Read more :
> https://www.openstreetmap.org/user/InfosReseaux/diary/391058
> >>
> >> Nevertheless it's an opportunity to review the branch:type tag
> >> replacement
> >> with line_management=*
> >>
> >> i'm still looking for an appropriate illustration for two values
> >> examples:
> >> * line_management=cross (two or more lines with different directions
> >> sharing the same support without connecting)
> >> * line_management=loop (two or more lines coming from the same direction
> >> are connected as to mock some of them)
> >>
> >> Feel free to propose and complete if you find corresponding situations
> on
> >> ground
> >>
> >> Thanks in advance
> >>
> >> François
> >>
> >> Le sam. 26 oct. 2019 à 20:59, François Lacombe
> >> 
> >> a écrit :
> >>
> >>> Hi all,
> >>>
> >>> After the review of line_attachment key this summer and Karlsruhe
> >>> hackweekend at Geofabrik headquarters last week, let me introduce the
> >>> second stage of tower:type key cleaning project for power lines. Great
> >>> time
> >>> has been spent on discussing and finding relevant situations.
> >>> https://wiki.openstreetmap.org/wiki/Proposed_features/Lines_management
> >>>
> >>> It's now about the arrangement of power lines around their supports:
> how
> >>> the lines branch, split, transpose or terminate.
> >>> As current tagging (without line_management) still collides with any
> >>> tower building function, the line_management key may be a solution to
> >>> strip
> >>> unrelated values from tower:type.
> >>>
> >>> I've published a diary entry to give more explanations
> >>> https://www.openstreetmap.org/user/InfosReseaux/diary/391058
> 

Re: [Tagging] Feature proposal - RFC - Overhead lines management (consecutive to line_attachment)

2020-03-26 Thread François Lacombe
Hi all,

The line_management=* proposal vote will be open starting on next Monday.
https://wiki.openstreetmap.org/wiki/Proposed_features/Lines_management

Clarifications and improvements have been made as follow :
* Focus on power only and remove telecom usecase. Proposed terminology is
generic enough to be used in telecom sector in a further proposal to give
better solutions to tag telecom supports.
* Remove line_management=loop and consider them as line_management=branch

Proposed key has been used by 6 people on ~450 features already without big
problems it seems.

Feel free to raise concerns or wait next week to vote on the document.

All the best

François

Le jeu. 9 janv. 2020 à 01:08, François Lacombe 
a écrit :

> Hi all,
>
> This proposal is still in RFC and may be voted in a couple of weeks as
> evaluation shown no issue so far, at least on transmission power lines.
> line_management tag is used carefully for testing.
> Read more : https://www.openstreetmap.org/user/InfosReseaux/diary/391058
>
> Nevertheless it's an opportunity to review the branch:type tag replacement
> with line_management=*
>
> i'm still looking for an appropriate illustration for two values examples:
> * line_management=cross (two or more lines with different directions
> sharing the same support without connecting)
> * line_management=loop (two or more lines coming from the same direction
> are connected as to mock some of them)
>
> Feel free to propose and complete if you find corresponding situations on
> ground
>
> Thanks in advance
>
> François
>
> Le sam. 26 oct. 2019 à 20:59, François Lacombe 
> a écrit :
>
>> Hi all,
>>
>> After the review of line_attachment key this summer and Karlsruhe
>> hackweekend at Geofabrik headquarters last week, let me introduce the
>> second stage of tower:type key cleaning project for power lines. Great time
>> has been spent on discussing and finding relevant situations.
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Lines_management
>>
>> It's now about the arrangement of power lines around their supports: how
>> the lines branch, split, transpose or terminate.
>> As current tagging (without line_management) still collides with any
>> tower building function, the line_management key may be a solution to strip
>> unrelated values from tower:type.
>>
>> I've published a diary entry to give more explanations
>> https://www.openstreetmap.org/user/InfosReseaux/diary/391058
>>
>> I'd draw your attention to the conclusion :
>> "Mapping utility supports like power towers or telecom poles is a
>> worldwide challenge. For instance in France, professionals including
>> operators and contractors rolling out overhead telecom cables are currently
>> looking for approx. 16 millions missing shared power poles that weren’t
>> mapped in operational GIS. There’s no doubt updating OSM can help."
>> There's no short term risk of importing massive data, at least.
>>
>> This proposal is a first try and may cause worries about some local
>> concerns. RFC is here to solve this prior to vote anything.
>> We have to focus on simple situations to begin with to adopt the right
>> semantic. More complex cases will be added step by step.
>> Feel free to open a topic in Talk page.
>>
>> All the best
>>
>> François
>>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Clearer definition of tunnel=flooded: when should it be used instead of tunnel=yes or tunnel=culvert?

2020-03-24 Thread François Lacombe
Hi all,

According to this discussion, I tried to update tunnel=flooded and
waterway=pressurised to make things more clear.

Feel free to improve if I made any mistake, examples list are always open
to add new situations if you find relevant ones.

All the best

François

Le lun. 23 mars 2020 à 01:30, Joseph Eisenberg 
a écrit :

> "To me 'tunnel=flooded' means that is cannot really be used for/by
> anything other than the fluid in it due to the very small amount of
> space left, if any. "
>
> Yes, that is what I would have guessed, too.
>
> I would have guessed that a canal tunnel which is passable by boats
> would be tunnel=yes, whether or not there is a side-path.
>
> (This is the problem with proposals that introduce several new tags
> all at once. I would have been better to discuss tunnel=flooded
> separately, so that this problem would not have occured.)
>
> -- Joseph Eisenberg
>
> On 3/23/20, Warin <61sundow...@gmail.com> wrote:
> > On 23/3/20 9:08 am, Volker Schmidt wrote:
> >>
> >>
> >> On Sun, 22 Mar 2020 at 19:09, François Lacombe
> >> mailto:fl.infosrese...@gmail.com>> wrote:
> >>
> >> Hi Volker,
> >> ...
> >> Fully disposed to make any improvement to wiki according to those
> >> points.
> >>
> >> Thanks, Francois.
> >>
> >> There is possibly a language bias (error?) in the use of tunnel=flooded.
> >> I am not a native speaker, but "flooded" to me means at least "more
> >> water than normal", and from this discussion it seems that we are
> >> talking about the normal presence of water in these structures.
> >
> >
> > Normal? No I don't think so. Some 'tunnels may be designed only to carry
> > water and have no real room for anything else.  I am thinking of hydo
> > schemes where tunnels are used
> >
> > To me 'tunnel=flooded' means that is cannot really be used for/by
> > anything other than the fluid in it due to the very small amount of
> > space left, if any.
> >
> > Humm ... a smaller description? '"tunnel=flooded' ... full or nearly
> > full of fluid so that the tunnel cannot be used for anything else' ???
> >
> >> Tag use tunnel=flooded: 2 in the UK,
> >> >> Many, if not the majority of the UK Inland Waterways canals have no
> >> tow-path.
> >> > Then tunnel=flooded is more appropriate.
> >> No, definitely not. These tunnels are not "flooded" at all, the water
> >> level in them is carefully controlled
> >> (The original method of powering the boats in these canals were men
> >> laying on their back and "walking" with their feet upwards along the
> >> tunnel ceiling. The French canals, being constructed later, generally
> >> did have tow-paths also in the tunnels see for example the
> >> Tunnel_de_Mauvages
> >> <
> https://www.google.com/url?sa=i=https%3A%2F%2Ffr.wikipedia.org%2Fwiki%2FTunnel_de_Mauvages=AOvVaw3UK-_RmcKBM_5fKTGMZyjW=1584997257128000=images=vfe=0CA0QjhxqFwoTCOijlIn9rugCFQAdABAS
> >.
> >>
> >> I remember when I was a boy my father showed me the tractors pulling
> >> the ships through the old tunnel near Arzwiller in Alsace on the same
> >> canal)
> >> They are uniformly tagged (correctly) as waterway=canal and tunnel=yes.
> >> I mentioned them in the context that tunnel=yes does not imply a
> >> tow-path.
> >>
> >> I had glanced at yourHydropower water supplies proposal, but I think I
> >> failed to intervene on three specific points:
> >>
> >>  1. The first one are the inverted siphons (botte sifone
> >> <https://it.wikipedia.org/wiki/Botte_sifone>, pont-siphon
> >> <https://fr.wikipedia.org/wiki/Pont-siphon>), which are
> >> gravity-pressurised always-water-filled sections of non-navigable
> >> canals. I usually map them as culverts, and i have just started to
> >> add the new tag culvert=inverted_siphon to the first three of them.
> >>  2. The second point is that the distinction between water-filled and
> >> part-filled water conducts is problematic: culverts that are
> >> frequently used to conduct free-flowing drains, ditches,
> >> irrigation canals, freshwater canals under roads can be anything
> >> from empry to fully filled (and slightly pressurised) depending on
> >> precipitations.
> >>  3. waterway=pressurised cannot be used together with waterway=canal
> >> for the inverted-siphon situation
> >>
> >> Volker
> >>
> >
> >
>
> ___
> 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] Clearer definition of tunnel=flooded: when should it be used instead of tunnel=yes or tunnel=culvert?

2020-03-22 Thread François Lacombe
Hi Volker,

Thank you for your answer

Le dim. 22 mars 2020 à 23:09, Volker Schmidt  a écrit :

>
>
> On Sun, 22 Mar 2020 at 19:09, François Lacombe 
> wrote:
>
>> Hi Volker,
>> ...
>> Fully disposed to make any improvement to wiki according to those points.
>>
>
> Thanks, Francois.
>
> There is possibly a language bias (error?) in the use of tunnel=flooded.
> I am not a native speaker, but "flooded" to me means at least "more water
> than normal", and from this discussion it seems that we are talking about
> the normal presence of water in these structures.
>

This objection was raised as it could mean it's more than normal, but no
better term has been proposed so far
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Hydropower_water_supplies#tunnel.3Dflooded.3F

Flooded has been taken as simpler  "Full of water".
"A flooded tunnel is an artificial structure intended to channel water on a
significant distance. Its dimensions and length allow human to fit inside
but safe walking is impossible due to high amount of water or other fluid
expected in operation."

Tag use tunnel=flooded: 2 in the UK,
> >> Many, if not the majority of the UK Inland Waterways canals have no
> tow-path.
> > Then tunnel=flooded is more appropriate.
> No, definitely not. These tunnels are not "flooded" at all, the water
> level in them is carefully controlled
>

Filling a tunnel with water doesn't prevent you to control the level.
It just means you won't be able to walk in and stay dry.


> (The original method of powering the boats in these canals were men laying
> on their back and "walking" with their feet upwards along the tunnel
> ceiling. The French canals, being constructed later, generally did have
> tow-paths also in the tunnels see for example the Tunnel_de_Mauvages
> <https://www.google.com/url?sa=i=https%3A%2F%2Ffr.wikipedia.org%2Fwiki%2FTunnel_de_Mauvages=AOvVaw3UK-_RmcKBM_5fKTGMZyjW=1584997257128000=images=vfe=0CA0QjhxqFwoTCOijlIn9rugCFQAdABAS>.
> I remember when I was a boy my father showed me the tractors pulling the
> ships through the old tunnel near Arzwiller in Alsace on the same canal)
> They are uniformly tagged (correctly) as waterway=canal and tunnel=yes.
> I mentioned them in the context that tunnel=yes does not imply a tow-path.
>

Agreed that tunnels with tow-paths like Tunnel de Mauvages should be tagged
with tunnel=yes.


> I had glanced at your Hydropower water supplies proposal, but I think I
> failed to intervene on three  specific points:
>
>1. The first one are the inverted siphons (botte sifone
><https://it.wikipedia.org/wiki/Botte_sifone>, pont-siphon
><https://fr.wikipedia.org/wiki/Pont-siphon>), which are
>gravity-pressurised always-water-filled sections of non-navigable canals. I
>usually map them as culverts, and i have just started to add the new tag
>culvert=inverted_siphon to the first three of them.
>
> No problem with this
If air can't get inside due to lowest elevation of inverted siphon, this
would be waterway=pressurised.

>
>1. The second point is that the distinction between water-filled and
>part-filled water conducts is problematic: culverts that are frequently
>used to conduct free-flowing drains, ditches, irrigation canals, freshwater
>canals under roads can be anything from empry to fully filled (and slightly
>pressurised) depending on precipitations.
>
> Finding a waterway punctually pressurised because of exceptional
conditions and another pressurised on purpose makes a *big difference*.
waterway=pressurised covers only the second situation where the intake of
conduit (tunnel or pipeline) is placed on purpose under the water level as
to prevent air coming inside.
For instance, you'll find hydropower plant operator stopping immediately
its turbines if water goes under a certain level in upstream dam lake
because it would allow air to get inside headrace and penstocks and finally
cause big damages on its equipment.

>
>1. waterway=pressurised cannot be used together with waterway=canal
>for the inverted-siphon situation
>
> Agreed, because waterway=canal is expected to be free flowing
https://wiki.openstreetmap.org/wiki/Key:waterway#Values

I see no problem to:
* alternate canal/pressurised on different waterway sections depending on
their condition.
* use waterway=canal on a culvert that isn't expected to be pressurised
even if this occurs on exceptional conditions.

I agree this could be more clear on wiki and will require more description
and examples
Would you like to collaborate to give some pictures or situations you are
familiar with?

All the best

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


Re: [Tagging] Clearer definition of tunnel=flooded: when should it be used instead of tunnel=yes or tunnel=culvert?

2020-03-22 Thread François Lacombe
Hi Volker,

Le dim. 22 mars 2020 à 18:35, Volker Schmidt  a écrit :

> Slippery terrain. In  the sense of definitions.
>
> Concerning the tunnel=flooded wiki page:
>
> The symbol shows free flowing water (air above the surface), wherea the
> first example is for a headrace where "no air can get inside" Why is this
> situation not tagged as pipeline? (see last row  in this table
> ?)
>

The point of the symbol is to show water in the whole tunnel section,
independently of flowing regime.

To me a tunnel is different from a pipeline in regard of structure and
building technique.
Both tunnels and pipelines could have usage=headrace or usage=transmision
https://wiki.openstreetmap.org/wiki/Proposed_features/Hydropower_water_supplies#Headraces_tunnels_and_canals


> The page states:
> ... tunnel =yes
>  where a path is
> usually intended for human to safely pass and where water level is usally
> controlled for safety reasons "
> I don't find areference to this implied meaning of tunnel=yes
> Many, if not the majority of the UK Inland Waterways canals have no
> towpath.
>

Then tunnel=flooded is more appropriate
This distinction has been determined to introduce tunnel=flooded.
https://wiki.openstreetmap.org/wiki/Proposed_features/Hydropower_water_supplies#Human_accessibility.2C_pipelines_vs_tunnels


> Other comments on the key "tunnel", referring to taginfo "tunnel="
> :
>
> Absence of  "tunnel= *"  means: "this way is not in a tunnel of any type"
> "tunnel=yes" on a way means: "this way is in a tunnel of some type"
>
> It looks as if tunnel:type
>  is practially not
> used
> We use instead tunnel= *
>  to indicate the
> type of tunnel.
>

:type suffix doesn't bring any additional information, indeed.


> This tagging is unfortunate, but in line with the (original) bridge
> approach
> tunnel=culvert is the most frequent value: 1208667 uses
> tunnel=flooded is rare in comparison; 2060 uses
>
> There is also 3337 instances of tunnel=covered, which, at least in Italy
> (140)  seem mainly tagging errors
>
+1

Fully disposed to make any improvement to wiki according to those points.

All the best

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


Re: [Tagging] Clearer definition of tunnel=flooded: when should it be used instead of tunnel=yes or tunnel=culvert?

2020-03-22 Thread François Lacombe
Hi Joseph,

Here are some points to make it clearer

This is the base situation :
https://wiki.openstreetmap.org/wiki/File:Waterway_drain_outlet.jpg

Le dim. 22 mars 2020 à 00:46, Joseph Eisenberg 
a écrit :

> Should a waterway=river every be tunnel=flooded, or is it then a canal?
>

Even if waterway=river is listed under useful combinations I think this
table is more correct :
https://wiki.openstreetmap.org/wiki/Key:waterway#Values
Then only drain or canal could be suitable for tunnel=flooded and
waterway=river could be removed from combinations (and even be marked as
incompatible)


> How safe for walking does the tunnel have to be?
>

Flooded means you can't stay dry and expose yourself to drowning hazard,
even if there no water at the time you get inside the tunnel.


> What about if a boat can go through the tunnel, but you can't walk?
>

It's flooded, no exceptions

Its not the case for Canal Saint Martin in Paris, since water level can't
rise up the built in passageways even if boat use to go inside too
So here tunnel=yes works.
https://www.urbextour.com/en/saint-martin-canal-is-the-biggest-underground-river-in-paris/

All the best

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


Re: [Tagging] Pumps (wells and many other things)

2020-03-19 Thread François Lacombe
Hi Michael,

Thank you for such interesting links :)
I was looking for established classification but most of time several
properties are mixed in attributes which is less usable.
My points below.

Le jeu. 19 mars 2020 à 05:01, Michael Patrick  a
écrit :

> Since pumps have been a manufactured commodity for about 400 years ( 
> https://www.worldpumps.com/general-processing/features/a-brief-history-of-pumps/
> ) there is an abundance of existing typologies and taxonomies dealing with
> pumps. If the goal is a general tagging scheme that can further be refined
> when needed to more detailed descriptions, there is a fairly low delta from
> a complete scheme compared to an incomplete one which will grow by random
> accretion. See  IEEE GlobalSpec's Engineering360
> https://www.globalspec.com/pfdetail/pumps/types
>
That sounds the most promising repository I could integrate to proposed
pump=* values.
Note that some proposed values already match this IEEE classification
(Wikipedia may took inspiration there)


> 
> There are public domain classification systems available also, like
> *UNSPSC* # *4015151 *takes you to a  Stainless Steel Deep Well
> Submersible Pump. See  the section " 2.2. Industrial Categorization
> Schemes and Product Data Management in 'Inter-organizational Networks" in 
> Integrated
> Product Ontologies for Inter-Organizational Networks' at
> https://pdfs.semanticscholar.org/c471/40672c0c2e5a34c098fcd2809185537ee985.pdf
>

Main problem of "Stainless Steel Deep Well Submersible Pump." is such a
name give many information, but let the mechanism unknown.
We've got material=*, submersible=yes/no and eventually man_made=water_well
but no corresponding value for pump=*
I've got the same issue with European INSPIRE classes as well in other
projects.

Once solved, this would be useful to give more details about a given pump=*
value in a further proposal.

All the best

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


Re: [Tagging] Feature Proposal - RFC - Pumps (wells and many other things)

2020-03-19 Thread François Lacombe
Hi Joseph and thank you for such a quick and complete comment session

That 7 points allowed to change the proposal a bit and include
man_made=windmill, watermill instead of actuator.
Answers are available in Talk :
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Pumping_proposal
I hope lacks of clarity are now fixed.
In case an answers solve a problem, don't hesitate to use {{Resolved|
comment}} template to close it.

Again, anyone would be welcome to propose situations involving pumps to
complete example sections.

All the best

François

Le jeu. 19 mars 2020 à 03:27, Joseph Eisenberg 
a écrit :

> I oppose deprecating pump=powered, pump=manual, and pump=no. This is a
> simple, clear system for use with water wells, and it is widely
> supported.
>
> 1) Clarify use with man_made=water_well
>
> Currently 88% of uses of pump=* are with man_made=water_well (the rest
> are with amenity=drinking_water) and with the 3 values: pump=powered,
> pump=manual, pump=no. This is a simple and intuitive system for
> mapping wells in developing countries and rural areas.
>
> Please clarify if you are asking mappers to add a separate
> man_made=pump feature or if that should only be used when there is no
> man_made=water_well feature.
>
> Why should we drop the use of pump=powered, pump=manual, pump=no?
> Distinguishing pump=powered, pump=manual is easy: you can hear the
> sound of an electric or diesel motor, and a manual pump has an obvious
> handle or similar. And pump=no is a well with a bucket or similar.
>
> 2) How can mappers figure out the technology of the pump?
> How are mappers expected to find out the pump technology mechanism?
> Most pumps are located deep inside the well, or hidden in a service
> building or structure next to the well. And why would this information
> be worth mapping?
>
> 3) Key:actuator
> The proposal mentions: actuator=windmill, actuator=watermill, and
> actuator=beam_engine. What do these have to do with pumps?
>
> The current use of the key actuator is quite rare, but the documented
> values are: actuator=manual, actuator=electric_motor,
> actuator=pneumatic_cylinder, actuator=hydraulic_cylinder - these don't
> seem to have anything to do with windmills and watermills?
>
> What about the exiting tags man_made=windpump, man_made=windmill,
> man_made=watermill? Are you proposing to deprecate these common tags?
>
> (also in the examples "actuator=manual" is mentioned, but it isn't in the
> list)
>
> -- Joseph Eisenberg
>
> On 3/19/20, Joseph Eisenberg  wrote:
> > François,
> >
> > Could you please simplify the "==Proposal==" section and make it 100%
> > clear:
> >
> > 1) What new Keys and Tags (Key=Value) are being approved by the proposal
> > 2) What old Keys and Tags are being deprecated
> > 3) Move the Proposal section to the top, before Rationale, so people
> > will be clear on what the proposal is going to do if it is approved.
> >
> > This is the current "==Proposal==" section. It's not clear what new
> > tags are being proposed and what old tags are being deprecated.
> >
> >
> > "It is proposed to complete OSM tagging for pumps used in any domain
> > with the following tags :
> >
> > man_made=pump
> > pump:output=*
> > pump=* is currenlty established to state if a water well runs with a
> > powered or manual pump (actually how the pump is driven if it exists).
> > We also need a terminology to define the pump technology as many sorts
> > exist in industry. It's then proposed to refurbish this tag with
> > values related to pumps mechnanisms.
> >
> > Devices used to drive pumps (and get water in case of water wells)
> > would be better described with existing actuator=* tag instead of
> > pump. handle=* is also suitable for manual pumps or emergency usage
> > with manual action when power isn't available.
> > This option allows to avoid pump:type=* as well."
> >
> > -- Joseph Eisenberg
> >
> > On 3/19/20, François Lacombe  wrote:
> >> Hi all,
> >>
> >> Following several discussions last month, including this one:
> >>
> https://lists.openstreetmap.org/pipermail/tagging/2020-February/051385.html
> >>
> >> Here is a proposal regarding pumps, obvious devices we all more or less
> >> know in industries or at home.
> >> This knowledge is useful for water management, water accessibility,
> >> industry moderation, emergency response...
> >> https://wiki.openstreetmap.org/wiki/Proposed_features/Pumping_proposal
> >>
> >> Classification is based upon Wikipedia community extensive work abo

[Tagging] Feature Proposal - RFC - Pumps (wells and many other things)

2020-03-18 Thread François Lacombe
Hi all,

Following several discussions last month, including this one:
https://lists.openstreetmap.org/pipermail/tagging/2020-February/051385.html

Here is a proposal regarding pumps, obvious devices we all more or less
know in industries or at home.
This knowledge is useful for water management, water accessibility,
industry moderation, emergency response...
https://wiki.openstreetmap.org/wiki/Proposed_features/Pumping_proposal

Classification is based upon Wikipedia community extensive work about 15
different pumping mechanisms. Nevertheless, I'm pretty sure some
technologies are still missing in the proposal.

It's currently the most ambitious version, including pump=* conversion for
machine mechanisms and moving driver description to existing actuator=*
Despite a consequent re-tagging effort (on water wells particularly), here
are some pros arguments :
- Use more appropriate terminology and wider possibilities for drivers with
actuator=*
- Avoid pump:type (:type doesn't bring any information)
- With 30k occurrences of pump=* and +100k for water wells, there is still
more wells to qualify than already qualified with pump availability.

Examples are for now incomplete. It would be great to have at least one use
case of each value. Feel free to contribute if you have appropriate
pictures.

Thank in advance for any comment, all the best

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


Re: [Tagging] Mapping pumps

2020-03-02 Thread François Lacombe
Hi Marc

I wonder how actuator intersects with existing pump=*, especially
actuator=manual and actuator=electric_motor
https://wiki.openstreetmap.org/wiki/Tag%3Aactuator%3Dmanual
https://wiki.openstreetmap.org/wiki/Tag%3Aactuator%3Delectric_motor

pump=* would have made a good key to precise which kind of pump it is,
there are a few :
https://en.wikipedia.org/wiki/Pump#Types

I should look for another one, less relevant I'm afraid :s

All the best

François

Le lun. 2 mars 2020 à 11:28, Marc Gemis  a écrit :

> Please note the existence of
>
> man_made=water_well + pump=manual
>
> https://wiki.openstreetmap.org/wiki/DE:Historical_Objects/Karteneigenschaften
> (search for Handschwengelpumpe)
>
> This might have to be mentioned in your proposal.
>
> regards
>
> m.
>
> On Sat, Feb 29, 2020 at 5:11 PM François Lacombe
>  wrote:
> >
> > Thank you all for answers
> >
> > Let's go for man_made=pump
> >
> > There are indeed many sorts of pumps and they would require a bunch of
> tags to be described.
> > We'll see that point in a formal proposal
> >
> > All the best
> >
> > François
> >
> > Le sam. 29 févr. 2020 à 13:36, Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> a écrit :
> >>
> >>
> >>
> >>
> >> 28 Feb 2020, 23:51 by fl.infosrese...@gmail.com:
> >>
> >> Hi all,
> >>
> >> One simple question : according to you, what is the most suitable key
> to use to map pumps?
> >> A device intended to raise pressure level of any fluid.
> >>
> >> Depends on a pump.
> >>
> >> Some are not mappable (pump in small
> >> private aquarium, thousands of pumps
> >> in a factory/refinery).
> >>
> >> Some are part of mapped objects
> >> (pumpjacks).
> >>
> >> And there are many remaining -
> >> though mapping pumps pumping
> >> - sewage
> >> - water as part of water supply
> >> - water as part of irrigation
> >> - water as part of power storage
> >> - oil in petrol stations
> >> - oil in pipelines
> >> - ? in pipelines
> >> - ? in ?
> >>
> >> Are unlikely to be benefiting from
> >> tagging as a single tag.
> >> ___
> >> 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] Mapping pumps

2020-02-29 Thread François Lacombe
Thank you all for answers

Let's go for man_made=pump

There are indeed many sorts of pumps and they would require a bunch of tags
to be described.
We'll see that point in a formal proposal

All the best

François

Le sam. 29 févr. 2020 à 13:36, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> a écrit :

>
>
>
> 28 Feb 2020, 23:51 by fl.infosrese...@gmail.com:
>
> Hi all,
>
> One simple question : according to you, what is the most suitable key to
> use to map pumps?
> A device intended to raise pressure level of any fluid.
>
> Depends on a pump.
>
> Some are not mappable (pump in small
> private aquarium, thousands of pumps
> in a factory/refinery).
>
> Some are part of mapped objects
> (pumpjacks).
>
> And there are many remaining -
> though mapping pumps pumping
> - sewage
> - water as part of water supply
> - water as part of irrigation
> - water as part of power storage
> - oil in petrol stations
> - oil in pipelines
> - ? in pipelines
> - ? in ?
>
> Are unlikely to be benefiting from
> tagging as a single tag.
> ___
> 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] Mapping pumps

2020-02-28 Thread François Lacombe
Hi all,

One simple question : according to you, what is the most suitable key to
use to map pumps?
A device intended to raise pressure level of any fluid.

man_made=pump why not
amenity=pump not at all
pipeline=pump pumps aren't always related to a pipeline (but would be a
relevant add beside pipeline=valve)

As we have power=generator, we may try water=pump. Well, pumps aren't
always related to water

pump=* already exists to state how a given pump is powered (or not)
https://wiki.openstreetmap.org/wiki/Key:pump
But it's focused on water wells while we find pumps in way more other
places with really different sizes.

We miss a key to map devices actually.

All the best
François
___
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

2020-02-27 Thread 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] man_made=gas_well Was man_made=petroleum_well vs man_made=pumping_rig

2020-02-26 Thread François Lacombe
Hi

Le jeu. 27 févr. 2020 à 00:23, Joseph Eisenberg 
a écrit :

> Different tags are used for petroleum wells vs water wells because
> they look totally different and their function for the general map
> user is quite distinct. A water well might just be a covered hole, but
> if it is a bored (drilled) well it will be connected to a manual or
> powered pump.
>

I respectably disagree Jospeh,

As mentioned, many countries actually drill ground to look for water
hundred meters down.
Water is collected like oil here and the well just look the same as
petroleum.

https://www.canadianconsultingengineer.com/features/the-great-man-made-river/
"The first, 15 years ago, was a mandate to drill and construct 117 water
wells, 36 piezometer wells and 23 exploratory wells in the Tazerbo area in
east-central Libya. Some of the wells had to be drilled to a depth of 1,200
metres, the length of 11 regulation football fields"

I think it's a bad idea to include the substance or purpose in the well
value as same facilities may be built to collect petroleum or water.


> 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.
>

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.

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

However I'm ok to say that a traditional water well (as any surface well)
don't look the same as industrial drilled wells.
So two or more value of man_made may be useful to reflect those difference
but please don't include any substance indication in man_made values.

All the best

François
___
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

2020-02-26 Thread François Lacombe
Le mer. 26 févr. 2020 à 22:06, Martin Koppenhoefer 
a écrit :

>
> these aren’t independent concepts, a water well works differently than a
> gas well. The substance (and its intended use, and the intended quantity)
> define/s the requirements for the well.
>

We both agree on the sense.
I meant semantic independence where substance got its own key and man_made
regards the well only.

Deep dug wells also exists for water (to take it out artesian aquifer for
instance or see GMMRP in Lybia), then we may need additional value for such
drilled wells.

man_made=well => "surface" well
man_made=drilled_well => very profound well
Both can get substance=* to state what we take out of each.

All the best

François
___
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

2020-02-26 Thread François Lacombe
Hi all,

Le mer. 26 févr. 2020 à 20:55, Martin Koppenhoefer 
a écrit :

>
> thank you for bringing this up. I just noticed you have added a
> deprecation note on
>
> man_made=gas_well
>
> and suggest to use man_made=petroleum_well for gas wells.
> https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dgas_well
>
> are we sure the term petroleum well  covers gas wells? (there is usually
> also some gas to deal with when extracting ”stone oil”, but a petroleum
> well which extracts only gas can still be called an “oil well”?)
>

Petroleum wells usually give gas as well (as gas is located upside
petroleum underground)

Nevertheess, should we take advantage of this discussion to use
man_made=well + substance=* only as to prevent usage of values mixing two
independant concepts (the well and the substance)?

Cheers

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


Re: [Tagging] Unremovable bollards

2020-02-16 Thread François Lacombe
Hi all,

My 2 cts : key actuator and especially actuator=hydraulic_cyclinder or
pneumatic_cylinder values are suitable for movable bollards (pchtt
noise when bollards go up and down means actuator=pneumatic_cylinder for
instance)
https://wiki.openstreetmap.org/wiki/Key:actuator

bollard=unremovable for fixed bollards sounds good to me.

All the best

François

Le sam. 15 févr. 2020 à 22:34, Volker Schmidt  a écrit :

> I have tagged around 1k bollards without "removable" or "raising", because
> they looked reasonably difficult to remove, even thought most likely nearly
> all of them are in one way or the other removable and not really fixed.
> My interpretation of the the absence of these tags has been that the
> object in question is not supposed to be removed by the normal road (or in
> my case cycle-parth) user.
> If you want to tag this fact, be aware that there are a large number of
> bollards already on the map which all would need remapping (and I certainly
> would not like to revisiting "my" bollards)
> Volker
>
> On Sat, 15 Feb 2020 at 21:33, ael  wrote:
>
>> On Sat, Feb 15, 2020 at 08:15:32PM +, John Sturdy wrote:
>> > I think that by default bollards are not removable, and that if a
>> bollard
>> > is not tagged as removable, it is reasonable to assume it's not
>> removable.
>>
>> +1
>>
>> ael
>>
>>
>> ___
>> 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] EV charging stations questions and proposals

2020-01-25 Thread François Lacombe
HI all,

According to practices and vocabulary, amenity=charging_station is mostly
used on nodes and have chances to refer to devices.
Even on situations with one single socket, the place has to include space
required to park vehicles while charging. Then it's preferable to map
places as polygons to reflect that space and keep nodes for individual
sockets or charging devices.

See
https://wiki.openstreetmap.org/wiki/Talk:Tag:amenity%3Dcharging_station#Is_this_a_device_or_a_place_.3F

What about amenity=charging_pool for such polygons including parking?

All the best

François

Le mar. 21 janv. 2020 à 18:08, François Lacombe 
a écrit :

> Hi all,
>
> Le sam. 18 janv. 2020 à 16:26, Mateusz Konieczny 
> a écrit :
>
>> Thanks for reviewing tagging and tagging docs as part of that!
>>
>
> You're welcome
>
>>
>> So charging station for bicycles and charging station for cars is
>> supposed
>> to be have the same top tag?
>>
>
> Yes I think so
>
>> According to official terminology, a station sounds to be a device in a
>> pool which refers to the place where you find several devices to charge
>> your EV. amenity=charging_station then should refers to individual devices
>> and not to whole facilities.
>> Can someone confirm this point please?
>>
>> https://wiki.openstreetmap.org/wiki/Talk:Tag:amenity%3Dcharging_station#Is_this_a_device_or_a_place_.3F
>>
>> I really hope that it is for a place.
>> If it is equivalent of tagging every pump separately then we need a new
>> tag
>> for the entire equivalent of amenity=fuel
>>
>
> Both could be desirable, for different use cases.
> This is what I asked on amenity=fuel Talk:
> https://wiki.openstreetmap.org/wiki/Talk:Tag:amenity%3Dfuel#Tagging_individual_pumps
>
> Le sam. 18 janv. 2020 à 17:26, Lionel Giard  a
> écrit :
>
>> For motorcar vs car, it seems logical to update it to motorcar as it is
>> the recommended way of tagging car access, as it is probably just an old
>> wiki information on the amenity=charging_station.
>>
>
> Agreed on this point.
> Would be great to read people that knows
>
>
>> i don't think these place are a "station".
>>
>
> So am I and it would be ok to have an additional tag for devices and
> choosing the right terminology to adopt for that
>
> We have to be careful because in some standards :
> The place including several devices = A pool
> The device with several sockets = A station
> A socket = An equipment (EVSE)
>
> Le lun. 20 janv. 2020 à 14:05, Martin Koppenhoefer 
> a écrit :
>
>>
>> I am not completely sure, but maybe "car" was chosen purposefully because
>> this is not the same as a legal access restriction?
>>
> Maybe
> This is not really meaningful nevertheless, not containing any references
> to "legal issues" in name.
> That could be improved
>
> All the best
>
> François
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] EV charging stations questions and proposals

2020-01-21 Thread François Lacombe
Hi all,

Le sam. 18 janv. 2020 à 16:26, Mateusz Konieczny 
a écrit :

> Thanks for reviewing tagging and tagging docs as part of that!
>

You're welcome

>
> So charging station for bicycles and charging station for cars is supposed
> to be have the same top tag?
>

Yes I think so

> According to official terminology, a station sounds to be a device in a
> pool which refers to the place where you find several devices to charge
> your EV. amenity=charging_station then should refers to individual devices
> and not to whole facilities.
> Can someone confirm this point please?
>
> https://wiki.openstreetmap.org/wiki/Talk:Tag:amenity%3Dcharging_station#Is_this_a_device_or_a_place_.3F
>
> I really hope that it is for a place.
> If it is equivalent of tagging every pump separately then we need a new
> tag
> for the entire equivalent of amenity=fuel
>

Both could be desirable, for different use cases.
This is what I asked on amenity=fuel Talk:
https://wiki.openstreetmap.org/wiki/Talk:Tag:amenity%3Dfuel#Tagging_individual_pumps

Le sam. 18 janv. 2020 à 17:26, Lionel Giard  a
écrit :

> For motorcar vs car, it seems logical to update it to motorcar as it is
> the recommended way of tagging car access, as it is probably just an old
> wiki information on the amenity=charging_station.
>

Agreed on this point.
Would be great to read people that knows


> i don't think these place are a "station".
>

So am I and it would be ok to have an additional tag for devices and
choosing the right terminology to adopt for that

We have to be careful because in some standards :
The place including several devices = A pool
The device with several sockets = A station
A socket = An equipment (EVSE)

Le lun. 20 janv. 2020 à 14:05, Martin Koppenhoefer 
a écrit :

>
> I am not completely sure, but maybe "car" was chosen purposefully because
> this is not the same as a legal access restriction?
>
Maybe
This is not really meaningful nevertheless, not containing any references
to "legal issues" in name.
That could be improved

All the best

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


[Tagging] EV charging stations questions and proposals

2020-01-18 Thread François Lacombe
Hi all,

As we plan to start a new "Project of the month" in France to improve EV
charging facilities mapping, a few questions raise regarding tagging of
those amenities.

We want to encourage people to use the established tagging and want to be
sure we won't do it in the wrong way as well.

amenity=charging_station recommends to use car=* to state the feature is
accessible by car.
According to more general highway tagging, motorcar=* is preferred to
describe such access rules. Should this recommendation evolve to replace
car=* by motorcar=* for charging stations ?
Open question on Talk :
https://wiki.openstreetmap.org/wiki/Talk:Tag:amenity%3Dcharging_station#Vehicles

According to official terminology, a station sounds to be a device in a
pool which refers to the place where you find several devices to charge
your EV. amenity=charging_station then should refers to individual devices
and not to whole facilities.
Can someone confirm this point please?
https://wiki.openstreetmap.org/wiki/Talk:Tag:amenity%3Dcharging_station#Is_this_a_device_or_a_place_.3F

In Europe, eMI3 standard describes how such pools and EVSE should be
identifies with unique references.
I propose https://wiki.openstreetmap.org/wiki/Key:ref:EU:EVSE as a
framework for those references with sourced documentation. Feel free to
suggest any improvement or concern you may have regarding this.

Best regards

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


Re: [Tagging] RFC free_water

2020-01-17 Thread François Lacombe
Hi Stuart

Thank you for this document.
It's a valuable effort and great to see you involve in a formal proposal
process following discussions on local mailing list.

i've posted a suggestion on the Talk page
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Free_Water

Best regards

François

Le ven. 17 janv. 2020 à 07:39, European Water Project <
europeanwaterproj...@gmail.com> a écrit :

> Dear All,
>
> Over the past days we have debated the merits of adding a new feature
> free_water and a sub-feature free_water:container, applicable in the
> context of cafes, bars, night-clubs, and restaurants which are willing to
> give out free water for bottle refill to anybody.
>
> In the attached proposal - which of course rests a draft open to
> amendments during the RFC period - I have attempted to properly take into
> account the main theme comments which seemed both logical and represent the
> majority opinion.
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Free_Water
>
> Thank you for your consideration,
>
> Stuart
> ___
> 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] Rare route=* values - route=power

2020-01-13 Thread François Lacombe
Le mar. 14 janv. 2020 à 01:33, Joseph Eisenberg 
a écrit :

> > Debate is open about route=power which may be replaced by a more
> meaningful tag (power=circuit for instance)
>
> +1 to this idea of power=circuit. And then use "type=power" instead of
> "type=route" if you make a relation,


This is a point of the whole debate and, why not type=power + power=circuit.

But i'm merely against power=circuit_segment and independent relations for
branch and trunk.
https://wiki.openstreetmap.org/wiki/Proposed_features/Power_routing_proposal#Advanced_cases:_branching

According to experience in France, a single relation involving all lines
and substations with appropriate roles (trunk, branch, whatever) is enough
and doesn't force to create several relations.
This point have to be cleared with proposal authors prior to vote.


> or if the circuit is less than a
> few hundred nodes you could just use a linear way.
>

I don't get that point.
Circuits need to be a relation.
A single way can't do the job since you have two substations to involve at
least.

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


Re: [Tagging] Rare route=* values - route=power

2020-01-13 Thread François Lacombe
Hi

Le lun. 13 janv. 2020 à 04:08, Warin <61sundow...@gmail.com> a écrit :

> Continuity can be had by the lines sharing a node. In the same way roads
> share a node to enable routing.
>
This is not a good idea since sometimes, lines sharing a node aren't
necessarily connected
https://upload.wikimedia.org/wikipedia/commons/d/de/Abzweigmast2.jpg


> I would expect a line that has n*3 cables to be tagged cables=3;3 (for
> n=2, add more ;3 for more n). This would signify that the 3 phase circuits
> are separate.
>
> Humm problem in identifying which of the 3 phases is connected to which
> when the line splits off.
>
That's the point and really difficulct to make it work without a relation.
Debate is open about route=power which may be replaced by a more meaningful
tag (power=circuit for instance)


> Who uses this route relation - as in a end use? Or is this a 'build it and
> they will come' thing?
>
It's first of all a kind of challenge to produce a whole dataset.

End use cases are the same as public transport : automatize this kind of
chart production, feed simulators, routing software...
https://www.sifoee.com/static/images/score.png
"Build it and they will come" is a bit necessarily since taking data from
GIS isn't a so common thing currently. BI and asset management are still
often separated from GIS
This has to change and osm can bring useful tools for that.

All the best

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


Re: [Tagging] Rare route=* values - route=power

2020-01-12 Thread François Lacombe
Hi Joseph,

Le sam. 11 janv. 2020 à 06:21, Joseph Eisenberg 
a écrit :

> Who is using route=power?
>

Some electricity mappers including me.

route=power represents a circuit (metallic continuity) between two or more
substations.
It is different from a line as a physical lines can hold several of those
circuits for a given distance (situations where you have n x 3 cables in a
3-phases power network).


> It has no documentation except for a rather confusing Proposal page
> (
> https://wiki.openstreetmap.org/wiki/Proposed_features/Power_routing_proposal/Tagging_similar_to_Transportation_routes
> )
> but it's used 15,000 times.
>

The proposal didn't reach the requested consensus.
There are currently two options for power routing, including route=power
but until now we didn't manage to find a single solution to be voted.
Discussion is still open I think.


> Is this feature actually useful and verifiable?
>

It is really useful and verifiable : follow the connected cables.
Some countries like France make open data available that describe those
relations.

See this Overpass query to see how it's going for RTE in France :
https://overpass-turbo.eu/s/yUw
We've just finished a few days ago to complete all ~1520 relations for
400kV and 225kV.

Le sam. 11 janv. 2020 à 07:03, Warin <61sundow...@gmail.com> a écrit :

> Is this feature actually useful and verifiable?
>
> Not usefull.
>
> Wow, how can you say that?


> However I view them similar to roads .. there maybe a power line there .. but 
> 'traffic' can be in both directions.
>
> I see no point in having a dedicated 'route' for power.
>
> Let us know how you can map this without a route relation :
https://www.openstreetmap.org/relation/6194774

Given the fact this line holds two independent circuits :
https://www.openstreetmap.org/way/130110647

All the best

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


Re: [Tagging] Feature proposal - RFC - Overhead lines management (consecutive to line_attachment)

2020-01-08 Thread François Lacombe
Hi all,

This proposal is still in RFC and may be voted in a couple of weeks as
evaluation shown no issue so far, at least on transmission power lines.
line_management tag is used carefully for testing.
Read more : https://www.openstreetmap.org/user/InfosReseaux/diary/391058

Nevertheless it's an opportunity to review the branch:type tag replacement
with line_management=*

i'm still looking for an appropriate illustration for two values examples:
* line_management=cross (two or more lines with different directions
sharing the same support without connecting)
* line_management=loop (two or more lines coming from the same direction
are connected as to mock some of them)

Feel free to propose and complete if you find corresponding situations on
ground

Thanks in advance

François

Le sam. 26 oct. 2019 à 20:59, François Lacombe 
a écrit :

> Hi all,
>
> After the review of line_attachment key this summer and Karlsruhe
> hackweekend at Geofabrik headquarters last week, let me introduce the
> second stage of tower:type key cleaning project for power lines. Great time
> has been spent on discussing and finding relevant situations.
> https://wiki.openstreetmap.org/wiki/Proposed_features/Lines_management
>
> It's now about the arrangement of power lines around their supports: how
> the lines branch, split, transpose or terminate.
> As current tagging (without line_management) still collides with any tower
> building function, the line_management key may be a solution to strip
> unrelated values from tower:type.
>
> I've published a diary entry to give more explanations
> https://www.openstreetmap.org/user/InfosReseaux/diary/391058
>
> I'd draw your attention to the conclusion :
> "Mapping utility supports like power towers or telecom poles is a
> worldwide challenge. For instance in France, professionals including
> operators and contractors rolling out overhead telecom cables are currently
> looking for approx. 16 millions missing shared power poles that weren’t
> mapped in operational GIS. There’s no doubt updating OSM can help."
> There's no short term risk of importing massive data, at least.
>
> This proposal is a first try and may cause worries about some local
> concerns. RFC is here to solve this prior to vote anything.
> We have to focus on simple situations to begin with to adopt the right
> semantic. More complex cases will be added step by step.
> Feel free to open a topic in Talk page.
>
> All the best
>
> François
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] Feature proposal - Approved - Telecom distribution points

2019-12-24 Thread François Lacombe
Hi all,

Voting period on telecom distribution points tagging proposal is over with
21 pros and 4 against. Approval rate is 84%
https://wiki.openstreetmap.org/wiki/Proposed_features/Telecom_distribution_points

It's nice to see this value joining exchange, connection_point and
service_device as reviewed on telecom key.
Next steps, for me, will consist in making documentation and definitions
clearer for connection_point vs distribution_point as late discussion shown
needs on this point.
This will encourage mappers to seek and tag those small boxes, obviously in
public space only.

Thank you to anyone who spent time to get involved in discussions and vote

Merry Christmas everybody and see you next year @tagging :)

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


Re: [Tagging] Feature proposal - Voting - Telecom distribution point

2019-12-14 Thread François Lacombe
Hi Everyone,

Sorry for long time to answeryour questions,

Le mar. 10 déc. 2019 à 19:58, Paul Allen  a écrit :

>
> Do you consider British Telecom DACS units to be a part of this?  They're
> old technology and I
> wouldn't expect new deployment as they're incompatible with ADSL but there
> may well be
> a lot of old installs still around.
> https://en.wikipedia.org/wiki/Digital_access_carrier_system
>

We also have those in France (called PCM).

They're only covered by the proposal if those "boxes" are the first you
encounter along the line starting from home.
If not, they are often included in a connection_point.

Facts are you may independently have multiplexers in distribution points or
connection points. It's only about their capacity and position in the
network.

Neverthess there is no tag currently to state the point is a dacs or not.
I may think about it later.

Le mar. 10 déc. 2019 à 23:06, Mateusz Konieczny  a
écrit :

> Yeah, vote is a good way to trigger comments.
>
> Certainly frustrating but hopefully it will
> result in a better tag and/or documentation.
>

No problem
Indeed it's a good occasion to improve and add points I didn't see neither.

Le mar. 10 déc. 2019 à 23:08, Graeme Fitzpatrick  a
écrit :

>
> In a lot of areas around here, all infrastructure is underground, so our
> lead-in cable (now an internet connection only) runs from a box on the
> outside wall of the house, under our front yard to a pit on the footpath,
> then to a bigger pit further down the road, & onwards from there.
>
> Should these pits be mapped under this scheme?
>

You may have a look to
https://wiki.openstreetmap.org/wiki/Tag:telecom%3Dconnection_point  if the
pits you talk about are located further in the network toward central
office.
Distribution points don't have patch panel to change subscribers from one
line to another. It's only local and direct connection to a bigger cable
(with less than 15 homes connected)
A connection point can handle a hundred of subscribers usually.

Be sure this precision will be added to improve documentation of
connection_point too.

Le mar. 10 déc. 2019 à 23:58, Warin <61sundow...@gmail.com> a écrit :

>
> I'm certainly not mapping them.
> Mainly because I don't know what these 'distribution points' really are.
>

Let's improve the example chapter with any situation you may see on ground
to disambiguate them.

All the best

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


Re: [Tagging] Feature proposal - Voting - Telecom distribution point

2019-12-10 Thread François Lacombe
Hi Jospeh,

Le mar. 10 déc. 2019 à 07:34, Joseph Eisenberg 
a écrit :

> I'm voting "no" because I do not see any discussion of this proposal
> at this mailing list or on the wiki. Has it been discussed somewhere
> else? The definition is not clear to me.
>

This is unfortunate, RFC lasts for 7 months until now. With several
announcements and questions:
https://lists.openstreetmap.org/pipermail/tagging/2019-May/045152.html
https://lists.openstreetmap.org/pipermail/tagging/2019-November/049373.html

I regret to only have examples for France and Spain, but I didn't find any
relevant picture for that on Commons and call anyone who want to add his
contribution from the very start of the RFC.
Since no comment raised, I took it as no concerns instead of lack of
consensus.


> The page says this is for mapping a "piece of equipment allowing to
> connect individuals and households to telecom local loops. They are
> often installed in the street, basements or on top of poles." That's a
> vague definition, though perhaps I do not know enough about telecom
> local loops.
>

No problem with that, the rational and proposal chapter of the document has
been updated.
Basically, it's really simple : the first box in the street your home is
connected on. If you don't find it, don't map it.
There are places where lines go out of homes from the roof and reach the
box on a pole in the street.


> Sorry for voting "no", but I don't think we should "approve" tags
> without discussion and reaching consensus.
>

Discussion is open since May but no one objected on this feature.
Then the time has come to vote and look for consensus, now.

All the best

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


[Tagging] Feature proposal - Voting - Telecom distribution point

2019-12-08 Thread François Lacombe
Hi all,

Following 7 months of RFC and apparently no problem to tag telecom
distribution points, the vote is now open.
https://wiki.openstreetmap.org/wiki/Proposed_features/Telecom_distribution_points

These are really (certainly too) tiny boxes with telecom network references
on them that I propose to map with telecom=distribution_point according to
IEC 722-12-19 definition.

Keep in mind this vote won't force anyone to map distribution points.
Question asked is to know if telecom=distribution_point is the most
appropriate key for that.
References can be taken as landmarks just like address numbers in your
neighborhood.

Thanks in advance for your time on this vote, all the best.

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


Re: [Tagging] Several different boxes on the same pole

2019-11-24 Thread François Lacombe
Thank you all for useful hints.

Le dim. 24 nov. 2019 à 22:01, Martin Koppenhoefer 
a écrit :

>
> there’s a proposal for a relation type=node which allows for several point
> objects with just one geometry object (could be semantically enriched by
> mapping the pole with the node, the boxes (type=node relations) could get
> the pole as member with an “attached_to”-role).
>

This one could be interesting in regard of quantity of stored data and
redundancy reduced by the use of relations.
Nevertheless, editors should be improved to let users edit simpler things
than relations for type=node to be usable.

I may recommend Marc marc approach in this proposal, and wait for a wider
support to map sharing-pole distribution points as node relation.
Anyway, it's not specific to telecom distribution points.

Le ven. 22 nov. 2019 à 23:56, Warin <61sundow...@gmail.com> a écrit :

>
> Site relation?


It's not applicable here : site relation requires to already have dedicated
and independent features, which we are looking for here.

Document has been slightly updated and RFC is going on
https://wiki.openstreetmap.org/wiki/Proposed_features/Telecom_distribution_points#Proposal

All the best

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


[Tagging] Several different boxes on the same pole

2019-11-21 Thread François Lacombe
Hi all,

Regarding this proposal for telecom distribution points, currently RFC :
https://wiki.openstreetmap.org/wiki/Proposed_features/Telecom_distribution_points

Situations may be found involving several of those boxes on a single pole.
This happen especially when FTTx (optical fibre) networks are rolled out in
parallel of existing older copper ones.
You'll find an old copper box and a more recent fibre one on the same pole
connecting households.

Those two boxes will be hard to describe on the same node, although they
can be located on the same pole.
Should we recommend to put as many nodes as required around the pole or
choose another option?

Let me know if you have ideas

All the best

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


Re: [Tagging] Feature proposal - Approved - Utility markers

2019-11-10 Thread François Lacombe
Hi Michael,

This is a good point and sorry for this time of answer.
I didn't mention position=* in the proposal but as a reviewed and
established practice for pipeline, easily extendable to other fields of
knowledge, it's ok to keep it on the marker.

I'll update the wiki shortly with it.

All the best

François

Le lun. 28 oct. 2019 à 20:14, Michael Brandtner via Tagging <
tagging@openstreetmap.org> a écrit :

> Hi,
>
> should position=* be kept when retagging pipeline markers to the new
> scheme? If yes, then this tag should be added to the wiki documentation.
>
> Michael
>
> Am So., Okt. 27, 2019 at 18:35 schrieb François Lacombe
> :
> Hi all,
>
> Voting of Utility markers proposal is now over and it was approved with 46
> yes out of 47 votes.
> This is a great participation level for such kind of topic.
> Thank you to anyone who spent time to improve this proposal and finally
> gives his vote.
>
> Cleanup has already began, wiki will be up to date in a couple of days.
> https://wiki.openstreetmap.org/wiki/Key:marker
> https://wiki.openstreetmap.org/wiki/Key:utility
>
> Feel free to add examples or raise concerns about particular situations in
> appropriate Talk pages
> Hope this will also help further milestone, highway/railway markers
> mapping and development.
>
> All the best
>
> François Lacombe
> ___
> 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] amenity=hospital on things that are not hospitals - is it a good idea?

2019-10-28 Thread François Lacombe
Le lun. 28 oct. 2019 à 09:46, Mateusz Konieczny  a
écrit :

> For me it seems a horrible and unacceptable tagging - amenity=hospital
> should be on hospitals
> and nothing else.
>

+1

Same kind of directions are given for marker=* key
https://wiki.openstreetmap.org/wiki/Key:marker#How_to_map
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] Feature proposal - Approved - Utility markers

2019-10-27 Thread François Lacombe
Hi all,

Voting of Utility markers proposal is now over and it was approved with 46
yes out of 47 votes.
This is a great participation level for such kind of topic.
Thank you to anyone who spent time to improve this proposal and finally
gives his vote.

Cleanup has already began, wiki will be up to date in a couple of days.
https://wiki.openstreetmap.org/wiki/Key:marker
https://wiki.openstreetmap.org/wiki/Key:utility

Feel free to add examples or raise concerns about particular situations in
appropriate Talk pages
Hope this will also help further milestone, highway/railway markers mapping
and development.

All the best

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


[Tagging] Feature proposal - RFC - Overhead lines management (consecutive to line_attachment)

2019-10-26 Thread François Lacombe
Hi all,

After the review of line_attachment key this summer and Karlsruhe
hackweekend at Geofabrik headquarters last week, let me introduce the
second stage of tower:type key cleaning project for power lines. Great time
has been spent on discussing and finding relevant situations.
https://wiki.openstreetmap.org/wiki/Proposed_features/Lines_management

It's now about the arrangement of power lines around their supports: how
the lines branch, split, transpose or terminate.
As current tagging (without line_management) still collides with any tower
building function, the line_management key may be a solution to strip
unrelated values from tower:type.

I've published a diary entry to give more explanations
https://www.openstreetmap.org/user/InfosReseaux/diary/391058

I'd draw your attention to the conclusion :
"Mapping utility supports like power towers or telecom poles is a worldwide
challenge. For instance in France, professionals including operators and
contractors rolling out overhead telecom cables are currently looking for
approx. 16 millions missing shared power poles that weren’t mapped in
operational GIS. There’s no doubt updating OSM can help."
There's no short term risk of importing massive data, at least.

This proposal is a first try and may cause worries about some local
concerns. RFC is here to solve this prior to vote anything.
We have to focus on simple situations to begin with to adopt the right
semantic. More complex cases will be added step by step.
Feel free to open a topic in Talk page.

All the best

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


Re: [Tagging] Feature Proposal - Voting - Utility markers

2019-10-14 Thread François Lacombe
Le dim. 13 oct. 2019 à 20:45, Markus  a écrit :

>
> It was a visual edit that added the  tags to the {{vote}}
> template, thus disabling the template. I've fixed it by removing the
>  tags.
>

That's right, and I didn't noticed that immediatly.
Thank you for the fix

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


Re: [Tagging] Feature Proposal - Voting - Utility markers

2019-10-13 Thread François Lacombe
Hi Graeme

I don't understand what do you mean exactly
Voting options are a template, and not visible on source

What is the expected behaviour you think about?

All the best

François

Le dim. 13 oct. 2019 à 02:13, Graeme Fitzpatrick  a
écrit :

> Just letting you know that something has happened to the page in that the
> normal voting options to copy don't appear when you go to Edit Source?
>
> Somebody may have accidentally pasted in the wrong spot on the page?
>
> Thanks
>
> Graeme
> ___
> 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 - Utility markers

2019-10-12 Thread François Lacombe
Hi all

The vote is now open on the proposal regarding utility markers, until
October 26.
Many comments allowed to find a nice and versatile tagging for markers
useful to be added in OSM.
It have been under test in France for the last month and didn't show any
significant issue.
https://wiki.openstreetmap.org/wiki/Proposed_features/Utility_markers_proposal

Like the title of the proposal may imply it, marker=* and utility=* are
introduced to map many more markers than pipeline=marker originally allows.

I choose to confirm pipeline=marker discouragement as it clutters the
pipeline key with features not directly involved in pipeline operation and
prevent definition of power=marker and telecom=marker as well.
Hope you won't be reluctant to this, marker=* adoption will be progressive.

Thanks in advance for your time, all the best

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


Re: [Tagging] New tag proposal: 'add=milestone'

2019-10-09 Thread François Lacombe
Hi,

I just want to bring to your attention the work currently done to propose
marker=* key with existing value marker=stone.
https://wiki.openstreetmap.org/wiki/Proposed_features/Utility_markers_proposal#Tagging

This is mainly intended for utility networks but may be useful for highways
milestones.
It starts with the deprecation of pipeline=marker to use marker as a more
general placeholder for marker definition in combination with utility=*

Do you find highway=**_marker desirable?
Will you consider things like highway=marker + marker=plate + ref=*... ?

This is an opportunity to make things to converge towards a common
framework for many kind of markers here

All the best

François

Le mer. 9 oct. 2019 à 22:03, Martin Koppenhoefer  a
écrit :

> Am Mi., 9. Okt. 2019 um 15:11 Uhr schrieb Paul Allen :
>
>> ...some mad king throwing darts at a map: if it looks like a house
>> number, is treated like a house
>> number, and appears on the house/gate/whatever as a house number, then
>> it's a house number.
>> House numbers don't have to be sequential or monotonic, I can think of a
>> couple of roads in my
>> town where the house numbers are counter-intuitive.  So it doesn't matter
>> if those house numbers
>> were assigned based on a distance along a road, and that subsequent road
>> remodelling has
>> resulted in them all being inaccurate without a milepost equation: if it
>> quacks like a house
>> number then it's a house number.
>>
>
>
> there is some sense in understanding the system (if there is), e.g. if not
> all numbers are recorded it allows you to estimate where the one you are
> looking for might be, how far it possibly is etc.. This is a typical use
> case: you have an address and are looking for it on the ground.
>
>
>
>> If they're not house numbers marked somewhere on the property, and if
>> there are sometimes
>> (as the OP has stated) missing markers, and if road remodelling has
>> rendered the distances
>> incorrect, then what good is addr:road_marker in those particular
>> circumstances?
>>
>> It appears addr:road_marker is only really applicable where all of the
>> following apply:
>>
>> 1: The number is not marked on the property (otherwise it's a house
>> number, however
>> derived).
>>
>
>
> there could be 2 numbers, a distance based on and a recently assigned,
> actual housenumber.
> You could also be interested in comparing an official register to the OSM
> data, e.g. to find missing spots, check for completeness etc.
>
>
>
>>
>>
>> 3) Road markers have not been recalibrated following extensive road
>> remodelling.
>>
>>
>
> good luck with this. In regions with lacking housenumbers I wouldn't put
> too much confidence in the road markers...
>
> 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


Re: [Tagging] Feature proposal - RFC - Utility markers

2019-09-19 Thread François Lacombe
A link would be better to reach the document
https://wiki.openstreetmap.org/wiki/Proposed_features/Utility_markers_proposal

Sorry for noise

François

Le jeu. 19 sept. 2019 à 23:59, François Lacombe 
a écrit :

> Hi all,
>
> Following useful comments received about the utility markers proposal, it
> has been reworked a bit.
>
> Now marker=* is used to classify markers upon their shape and design,
> which allows to include already used marker=stone in it. marker=* is
> intended in the specific context of utility markers but can be used
> elsewhere if suitable.
> This change enable to get rid of support=* key as the design of the marker
> implies the support. It's now more convenient to use marker=* on another
> feature (marker=plate on power=pole for instance).
>
> utility=* key is introduced to give information of what is actually
> referred by the marker.
> More valuable than the colour (which is nevertheless optional), utility
> will be usable in many contexts and situations with a set of commonly
> adopted values and ability to define more local ones if required.
>
> For now I'm still in favour of deprecating pipeline=marker and don't
> encourage to use power=marker any more (I'm aware this require a
> significant effort
> As explained, markers aren't part of pipelines or cables and they should
> get their own key as to not clutter several keys with the same concept.
>
>
> Feel free to raise concerns on Talk page, all the best
>
> François
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature proposal - RFC - Utility markers

2019-09-19 Thread François Lacombe
Hi all,

Following useful comments received about the utility markers proposal, it
has been reworked a bit.

Now marker=* is used to classify markers upon their shape and design, which
allows to include already used marker=stone in it. marker=* is intended in
the specific context of utility markers but can be used elsewhere if
suitable.
This change enable to get rid of support=* key as the design of the marker
implies the support. It's now more convenient to use marker=* on another
feature (marker=plate on power=pole for instance).

utility=* key is introduced to give information of what is actually
referred by the marker.
More valuable than the colour (which is nevertheless optional), utility
will be usable in many contexts and situations with a set of commonly
adopted values and ability to define more local ones if required.

For now I'm still in favour of deprecating pipeline=marker and don't
encourage to use power=marker any more (I'm aware this require a
significant effort
As explained, markers aren't part of pipelines or cables and they should
get their own key as to not clutter several keys with the same concept.


Feel free to raise concerns on Talk page, all the best

François


Le dim. 8 sept. 2019 à 15:48, François Lacombe 
a écrit :

> Hi everyone
>
> Le sam. 7 sept. 2019 à 02:06, Joseph Eisenberg 
> a écrit :
>
>> Because most mappers only add 1 tag to each new object. (Folks like
>> you and me are an exception - and a year ago, when I was new at this,
>> I only usually added 1 tag per feature). If an object can be described
>> with one tag, it's better to do this and create several tags, (e.g.
>> pipeline=marker, power=marker) rather than requiring each object to be
>> tagged with 2 or 3 or 4 tags. This saves mapper time and makes sure
>> that each object is fully described.
>>
>
> I understand the need of simplicity in chosen terms. Neverthess I can't
> imagine OSM with single-key objects as a principle.
> +1 with Martin : if occasional mappers want to reduce their typing time,
> they will use presets in convenient editors like iD or JOSM.
> This argument comes on many discussions and oppose kind of simplicity to
> semantic consistency. Tagging with several consistent tags could be more
> easily handled and versatile than one single key mixing concepts for
> reasons that are not necessarily shared by the whole community.
>
> However, this proposal will be reworked to take care of this batch of
> comment, it's appreciable we can discuss these points here.
>
> Le sam. 7 sept. 2019 à 07:17, Mateusz Konieczny 
> a écrit :
>
>> Is it typical to map "it is marker of an
>> unknown kind" like splitting shop
>> and opening hours makes sense?
>>
>
> It makes sense to map "here is a marker what it looks like" without
> explicitly attaching it to a utility.
> One mapper will describe what she/he sees, and a second will complete with
> her/his own knowledge.
>
> Le sam. 7 sept. 2019 à 16:11, Martin Koppenhoefer 
> a écrit :
>
>> I would expect utility marker mapping to be a special interest. Jane
>> Mapper will not map these, or will be so excited about her discovery on the
>> ground that she will be willing to look it up on a wiki page ;-)
>>
> I definitely have to meet Jane Mapper, Martin :d
>
>
> All the best
>
> François
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature proposal - RFC - Utility markers

2019-09-08 Thread François Lacombe
Hi everyone

Le sam. 7 sept. 2019 à 02:06, Joseph Eisenberg 
a écrit :

> Because most mappers only add 1 tag to each new object. (Folks like
> you and me are an exception - and a year ago, when I was new at this,
> I only usually added 1 tag per feature). If an object can be described
> with one tag, it's better to do this and create several tags, (e.g.
> pipeline=marker, power=marker) rather than requiring each object to be
> tagged with 2 or 3 or 4 tags. This saves mapper time and makes sure
> that each object is fully described.
>

I understand the need of simplicity in chosen terms. Neverthess I can't
imagine OSM with single-key objects as a principle.
+1 with Martin : if occasional mappers want to reduce their typing time,
they will use presets in convenient editors like iD or JOSM.
This argument comes on many discussions and oppose kind of simplicity to
semantic consistency. Tagging with several consistent tags could be more
easily handled and versatile than one single key mixing concepts for
reasons that are not necessarily shared by the whole community.

However, this proposal will be reworked to take care of this batch of
comment, it's appreciable we can discuss these points here.

Le sam. 7 sept. 2019 à 07:17, Mateusz Konieczny  a
écrit :

> Is it typical to map "it is marker of an
> unknown kind" like splitting shop
> and opening hours makes sense?
>

It makes sense to map "here is a marker what it looks like" without
explicitly attaching it to a utility.
One mapper will describe what she/he sees, and a second will complete with
her/his own knowledge.

Le sam. 7 sept. 2019 à 16:11, Martin Koppenhoefer 
a écrit :

> I would expect utility marker mapping to be a special interest. Jane
> Mapper will not map these, or will be so excited about her discovery on the
> ground that she will be willing to look it up on a wiki page ;-)
>
I definitely have to meet Jane Mapper, Martin :d


All the best

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


Re: [Tagging] Feature proposal - RFC - Utility markers

2019-09-06 Thread François Lacombe
Hi all,

Thank you for yout contributions

Le ven. 6 sept. 2019 à 09:13, Joseph Eisenberg 
a écrit :

> I'm still opposed to this proposal:
>

Answers provided at
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Utility_markers_proposal#Oppose_deprecating_pipeline.3Dmarker_and_marker.3Dstone

Le ven. 6 sept. 2019 à 09:18, Jez Nicholson  a
écrit :

> Arriving fresh to a proposal, my first action would be to look at what is
> currently in OSM. There are 6,043 "marker"="stone", which is 81.5% of the
> usage of "marker" in OSM. I would expect the proposal to support current
> usage.
>
I respectably disagree on that point.
Biggest problem is that current usage isn't documented, and may not have
been reviewed like we are doing right now.

This proposal aims to define values for marker=* to describe utility
markers.
Despite marker=stone may be unconsistent with what is proposed, it doesn't
make it incompatible and this proposal only notices this fact without
thinking of deprecating it.

I would then look at "power":"marker" and be very concerned to see 35,288
> tags. That's a very strong existing usage. You might be lucky that power
> markers aren't as useful to render as power lines, etc.
> https://openinframap.org/#12.2/49.49246/0.21175
>
I don't get the right term here. I see only 222 items for power=marker and
nothing for power:marker=*
Which one are you refering to with 35k uses please?

One of the goals is precisely to get a comprehensive render with marker=*
for many kind of markers, not only pipeline ones.

Le ven. 6 sept. 2019 à 12:20, Martin Koppenhoefer 
a écrit :

> I would rather have expected a generic description of the marker, like
> marker=
> post
> cone
> sign
> ...
> aerial_marker (maybe this should be a property, not a type? This seems to
> be a quite interesting property for our context)
>

Ok this one is really interesting.
Why not using marker=* to give its nature and another key utility=* with
values "gas", "power", "telecom", "water"... ?
Seems it is already used:
https://taginfo.openstreetmap.org/keys/utility#values

marker=* + utility=* give a "utility marker", right?

All the best

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


Re: [Tagging] Feature proposal - RFC - Utility markers

2019-09-05 Thread François Lacombe
Hi all

The proposal to introduce marker=* key for all kind of utility markers is
about to be voted.
https://wiki.openstreetmap.org/wiki/Proposed_features/Utility_markers_proposal

All previous comments have been solved and any new one will be welcome.

Currently, more than 6k object are described with undocumented marker=stone
which conflicts a bit with proposed marker classification.
As those are mainly (to be determined on each situation) highway milestones
or private ground limits, they're not covered by this proposal
A suggestion would to define marker=milestone or marker=land_limit +
support=pedestal + material=stone.

All the best

François

Le ven. 19 juil. 2019 à 21:22, François Lacombe 
a écrit :

> Hi Jospeh
>
> This proposal is an attempt to bring consistency in markers mapping, in
> two ways :
> - Provide a common concept to tag them all.
> - Free pipeline=* from some features unrelated directly to pipeline
> operation.
>
> Second point should encourage a mapping good practice I didn't have in
> mind in previous pipeline mapping evolutions : the marker shouldn't be part
> of the pipeline way directly as it warns about the presence of pipelines in
> a given range or distances.
> Just like road signs should get their own node beside the road instead of
> be part the highway way.
> To me yes, we should encourage to use marker=pipeline instead of
> pipeline=marker prior to the last gets *really* used.
> 29k features is less than the whole amount of pipeline markers we have to
> find in France (which is a small area).
>
> All the best
>
> François
>
> Le jeu. 18 juil. 2019 à 06:07, Joseph Eisenberg <
> joseph.eisenb...@gmail.com> a écrit :
>
>> It looks like the main effect of this proposal would be to replace
>> pipeline=marker (used 29k times) with marker=pipeline, though the new key
>> marker= could also be used for power cables and telecommunications cables.
>>
>> Is it really necessary to change pipeline=marker?
>>
>> -Joseph
>>
>> On Sun, Jul 14, 2019 at 11:10 PM François Lacombe <
>> fl.infosrese...@gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> Here is another proposal we were two working on it.
>>> It regards several kinds of utility markers usually warning about buried
>>> infrastructure beneath them.
>>>
>>> https://wiki.openstreetmap.org/wiki/Proposed_features/Utility_markers_proposal
>>>
>>> Markers are currently described with keys like pipeline=* and power=*
>>> although they're not directly involved in infrastructure running processes
>>> (like a valve can be on a pipeline for instance).
>>> Then it can be useful to define a new key marker=* to gather more
>>> categories on OSM (pipeline is for now the most mapped here) and prevent
>>> pipeline, power and telecom keys be cluttered with not directly related
>>> features.
>>>
>>> Note that markers mapping is important on OSM as location signs and
>>> relevant data to verify presence of not visible infrastructures.
>>>
>>> Feel free to raise concerns here and on talk page.
>>>
>>> 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 mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] How to tag flood prone points and areas?

2019-09-01 Thread François Lacombe
Hi all,

flood_prone=yes doesn't sound to be good semantics.
Should we rewrite it as floodable=* with 3 or four big level of probability
(or causes, or whatever) instead?

Many people raised concerns about yes/no tags and the key name seem to
contain two distinct information (floodable + probability) while the value
meaning could be improved.

Furthermore, such work can be useful for many hazard description.
This proposal is interesting :
https://wiki.openstreetmap.org/wiki/Proposed_features/hazard

Floods can also occur on river banks surroundings when hydropower is in
operation upstream
https://lists.openstreetmap.org/pipermail/tagging/2018-July/037973.html
Here is what is often displayed : https://imgur.com/a/TLhZcgE

All the best

François

Le dim. 1 sept. 2019 à 14:07, Joseph Eisenberg 
a écrit :

> For `flood_probability` to be useful and verifiable in some way, there
> should be a link to the source in the changeset, or perhaps also
> source: flood_probability= on the object.
>
> Such statistical features like "1% risk of flood per year" can't
> really be verified by individual mappers, since they are based on
> calculations of the floodplain geometry and historical observations of
> floods over many decades. So it's probably more useful to have these
> mapped in official sources which are kept up-to-date, rather than
> importing the data from the external source into OSM, and then having
> to maintain it in our database.
>
> I agree that if there is a sign that says "this area prone to
> flooding", then "flood_prone=yes" is verifiable and helpful to add,
> since that's representing a feature that can be checked when the area
> is next survey.
>
> On 9/1/19, Paul Allen  wrote:
> > On Sun, 1 Sep 2019 at 05:24, Warin <61sundow...@gmail.com> wrote:
> >
> > You could add flood_prone=yes to the car park tag but that will show the
> >> whole car park as affected, whereas it's only the bit down this end that
> >> has a problem. Would drawing a separate area & marking that as
> >> flood_prone=yes work?
> >>
> >
> > Better than nothing.  If you feel adventurous, you could try mapping it
> as
> > two, non-overlapping,
> > constituent areas of a multipolygon and see what happens.
> >
> >> I asked this question some time ago. I was told it was not verifiable
> and
> >> therefore not for OSM.
> >>
> >
> > My opinion is that if there is signage/road markings it's verifiable and
> > mappable.  When we
> > map the speed limit of a road from signs the only actual, verifiable
> > information we have is
> > the presence of the sign, but we assume the sign is true and infer the
> > speed limit of the
> > road from it.  Same thing here: sign says it's prone to floods so we
> infer
> > the place is prone to
> > floods.
> >
> > Where I differ from some is that I'd consider official documents also
> > providing verifiability
> > provided their copyright permits it.
> >
> > However there is the question of frequency, once in 10 year event, once
> in
> >> 100 etc. So I would add a sub tag or value about frequency of the
> event..
> >> The key frequency is already in use. Period has some use too, though the
> >> use looks to be years.. no wiki to say what it is?
> >>
> >
> > Period is the multiplicative inverse of frequency: normalize the units,
> > multiply them together
> > and the result should be 1.  Neither is appropriate in this case.  A
> > once-in-100-year event
> > does not occur at 100 year intervals, it has a probability of  1% of
> > occurring (technically,
> > being equalled or exceeded) in any given year.
> > https://en.wikipedia.org/wiki/100-year_flood
> > So we should be tagging a probability.  Technically, exceedance
> probability
> > for floods.
> >
> > Taginfo shows floodplain_probability used 77 times.  Is that sensible?
> > It's a floodplain or it isn't.
> > Also flood_probability 4 times (better) and hazard:probability once.  The
> > flood_probability value
> > in taginfo is "100y" rather than 1%.  People who used
> > floodplain_probability divide into those
> > who expressed a large number like 100 (probably meaning years) and those
> > who expressed
> > a small number like 1 or 0.5 (probably a percentage).  The only value for
> > hazard:probability
> > is "low" (which I consider to be effectively meaningless).
> >
> > I dislike floodplain_probability because it IS a floodplain with a
> > probability of being
> > flooded, not a probability of an area being classified as a floodplain.
> > Also because
> > it's been given both in terms of years and percentages (except it's
> > impossible to be sure
> > because nobody has given units, so maybe the 100 means it's 100% likely
> to
> > flood and
> > the 0.5 means it is likely to flood every six months).  It's a mess.
> >
> > I'm fairly happy with flood_probability.  There's something nagging at
> the
> > back of my
> > mind saying I ought to be unhappy with flood_probability, but it's not
> > telling me why.
> >
> > I like hazard:probability, especially if 

Re: [Tagging] waterway=artificial documentation

2019-08-31 Thread François Lacombe
Hi Paul

Indeed I didn't think about an import, thank you to remind me this

Le ven. 30 août 2019 à 20:49, Paul Allen  a écrit :

>
> I'll leave it to you to figure out the best way of dealing with it,
> although I suspect translating
> that particular Ftype to waterway=ArtificialPath was an error (possibly a
> bulk error from
> a bulk import) and it should have been waterway=river, along with a note
> saying it's
> an NHD artificial path or a source tag saying it came from an NHD
> artificial path, or something.
>

I'll directly ask to US community about this

All the best

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


[Tagging] waterway=artificial documentation

2019-08-30 Thread François Lacombe
Hi all,

I've notice that waterway=artificial is currently used more than 16k times.
https://taginfo.openstreetmap.org/tags/waterway=artificial

This value doesn't appear to be documented, does someone know what is its
real meaning please?
Only this DataItem is availabe :
https://wiki.openstreetmap.org/wiki/Item:Q19211

Efforts has been made to distinguish open flow and pipe flow waterways and
waterway=artificial may fit in both regimes.
It's an occasion to see if a more precise value is missing to cover those
situations.
https://wiki.openstreetmap.org/wiki/Waterways#Artificial_waterways:_pressurised_vs_Open-flow_Waterways
https://wiki.openstreetmap.org/wiki/Key:waterway#Values

Many objects are located in an area in the US, like this one :
https://www.openstreetmap.org/way/46314476
It seems that waterway=river would be more suitable for this one.

All the best

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


Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

2019-08-28 Thread François Lacombe
Le jeu. 29 août 2019 à 01:01, Graeme Fitzpatrick  a
écrit :

>
> I've just had a quick play on TagInfo & protect_class & protection_title,
> plus a couple of others, all refer to protected areas of one type or another
>

Current usage on OSM is clear and I don't question this
This proposal is an opportunity to be sure we're choosing the most
appropriate word regarding what the target is.


>  How about reserving IP_class or IP_protection? Would seem to cover it
> nicely (especially if they're not actually used!)
>

According to what Paul said, ingress_protection would be better.
ip_protection is redundant (p of protection + "protection")

Then we shouldn't have simple protection=* for this proposal but
_protection too.
As N of IUCN means Nature, what about nature_protection?

Le jeu. 29 août 2019 à 01:05, Kevin Kenny  a
écrit :

>
> If people insist, I'd go to 'protected_area:category', but I consider
> that to be rather too verbose, and I'm not sure that it's worth it to
> avoid the minimal risk of namespace pollution.


Effort is appreciable, but there is no need to introduce namespace here
Currently I'd be in favour of removing at least _class or _type suffixes as
it doesn't bring additional information.

All the best

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


Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

2019-08-28 Thread François Lacombe
Le mer. 28 août 2019 à 19:09, Paul Allen  a écrit :

> But IP ratings are regarded as environmental protection ratings.  So that
> has the same problem.
> "Environmental protection" can mean "protecting the environment" or
> "protecting things from the
> environment."
>

Seems legit
This will need further thinking, maybe someone else will get the proper key
name


>
> Nope, Ingress Protection.  It's an international standard, though.
>
Thats a detail, official document stands for International Protection
https://texa-co.ir/wp-content/uploads/2017/04/IEC-60529.pdf (see §4 page 18)

If we can avoid confusion, we should.  I'm not sure that this does.
>
It requires at least a strong context to not be confused with any other
protection classification system.

Let's see if Kevin wishes to take care of this

All the best

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


Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

2019-08-28 Thread François Lacombe
Le mer. 28 août 2019 à 18:15, Paul Allen  a écrit :

> "Protection class" is something of a misnomer when it comes to IEC 60529,
> since it specifies
> a level of ingress protection (hence the "I" and "P" in the designation)
> against water and
> dust.  It does, as a side-effect, have some bearing on the possibility of
> contact of dangerous
> parts by fingers, but that is largely incidental.  And while you may have
> seen it referred to
> as "protection class" it seems more common to refer to it as "ingress
> protection class."
>

Hi Paul,
As both the topic of the proposal and the IP norm are approximately at the
same semantic distance of "protection class" term, that's why I recommend
to move to "environment_protection=*" (or something like this) to be more
focused on what is actually described.
IP stands for International Protection, which indeed consist in limiting
ingress of foreign object or water in a given enclosure.

Even if protection class is a misnomer, I find risky to use it as this for
a completely different topic, that's my 2 cts.
All the best

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


Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

2019-08-28 Thread François Lacombe
Hi all,

This proposal sounds good in the field of knowledge it covers and I would
certainly go for it when vote will be open.

I've noticed a potential conflict with protection degrees defined in IEC
60529 norm (IP-XY numbers seen on many electronic appliances), also called
"protection class".
Could you please consider this contribution to RFC please?
https://wiki.openstreetmap.org/wiki/Talk:Proposal:_Named_protection_class_for_protected_areas#Potential_conflict_with_IEC_60529_degrees_of_protection

All the best

François

Le dim. 18 août 2019 à 15:43, Joseph Eisenberg 
a écrit :

> Kevin,
>
> The proposal looks pretty good.
>
> When you've finished editing, please make a clear list off all the
> new, proposed tags, in one place. Also please clarify what pages are
> being edited and if protect_class=* is being deprecated by this
> proposal.
>
> It might make sense to deprecate all values of protect_class other
> than 1 to 6, since those numbers at least correspond to the IUCN
> numbers and most are fairly commonly used, while the higher numbers
> are rare and confusing. Over time, if protection_class becomes much
> more popular, the protect_class:1 to 6 might also become obsolete, but
> for the short term it might be difficult to change them all right
> away.
>
> One thing is that you write in one place that
> protection_class=condition should maybe just be
> protection_class=hazard, to replace the current protect_class=15 and
> 16, "Location Condition" and "Longtime Hazard Area". I think this
> makes sense.
>
> Re: protect_class=24, "Political protection", you might need to talk
> to the folks in Brazil who are using this tag. Not all of them were
> happy with using boundary=aborignal_lands instead, if I recall
> correctly, but perhaps this could change.
>
> Thanks for working on this. I think it's worth doing, since most of
> the protect_class values have never really become used, and their
> meaning is not very clear.
>
> On 8/18/19, Kevin Kenny  wrote:
> > .As has already been discussed at some length in the thread on tagging
> > of State Parks in the US, I've been working on a proposal for a
> > 'protection_class=*' key to replace 'protect_class=*'. It replaces the
> > seven numeric codes from IUCN (plus a zoo of codes that OSM appears to
> > have cut out of whole cloth) with 'protection_object=*', whose values
> > are drawn from a group of word-oriented codes that, it is hoped, will
> > be more mnemonic. (The proposal to describe State Parks as protected
> > areas was reasonably well received except for the issue that it
> > depended on the numeric 'protect_class=*' to describe the protection.)
> >
> > The proposal has now reached a state where I think it can be opened
> > for a formal RFC, and can be found at
> >
> https://wiki.openstreetmap.org/wiki/Proposal:_Named_protection_class_for_protected_areas
> > .
> >
> > Of course, I'll monitor both this list and the talk page for the Wiki
> > page for comments, and try to address whatever comes up.
> > --
> > 73 de ke9tv/2, Kevin
> >
> > ___
> > 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] Feature proposal - Approved - Line attachments

2019-07-28 Thread François Lacombe
Hi all,

Voting period on line attachments proposal is now over.
23 pros votes make the new key line_attachment approved, thanks to voters
for their support
https://wiki.openstreetmap.org/wiki/Proposed_features/Lines_attachments

The proposal took approx 1 year to be mature enough for the vote and
reworked several times thanks to TOGA's comments

The wiki is currently edited with new values for the proposed key.
tower:type=anchor and tower:type=suspension should now be carefully
replaced with appropriate line_attachment values.
Feel free to complete example sections for each page with situations you
see

All the best

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


Re: [Tagging] Reviewing wiki pages - Tag:waterway=sluice gate

2019-07-19 Thread François Lacombe
That's way nicer, thanks Mateusz

Le ven. 19 juil. 2019 à 12:55, Mateusz Konieczny 
a écrit :

> I linked mentioned resources, see
>
> https://wiki.openstreetmap.org/w/index.php?title=Tag%3Awaterway%3Dsluice_gate=revision=1879862=1879574
>
> Anyone with experience in mapping such structures is welcomed to further
> improve this page.
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature proposal - RFC - Utility markers

2019-07-19 Thread François Lacombe
Hi Jospeh

This proposal is an attempt to bring consistency in markers mapping, in two
ways :
- Provide a common concept to tag them all.
- Free pipeline=* from some features unrelated directly to pipeline
operation.

Second point should encourage a mapping good practice I didn't have in mind
in previous pipeline mapping evolutions : the marker shouldn't be part of
the pipeline way directly as it warns about the presence of pipelines in a
given range or distances.
Just like road signs should get their own node beside the road instead of
be part the highway way.
To me yes, we should encourage to use marker=pipeline instead of
pipeline=marker prior to the last gets *really* used.
29k features is less than the whole amount of pipeline markers we have to
find in France (which is a small area).

All the best

François

Le jeu. 18 juil. 2019 à 06:07, Joseph Eisenberg 
a écrit :

> It looks like the main effect of this proposal would be to replace
> pipeline=marker (used 29k times) with marker=pipeline, though the new key
> marker= could also be used for power cables and telecommunications cables.
>
> Is it really necessary to change pipeline=marker?
>
> -Joseph
>
> On Sun, Jul 14, 2019 at 11:10 PM François Lacombe <
> fl.infosrese...@gmail.com> wrote:
>
>> Hi all,
>>
>> Here is another proposal we were two working on it.
>> It regards several kinds of utility markers usually warning about buried
>> infrastructure beneath them.
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Utility_markers_proposal
>>
>> Markers are currently described with keys like pipeline=* and power=*
>> although they're not directly involved in infrastructure running processes
>> (like a valve can be on a pipeline for instance).
>> Then it can be useful to define a new key marker=* to gather more
>> categories on OSM (pipeline is for now the most mapped here) and prevent
>> pipeline, power and telecom keys be cluttered with not directly related
>> features.
>>
>> Note that markers mapping is important on OSM as location signs and
>> relevant data to verify presence of not visible infrastructures.
>>
>> Feel free to raise concerns here and on talk page.
>>
>> 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 mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Sluice gate vs valve (was Re: Reviewing wiki pages - Tag:landcover=greenery, Tag:waterway=sluice gate, Tag:landcover=water, Tag:landcover=shrubs, Tag:landcover=sand, Tag:waterway=slRevie

2019-07-18 Thread François Lacombe
Hi Marc,

Le jeu. 18 juil. 2019 à 07:48, Marc Gemis  a écrit :

> Is the second picture a valve ?
> https://www.wisegeek.com/what-is-a-sluice-gate.htm  This page calls it
> sluice gate. I'm not familiar with the terminology, so perhaps experts
> can enlighten me.
>

Functionally a valve regulates the flow of a fluid in a given duct. Such a
definition would match the gates this topic is about
https://en.wikipedia.org/wiki/Valve

A piping gate valve involves a sluice which moves in and out the full flow
section
https://en.wikipedia.org/wiki/Gate_valve

Usually, a valve can't be overflowed as it's often about pressurised piping.
In case of openflow canals water may flood surroundings, but IMHO big gates
can still be called a valve according to definition.
Wikipedia states that "Valves have many uses, including controlling water
for irrigation " then imply valve
terminology would be suitable for canals.

In French valve is translated in "vanne" and refers to both kind of devices
(piping and water ways)

All the best

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


Re: [Tagging] Reviewing wiki pages - Tag:landcover=greenery, Tag:waterway=sluice gate, Tag:landcover=water, Tag:landcover=shrubs, Tag:landcover=sand, Tag:waterway=slReviewing wiki pages - Tag:landcove

2019-07-17 Thread François Lacombe
Hi

Le mer. 17 juil. 2019 à 15:07, Marc Gemis  a écrit :

> > https://wiki.openstreetmap.org/wiki/Tag:waterway%3Dsluice_gate
>
> The person that added this page, is not happy with
> waterway=flow_control; flow_control=sluice_gate
> (discussion on Belgian Forum:
> https://forum.openstreetmap.org/viewtopic.php?id=66728 )
>

I'm sorry I can't be part of Ducth discussions.
Both waterway=flow_control + flow_control=sluice_gate and
waterway=sluice_gate aren't properly described on wiki and used
respectively about 500 and 250 times each.
A proposal remains about the first
https://wiki.openstreetmap.org/wiki/Proposed_features/sluice_gate

As a reviewed key valve=gate exists, I'd be in favor of a third possibility
: waterway=valve + valve=gate
https://wiki.openstreetmap.org/wiki/Tag:valve%3Dgate (I know one of the
examples involves a sluice gate and described as pipeline=valve).
This would be consistent with pipeline=valve (equivalent of flow control
device) + valve=gate.
waterway=valve would be designed for every situation where pipeline=valve
isn't suitable (i.e when the duct isn't a pipeline, for free flow canals,
tunnels and so on...)

All the best

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


[Tagging] Feature proposal - RFC - Utility markers

2019-07-14 Thread François Lacombe
Hi all,

Here is another proposal we were two working on it.
It regards several kinds of utility markers usually warning about buried
infrastructure beneath them.
https://wiki.openstreetmap.org/wiki/Proposed_features/Utility_markers_proposal

Markers are currently described with keys like pipeline=* and power=*
although they're not directly involved in infrastructure running processes
(like a valve can be on a pipeline for instance).
Then it can be useful to define a new key marker=* to gather more
categories on OSM (pipeline is for now the most mapped here) and prevent
pipeline, power and telecom keys be cluttered with not directly related
features.

Note that markers mapping is important on OSM as location signs and
relevant data to verify presence of not visible infrastructures.

Feel free to raise concerns here and on talk page.

All the best

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


[Tagging] Feature proposal - Voting - Line attachments

2019-07-14 Thread François Lacombe
Hi all,

The voting on the line attachments proposal is now open
https://wiki.openstreetmap.org/wiki/Proposed_features/Lines_attachments

Proposed tagging regards how any line is bound to its supports.
This proposal wasn't intended to describe power insulators only (further
work may be done regarding this goal) but delivers a set of concepts to
address power, telecom, various mechanical use cases...

Many comments have been received during more than 1 year of writing which
is really great. I think the document is mature enough to be voted now
thanks to contributions.
Tagging has been experienced recently in France and Senegal on several
situations and was used as expected.

Thanks in advance for your time, all the best

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


  1   2   3   4   5   6   >