Re: [Tagging] Feature proposal - Voting - guard stone

2020-12-21 Thread Volker Schmidt
On Tue, 22 Dec 2020, 01:02 Paul Allen,  wrote:

> On Mon, 21 Dec 2020 at 23:34, Volker Schmidt  wrote:
>
> (perhaps the duck principle could be applied: it looks like a guardstone,
>> it keeps the wheels on the road like a guard stone, hence it can tagged as
>> a guard stone)
>>
>
> Guardstones don't keep the wheels on the road, they keep the wheels off the
> building.  Your duck is a drake
>
I am not saying they are the same, I was pointing out, that, by stretching
the duck principle a bit you could use the same tag. But I would prefer us
finding a better tag.

>
> The pair of "guard" stones one on each side of the minor road could be a
>> kind of ancient width limiter for passing vehicles. I have seen many of
>> these on the artificial earthen embankments (Italian: argine) that are
>> common along waterways in the flat lands of Northern Italy. So we could tag
>> them as barrier=bollard; maxwidth=x
>>
>
> Seems plausible.
>
> The rows of "guard stones" along roads are certainly a predecessor of
>> guard rails, i.e. they prevented vehicle from veering off the road.
>>
>
> Maybe, but they're on the wrong side of the road.  They prevent the vehicle
> veering into trees, which would be just as effective as stopping it going
> further and do as much (or as little) damage.  A guardrail would be
> on the other side of the road, to prevent a vehicle going over the cliff.
>
You must be looking at different picture. The one I linked, shows
definitely false guard stones on the valley side. I drove that road in
1963, when it was in better shape, I guarantee you the protection was on
the correct side, and the terrain  is steep.

>
>> I just googled this interesting German document
>> <http://strassengeschichte.de/Menueoptionen/Geschichte/HistorieGesch/Randsteine/randsteine.htm>
>> So the German term is "Leitstein", at lest it was in the former DDR The
>> modern
>>
> equivalent are the "Leitpfosten
>> <https://de.wikipedia.org/wiki/Leitpfosten>", French "délinéateur", but
>> there is no English
>>
> equivalent
>>
>
> The English equivalent of the modern Lietpfosten appears to be
> called "verge marker" or "marker post" (the bulkier ones are
> called bollards)
> https://uk.glasdon.com/road-safety/reflective-verge-markers
>
> I don't know the English term for Leitstein or even if we ever had such
> things.
>
I learned the term. "Leitstein" today from the report that I googled.

Volker

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


Re: [Tagging] Feature proposal - Voting - guard stone

2020-12-21 Thread Volker Schmidt
I forgot to follow up on two other aspects of this, sorry.

A) how are they tagged when two of them are on both sides of a gate

?

B) There are occasionally also rows of them in historic towns

.

C) Freestanding guardstone-like objects are often found independently of
buildings.
I am not sure what they are called, here are some examples.
They come in three types of  arrangements:: pairs, or rows, or pairs of
rows.
The pairs are often on minor roads on embankments
 (don't know what
the purpose was)
The rows are often on major roads on embankments
, or older
mountain pass roads.

(predecessors of guardrails I suppose)

Volker


Virus-free.
www.avast.com

<#m_980705564951531214_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Mon, 21 Dec 2020 at 11:50, Anne-Karoline Distel 
wrote:

> Hi,
>
> there haven't been any comments on it in a while, so I think it is safe
> to start the voting process on
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/guard_stone
>
> Voting ends on January 4th.
>
> Thanks to everyone who contributed to the discussion and proposal page!
>
> Happy holidays,
>
> Anne (b-unicycling)
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Reservoirs, lakes, and ponds

2020-12-21 Thread Volker Schmidt
Thanks for the pointer, but It does not help. I'm an iD occasional basic
user only.
I am talking about the behaviour of JOSM.
Maybe I am also JOSM ignorant regarding its functionalities.

<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Mon, 21 Dec 2020 at 14:56, Paul Allen via Tagging <
tagging@openstreetmap.org> wrote:

> On Mon, 21 Dec 2020 at 09:02, Volker Schmidt  wrote:
>
>>
>> That we will have to live with two tags, or more,  for the same thing is
>> nothing new, what I don't like is to be pestered continuously to do things
>> to objects that happen to be in my downloaded area, and which I had no
>> intention even to look at.
>>
>
> If you open iD's issue inspector you have the choice of "My edits" or
> "Everything."  You also have the choice of "In view" or "Everywhere."  Does
> that help?
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Reservoirs, lakes, and ponds

2020-12-21 Thread Volker Schmidt
Yep.
I know that.
But for the tag to be on the deprecated tag list, it has to be deprecated
in the wiki, I presume at least. That is my point. I don't think that JOSM
will flag it deprecated because ID deprecated it, while the wiki still has
it as a valid tag.
That we will have to live with two tags, or more,  for the same thing is
nothing new, what I don't like is to be pestered continuously to do things
to objects that happen to be in my downloaded area, and which I had no
intention even to look at.
Mass deprecations are counter-productive in general and independently of
whether they the new tagging is better in some way..


On Sun, 20 Dec 2020 at 16:59, Paul Allen  wrote:

> On Sun, 20 Dec 2020 at 15:29, Volker Schmidt  wrote:
>
>>
>>
>>
>> In addition, please consider that deprecated features are being flagged
>> by editor sw on
>>
> saving any changeet that contains an deprecated tag, even if it has
>> nothing to do
>>
> with your actual editing, this would be adding another contnued nuisance
>> for mappers
>>
> (there are already others opf that type).
>>
>
>> Please don't do it
>>
>
> Too late, at least for iD.  Its authors have already decided to deprecate
> landuse=reservoir.  All this proposal does is document the fact.
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Continuous shoulder rumble strips (CSRS)

2020-12-20 Thread Volker Schmidt
The OSM wiki page Traffic_calming defines

   - traffic_calming=rumble_strip
   <https://wiki.openstreetmap.org/wiki/Tag:traffic_calming%3Drumble_strip>

as a structure that crosses the road. It also says explicitly:
" Do not confuse with longitudinally placed rumble strips to alert drivers
that they are leaving their lane, which are generally not mapped by OSM.
(See rumble strips <https://en.wikipedia.org/wiki/rumble_strips>.)"

Regarding the legal aspect of riding on the hard shoulder. I don't know the
general rules in the US States, but I rode several hundred km on freeway
hard shoulders in the western US that were explicitly signed as "cyclist
use hard shoulder". If necessary I can check with my friends of Adventure
Cycling Association - they are running a campaign to improve the situation
regarding the danger posed by longitudinal rumbling strips in the US.

On Sun, 20 Dec 2020 at 22:02, Paul Johnson  wrote:

>
>
> On Sun, Dec 20, 2020 at 10:27 AM Jeremy Harris  wrote:
>
>> On 20/12/2020 16:07, Volker Schmidt wrote:
>> > Is there a tagging scheme for these bicycle  killers
>> > <https://www.mapillary.com/map/im/vxYMpzmOjO8cZtfOMfFsKA>?
>> > I have encountered them on freeways and other major roads that allow
>> > cyclists, in the western States of the USA.
>>
>> How about
>>
>> cycleway = shoulder
>> shoulder:barrier = rumble_strip
>>
>
> I'm pretty sure a hard shoulder isn't actually a cycleway.
> ___
> 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 - Tag:traffic_calming=hillocky

2020-12-20 Thread Volker Schmidt
Martin, the former ones (
http://www.valsassinanews.com/image/original/12663.jpg )  are "tables" (
traffic_calming=table)  in OSM-speak - see
https://wiki.openstreetmap.org/wiki/Key:traffic_calming.


I was referring to the latter ones as sausage-shaped.

On Sun, 20 Dec 2020 at 17:02, Martin Koppenhoefer 
wrote:

> Am So., 20. Dez. 2020 um 16:11 Uhr schrieb Niels Elgaard Larsen <
> elga...@agol.dk>:
>
>> Martin Koppenhoefer:
>> > I thought they would make people drive slower, while retaining a
>> possibility for
>> > bicycles to pass in between.
>>
>> That is what the proposal says. But there is no way a bicycle could pass
>> between
>> those seen on the proposal page at anything near normal bicycling speed.
>
>
>
>
> in Italy common bumps are like these:
> http://www.valsassinanews.com/image/original/12663.jpg
> which do not pose a problem to cyclists at bicycle speed.
>
> and there are variations of these:
>
> http://www.terminalmilazzo.com/wp-content/uploads/2019/03/dosso-artificiale-300x169.jpg
> where quite often you can be lucky and one segment, to pass through by
> bike, is missing for reason or the other.
>
> 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


[Tagging] Continuous shoulder rumble strips (CSRS)

2020-12-20 Thread Volker Schmidt
Is there a tagging scheme for these bicycle  killers
?
I have encountered them on freeways and other major roads that allow
cyclists, in the western States of the USA. In theory there should be no
problem, as the cyclist is supposed to be on the shoulder all the time, but
in practice there are many situations where the shoulder is simply not
usable, and so you have to cross over them and back to avoid the obstacles
(in most cases a tyre carcass which sheds the dreaded bent-needle shaped
tire flatteners for cyclists)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Tag:traffic_calming=hillocky

2020-12-20 Thread Volker Schmidt
These objects need a new tag, not  a sub-tag of traffic_calming=bump (220k
uses), for the simple reason that it has a different effect on the road
users.
I have myself tagged many such sausage-shaped bumps with
traffic_calming=bump and no sub-tag. They slow down every vehicle, but are
not as particularly nasty to cyclists and, probably, motor cyclists as the
ones in the sample pictures.
If you were to create a sub-tag for the new ones, we would need to add a
dìfferent sub-tag to all the existing occurrences of .

Concerning the tagging:
If they are used only in a few countries, then we may want to use the term
used in one of these country, if  there is no British English term
available.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Reservoirs, lakes, and ponds

2020-12-20 Thread Volker Schmidt
383 813
*landuse* 
*reservoir* 
334 450
*water* 
*reservoir* 
I think it does make no sense to deprecate a tag with 380k uses.
The two will stay with us in parallel for the entire lifetime off the OSM
database
As you rightly state that no automatic conversion should be used, any
atempt of manual editing is a waste of time.
In addition, please consider that deprecated features are being flagged by
editor sw on saving any changeet that contains an deprecated tag, even if
it has nothing to do with your actual editing, this would be adding another
contnued nuisance for mappers (there are already others opf that type).

Please don't do it

Volker

On Sun, 20 Dec 2020 at 15:58, Brian M. Sperlongano 
wrote:

> A proposal[1] to clarify the tagging of reservoirs, lakes, and ponds is
> now open for comments.
>
> This proposal:
>
>   1. Deprecates landuse=reservoir
>   2. Provides definitions for:
>  a. water=reservoir
>  b. water=lake
>  c. water=pond
>
> It is clear from various multiple discussions on this topic that there are
> still open questions from the original 2011 water=* proposal, as well as
> the exact definition of a reservoir, and how they differ from lakes and
> ponds.  Previous discussions indicated that there is community support for
> maintaining a distinction between lake and pond, rather than eliminating or
> merging these concepts.
>
> The definitions posed in this proposal were developed with the help of
> considerable community input over the last week, and I want to thank the
> numerous folks that collaborated on this.  The real world presents many
> edge cases that make it challenging to come up with clear definitions, but
> that should not prevent us from trying.
>
> The goal in these definitions is to *describe* rather than *prescribe* how
> reservoir, lake, and pond are actually tagged.  This necessarily involves
> some degree of subjectivity between the categories, and the proposed
> definitions leave it to mappers to make these subjective decisions when a
> body of water exhibits some characteristics of more than one of these terms.
>
> As this topic has been discussed ad nauseam for nearly a decade, I hope
> that this proposal, discussion, and subsequent vote will allow us to put
> this issue to rest, and/or document the level of community support that
> exists for different tagging schemes.
>
> [1] https://wiki.openstreetmap.org/wiki/Proposed_features/Reservoir
> ___
> 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] Rapids (whitewater) on rivers

2020-12-17 Thread Volker Schmidt
There are area hazards around, like shooting ranges, and high electric
fields around radio transmitters, and more likely others.

I am not insisting on using the hazard key - I only noted similarities.

On Thu, 17 Dec 2020 at 17:33, Joseph Eisenberg 
wrote:

> Another argument against use of hazard=* for rapids is that the hazard key
> has been used almost always with highway=* features, not waterways.
>
> Also, currently waterfalls (which can be considered very large and steep
> rapids!) are tagged waterway=waterfall on a node. Other waterway barriers
> are also tagged this way, e.g. waterway=dam and waterway=weir. Tagging
> waterway=rapids on a node allows rapids to be tagged like other waterway
> barriers to travel and similar to waterfalls.
>
> -- Joseph Eisenberg
>
> On Thu, Dec 17, 2020 at 2:36 AM Tomas Straupis 
> wrote:
>
>> 2020-12-17, kt, 00:02 ael via Tagging rašė:
>> > This is slightly off-topic in that I am picking up on the
>> > hazard tag rather than rapids. I see no objection to adding
>> hazard=rapids
>> > although that might be redundant unless there exist rapids that are
>> > not hazardous. I suppose shallow rapids might qualify.
>>
>>   Note that rapid does not necessarily have to be interpreted as
>> hazard. If prominent on the ground it can be one of orienting points
>> (with bridges, settlements, intakes etc.) - to cover distance
>> covered/remaining. We have a lot of "small rapids" which can be easily
>> passed with no risk even with babies and they're still marked for
>> orienting purposes.
>>
>> ___
>> 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] cable:ferry

2020-12-17 Thread Volker Schmidt
What is missing in the route=ferry tagging is any way of indicating the
ferry type and/or size in general.
That would include a reaction ferry, amongst others

On Thu, 17 Dec 2020 at 09:36, joost schouppe 
wrote:

> Hi,
>
> This article https://wiki.openstreetmap.org/wiki/Tag:route%3Dferry
> mentions ferry:cable=yes as a reaction ferry -  a specific type of cable
> ferry. While the article has a picture of a non-reaction cable ferry, it
> offers no tagging suggestion for that. So I'm guessing that in practice,
> there is no tag for reaction ferry at all, and the wiki definition of
> ferry:cable should be changed.
>
> --
> Joost Schouppe
> ___
> 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] Rapids (whitewater) on rivers --> Hazards

2020-12-16 Thread Volker Schmidt
Brian,
I am trying to put order in this also in  my own mind.
I think we should have an approach which is already clearly structured
towards two things
A the difference between
- signposted hazards
- unsigned hazards perceived by the mappers
B for hazards that may have different degrees of hazardness (like the
difficulty classes of hiking paths, MTB tracks, rapids,...)
we should have solutions that allow a basic tagging plus the option of
classes of hazardness for advanced mappers

This approach should be put in the hazard proposal, even if at the moment
the proposal only covers signposted hazards.

Volker

PS be prepared: how do we tag a hazard like this.
<https://www.google.com/imgres?imgurl=https%3A%2F%2Fi.pinimg.com%2Foriginals%2Ff8%2F1f%2F81%2Ff81f81a46c423165f1ebf46dd63c9d64.jpg=https%3A%2F%2Fwww.pinterest.se%2Fpin%2F446208275551301611%2F=Lf3Kf2ucFsOb3M=12ahUKEwifs6ryz9PtAhUO16QKHZ2-AjEQMygAegQIARAu..i=EcY5sJtmk2sheM=1200=1050=1=california%20highway%201%20curves%20for%20next%2074%20miles=firefox-b-d=2ahUKEwifs6ryz9PtAhUO16QKHZ2-AjEQMygAegQIARAu>




On Wed, 16 Dec 2020 at 23:13, Brian M. Sperlongano 
wrote:

> As the maintainer of the current hazard proposal - I don't really have
> strong opinions about signed versus unsigned hazards, though I know others
> do.  However, signed hazards seem to be something that we all agree should
> be tagged, and this proposal is attempting to approve the collection of
> usages that we all agree on.  I knew going in that the topic was too big to
> be able to address every possible hazard that someone might want to tag but
> we have to start somewhere.
>
> So --- consider this proposal a starting point, not the end of the story!
>
> There is no reason why hazard tagging can't be expanded from this current
> base, and since we have free tagging, there is nothing stopping any mapper
> from either simply inventing their own new hazard tag values or other
> usages for things not covered, or offering new proposals to expand the
> usage.
>
> On Wed, Dec 16, 2020 at 5:02 PM ael via Tagging 
> wrote:
>
>> On Wed, Dec 16, 2020 at 10:22:44PM +0100, Volker Schmidt wrote:
>> > I see this subject directly related to the "hazard" discussion in the
>> sense
>> > that I suggested to clearly define the difference between signposted
>> > hazards/dangers/warnings and un-signed such situations that are
>> observable
>> > on the ground, and therefore are subject also to personal judgement.
>> With
>> > other words, beyond the question of how to map it, there is also the
>> > question of what is a rapid or any other hazard.
>>
>> I strongly agree. I was planning to vote against the current hazard
>> proposal on exactly these grounds. There are clear hazards that
>> are not necessarily signed. I don't see why we need two different
>> tags.
>>
>> This is slightly off-topic in that I am picking up on the
>> hazard tag rather than rapids. I see no objection to adding hazard=rapids
>> although that might be redundant unless there exist rapids that are
>> not hazardous. I suppose shallow rapids might qualify.
>>
>> 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] Rapids (whitewater) on rivers

2020-12-16 Thread Volker Schmidt
I see this subject directly related to the "hazard" discussion in the sense
that I suggested to clearly define the difference between signposted
hazards/dangers/warnings and un-signed such situations that are observable
on the ground, and therefore are subject also to personal judgement. With
other words, beyond the question of how to map it, there is also the
question of what is a rapid or any other hazard.
I would like to have a scheme for both situations, i.e. one scheme would be
for mapping signs for officially posted hazards, the other scheme would be
for hazards that the mapper sees on the ground, but without signposting.
In the signposted case the mapper has no role in assessing the presence or
not of the actual hazard, whereas in the second case we need  to establish
how to avoid wildly different meanings of the same tagging.
I'm familiar with two similar problems: mountain hiking and MTB routes. We
have tags for the level of difficulty for both of them (which are directly
related to the possible hazard). I use mountain paths and I ride a normal
touring bike off-asphalt. I can distinguish between, say, the lowest two
levels of difficulty in both cases, but not the higher levels, simply
because I would not go there.
So, transferring that to the rapids,: I can see a rapid in a river, but
cannot access its grade of difficulty (and I am also lacking the knowledge
of how much a river changes with the seasons and the weather).
I am a bit digressing from the posed question, but I think that should also
be taken into account.



On Wed, 16 Dec 2020 at 21:58, Joseph Eisenberg 
wrote:

> In the year 2020 waterway=rapids has been added a couple hundred times,
> and the other two tags whitewater:section_grade and whitewater:rapid_grade
> have been used about 100 times each:
> https://taghistory.raifer.tech/#***/whitewater:rapid_grade/&***/whitewater:section_grade/&***/waterway/rapids
> (zoom in to the most recent yet)
>
> I think both tagging methods have their use. The tag waterway=rapids is
> great to add to a node to specify that there are rapids here, and the
> others are good for expert kayakers and rafters who are able to assess the
> rapid grade.
>
> I don't know enough about the subject to make a proposal to clear things
> up, but the existing tags seem to be fine.
>
> -- Joseph Eisenberg
>
> On Wed, Dec 16, 2020 at 12:35 PM Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> wrote:
>
>>
>>
>>
>> Dec 16, 2020, 19:27 by kevin.b.ke...@gmail.com:
>>
>> The last time I looked, there was no non-deprecated way to map the
>> information that I had.
>>
>> That is sign of bad tagging scheme.
>>
>> I now see that @jeisenbe has restored the `waterway=rapids` tag to the
>> Wiki.
>>
>> Is it enough?
>>
>> I asked here on the mailing list, and the only answers that I got were
>> along the lines of "then don't map it."  So for several years I haven't
>> attempted to map rapids. The ones I know of and want to render, I maintain
>> separately from OSM, because the previous discussion had caused me to label
>> this feature mentally as, "OSM doesn't want this mapped."
>>
>> :( Hopefully this can be fixed so this will not happen.
>> ___
>> 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-13 Thread Volker Schmidt
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.


On Mon, 14 Dec 2020, 00:40 Brian M. Sperlongano, 
wrote:

> François, thank you for your hard work on this proposal!  I will most
> likely support this version.  I have a few questions:
>
> 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.
>
> 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.
>
>
> On Sun, Dec 13, 2020 at 1:48 PM François Lacombe <
> fl.infosrese...@gmail.com> wrote:
>
>> 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
>>
> ___
> 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-13 Thread Volker Schmidt
Missing at first glance: what is the mapper expected to do with pumping
stations.
We have around here in the Po valley, thousands of them for draining
purposes., and I presume that places like the Netherland have considerably
more of them. Many are housed in dedicated and locked buildings and they
often house several large pumps.
Normally you find the name of the operator posted somewhere.
Sometimes they have signs outside, giving the pumping capacity.
Sometimes, I can see the pipes, and that gives me an idea how many pumps
there are.
I also know that nowadays , apart from museums, pumps are operated by
electrical power.
The rest I don't know, and I would have to consult the web site of the
operator, as it may give some information.
But I think that goes far beyond what a normal mapper without specific
knowledge in pumps would ever do.
I am already happy if people map a man_mde=pumping_station and not only
building=industrial.







Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Sun, 13 Dec 2020 at 21:08, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Pumping_proposal#Examples
>
> Looking at the first example - I see nothing clearly indicating that pump
> is operated
> by muscle power.
>
> Is it intentional to not include this distinction?
>
>
> Dec 13, 2020, 19:45 by fl.infosrese...@gmail.com:
>
> 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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - crossing=priority

2020-12-13 Thread Volker Schmidt
In principle a good idea.
In the jurisdictions I am familiar with, any marked pedestrian crossing
gives priority to pedestrians over the traffic on the crossed road.
Unmarked crossing (no vertical sign, no horizontal sign) means no priority.
And each country has developed their own tagging on how to to map them in
OSM, and sometimes more than one,.
But the priority rules are more complex than you ay be aware of, when it
comes to cyclists crossing as well, which is a common situation.

Specifically in Italy we do have a strange situation, that cannot be
tackled with any tagging, unless you tag 0nly the the signage, but not
their meaning.
On normal pedestrian crossings cyclists riding their bike have no priority,
they need to dismount and push their bike, as pedestrians, to have the
priority.
On explicitly marked bicycle-only crossings or  bicycle-plus-foot crossings
they have the priority without dismounting.
So far so good
If a pedestrian-only crossing is painted and signposted to connect two
mixed foot-cycle-paths, cyclists have the priority even if the road signs
do not  show it (and it is ìonly based on some legal cases, but i tis not
written in the Highway Code.
The solution is to map what is on the ground, i.e. the signing, but leaving
the interpretation of the signing to the road user. .

In addition we have another area of uncertainty, i.e. the cases when
footways meet cycleways.As far as I know there are simply no rules for that
case.




Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Sun, 13 Dec 2020 at 21:55, Peter Elderson  wrote:

> Just to clarify:
>
> > crossing=priority Indicates that the node is a pedestrian crossing  
> when applied to highway=cycleway, should this read bicycle crossing?
>
> when applied to a highway=cycleway, does the tag imply priority for
> cyclists, pedestrians, or both?
>
> > belisha_beacon=yes|no
> Is belisha beacon a generally known term outside the UK?
> Since only presence is significant,  the value no is useless
>
> > segregated=boolean (yes/no) (no default assumed)
>
> Since the proposal talks about pedestrians, cycleways and horses crossing:
> what exactly is segregated when segregated=yes is applied to a cycleway?
> And with segregated=no, do motorists get a warning that horses may cross on
> the cycleway?
>
>
> Peter Elderson
>
>
> Op zo 13 dec. 2020 om 21:08 schreef ipswichmapper--- via Tagging <
> tagging@openstreetmap.org>:
>
>> Yes, most likely this won't be required. However I have kept it there in
>> case it works differently in other countries. Maybe not all zebra crossings
>> in Singapore have belisha beacons (for example, I don't know if this is
>> true). That is why I am leaving it open for discussion for now, if after
>> the RFC it is decided that this is a bad idea I'll remove it.
>>
>> Thanks,
>> IpswichMapper
>>
>> --
>>
>>
>> 13 Dec 2020, 19:50 by tagging@openstreetmap.org:
>>
>> It seems to be proposing also belisha_beacon=yes that
>> is now unused
>> https://taginfo.openstreetmap.org//search?q=belisha_beacon%3Dyes
>>
>> At the same time it has
>> "However, in countries like the UK, where belisha beacons are used, every
>> single zebra crossing has belisha beacons installed, so there is no need
>> to tag them"
>>
>> There is also
>> "Indicates the presence of a "belisha beacon" at the crossing. (Most
>> likely unnecessary, discuss below)"
>>
>> Given there is no indication that it would be useful or needed I think
>> that it should be not proposed.
>>
>> If that it would be useful or needed it can be proposed separately.
>>
>> Note that having two proposals in one will result in people voting against
>> if there are against any of them, so splitting would be a good idea
>> anyway.
>>
>> Dec 13, 2020, 20:25 by tagging@openstreetmap.org:
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/crossing%3Dpriority
>> 
>>
>> Here is my first proposal for a tag to describe pedestrian crossings
>> where the pedestrian has right of way over all vehicles on the road from
>> the moment they have indicated their intent to cross. I created this
>> because "crossing=zebra" or "crossing=marked" aren't clear enough. Please
>> read the proposal for more details.
>>
>> Thanks,
>> IpswichMapper
>>
>>
>>
>> ___
>> 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 - barrier:guard_stone

2020-12-09 Thread Volker Schmidt
My apologies, wrong link!
The corner guard stone is here:
https://www.mapillary.com/map/im/USu9htX8nw95mW77kSeZ7Q

Volker

On Tue, 8 Dec 2020 at 23:40, Alan Mackie  wrote:

>
>
> On Tue, 8 Dec 2020 at 17:03, Volker Schmidt  wrote:
>
>> My gard stone example  on a building corne
>> <https://www.mapillary.com/map/im/YNhbgcyBHpYAhqatX0CwSF>is also useful
>> for this part of the discussion. I know the place well and I know the local
>> amateur history expert, and we talked about this specific stone, and also
>> asked about its historic value.
>>
> I'm sorry, I'm having trouble spotting it at that link, is it by the gate?
>
>> It is anywhere between 100 and a couple of hundred years old. It is on a
>> building the walls of which may have many hundreds of years. So it's
>> historical and as it's the only guard stone in that part of the city, it's
>> most likely also historic, not because in itself it is historic, but it's a
>> historical marker, as we are not good at keeping historic buildings of
>> minor importance.  The next building down the road, (which BTW may well be
>> of Roman origin as it used to lead straight to the historic city center of
>> Roman Patavium) was a tavern with several hundred years of confirmed
>> history, but was torn down about ten years ago to make place for a new
>> private house. So my personal opinion is that it is historic, even though
>> most likely 99% of the locals have never noticed it.
>>
>> On Tue, 8 Dec 2020 at 15:15, Paul Allen  wrote:
>>
>>> On Tue, 8 Dec 2020 at 09:56, Martin Koppenhoefer 
>>> wrote:
>>>
>>>>
>>>> I am not saying that these stones should or not get a historic tag, but
>>>> surely it isn’t an argument that one of the OpenStreetMap based maps
>>>> highlights things based on a wildcard selection.
>>>>
>>>
>>> Not an argument, merely a piece of evidence to consider.
>>>
>>>
>>>> If this tag would pose a problem for their rendering I am sure they
>>>> would adjust the selection rules.
>>>>
>>>
>>> Or perhaps we should not force them to adjust their selection rules by
>>> abusing
>>> "historic" to mean "old."  We have start_date=* to specify that things
>>> are old.
>>>
>>>>
>>>> Regarding “historic means historic as in the battle of Waterloo or the
>>>> pyramids of Gizeh”, we have seen from previous discussion that this was a
>>>> minority opinion.
>>>>
>>>
>>> An explanation, by one person, of what the wiki page says and the
>>> distinction
>>> between "historic" and "historical."  Those do not mean the same thinhg,
>>> however much you wish them to.
>>>
>>> On the one hand we have the wiki page, the distinction between
>>> "historic" and "historical" and a map with the sole purpose of
>>> rendering historic, rather than historical, objects.  On the other
>>> hand we have people who insist that "historic" means "historical."
>>>
>>> Many people see historic as a keyword for objects that typically could
>>>> be seen as historic, but then includes any objects of the class, without
>>>> further  differentiating them by “historic value”.
>>>>
>>>
>>> Many people do not read the wiki page.  Many people do not understand
>>> the distinction between "historic" and "historical."
>>>
>>>>
>>>> We do not have different tags for truly historic wayside shrines or
>>>> crosses and others. How many charcoal piles do you expect to be of
>>>> exceptional historic value?
>>>> https://taginfo.openstreetmap.org/keys/historic#values
>>>>
>>>
>>> I would expect a handful, at most, not the tens of thousands that have
>>> been
>>> mapped.  Those SHOULD have been mapped with a lifecycle prefix.  But
>>> people who don't understand the difference between "historic" and
>>> "historical" and don't read the wiki misuse historic=* then document it.
>>>
>>>>
>>>> For guard stones I could imagine using the man_made key as well, but
>>>> historic would seem to work because most of these are giving testimony of
>>>> former times.
>>>>
>>>
>>> "Historic" does not mean "historical."  Those stones are historical but
>>> they are not historic.  If you want to emphasise that they are old,
>>> start_date=* is the way to go.
>>>
>>> --
>>> Paul
>>>
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - barrier:guard_stone

2020-12-08 Thread Volker Schmidt
My gard stone example  on a building corne
is also useful for
this part of the discussion. I know the place well and I know the local
amateur history expert, and we talked about this specific stone, and also
asked about its historic value.
It is anywhere between 100 and a couple of hundred years old. It is on a
building the walls of which may have many hundreds of years. So it's
historical and as it's the only guard stone in that part of the city, it's
most likely also historic, not because in itself it is historic, but it's a
historical marker, as we are not good at keeping historic buildings of
minor importance.  The next building down the road, (which BTW may well be
of Roman origin as it used to lead straight to the historic city center of
Roman Patavium) was a tavern with several hundred years of confirmed
history, but was torn down about ten years ago to make place for a new
private house. So my personal opinion is that it is historic, even though
most likely 99% of the locals have never noticed it.

On Tue, 8 Dec 2020 at 15:15, Paul Allen  wrote:

> On Tue, 8 Dec 2020 at 09:56, Martin Koppenhoefer 
> wrote:
>
>>
>> I am not saying that these stones should or not get a historic tag, but
>> surely it isn’t an argument that one of the OpenStreetMap based maps
>> highlights things based on a wildcard selection.
>>
>
> Not an argument, merely a piece of evidence to consider.
>
>
>> If this tag would pose a problem for their rendering I am sure they would
>> adjust the selection rules.
>>
>
> Or perhaps we should not force them to adjust their selection rules by
> abusing
> "historic" to mean "old."  We have start_date=* to specify that things are
> old.
>
>>
>> Regarding “historic means historic as in the battle of Waterloo or the
>> pyramids of Gizeh”, we have seen from previous discussion that this was a
>> minority opinion.
>>
>
> An explanation, by one person, of what the wiki page says and the
> distinction
> between "historic" and "historical."  Those do not mean the same thinhg,
> however much you wish them to.
>
> On the one hand we have the wiki page, the distinction between
> "historic" and "historical" and a map with the sole purpose of
> rendering historic, rather than historical, objects.  On the other
> hand we have people who insist that "historic" means "historical."
>
> Many people see historic as a keyword for objects that typically could be
>> seen as historic, but then includes any objects of the class, without
>> further  differentiating them by “historic value”.
>>
>
> Many people do not read the wiki page.  Many people do not understand
> the distinction between "historic" and "historical."
>
>>
>> We do not have different tags for truly historic wayside shrines or
>> crosses and others. How many charcoal piles do you expect to be of
>> exceptional historic value?
>> https://taginfo.openstreetmap.org/keys/historic#values
>>
>
> I would expect a handful, at most, not the tens of thousands that have been
> mapped.  Those SHOULD have been mapped with a lifecycle prefix.  But
> people who don't understand the difference between "historic" and
> "historical" and don't read the wiki misuse historic=* then document it.
>
>>
>> For guard stones I could imagine using the man_made key as well, but
>> historic would seem to work because most of these are giving testimony of
>> former times.
>>
>
> "Historic" does not mean "historical."  Those stones are historical but
> they are not historic.  If you want to emphasise that they are old,
> start_date=* is the way to go.
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Many historic=wayside_cross are not historic

2020-12-07 Thread Volker Schmidt
Italy is very religious (roman catholic).
Just in the Veneto region there are 2045 nodes + 532 polygons tagged as
wayside crosses or shrines.
That includes everything from a homemade little altar on the fence of a
private home to a minute chapel-like shrine on a minor road crossing that
most likely sits on top  of a Roman shrine for the local water goddess.

My real question is: Am I correct that this is the accepted tagging after
all, and that's it?


On Mon, 7 Dec 2020 at 23:46, Paul Allen  wrote:

> On Mon, 7 Dec 2020 at 22:33, Volker Schmidt  wrote:
>
>> I am sure someone has made this observation before me:
>>
>
> We rehash this frequently. :)
>
> Many historic=wayside_cross and historic=wayside_shrine are not historic
>> objects in the sense of the definition of the wiki page Historic
>> <https://wiki.openstreetmap.org/wiki/Historic> which reads:
>> "The historic <https://wiki.openstreetmap.org/wiki/Key:historic>=* key
>> is used to identify features that are of historic interest"
>>
>
> That depends how you define "historic interest."
>
> We have 130k "historic" wayside crosses and 80k "historic" wayside shrines
>> in the database.
>> Many of these are "mine" and many of these are certainly not of any
>> historical interest, they are often not even old. But some few certainly
>> are historic.
>>
>
> The roadside shrines commemorating accidents are historic.  That accident
> may have happened long ago and the memorial erected yesterday.  Or the
>  accident may have happened recently.  Such shrines act as a form of
> plaque saying "this happened here on this date."
>
> The ones that do not commemorate an accident or other historic event are
> merely open-air places of worship.  The equivalent of a chapel of ease
> without the building.  However, if they were on a historic pilgrimage
> route,
> then they may count as historic, although that is debatable.
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] Many historic=wayside_cross are not historic

2020-12-07 Thread Volker Schmidt
I am sure someone has made this observation before me:
Many historic=wayside_cross and historic=wayside_shrine are not historic
objects in the sense of the definition of the wiki page Historic
 which reads:
"The historic =* key is
used to identify features that are of historic interest"
We have 130k "historic" wayside crosses and 80k "historic" wayside shrines
in the database.
Many of these are "mine" and many of these are certainly not of any
historical interest, they are often not even old. But some few certainly
are historic.

Volker
mostly mapping in Italy
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - barrier:guard_stone

2020-12-07 Thread Volker Schmidt
Yes, that tag is a good idea.
But, it is not a barrier on the way, but a single object off the way.
Normally, but not always they come in pairs, but it does not always come in
pairs. They are often corner stones.
When there is a pair, i.e. one on each side, it would make sense to see it
as a barrier, with maxwidth.
But if it is on a building corner
, it is a single
object, not a barrier at all.
Needs some thinking.
Volker


On Mon, 7 Dec 2020 at 22:28, Anne-Karoline Distel 
wrote:

> Hi everyone,
>
> mostly for European use (I think), I propose a new node type barrier,
> namely "guard stone":
>
> A guard stone is in most cases a stone built onto or into the corner of a
> building or wall. They are usually found on either side of an entrance to a
> laneway or gateway. Guard stones may be put alongside a wall to protect it.
> Many are historical barriers that kept the wheels of carriages from
> damaging buildings. Some of them bear survey markers such as benchmarks.
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/guard_stone
>
> Thanks, have a good time, stay safe.
> ___
> 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 - Hazards

2020-12-05 Thread Volker Schmidt
Traffic lights triggered by avalanches! Is that close enough, Martin?

https://elearning.unipd.it/scuolaamv/pluginfile.php/19629/mod_resource/content/1/04_02%20difesa%20dalla%20valanghe.pdf

I remember I saw them for the first time in 1985 in the Val Zoldana,
Provincia di Belluno (SP251), but had no idea how they worked. The document
above explains it.
:-)

Volker

On Sat, 5 Dec 2020 at 19:22, Martin Koppenhoefer 
wrote:

>
> >
> > Also at much larger airports. Brize Norton
> > (https://en.wikipedia.org/wiki/RAF_Brize_Norton), for example.
>
>
> you guys are finding real world examples for every weird situation that
> nobody expected to even exist. Traffic lights for rock fall somewhere?
>
> 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 - Hazards

2020-12-05 Thread Volker Schmidt
Hi,
I have been following this proposal with interest. I often have tried to
tag hazards, and not found a good ways of doing it.
We are now compiling a long list of hazards, including golf players
crossing the road, but I see some basic aspects which are not being
addressed (unless I missed something):

I would like to see signposted hazards completely separately tagged from
hazards that the mapper perceives in a place, but which are not signed.

Signed hazards should be mapped.

   - on nodes, if the extension of the hazard is point-like (example:
   dangerous railway crossing)
   - on ways, if the hazard exists along a highway (example: animals
   crossing zones)
   - (possibly) on areas, if the hazard is present in an area (example:
   landslides)

In the case of signed hazards, I see two alternative ways of tagging the
signing:

   - (only for nodes and ways highway segments) by adding source:xxx=sign
   like we do with speed limits
   - by mapping the relative signs as nodes

Insertion of signposted hazards do not require any assessment of the
presence of the hazard by the mapper.

Signposted hazards are most often signalling dangers for vehicle drivers.
Let's take the sign for hazard=cyclists (crossing), which warns clearly the
vehicle drivers on the carriageway, that there could be cyclists crossing.
There is normally no such warning on the crossing cyclists' path.
There are exceptions of hazard warnings for both parties like a "cyclists
sharing the road" sign, but that's the only one that comes to mind.

Another aspect that should be defined: Are writings or pictograms on the
road surface equivalent to vertical traffic signs?


A completely different story are unsigned hazards with no signs on the
ground, i.e. situations perceived as a hazard by the mapper.
These are the tricky ones. I map cycling infrastructure, hence my examples
come from that perspective.
Examples:

   - foot-cycle crosswalks where there is a sign-posted speed limit of
   30km/h, but where 90% of the cars pass with speeds far exceeding that value
   and making the place really dangerous
   - a two-way cycle path that is parallel to a main road and crosses  a
   side road with a foot.bicycle crosswalk - car drivers entering the side
   road regularly overlook cyclists which ride in the same direction as they
   drive (to my knowledge the major cause of cyclists being killed in many
   countries. These in most cases in my part of the world have no danger
   signs.
   - And now consider the same situation with a row of trees between the
   cycle path and the main carriage way.
   - In my part of the world authorities put all kinds of bollards, arches,
   chicanes on cycleways (supposedly for the safety of cyclists, but in
   reality to keep car drivers from parking there). Many of these are grey
   metal objects that become invisible at night even if you have a good cycle
   light, as they have no reflective markers on them.

The problem here is that the tagging will be based on my perceived version
of ground truth. If I am a cyclist, I may be good at spotting hazards for
cyclists. If I am a horse rider I will be good at mapping hazards for horse
riders.

Then we have also the asymmetric situations: e.g. car drivers are warned by
a sign that there will be cyclists crossing, but the (bigger) hazard of
cars hitting the cyclists on the same crossing is not signposted for
cyclists.

Volker


On Sat, 5 Dec 2020 at 17:05, ael via Tagging 
wrote:

> On Fri, Dec 04, 2020 at 09:48:27PM +, Paul Allen wrote:
> > On Fri, 4 Dec 2020 at 19:56, Martin Koppenhoefer  >
> > wrote:
> >
> > Up until around ten years ago, a minor road went past the end of the
> > runway at what passes for an airport.  The planes could be so low on
> > approach to the runway that there were traffic signals to prevent
> > vehicles crossing the path of an aircraft.  There were also signs
> > warning of low-flying aircraft, which I referred to as "Give way
> > to aircraft."
>
> Also at much larger airports. Brize Norton
> (https://en.wikipedia.org/wiki/RAF_Brize_Norton), for example.
>
> https://www.openstreetmap.org/node/190194553 for one of the traffic
> lights.
>
> 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


Re: [Tagging] Animal trails

2020-12-02 Thread Volker Schmidt
There is another problem with animal paths completely apart from
permissions: they may lead you to nowhere.
(years back I nearly got lost in a labyrinth of footpaths in the dense
macchia in Corsica. They were well visible and wide, but just high enough
to walk for children, and were actually trodden by escaped bovines or wild
boar (?). I really got scared - I had no compass and no provisions)

On Wed, 2 Dec 2020 at 13:19, Brian M. Sperlongano 
wrote:

>
>
> On Wed, Dec 2, 2020 at 7:03 AM Martin Koppenhoefer 
> wrote:
>
>> Am Di., 1. Dez. 2020 um 18:08 Uhr schrieb Brian M. Sperlongano <
>> zelonew...@gmail.com>:
>>
>>> +1, it's unreasonable for mappers to be mind readers about the intent of
>>> land managers.  Either the public is allowed to walk on these paths, or
>>> they are not.  There isn't really a middle ground here.
>>>
>>
>>
>> There is middle ground. For example in many German nature reserves, you
>> may enter the reserve, provided you remain on the foot paths.
>>
>
> We are saying the same thing.  access=yes for the allowed paths, access=no
> for anything else.  The topic of discussion are unofficial/social/animal
> paths in places where there are established paths intended for visitors.  I
> suppose if there is a middle ground you could muster access=discouraged,
> but the documentation says this is for signed roads, not unsigned paths.
> ___
> 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] Segregated foot-cycle path with different surfaces

2020-11-23 Thread Volker Schmidt
How do I correctly tag this way: OSM way 434742113
,  Mapillary image

It's a segregated bidirectional foot-cycleway:
highway=path
bicycle=designated
foot=designated
segregated=yes
onewy=no
Its overall width is
width=4
It's illuminated
lit=yes
Its surface is ok:
smoothness=good
I want to indicate the relative position of foot and cycle lanes:
lanes=2
bicycle:lanes=no|yes
foot:lanes=yes|no
I'm tempted to extend this approach  to the surface and width as well:
surface:lanes=asphalt|fine_gravel
width:lanes=1.5|2.5

Is this tagging correct? Are there (better) alternatives?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Tagging Cycle Route Relations vs. Ways

2020-11-16 Thread Volker Schmidt
The ways making up a cycle route typically have names themselves, and the
Route name normally is not the name of the way,
Hence in many cases this would be a mapping error, i.e. the name of the way
is not correctly tagged in the database.

There may be exceptions to this general, abstract statement, so it would be
useful if you could five pointers to specific examples.
For example it is well possible that a local administration assigns the
name of the Route as name to a specific way that is part of the Route, so
certainly any corrections need either local knowledge or street level
photos that show name signs (e.g. Mapillary)




Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Mon, 16 Nov 2020 at 17:22, Seth Deegan  wrote:

> The Cycle Routes Wiki Page
> 
> states:
> "It is preferred to tag the cycle routes using relations instead of
> tagging the ways."
>
> If I come across a route that has the Ways already tagged with the name
> =* of the route, can I
> delete the name =*s in the
> Ways and just create a Route Relation with the name?
>
> I assume this is not prefered because a number of applications use the
> names in the Ways themselves and not the Route Relation, most notably
> osm-carto.
>
> However, some benefits of doing this might be:
>
>- Takes up less space in the DB
>- More tags that apply to the whole coute could be added to the
>Relation like surface 
>=* and source =* (like
>the official map of the route).
>- Ways with two or more routes wouldn't be tagged name
>=route 1 & route 2
>
> 
>  and
>instead have their respective Relations. This could help with preferred
>routing/data usage in general.
>
>
> I would propose that *all* routes and their names should be tagged in a
> Relation and *never* the Ways, even if the Route Relation only has *one
> member*.
>
> This way data consumers know that all Routes are going to be relations.
> Also future Routes mapped that share the Way of a Route that does not have
> Relation, won't require the mapper to shift all of the data stored in the
> Way to a new Relation.
>
> Also, if Proposed features/Relation:street
>  is
> ever approved, this would help establish a consistent OSM-wide routing
> standard.
>
>
> *As for now*, I do not think that we should be deleting the name
> =*s of Ways. However, I
> think osm-carto *should* render and *prefer* to render Relation names for
> Cycle routes over the names of the Ways. The Editors should also somehow
> influence users to map Relations for Cycle routes instead of naming them.
>
>
> Thoughts?
> Seth Deegan (lectrician1)
> ___
> 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] Defining the meaning of capacity tag for tourism=camp_site

2020-10-31 Thread Volker Schmidt
Looks like a good idea.

In that context: When travelling with a bike and a small tent (applies
equally to hikers) I have encountered the following issues:

   - camp sites that do not accept small tents  - they only have places for
   caravans and large tents.
   - camp sites that do have areas dedicated to that type of travellers,
   but the limit is the space, there is areno  max numbers of persons or tents

If you cannot give any precise max numbers, it would be nice to have some
kind of classification of size of a camp site but I have no idea how to
express that aspect.

If we are introducing a major change thes issues could also be addressed

Volker



On Sat, 31 Oct 2020 at 14:43, Sven Geggus 
wrote:

> Jan Michel  wrote:
>
> > In fact, capacity:caravan and capacity:motorhome are used more often
> > compared to caravans and motorhomes.
> >
> > I would go for
> >
> > - capacity:persons
> > - capacity:tents
> > - capacity:caravan
> > - capacity:motorhome
>
> We are already using plural when tagging caravans=yes/no and tents=yes/no.
>
> Thus I would not suggents to tag this singular in case of capacity.
>
> Looking at the current state of tagging in taginfo we have:
>
> capacity:caravans 65
> capacity:caravan 4
> capacity:tents 241
> capacity:tent 0
>
> Thus I do not see a real argument for using singular here.
>
> Sven
>
> --
> "Thinking of using NT for your critical apps?
>   Isn't there enough suffering in the
> world?"
>(Advertisement of Sun Microsystems in Wall Street
> Journal)
> /me is giggls@ircnet, http://sven.gegg.us/ on the Web
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2020-10-30 Thread Volker Schmidt
I am confused on what the tag electricity= is intended for.

You say in the first of the two proposals:
" The parent key electricity
 would be used to tag
the availabilty and source of electricity, i.e. whether a building or
amenity has electricity. The availability of this electricity to the
public, either for free or for a fee, would be determined by the typical
access  and fee
 tags."

So let's go to the practical side:
My home is an average single family house in an average city in an average
country in Europe.
As for 99.9% of the buildings in this country it is connected to the
(national) electricity grid, hence electricity=grid.
But I do not sell electricity to the public, and I do not offer a free
electricity supply to the public, hence it would be
electricity:access=private
So we will start a major campaign to add the two tags to 99.9% of the
buildings in my country? This cannot be done automatically, as there are
the odd (for the time being) buildings that are autonomous with, for
example, solar + battery.and other odd arrangements.

I am sure that you have thought of that and the intention is to put the
electricity= tag only on some categories of buildings in those areas of the
world where it is normal to be connected to the grid, but which?

Going on from there, what about other services like drinking water, sewage,
surface water drainage, television antennas, Internet connection, postal
delivery services, garbage collection, and so on?

I have to confess, I only have questions, but no answers.

Volker



On Fri, 30 Oct 2020 at 13:47, Lukas Richert  wrote:

> Since a lot of people apparently didnt see the RFC the first time, I'll go
> back to RFC status for now. (I thought the threads were sorted by subject
> title of the email and didnt check online if it was actually visible. )
>
>
> --
>
> The original message:
>
> Hello all,
>
> after the comments on the confusing nature of the word 'source' in my
> original proposal of 'electricity:source', I have now changed the name to
> 'electricity:origin' as suggested on the discussion page. Furthermore, I
> would like to revive and extend the proposal of the key 'electricity' as
> this previously conflicted with parts of the electricity:source proposal
> and was not consistent.
>
> Both proposal pages:
>
> [1] https://wiki.openstreetmap.org/wiki/Proposed_features/electricity
>
> [2]
> https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/electricity:source
>
> The idea now is to allow for the tagging of buildings or amenities that
> have electricity. The rationale is described in more detail at [1]. Tags
> such as access, fee, schedule and origin can then narrow down the
> availability to the public and the question of financial or direct origin
> of the electricity.
>
> This is distinct from the drafted tag power_supply as it is used to
> describe the type of sockets used at a specific outlet. The values for that
> tag are still currently under discussion.
>
> I would also not tag this as a subset of power=* as this maps the
> facilities and features that relate to the generation and distribution of
> electrical power and should not be used to map the consumers of electricity.
>
>
> I am eager to hear the feedback to the revised proposals!
>
> ---
>
> Also, perhaps relevant: both the  power_supply
>  and socket
>   keys describe the same
> feature. power_supply so far has occasionally been used in the manner that
> electricity proposes to be. Unfortunately, the proposal for power_supply is
> relatively inconsistent. I think the socket:* tag is better thought out and
> also currently more used. I would be in favor of deprecating power_supply
> and separating the two meanings it currently has into electricity=* and
> socket:*=#.
>
> Regards,
>
> Lukas
> ___
> 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] What does bicycle=no on a node means?

2020-10-19 Thread Volker Schmidt
Martin, please do not even think about deprecating a tagging that is
heavily used.like highway=crossing with bicycke=no|yes|dismount
I am already ignoring the frequent JOSM Warning about the deprecated
crossing=island which JOSM shows me everytime I download a stretch of road
that contains this tagging, not to speak of the tens of warnings of
deprecated tags in bus lines, which I even don't know how to fix, that turn
up everytime I my download area touches a bus line.

I also don't agree with " not worth the benefit of informing cyclists
whether they have to push 4 meters or can drive on the crossing.". To the
contrary, I would like the bicycle routers to inform the cuyclist about the
difference nd send them preferably across bicycle-friendly crossings.
Good bicycle navigation is an important issue, in the context of bike
sharing, and for people who trvel with their folding bikes.

Volker


On Mon, 19 Oct 2020 at 10:29, Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 18. Oct 2020, at 10:39, Mateusz Konieczny 
> wrote:
> >
> > Still, highway=crossing bicycle=no is an acceptable tagging (like you
> can map cemeteries or parks
> > or churches as nodes in the first pass, especially when there is no good
> aerial imagery available)
>
>
> my preference is deprecating this as it has too many risks, not worth the
> benefit of informing cyclists whether they have to push 4 meters or can
> drive on the crossing.
>
> I would suggest sth like crossing:bicycle=yes/no
>
> 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] What does bicycle=no on a node means?

2020-10-17 Thread Volker Schmidt
On Thu, 15 Oct 2020 at 09:46, Martin Koppenhoefer 
wrote:

> Generally, I would propose to only tag crossing =* on the crossing node,
> but refrain from access like tags on this node (no bicycle or foot tags).
> The access should be derived from the crossing ways.
>

This statement is only correct if there are crossing ways using the
crossing node.
However, in practical terms it happens very often that in a first mapping
of a road the foot and/or bicycle crossings, as they are nicely visible on
aerial imaging, ar mapped, but not the crossing foot- and/or cycle-ways,
mainly because the details are not visible on aerial imagery or the mapper
is not interested, at that stage, in foot/cycling details. And the
distinction, at least in Italy, between foot-only and combined foot-cycle
crossing are well visable on satellite imagery. Also traffic-signals are
often clearly visible because of the stop lines. Hence in that first round
it is easy to map crossings and basic crossing types. The crossing way is
then often added later. To me it comes natural not to remove the existing
tagging on a crossing node when I add a crossing  way later.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Crossing tagged on both way and node (was: What does bicycle=no on a node means?)

2020-10-15 Thread Volker Schmidt
I don't know what the routers need, to be honest.
I have adopted the approach happily because of the frequent two-stage
approach. First the main road is mapped with foot/bicycle crossings as
nodes , and at a later stage someone else may add the foot/cycleway
details  - I did not occur to me that there may be an advantage in removing
at that stage the already existing crossing node.
I would also naively assume, that a car-only router does not need to
inspect any of the foot/cycleways in the map, and can use the
highway=crossing nodes as an indication to add small delays inthe routing.
Anyone in the router business listening in on this conversation?

On Thu, 15 Oct 2020 at 17:39, Jmapb via Tagging 
wrote:

> On 10/13/2020 6:30 PM, Kevin Kenny wrote:
>
> On Tue, Oct 13, 2020, 17:41 Volker Schmidt  wrote:
>
> I changed the crossing to the way we do it in many parts of Europe, i.e. a
>> crossing node *and* a crossing way. This was described as an option on
>> the highway=crossing wiki page until it was changed on 07:52, 3 October
>> 2020by user Emvee <https://wiki.openstreetmap.org/wiki/User:Emvee> by
>> addng the diagram and its description.
>> If you don't like it, please change it back - I used it in place of a
>> longish explanation.
>>
>
> Both of those are better, thanks! The routers that I use for testing seem
> to be aware of crossings without crossing nodes, so I too often forget to
> tag them.
>
> I've always been surprised to see a footway=crossing/cycleway=crossing way
> with the intersection node tagged as highway=crossing. There's only a
> single physical crossing, so this seems contra to the
> one-feature-one-element rule.
>
> A highway=crossing node makes sense in an area without mapped
> footways/cycleways. But if the crossing ways are mapped, routing software
> will need to examine the intersection node and scan the properties of all
> highways intersecting there. It seems to make tagging the node itself
> redundant.
>
> Are there really routers that require the node be tagged as well?
>
> Jason
> ___
> 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] Proposal to change key:man_made to key:human_made

2020-10-15 Thread Volker Schmidt
May I remind my dear mapper friends, that tags are just that: tags. From
the database point of view these are just couples of arbitrarily chosen,
character strings. OSM uses a convention to make it easier to memorize
these strings by using GB-English terms for them, but, I repeat that is
just a convention to help our human brain facilities. If you were to
replace the string "man_made" at every occurrence in the database and in
all programs that use the database with "3rgnJI)oò-" this would make no
difference to OSM (provided you use different strings for different
keys/values), but it would make a huge differnce to the work of
inserting/correcting/consulting data by human beings.
In addition, replacing one string with another string in all occurrences in
OSM, apart from creating completely unnecessary new versiones of the
objects, is trivial. Changing all products that make use of these data will
be an enormous amount of work.
And all this effort achieve what?

On Thu, 15 Oct 2020 at 14:22, Paul Allen  wrote:

> On Thu, 15 Oct 2020 at 09:38, Martin Koppenhoefer 
> wrote:
>
>>
>> I fear in „human“ there is still a man, even in every woman there‘s a
>> man, as in female there is a male. Overall it looks as if English is not
>> suitable for gender neutral language,
>
> everything refers back to men. I propose to use German as the language for
>> tags.
>>
>
> Hahahaha.  That would resolve "man made."  By replacing "made."
>
>
>> It might look like an impossible endeavor at first glance to retag those
>> millions or billions of objects, but if you dig deeper you will find that
>> many tags are already more German than English, so ultimately it wouldn’t
>> be as much change as it may sound initially.
>>
>
>  It only needs a little re-tagging.  Simple.
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] What does bicycle=no on a node means?

2020-10-13 Thread Volker Schmidt
On Tue, 13 Oct 2020 at 22:16, Emvee via Tagging 
wrote:

> On 13/10/2020 16:07, Kevin Kenny wrote:
>
>
> I don't try to solve it. I put in a short way for the crossing.
>
> https://www.openstreetmap.org/way/781981138 is the first example that
> came to mind for me. https://www.flickr.com/photos/ke9tv/49667335508 is a
> street view of the crossing in question.
>
> That is a perfect solution that is even better then it would be as mapping
> the crossing node because now the router can make a good estimate based on
> the length on what travel time it takes, that is not possible with a node.
>

I changed the crossing to the way we do it in many parts of Europe, i.e. a
crossing node *and* a crossing way. This was described as an option on the
highway=crossing wiki page until it was changed on 07:52, 3 October 2020by
user Emvee  by addng the
diagram and its description.
If you don't like it, please change it back - I used it in place of a
longish explanation.
(I also moved the two stops away from the end nodes of the ways as the tag
direction=forward|backward is better not placed on a node that connects two
ways )

This recent wiki change by Emvee
 is in my view not helpful,
or even misleading, as it does discourage a wide-spread tagging practice
(if we like this or not is a different question, but it's established
tagging, and the wiki is supposed to describe the establsihed methods of
tagging)

Volker
(Italy)


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] bicycle lane on mini-rounabout

2020-10-10 Thread Volker Schmidt
How do I tag a bicycle lane (way.Type element on a mini-roundabout
(node-type element)?.
Example:
https://www.mapillary.com/map/im/-yxlx8FNVBHgMC7LH9eFNA



Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Tagging a government job centre

2020-10-10 Thread Volker Schmidt
If you go to the (admittedly, very short) wiki page for
office=employment_agency, you find that the picture illustrating the tag
shows a German "jobcenter" of the Agentur fuer Arbeit, which is a government
agency. 
So I think your starting assumption is not reflecting the actual tagging
This means also that your idea of creating a new "government" related tag
would be in conflict with the established tagging, at least in Germany

Volker
(Italy)


> On 10/10/2020 00:09, António Madeira via Tagging wrote:
> >> I was searching for a way of tagging a government job centre and I found
> >> there's no suitable way of doing this.
> >> There's office=employment_agency which doesn't seem to fit here, cause
> >> it seems to correspond to private companies who work with this kind of
> >> services.
>


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2020-09-29 Thread Volker Schmidt
The main problem is the ground truth. A mapper cannot verify the supply
contracts.
The only exception could be the presence of a generator on the premises.




Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] "width" on streets: Time for a recommendation

2020-09-29 Thread Volker Schmidt
May I injection another complication: In many jurisdictions the width
available to the moving traffic is defined by white lines on the tarmac
creating an additional safety/buffer zone between the marked parking spaces
and the flowing traffic.

On Tue, 29 Sep 2020, 12:52 Pieter Vander Vennet, 
wrote:

> Hey Alex,
>
> First of all, I didn't consult the community for this project, I just
> wanted to get it rolling. We pondered a long time about how to measure
> for our local situation, not about what would be the most appropriate
> tag for use worldwide. Sorry for that and again, if in these discussions
> a better consensus pops up, I'll retag.
>
> I included parking lane width, as in some cases there are no lines on
> the ground indicating where the parking lane begins. We just have a
> traffic sign indicating that parking is allowed. As a result, the area
> available for traffic can vary when a very small car or very wide car is
> parked - the main reason we went with a curb-to-curb distance -
> including parking-lanes.
>
> The actual width available for traffic is then calculated based on OSM
> data. Can cars go in one or two directions? Can bicycles go in one or
> two directions? Are sidewalks present?
>
> I understand that 'width:carriageway' is confused with the room
> available for traffic. On the other hand, parked cars are a 'carriage'
> as well ;)
> Furhtermore, in my opinion, saving a 'width:traffic_area' directly into
> OSM is unnecessary (as an indicative value can be calculated from the
> other, more objective properties) and is even a bit subjective and prone
> to change (e.g. due parked cars). Did you know that the avarage car has
> gotten ~30cm wider since 1960? This means that the calculation of
> 'traffic_area' should be changed every few years.
>
> Also keep in mind that in the city center of Bruges, where we did those
> measurements, we don't have the 'half-on-curb' rules and have only a few
> perpendicular/diagonal parking lanes (which I conveniently ignored).
>
> Anyway, I'm not planning on getting too involved in this discussion (I
> have other things to do). However, Alex, I would propose to turn around
> your logic: not to map the traffic area, but to map 'width:carriageway'
> as 'curb-to-curb' distance, and mapping the 'parking:lane:left:width'
> and 'parking:lane:right:width'-values. If the parking lane doesn't have
> lines (and thus the width isn't well defined), software can choose a
> sensible default for the region. This would also work for
> 'half-on-kerb': if there is a line, one can use the line to determine
> the width. If not, software can use a sensible default.
>
> The drawback of this scheme is that software which wants to work with
> this data should be somewhat complicated right from the start.
>
> --
> Met vriendelijke groeten,
> Pieter Vander Vennet
>
> ___
> 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] highway=services on bicycle routes?

2020-09-28 Thread Volker Schmidt
Can I use highway=services for a service stop on bike routes? It typically
comprises restrooms, some kind of food service, bicycle repair
tools/service, often bicycle rental.
They go by different names. In Italy we have a number of "Bicigrill", a
term "borrowed" from a trade mark for motorway fast food ("Autogrill").
Examples
https://www.mapillary.com/map/im/f7z3DBQiS6FVyppXXQ97RL
https://www.mapillary.com/map/im/kJFqtrHTLfmgdePbfsbbiQ
https://www.mapillary.com/map/im/PU34nYunoIEvH3PnRuJgtQ
https://www.mapillary.com/map/im/5FU96KmV7_l8U-iHURV5uQ





Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] admin, please remove this user from the list

2020-09-23 Thread Volker Schmidt
Thanks, Marin for bringing this up. Same problem for me.


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Wed, 23 Sep 2020 at 10:54, Martin Koppenhoefer 
wrote:

> It's been some weeks now that I get this kind of reply for every message
> that I write to tagging. Can an admin please remove the address
> jim...@hey.com from the list recipients? Thank you.
>
>
> *haystack-mail-home-inbound-postfix-0.localdomain rejected your message to
> the following email addresses:*
>
> jim...@hey.com
> The address you sent your message to wasn't found at the destination
> domain. It might be misspelled or it might not exist. Try to fix the
> problem by doing one or more of the following:
>
>1. Send the message again, but before you do, delete and retype the
>address. If your email program automatically suggests an address to use,
>don't select it.
>2. Clear the recipient AutoComplete cache in your email program by
>following the steps in this article: Status code 5.1.1
>. Then resend the
>message, but before you do, be sure to delete and retype the address.
>3. Contact the recipient by some other means (by phone, for example)
>to confirm you're using the right address. Ask them if they've set up an
>email forwarding rule that could be forwarding your message to an incorrect
>address.
>
>
>
>
>
> *haystack-mail-home-inbound-postfix-0.localdomain gave this error:
> >: Recipient address rejected: User unknown
> *
>
>
> ___
> 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] Linking Sidewalks to Highways

2020-09-21 Thread Volker Schmidt
I think I mentioned this already in this context: in many countries you are
not allowed to cross roads everywhere you like. In Italy, for example, you
are by law required to use cross-walks, unless they are further than 200m
from your actual position.
I know that this is very theoretical, but it could give us an idea to a
practical solution for separately mapped foot and/or cycleways.
1) Map all foot/cycle crossings.
2) In addition map the occasional connecting driveway or side-roads to make
reasonable foot and cycle routing possible.

Another aspect is the mapping of unmarked pedestrian crossings near road
junctions, in those countries where by law pedestrians are allowed to cross
near road junctions even if there is no painted or signposted crossing
(implicit crosswalks).

Mapping of sidewalks/sidepaths as part of the main road has all kinds of
problems, like width and surface tagging, the relative position of foot and
cycle paths, not to talk about roads like this
, where any system
breaks down.

Volker




Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] "width" on streets: Time for a recommendation

2020-09-19 Thread Volker Schmidt
Some thoughts that trouble me...

To me it seems obvious that width values, independently on how they are
measured, are at best estimates, as measuring them is in most cases
dangerous or requires good technical equipment. I guess that most width
values in the database are reality estimates (I don't think that this is an
unjustified extrapolation from my own mapping - 99.9% of my width tagging
based on estimates). Estimates are relatively easy for narrow roads if you
have street-level photographs. They become much more unreliable for wider
roads. I solve this by using only lanes count for wider roads. Precise
width measurements are difficult to impossible, but fortunately they are
also less important than the lanes count for the end user.

The discussion about including/excluding sidepaths/sidewalks becomes also
irrelevant if we were only to use the lanes count as that counts only motor
traffic lanes.

Would also overcome another aspect of the width definition: If we use width
for the entire road, i.e motor-traffic lanes, shoulders, sidewalks, cycle
lanes/tracks/paths, tree rows between foot and cycleway, ... we do in the
end not know enough about the the actual widths of the different component
"lanes".

Width values are useful and easy to estimate from street-level photographs
for sidewalks, cycle paths/lanes/tracks, certainly to within 0.5m precision.

We need in any case a good system for regrouping parallel ways that belong
to the same street.
A relation seems to me the better option, but in any case, whatever
approach we pick now, we will face an nearly impossible amount of
retrofitting work. Anything we do on this from now will not make the
problem go away with the existing stock of data.

Volker









Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Fri, 18 Sep 2020 at 22:35, Tobias Knerr  wrote:

> On 17.09.20 02:35, Taskar Center wrote:
> > This is yet another example why "sticking" the sidewalks onto the
> > highway (as a tag) rather than mapping them as separate ways is
> > appearing to be less and less practical. Please see our sidewalk schema
> > proposal
> > 
> > from several years ago.
>
> Your sidewalk proposal unfortunately doesn't really address the crucial
> shortcoming of separately mapped sidewalks: The lack of a reliable
> mechanism for figuring out which section of road a given sidewalk way
> belongs to.
>
> I agree that we should be able to give sidewalks their own geometry, but
> we _also_ need the relationship between sidewalk and road. So far, all
> the proposals attempting to support the former end up sacrificing the
> latter.
>
> There have been some promising discussions recently around the
> sidepath_of idea, but that's still just brainstorming. Until a practical
> solution is found and actually used in the database, sidewalk mapping
> will remain a choice between two options that are broken in different ways.
>
> As for the main issue of the thread: I would welcome a clear definition
> for the meaning of width. In my own mapping and when writing the
> relevant code in OSM2World, I have counted sidewalks etc. as part of the
> road's width if they are mapped as tags on the main way. But I would of
> course change that if there finally was a documented and widely
> agreed-upon recommendation. I don't care so much which one it is - but
> we need one.
>
> ___
> 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] Addition of highway=emergency_bay and priority_road=yes to Map Features?

2020-09-17 Thread Volker Schmidt
On Wed, 16 Sep 2020 at 10:00, Martin Koppenhoefer 
wrote:

> emergency bays are quite common in Italy

Italy:
622 ways
2020 nodes
(not limited to motorways without emergency lanes - vedi esempio
)


> and Germany when there isn’t an emergency lane.
>


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] "width" on streets: Time for a recommendation

2020-09-15 Thread Volker Schmidt
On Tue, 15 Sep 2020 at 10:34, Tobias Zwick  wrote:

> I plan to soon implement a "What is the width of this road" quest in
> StreetComplete where the user can measure the width of the road using his
> or her smartphone (similar to the app Measure from Google [1]). The app
> will need to instruct the user very clearly what should be measured.
>

With the satellite photos that OSM can legally use, we usually have a
resolution problem. In most cases it will be tricky to get to a precision
better than one metre, which in my view is not enough.
Alternative: use est_width=  or width= plus source.width=estimated
Another problem are the contrast enhancement filters that most satellite
images are subject to. They oftenwiden the roads to some extent or create
an artificial limiting line, depending on the filtering algorithm.
In case there are Mapillary Mapillary photos you can, in many countries,
count the stripes of zebra crossings (in Italy they are 0.5m wide) to
measure the width of urban roads.



Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] sloped kerbs

2020-09-07 Thread Volker Schmidt
How do you tag sloped kerbs/curbs like these.

(I am referring to the zebra-striped sloped concrete borders of the traffic
islands)

barrier=kerb and kerb=sloped ?

The kerb  wiki page  shows
this picture 
without saying how it should be tagged.
Admittedly a different use, but mechanically similar.


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Rail segment in a bike route

2020-08-31 Thread Volker Schmidt
The double role issue, if it occurs, is there in either case, separate
relation or role in the bicycle route relation.

Regarding travel details of ferry/rail/bus sections within bicycle routes:
This information, if available, should go on the the ferry/rail/bus route
relations, as these means of transport are not exclusive to the bike route,
at least in most cases, and therefore should have their own relations
independently of bicycle travel.

In more general terms, this intermodal transport problem is a big black
hole in OSM in general. The commercial competition is spending a lot of
money in that sector. I am not sure we can or even want to compete with
that.




On Mon, 31 Aug 2020 at 09:53, Peter Elderson  wrote:

> Jo:
>
>> I added that it's not needed for ferries in the proposal on the wiki.
>> It's alright if we have more than 1 way to do it and leave it up to the
>> mapper to decide whether to map as a single route relation or split them
>> and use a superroute relation.
>>
>
> Wouldn't this apply to other transfer/transport sections as well?
>
>
>> If I start doing a bicycle tour, I want to know in advance if I'll be
>> able to cycle the whole stretch, or if there will be waiting time for other
>> means of transportation. I would also like to know if there will be a fee
>> to pay for these means of transportation and whether it's necessary to
>> hurry, in case there is only 1 per x hours, or they don't function at
>> night. By using separate route relations, it becomes possible to add
>> opening hours and a frequency/period on them.
>>
>
> Wouldn't this apply to ferries as well?
> _
>
>> 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] Rail segment in a bike route

2020-08-30 Thread Volker Schmidt
Keep it simple, if the simple solution does not limit you.

For the mixed transportation aspect of bicycle routes, I have the gut
feeling that separate relations for each segment are overkill.
At the practical level, if you take Eurovelo1 (relation 2763798
). I am interested
in the Northern Norway part of it, because I remember containing many
ferries.
If you drill down with Waymarked trails - Cycling (both the Relation
Analyzer and OSM Route Manager are not capable of dealing with it) you will
see that this is a super relation of 9 relations.
Let's take the Norway part "EuroVelo 1 - Atlantic Coast Route - part Norway"
- relation 9523683. 
This is again a super relation of 4 relations.
The interesting part in this is "EuroVelo 1 - Atlantic Coast Route - part
Norway 2" - relation 9523681

That stretch of 670km has four ferry transfers, which in the new proposal
would create another layer  of 9 child relations.

Or another example, closer to home for me:
to get across the islands that close the lagoon of Venice you need to cross
three "mouths" (bocche). On two of them you have even the choice between
different service providers, which each would need a different relation.

Please don't do it.

The "transportation" role in the bicycle route relations should be
sufficient to cover this aspect.







On Sun, 30 Aug 2020 at 20:16, Jo  wrote:

> I know that it's possible to look at the type of the child route relation,
> but I don't think it hurts to be explicit about it in the role.
>
> Regarding the 'complex' bicycle relations. I want to use superroutes for
> other purposes as well.
>
> Jo
>
> On Sun, Aug 30, 2020 at 7:53 PM Peter Elderson 
> wrote:
>
>> Route hierarchy is regular practice.The parent relation holds child
>> relations. This is the case for many types of route,
>>
>> As far as I can see, there are two new elements:
>>
>> 1. A child relation (route section) can be of a different route type.
>> 2. Provided it has a special role
>>
>> Since the type is in the child relation, you don't need to specify that
>> in the role.
>>
>> This is valid for many route types. I would suggest not to present it as
>> a complex bicycle route, but as a way to incorporate transfer sections of
>> different types in routes of any transport type.
>>
>> Best, Peter Elderson
>>
>>
>> Op zo 30 aug. 2020 om 17:52 schreef Jo :
>>
>>> Hi Francesco,
>>>
>>> I started a proposal on the wiki:
>>>
>>> https://wiki.openstreetmap.org/wiki/More_complex_cycle_routes
>>>
>>> It will probably need to be moved to the proposal name space, but we can
>>> work on it over there before putting it up for a vote.
>>>
>>> Jo
>>>
>>> On Sun, Aug 30, 2020 at 3:09 PM Francesco Ansanelli 
>>> wrote:
>>>
 I saw your changes... LGTM.
 Thanks!
 It would be great to have a page to document your proposal.
 Cheers
 Francesco

 Il dom 30 ago 2020, 12:03 Jo  ha scritto:

> Hi Francesco,
>
> I will create the superroute and route relations as an example. If you
> don't like the solution, feel free to remove those relations again
> afterwards. I will only fix a small error in the original relation, but
> keep it for now, so both solutions can be analysed next to each other.
>
> I don't really like the idea of a role 'transfer' on all those railway
> ways in a single route relation. In the case of your example, there is 
> only
> a single railway, but in theory there could be one for each direction of
> travel of the train. So if you want to describe that in the route 
> relation,
> you would need role forward/backward in the route relation, which cannot 
> be
> combined with role transfer.
>
> Jo
>
> On Sun, Aug 30, 2020 at 11:24 AM Francesco Ansanelli <
> franci...@gmail.com> wrote:
>
>> Dear Polyglot,
>>
>> it sounds good to me. But what roles do you suggest for such
>> superroute?
>> Many thanks
>> Francesco
>>
>> Il giorno dom 30 ago 2020 alle ore 11:00 Jo  ha
>> scritto:
>>
>>> How would you feel about mapping it with a superroute relation?
>>>
>>> The superroute would then contain 3 route relations.
>>>
>>> 1 for the first part by bicycle
>>> 1 for the middle part by train
>>> 1 for the last part by bicycle
>>>
>>> If we give the train part a different role in the superroute, we can
>>> make it such that the continuity line in JOSM is still drawn.
>>>
>>> This solution might also work to indicate that certain parts of a
>>> bicycle route need to be done on foot. Although creating separate route
>>> relations for such short stretches may feel like overkill.
>>>
>>> The other 'interruption' of a bicycle route I can think of, is where
>>> a ferry needs to be taken. In theory this 

Re: [Tagging] Confusion bicycle_road <> cyclestreet

2020-08-26 Thread Volker Schmidt
Yes, there is a legal difference

*bicycle_road*
A German "Fahrradstrasse" (which is the prototype on which this tag seems
to be modeled) is a road exclusively  for bicycles in the sense that
carries the the sign "Fahrradstrasse" without addition indicates that the
carriageway of the road is reserved for bicycles, pedestrians, people on
skayes, youn children on bicycles need to use the sidewalk (if available).
lso an implied speed limit of 30km/h applies.
In my opinion the "naked " German Fahrradstrasse is equivalent to
highway=service|residential
vehicle=no
foot=use_sidewalk  or sidewalk=separate if there is a separate sidewalk
bicycle=designated
maxspeed=30
So what do you "save" in tagging with bicycle_road=yes ?
As far as I can see it replaces "vehicle=no" and "bicycle=designated" with
"bicycle_road=yes"
(the speed limit is not part of the the bicycle_road tag nor is there any
indication about pedestrians)

*cyclestreet*
The prototype cycle street seems to be the Belgian "rue cyclable |
fietsstraat" that describes a road that is not wide enough for creating
separate cycle lanes or cycleways, hence the carriageway is shared between
cyclists and motor vehicles. Motor vehicles are not allowed to overtake
bicycles and there is an implicit speed limit of 30km/h

Such a road would be equivalent to
highway=service|residential
foot=use_sidewalk  or sidewalk=separate if there is a separate sidewalk
maxspeed=30
overtaking:motorcar=no (this tagging is not defined in the wiki)
What is the "saving" n using the cyclestreet=yes tagging?
None, as both maxspeed and overtaking restriction are not part of the OSM
tah cyclestreet=yes

Basically I see no need for separate tags like bicycle_road and
cyclestreet, as you can easily describe their properties with existing
tags. Add to this the confusion between the two tags, and then add to the
mix the myriad of variants on the subject in countries other than Germany
and Belgium, respectively.
These two tags should be discouraged.
As that most likely is not possible, maybe we can at least discourage their
"export" to other countries.



On Wed, 26 Aug 2020 at 08:51, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

> I am curious is there any difference in practical use of this two tags.
>
> Aug 25, 2020, 12:13 by vosc...@gmail.com:
>
> Hi,
> I have come across a new (to me) street sign In Italy:
> https://italy-cycling-guide.info/tips-advice/riding-in-italy/
> The road is a one-lane residential road on which bicycles and pedestrians
> can circulate.
> I don't know the legal status, however (I am inquiring).
>
> In that contest I have noticed that we have two wiki pages defining two
> tags, which seem to be describing nearly the same concept:
> bicycle_road 
> created 14:54, 7 August 2010
> 
> ‎
> cyclestreet
> 
> created 09:58, 9 May 2018
> ‎
>
>
> The main difference, as I understand it, is that the bicycle road is for
> bicycles only, unless there are additional signs, whereas
> on a cycle street "cars are also allowed. However, this car use is limited
> by the character and layout of the cyclestreet"
>
> To make the confusion perfect, both wiki pages use the same (German) road
> sign as illustration for the situation in Germany.
>
> https://wiki.openstreetmap.org/wiki/File:Zeichen_244_-_Beginn_der_Fahrradstra%C3%9Fe,_StVO_1997.svg
>
> Taginfo:
> bicycle_road=yes
>  7906
> cyclestreet=yes
>  4076
>
> Volker
> Padova, Italy
>
>
>
>
>
>
>
>
>
>
> ___
> 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] Confusion bicycle_road <> cyclestreet

2020-08-25 Thread Volker Schmidt
Hi,
I have come across a new (to me) street sign In Italy:
https://italy-cycling-guide.info/tips-advice/riding-in-italy/
The road is a one-lane residential road on which bicycles and pedestrians
can circulate.
I don't know the legal status, however (I am inquiring).

In that contest I have noticed that we have two wiki pages defining two
tags, which seem to be describing nearly the same concept:
bicycle_road 
created 14:54,
7 August 2010
‎

cyclestreet

created 09:58,
9 May 2018
‎


The main difference, as I understand it, is that the bicycle road is for
bicycles only, unless there are additional signs, whereas
on a cycle street "cars are also allowed. However, this car use is limited
by the character and layout of the cyclestreet"

To make the confusion perfect, both wiki pages use the same (German) road
sign as illustration for the situation in Germany.
https://wiki.openstreetmap.org/wiki/File:Zeichen_244_-_Beginn_der_Fahrradstra%C3%9Fe,_StVO_1997.svg

Taginfo:
bicycle_road=yes
 7906
cyclestreet=yes 
4076

Volker
Padova, Italy
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] ref on roundabout

2020-08-23 Thread Volker Schmidt
The route ref tag on a roundabout is the logical extension of the route ref
on any other road that is part of route with that ref number.
The arguments for putting the ref in the route relation and not on the ways
making up the route are valid along for roundabout that are part of route.
Trouble arises if both the route members and the route relation carry ref
tags and do not coincide.  A classical is a roundabout that connects
several routes. In that case the relation approach is clean, the "ref on
the members" approach is problematic.

On Sun, 23 Aug 2020, 18:54 Walker Bradley, 
wrote:

> In Afghanistan, there are continuous highways that have roundabouts as
> junctions.  The roundabouts, also have the same Ref because they are part
> of the continuous highway.  For an example check ref=NH0101 ref=NH0102
> ref=NH0103 or ref=NH0104
>
> On Aug 23, 2020, at 10:35, Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> wrote:
>
> 
>
>
>
> Aug 23, 2020, 15:23 by f...@zz.de:
>
> On Sat, Aug 22, 2020 at 01:28:07PM +0200, Mateusz Konieczny via Tagging
> wrote:
>
> Aug 22, 2020, 12:17 by f...@zz.de:
>
> > On Sat, Aug 22, 2020 at 12:09:14PM +0200, Mateusz Konieczny via Tagging
> wrote:
> >
> >> I would expect roundabout to be split in parts where
> >> ref is applying and parts where it is not applying, in other words
> >> without any special handling and tag it as usual.
> >>
> >
> > But the point is that on a roundabout the "name" references the name
> > of the _roundabout_ not one of the streets connected to it.
> >
> Yes
>
> > Same should apply to ref as it will reference the Roundabout
>
> why?
>
>
> 1. How do you tag a reference number for a roundabout when suddenly
> the ref contains a ref of one of the streets?
>
> Can you give example of roundabout with its reference number?
>
> For now it feels like a theorethical excercise.
>
> I never considered such case as I have never encountered or
> heard about junction with its ref.
>
> But there are named junctions, and I would look there for inspiration.
>
> 2. Inconsistency - Some informations on the roundabout contain
> informations about itself, and some are just copied over from
> attached streets.
>
> So it is about case where road has its own reference number
> and junction has its own reference number, separate from
> reference number of road routes?
>
>
> Yes - We should be consistent that an object carries informations about
> itself and ONLY itself and not carry on some information of related
> objects. To glue objects together or describe their relation
> we typically use relations. We do this in Germany a lot - So primary
> roads typically have relations carrying all road segments including
> the roundabout.
>
> In Poland road route continues through roaundabout and roaundabout way
> is part of such route.
>
>
> Correct - In Germany - at least for "Straßen NRW" thats the same. The
> road surface of the roundabout is part of the Road through it. But
> nevertheless - OSM has had a different Data Model to address/reference
> roundabouts itself to be able to do landmark routing e.g
>
> "Take 1st exit at the Hampstead Roundabout, then take the 2nd exit at
> the Foobar Roundabout".
>
> For this to work you have to put the information about the roundabout
> itself somewhere. This has been documented for ages to be the
> way carrying the junction=roundabout which has a name tag on its own.
>
> So using ref on the roundabout for either the road, or a reference
> of the roundabout breaks the assumptions that informations on the
> junction=roundabout only refer to the roundabout. With this concept
> it may sometimes refer to one or more roads which are connected to the
> roundabout. This basically makes the information useless.
>
> Flo
> --
> Florian Lohoff f...@zz.de
> UTF-8 Test: The  ran after a , but the  ran away
>
>
> ___
> 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] bridge:name and tunnel:name

2020-08-23 Thread Volker Schmidt
I guess that what we have is another case of two (in reality three) tagging
practices for (nearly) the same thing.
name=* for a tunnel's name that is mapped with tunnel=yes seems to be
common practice (at least 760 motorway tunnels in Italy are tagged this
way).
On the other hand we do have many tunnels, where the road in the tunnel
does have a name, and in those cases that the tunnel does have a different
name from the road we need a tagging scheme, which seems to be
tunnel:name=* if we want to use tunnel=yes on the road, or man_made=tunnel
with its own name tag, if the user prefers this tagging scheme.
We cannot mandate to retag existing tunnels and we need to have at least
one tagging scheme in case of two different names. So be it.
What I would not do is to state that tunnel:name is preferred. I would
point out that we have the two solutions sketched above in case of separate
names for road and tunnel.

On Sun, 23 Aug 2020 at 01:09, Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 22. Aug 2020, at 23:22, Arne Johannessen  wrote:
> >
> > That's not what I'm saying at all. In fact, I'm only applying *exactly*
> what's currently documented on the wiki's name=* page, which considers
> pragmatics instead of semantics.
> >
> > In other words, instead of focusing on the objective meaning of tags, it
> focuses on their meaning in context of real-world usage.
> >
> > In particular, as documented, name=* should contain the "common default
> name" of an element, whatever it may be. This means that for any particular
> element which e. g. has the two names Foo and Bar, but which is most
> commonly referred to by locals only as Bar, the Bar name should go into
> name=* and the Foo name into another appropriate name tag (alt_name=*,
> xyz:name=*, whatever fits).
>
>
> I would see it like this: if someone refers colloquially to a road in a
> tunnel, they will use the name of the tunnel because what they actually do
> is refer to the tunnel, not specifically the road in the tunnel. This does
> not have implications for our tagging such as you have proposed. It is not
> deductible from the „common default name“ definition, IMHO.
>
> 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] ref on roundabout

2020-08-22 Thread Volker Schmidt
That's the approach anyway for bicycle and bus route relations on
roundabouts.
Yes, it causes additional work, because you need to split the roundabout
way,
but I do not see a way to avoid that.

Volker


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Sat, 22 Aug 2020 at 19:14, Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 22. Aug 2020, at 12:11, Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> wrote:
> >
> > I would expect roundabout to be split in parts where
> > ref is applying and parts where it is not applying, in other words
> > without any special handling and tag it as usual.
>
>
> +1
>
> 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] Canopy Walkways

2020-08-22 Thread Volker Schmidt
What about
highway=footway
bridge=yes
layer=*
bridge:structure=canopy_walkway
?


<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
<#m_-1065115381681509086_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Thu, 20 Aug 2020 at 23:50, Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 20. Aug 2020, at 23:18, Volker Schmidt  wrote:
> >
> > What's wrong with "bridge" ?
>
>
> it’s ok, but not sufficient when you want to search them.
> Maybe something like leisure=canopy_walkway or tourism=canopy_walkway (in
> addition)?
> Or maybe footway=canopy_walkway? highway= Footway and bridge=yes seem
> essential for a basic description.
>
> Cheers Martin
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Canopy Walkways

2020-08-21 Thread Volker Schmidt
The footway= approach isn't so good. A canopy walkway is more a bridge type.

On Fri, 21 Aug 2020, 00:28 Graeme Fitzpatrick, 
wrote:

>
>
>
> On Fri, 21 Aug 2020 at 07:50, Martin Koppenhoefer 
> wrote:
>
>>
>> Or maybe footway=canopy_walkway? highway= Footway and bridge=yes seem
>> essential for a basic description.
>>
>
> The combination of the three of them seems like a good, simple solution!
>
> 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


Re: [Tagging] Canopy Walkways

2020-08-20 Thread Volker Schmidt
What's wrong with "bridge" ?


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Thu, 20 Aug 2020 at 19:03, Jake Edmonds via Tagging <
tagging@openstreetmap.org> wrote:

> I can’t find any references to canopy walkways in the wiki or on Taginfo.
>
> https://en.wikipedia.org/wiki/Canopy_walkway
> https://commons.wikimedia.org/wiki/Category:Canopy_walkways
>
> Currently, many are tagged as bridge=yes or highway=footway.
> https://www.openstreetmap.org/way/352398702
> https://www.openstreetmap.org/way/121881927
> https://www.openstreetmap.org/way/418596115
>
> The wiki entry for bridge=boardwalk suggests it is used for structures
> close to the ground.
>
> Any thoughts?
> ___
> 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 -Funeral hall

2020-08-19 Thread Volker Schmidt
With respect to the proposed key, I would invite you to consider an
alternative way of tagging this function.
In various countries and in various religions the approaches on how to say
good-bye to the dead are different.
I am thinking of the "camera ardente" in Italy or the "Aufbahrung" in
Germany, these are ways of providing this in different contexts. What about
a tag that can be added to any kind of place, a funeral director's or a
chapel or the town hall, indicating that this kind of farewell can be
arranged.
I do not have the correct wording in GB English right now ("laying out"?),
but the concept would be not to create a tag that implies a dedicated
building, but to create a tag for the function that can be added to a
building or a "shop".
https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Wed, 19 Aug 2020 at 17:59, Joseph Eisenberg 
wrote:

> In the US, there are privately owned cemeteries, often with a private
> funeral home / mortuary building on the site. You can buy a plot and also
> pay for the funeral services, including the use of a hall for a viewing,
> reception or funeral service (religious or otherwise).
>
>  E.g.:
> https://www.dignitymemorial.com/funeral-homes/glendale-az/west-resthaven-funeral-home/4707
> - a funeral home and private cemetery.
>
> In many American cities most of the cemeteries, crematoriums and
> mausoleums are privately owned and operated.
>
> So my question is if we should add this new tag to the reception / service
> halls which are found at at private funeral homes / mortuaries as well?
> Often these are in the same building as the crematorium and the morgue
> (where bodies are prepared and stored prior to burial or cremation), and
> the offices and reception for the funeral home are also there.
>
> Or are we only thinking to use this new tag for stand-alone halls?
>
> It would also be good to clarify how these are different than a
> place_of_worship. For example, consider the many non-sectarian chapels and
> prayer rooms found in airports, shopping centres, hospitals, and similar
> public facilities. Aren't those tagged as amenity=place_of_worship - or is
> that also a mistake?
>
> - Joseph Eisenberg
>
> On Wed, Aug 19, 2020 at 7:13 AM  wrote:
>
>> Not important at all. I just think that if it is ancillary to the
>> business of selling coffins, transporting corpses, preparing them for
>> burial, doing paperwork in relation to that etc. (what the French call a
>> "funérarium"), then it doesn't deserve a tag distinct from the funeral
>> directors tag (but if a majority think otherwise, I don't have strong
>> feelings about it either).
>>
>> Am 19.08.2020 15:47 schrieb Martin Koppenhoefer:
>> > sent from a phone
>> >
>> >>> On 19. Aug 2020, at 15:33, woll...@posteo.de wrote:
>> >> I could imagine rare cases of a privately run cemetery not linked to
>> >> any religion or belief/life stance and where there is such a building.
>> >> But typically, they would be public.
>> >
>> >
>> > let me rephrase my question: how important is it that the facility is
>> > “public”?
>> > IMHO this feature should have a functional definition only, everything
>> > else depends on the context and is not really relevant.
>> >
>> > 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
>>
> ___
> 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] new page for tree_lined=*

2020-08-14 Thread Volker Schmidt
I love tree-lined roads in the country side or in city settings.
I would love a router that I could instruct to find them for me.
For travelling by car and by bicycle.
In past periods trees were part of the road.
I like the idea of easily adding this feature to the map.
But I also fear the maintenance requirements and hence quality issues this
may generate.

I do see these issues with adding sidewalks and cycle paths, where we have
a similar choice between mapping as separate objects or as road property.

Map maintenance is mostly limited by available manpower. A leisurely 30km
bike ride with Mapillary images produces "data"  for one week of JOSM
sessions to convert the collected information in map data.

Thanks for having read so far. I have no solution, but would suggest to
create a single wiki page for tree-lined road mapping, so that we have one
place where we describe the three different approaches for mapping them.

And maybe we invent a work flow to extract those lovely tree-lined country
roads from Mapillary's semantic AI efforts.

When I was a boy I learned from my father, who loved travelling by car,
that his secret was to follow those roads that had the green side bar on
the Michelin 1:20 classic maps, which in my area often were roads built
by Napoleon, and he always planted trees along the roads (not for cyclists,
but for his troops).





On Sat, 15 Aug 2020, 00:26 Christian Müller via Tagging, <
tagging@openstreetmap.org> wrote:

> > On Fri, 14 Aug 2020 at 14:33, Paul Allen via Tagging <
> tagging@openstreetmap.org[mailto:tagging@openstreetmap.org]> wrote:
>
> > Is there a serious need (other than, say, one person's dissertation) to
> perform
> > database queries to find objects that are tree-lined?  I can see the
> need to
> > find the nearest car park with disabled spaces, or vehicle charging
> points, but
> > not for trees lining it.  That's probably just me, but trees lining a
> car park do
> > not influence my choice of whether or not to use it.
>
>
> It may be important to the crazy people that still use their bicycle
> in an otherwise air-conditioned, motorized world.  "Back in the days"
> people with a less strange relation to mother nature knew that a tree
> lined way has much more comfort cycling on if these trees spend shadow
> on a sunny day.  If you do long-distance cycling it may be of interest
> to find a route not predominantly exposed to sheer sun.
>
> /rants on/
> Unfortunately, most people do not seem to care.  Driving a car is
> "god given" and if you say anything people go crazy.  If you don't
> own something that makes noise and pollutes the environment, di-
> rectly by fumes or indirectly by production (the electro hype),
> you're deemed impotent or low-performing.  And anti-mobbing
> courses are beyond the scope of OSM. :.p
> /rants off/
>
>
> Greetings
>
>
> ___
> 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] new page for tree_lined=*

2020-08-14 Thread Volker Schmidt
On Fri, 14 Aug 2020, 13:41 Mateusz Konieczny via Tagging, <
tagging@openstreetmap.org> wrote:

> I feel that tree_lined=separate should be used if trees are separately
> mapped
>

This would make it worse because you would have to add this to all objects
with tree lines already tagged with individual trees or tree lines.

Apart from that I would not advocate "overlapping" mapping with three
different schemes: individual trees a separate nodes, tree lines as
separate ways, and the new proposal.
On any given object there should never bee tree rows mapped in different
ways.


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


Re: [Tagging] RFC: service=? for all highway=service (service=parking needed, primarily, I think)

2020-08-04 Thread Volker Schmidt
On Tue, 4 Aug 2020 at 16:27, David Dean  wrote:

The main problem with this is the retrofitting of the missing service=* tags
Unless we start a mega campaign to add service=* to all highway=service, we
will have to live with the actual situation for ever.
Some roads are "service" only and other roads are special "service" roads.
OSM is full of other examples of this tagging scheme. Adding afterwards
more specific tagging does not help at all, it only adds additional work fr
routers and renderers.
If we had started out with a clean scheme, yes, it would have been useful,
but now it is completely useless.

>
> # Parking Access
>
> There are already 2K examples of service=parking in use around the world (
> https://taginfo.openstreetmap.org/tags/service=parking), and while I
> can't claim to have done an exhaustive study, it appears that it is used
> for the purpose of the main driveways through a parking lot.
>

This is peanuts in comparison with the number of "naked" service roads that
connect parking lots.
Just to give you an idea:
Only in the city of Berlin, Germany, there are more than 8k parking lots
(and each should have a service=parking entry road) and there are 25k
"naked" service  roads.

Volker


Virus-free.
www.avast.com

<#m_-5835600118117805121_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] kerb=regular vs. raised

2020-08-01 Thread Volker Schmidt
Please revert this wiki change.
The kerb hight values have been used in at least one project documenting
wheelchair accessibility.

On Sat, 1 Aug 2020, 08:53 Supaplex,  wrote:

> As an result of this diskussion (no strong opposition, some general
> remarks, some endorsement) I added "kerb=regular" to the tagging example
> list in the wiki and adjusted hight descriptions (with values discussed
> here). If there is further need for discussion and changes, it could be
> carried out in the wiki: https://wiki.openstreetmap.org/wiki/Key:kerb
>
> Greets, Alex
>
>
> Am 29.07.20 um 20:56 schrieb Supaplex:
>
> Hey all,
>
> I started mapping detailed sidewalk information in my area, including
> crossing and kerb information. It seems that there is a lack of clarity
> in the differentiation between raised and regular ("normal", neither
> lowered nor raised) kerbs. "kerb=regular" is already in use but is
> undocumented and should be explicitly distinguished from "kerb=raised".
> There is a relevant difference not only for wheelchair users, but also
> for other mobility groups (cargo bikes, strollers, pedestrians with
> reduced mobility…).
>
> So I propose adding "kerb=regular" to the tagging list in the wiki as
> well as suitable descriptions for height, use… and an example image. I
> made a suggestion in the wiki (since there has been no reaction so far I
> post it 
> here):https://wiki.openstreetmap.org/wiki/Talk:Key:kerb#kerb.3Dregular_vs._raised_--_add_.22regular.22_example
>
> Is there a reason not to add this? Otherwise I’ll do that.
>
> Greets, Alex
>
>
>
>
> ___
> 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] kerb=regular vs. raised

2020-07-29 Thread Volker Schmidt
Problem: what is "regular" ?
(and hence: what is "raised" and "lowered" ?)

See for example:
https://www.quora.com/What-is-the-standard-curb-height-in-the-United-States-and-how-is-that-height-decided-on



On Wed, 29 Jul 2020 at 20:58, Supaplex  wrote:

> Hey all,
>
> I started mapping detailed sidewalk information in my area, including
> crossing and kerb information. It seems that there is a lack of clarity in
> the differentiation between raised and regular ("normal", neither lowered
> nor raised) kerbs. "kerb=regular" is already in use but is undocumented and
> should be explicitly distinguished from "kerb=raised". There is a relevant
> difference not only for wheelchair users, but also for other mobility
> groups (cargo bikes, strollers, pedestrians with reduced mobility…).
>
> So I propose adding "kerb=regular" to the tagging list in the wiki as well
> as suitable descriptions for height, use… and an example image. I made a
> suggestion in the wiki (since there has been no reaction so far I post it
> here):
> https://wiki.openstreetmap.org/wiki/Talk:Key:kerb#kerb.3Dregular_vs._raised_--_add_.22regular.22_example
>
> Is there a reason not to add this? Otherwise I’ll do that.
>
> Greets, Alex
> ___
> 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=customer_service RFC

2020-07-23 Thread Volker Schmidt
Careful with "access".
access=customers on an office building would imply you can drive into this
building with any means of transport, provided you are a customer.

On Thu, 23 Jul 2020 at 15:46, bkil  wrote:

> On Thu, Jul 23, 2020 at 3:39 PM Volker Schmidt  wrote:
>
>> So it would have to be customer_service=yes|no at least.
>> That would also permit to check which offices have been evaluated by
>> mappers for the presence or less of customer_service.
>>
>>
> access=customers/private would also solve this without having to invent a
> new top level 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


Re: [Tagging] Hiking "guideposts" painted on rocks, trees etc.

2020-07-23 Thread Volker Schmidt
... and if the fingers are nailed on a shed, a common practice in the
mountains around here?
No post? Or the building is the post?


On Thu, 23 Jul 2020 at 14:07, Paul Allen  wrote:

> On Thu, 23 Jul 2020 at 02:03, Warin <61sundow...@gmail.com> wrote:
>
>>
>> No. The material the guidepost is made from is of lesser importance to
>> the fact that it is a 'guidepost'.
>>
>
> That is one viewpoint.  It is something indicating the path of a route.
> Collect them all under one tag because they all specify that kind
> of information, no matter what they look like.  It makes overpass
> queries easier, etc.  That's why trail blazes are
> information=trail_blaze and not guidepost.  Ooops!
>
> Another viewpoint is that these things LOOK different even though they
> may convey the same information.  As waypoints, if you're looking for
> a signpost you may discount what looks like graffiti on a distant rock.
>
> These are signposts.  They are signs.  On posts.
> https://www.geograph.org.uk/photo/5901641
> https://www.geograph.org.uk/photo/4006975
> https://www.geograph.org.uk/photo/6191138
> https://www.geograph.org.uk/photo/6324438
> https://www.geograph.org.uk/photo/3507964
>
> What you are describing is not a signpost.  It's more of a blaze
> with text.  If I were insistent upon ramming a square peg into
> a round hole, I'd abuse trail_blaze rather than guidepost.
> Because THERE IS NO POST.
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] amenity=customer_service RFC

2020-07-23 Thread Volker Schmidt
You are trying to address a reaIly (numerically) big problem.
I would have thought anything with office=* may need an indication of the
presence or less of customer service.
Most likely anything that is shop=* would implicitly offer customer service.
So for the 700k office=* we need to retrofit an indication, whether they
offer or not customer service.
As I said above, this looks to me like a gigantic task to start with, but I
also see a problem with the proposed tag:
If an office offers customer service I add amenity=customer_service, but
how do I indicate that they don't?
So it would have to be customer_service=yes|no at least.
That would also permit to check which offices have been evaluated by
mappers for the presence or less of customer_service.



On Thu, 23 Jul 2020 at 15:10, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

> Yes, and in such cases shop should be used.
>
> But in some cases where office=* is used
> there is no known to me tagging scheme
> covering this, such as car of energy
> company customer service location.
>
> It is place where you may handle overdue
> bill payment plans or attaching new property
> to power network or dispute bill.
>
> Is there shop tag for that?
> At least in my region people always tag
> it work office, and it seems to not be
> really fitting for shop key.
>
>
> 23 Jul 2020, 14:06 by si...@poole.ch:
>
> Wouldn't most, if not all, cases where this would be used already be
> covered by the corresponding (and likely already in use) shop=* value?
> Am 23.07.2020 um 12:49 schrieb Mateusz Konieczny via Tagging:
>
> See https://wiki.openstreetmap.org/wiki/Proposed_features/Customer_service
>
> Feedback, complaints, edits to the page (especially concerning grammar,
> typos and clarity)
> are highly welcomed
>
> ___
> 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] Is there a good way to indicate "pushing bicycle not allowed here"?

2020-07-22 Thread Volker Schmidt
On Wed, 22 Jul 2020 at 22:51, bkil  wrote:

> Although I think we've given enough evidence and _some_ of your quotes
> make sense, let me add another consideration.
>
> This is where bicycle=dismount could be used (although it is the default
> on highway=footway):
> https://commons.wikimedia.org/wiki/File:Opastemerkki.jpg
>
Highway=footway implies foot=designated which in turn implies the sign you
show. The default for this is bicycle=no. (in the sense of dismount) in OSM.

>
> bicycle=no is usually used on busy motorways where dismounting isn't
> feasible:
> https://commons.wikimedia.org/wiki/File:Nederlands_verkeersbord_C14.svg
>
On Italian motorways pedestrians and cyclists are forbidden. The default
OSM tags are foot=no and bicycle=no (the foot=no excludes the possibility
to walk your bike on motorways - so there is no problem there)

> Am I understanding correctly that this is what the wilderness rules would
> like to achieve?
> vehicle=no + scooter=prohibited + bicycle=prohibited + moped=prohibited +
> unicycle=prohibited + hand_cart=prohibited + wheeled_luggage=prohibited
>
correct

>
> I think if we concentrated on this case, it would be better to invent a
> specific access value to convey that they don't want to see you be in
> possession of anything that could leave a track in normal use
> (access=legged). When you go out with something like this in the wild, they
> could rightly infer that you would want to ride it when the park rangers
> are not looking. Not sure about the extent of such restriction, but it
> might also make sense to put it onto the natural area instead of each and
> every individual path of it.
>
Apart from the wilderness case we have at least two examples where walked
bicycles are explicitly forbidden, but other wheeled means of human
transport are not, like wheelchairs and baby buggies: the historic part of
Venice and Nymphenburg Schlosspark in Germany. And I am sure there are more
like this.
One thing which springs in mind are many underground systems (with one
notable exception that I know of: Helsinki)

So the problem does not go away. We need a generic no-bicycles-allowed-here
type of tag
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Hiking "guideposts" painted on rocks, trees etc.

2020-07-22 Thread Volker Schmidt
Guidebooks in a hiking/cycling route should be fine, provided they carry
the role=guidepost tag.

On Wed, 22 Jul 2020, 17:20 Andy Townsend,  wrote:

> On 22/07/2020 16:08, pangoSE wrote:
> >
> > I suggest you add the guidepost to a node on the path instead.
> >
> Please don't do this.  If there's a gate on one side of the road you
> wouldn't add that gate to the road itself, would you?
>
>
> > I really think it would be nice to be able to say query and list all
> > hotels, wilderness huts and shelters within 200 m of the Kungsleden
> > trail (Swedens most famous trail) but I don't think adding them to
> > relations is the way forward. Maybe this can already be done with
> > overpass.
>
> What Overpass certainly can't do is tell you "which guideposts are for
> which trail" if that information isn't recorded anywhere.
>
>
> Best Regards,
>
> Andy
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?

2020-07-22 Thread Volker Schmidt
It's not the routers' fault. They correctly reflect the mappers'
intentions. In almost all cases when we map bicycle=no it means, according
to the law, you can pass if you walk your bicycle, because you are
considered a pedestrian. We simply missed to realise that we overlooked the
rare cases where you are not allowed to walk your bicycle.
>From time to time, we discuss this issue, but have so far not come up with
a solution.

On Wed, 22 Jul 2020, 16:54 Tod Fitch,  wrote:

> This thread has been quite amazing to me. My impression is that it starts
> with some routers (a.k.a data consumers, a.k.a. “renderers”) treating a
> “no” as a “maybe” and now people are looking for a new term to indicate
> that “we really, really, mean NO!”. This is worse than tagging for the
> render, it is obsoleting a straight forward and explicit tag value for a
> broken renderer.
>
> Discussion devolves into “if I disassemble by bicycle and put into wheeled
> luggage is it okay now?”.
>
> Why not treat “no” as no? If I can push the bicycle through then we
> already have “dismount”.
>
> Is there some other way of getting a bicycle through? If so, then come up
> with a new value for that (“disassembled”?).
>
> In the meantime, file bug reports against any router that routes a bicycle
> over a “no”.
>
> At least where I am, “no really means no” and if you are caught with a
> bicycle at all then you are subject to a fine. Thousands of kilometers of
> paths are so marked and it really wouldn’t be nice to redefine an existing
> value.
>
> Cheers!
> Tod
>
> On Jul 22, 2020, at 7:34 AM, Allroads  wrote:
>
>
> https://images.mapillary.com/yQWkL-XX5eRN5A2j0JkKIA/thumb-2048.jpg
> Geen toegang:
> - met (brom)fietsen.
> No access:
> - with bicycles.
> This is written, grammatically and  orthographly, in a way, that the
> "vehicle" is meant.
> explicit the bicycle no access.
>
> This is privat land, Staatsbosbeheer, owned or in control, all over the
> Netherlands, you see these type of signs, arranged in the same way, the
> layout.
> Mostly all of these roads/tracks path are permissive
>
>
> https://commons.wikimedia.org/wiki/File:Waterloopbos._Natuurgebied_van_Natuurmonumenten._Informatiebord.jpg
> - Fietsers op verharde fietspaden en wegen
> -Bicyclist on paved cycleway and roads.
> Here is written what is allowed.
> But more important:
> Overigens verboden toegang Artikel 461 W.v.S.
> Others prohibited access, article 461 Code criminal law.
> The word  “Overigens” means:  all the other which is not mentioned above
> on the sign
> Not pushing a bicycle on a unpaved cyclway, path, tracks. So others then
> “wegen” roads.
>
> A active Openmapstreet member got  a ticket for pushing his bike on a not
> allowed “wegen” by a certified ranger (BOA) Community service officer.
>
> This sign with “Overigens”  of  the private organisation Natuurmonumenten,
> you find them all over the Netherlands, with the same layout.
>
>
>
> ‘'
>
>> bicycle=explicit_no sounds to me like "there is an explicit sign
>> forbidding this",
>>
>
> Indeed.
>
>
>> not "bicycle vehicle itself is prohibited, not just cycling".
>>
>
> That sounds like bicycle=prohibited. :)
>
> ‘'
>
> Text on sign: “Overigens” and “- met fietsen”  "bicycle vehicle itself is
> prohibited”
>
> I need a value .*=explicit_no for “the vehicle” or some other value that
> means the same. “the bicycle is not allowed”
>
> This is for all kind of transportation and vehicles. Pushing carry/not
> allowed.
>
>
>
>
>
>
> It seems highly strange that you wouldn't even be allowed to carry/push
> your bike, are you sure that was what it meant?
> Do you have a picture of the sign?
>
> ___
> 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] Is there a good way to indicate "pushing bicycle not allowed here"?

2020-07-22 Thread Volker Schmidt
The boxes business is most likely leading us a bit up the Nymphenburg
Schlosspark garden path.
The real issue is routing for bicycles.
Many (bicycle) routers I know would route you against (short) stretches of
one-way roads or on short stretches of (bicycle=no) footpaths, so in those
cases it is important to be sure that you distinguish between hard-no and
soft-no for bicycles.
I have come across another type of hard-no for bicycles in the form of
chicane-type cycle barriers too narrow to push a bicycle (or a wheelchair)
through.

On Wed, 22 Jul 2020 at 11:48, bkil  wrote:

> I have yet to see a park where they limit the size of luggage I can carry
> with me (within rational limits).
>
> I think local law always defines what a bicycle is exactly. I don't think
> that they have the right to search your box to check whether it contains
> legally defined bicycles - that could only be done by a police officer and
> would need a warrant, so I think we can always carry bicycles in a box.
> Mind you that luggage could also have wheels.
>
> For circumventing carry-on rules, it was common knowledge that if you
> removed the front tire, it could not be ridden anymore and could be
> understood to be not a bicycle, rather it was classified as "bicycle
> parts". Some thought this could be used to transport bicycles on a train
> for free, but it was actually oversized for the definition of luggage, so
> the actual deciding factor was always the kindness of the staff.
>
> If you carry a front wheel and your friend carries the rest, can you enter
> the park? Both of you are only carrying parts, and none of you
> possess bicycles.
>
> On the other hand, the terms of services of transport companies usually
> have written provisions for carrying on folded bicycles irrespective of
> size limits (for example, they even allow folded mountain bikes).
>
> Just for kicks:
>
> https://ecofriend.com/bike-that-folds-into-an-a3-paper-size-box-is-rightly-named-the-a3-bicycle.html
>
> On Wed, Jul 22, 2020 at 11:30 AM Martin Koppenhoefer <
> dieterdre...@gmail.com> wrote:
>
>>
>>
>> sent from a phone
>>
>> On 22. Jul 2020, at 11:07, Mateusz Konieczny via Tagging <
>> tagging@openstreetmap.org> wrote:
>>
>> bicycle_pushed=no was suggested in previous discussion, see
>>
>> https://lists.openstreetmap.org/pipermail/tagging/2019-November/thread.html#49056
>>
>>
>>
>> and then you would also need
>> bicycle_carried=no
>> and
>> bicycle_carried_in_a_box=no
>> (the latter is rare and could be seen as another way of saying
>> carrying_boxes=no or maybe carrying_boxes:conditional =no@(any_dimension
>> > 0.3m)
>>
>> And we would have to define what „bicycle“ means.
>>
>> Are these bicycles?
>> 1.
>> https://www.picclickimg.com/00/s/ODAwWDgwMA==/z/F-8AAOSwstJZXeV2/$_12.JPG
>>
>> 2.
>> http://img0.biker-boarder.de/detail_oxp1/g13_edge_raw.jpg
>>
>> 3.
>> http://www.unicyclist.com/filedata/fetch?id=2476281
>>
>> 4.
>>
>> https://photos.netjuggler.net/monocycle-kris-holm-24p/grande/Monocycle-Kris-Holm-24-pouces-isis1.jpg
>>
>> etc.
>>
>> 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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?

2020-07-22 Thread Volker Schmidt
Apart from the island parts of Venice, there is this "famous" example,
cited everytime the argument comes up: Bicycles, even walke, are not
allowed in the Schlosspark Nympenburg (see leaflet):

"Das Mitführen von Fahrrädern ist im ganzen Park nicht gestattet. Nutzen
Sie bitte das Angebot an Fahrradständern an den Eingängen."
It appears that we still have no commonly agreed tag in OSM to indicate
that type of restriction. OSM's "bicycle=no" is used to mean "riding of
bicycle is forbidden" or  "you cannot bring a bicycle here".
I agree we need a tag for a "hard" no-bicycle tag.
In theory we do have the bicycle=dismount tag for not-riding a bicycle,
but, unfortunately we do have too many existing uses bicycle=no in the
database that in reality should be bicycle=dismount
(Taginfo:
1?078?526 bicycle=no
79528 bicycle=dismount)
I do not like "explicit-no", but I do not have any alternative suggestion
either. bicycle=hard-no ? bicycle=prohibited ?

I guess there is a similar problem with dogs: there are places where you
cannot bring a dog, and there are places where you can not walk your dog,
but you may carry it.




On Wed, 22 Jul 2020 at 10:32, Oliver Simmons  wrote:

> It seems highly strange that you wouldn't even be allowed to carry/push
> your bike, are you sure that was what it meant?
> Do you have a picture of the sign?
>
> On Tue, 21 Jul 2020, 22:50 Allroads,  wrote:
>
>> There lots of forest roads/path, where the bicycle/pushed carried is
>> prohibited. Mostly, private owned land with a access_sign.
>> “the bicycle” “transportation vehicle” is prohibited.
>>
>> Because, navigation programs do not us bicycle=no, as a hard no, there is
>> the need for a extra value.
>> bicycle=explicit_no, means “the vehicle” is prohibited.
>>
>> Why a value?
>> We need a one value, otherwise a lot of more keys, which makes it things
>> complicated. At the end it means for all explicit no!
>> bicycle_pushed=no
>> motorcycle_pushed=no
>> horse_pushed=no ;-)
>> moped_pushed=no
>> mofa_pushed=no
>> etc.
>>
>> Better one value, key=explicit_no
>>
>> What do you think?
>>
>> If we do not solve this problem, this stays forever.
>>
>> On the wiki page dismount, this bicycle_pushed is mentioned.
>> https://wiki.openstreetmap.org/wiki/Tag:bicycle%3Ddismount
>> For me a wrong advise.
>> The problem is wider for more transportation modes, even for other
>> product to carry around.
>>
>> Private access_sign rules, can go much further then traffic_sign. In what
>> is prohibited.
>> What the owner think and write down on the sign is valid.
>> The skateboard is prohibited, means you can not carry a skateboard around
>> with you.
>> skateboard=explicit_no
>>
>> I need this value to do it correctly. Where the bicycle is no allowed. Or
>> a other value meaning the same.
>>
>> ___
>> 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] Farmlands subject to rotation of crops

2020-07-22 Thread Volker Schmidt
This is a rather tricky problem, especially as the changes may not follow
any particular pattern.
I am not a crop mapper at all, but I can distinguish between the major
local crops (in Italy). And in many cases the mapping in OSM is wrong,
mostly because the data is fruit of imports which were too specific.
One effect which is noticeable around here is not rotation, but that the
crops tend to follow patterns like market prices, or subsidies by the EU.
There are exceptions, like corn (mais) which normally does not change. So
my experience with precise crop mapping is that very often it is simply
wrong.
There are obvious exceptions, like orchard (fruit, olives), and vineyards.
But most annually sown crops may change easily, and the average OSM mapper
does not update crops. I would go with farmland, orchard, vineyard and not
even consider indicating any rotation of crops.

That does not exclude making a special effort in certain areas, provided
you have the trained mappers.

On Tue, 21 Jul 2020 at 17:13, Michael Montani 
wrote:

> Dear all,
>
> I wanted to check with you which is the best way to map farmlands subject
> to rotation of crops. An example could be of a farmland used for general
> crop in one part of the year and left it at rest for the remaining part of
> the year, being actually used as a meadow for animals grazing there.
>
> Which would be the best way to tag such area?
>
> Thanks,
>
> --
> *Michael Montani*
> GIS Consultant, *Client Solutions Delivery Section*
> *Service for Geospatial Information and Telecommunications Technologies*
> United Nations Global Service Centre
> United Nations Department of Operational Support
>
> Brindisi | Phone: +39 0831 056985 | Mobile: +39 3297193455 | Intermission:
> 158 6985
> E-mail: michael.mont...@un.org  | www.ungsc.org
> ___
> 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] Riverbanks

2020-07-21 Thread Volker Schmidt
Please let us not forget that the wiki is supposed to document what is used
in OSM. In this case it should say that two schemes exist, and, if we have
good numbers for the relative use, we can add that.
Putting an advice to prefer one or the other is not within the scope of the
wiki in such a situation

On Tue, 21 Jul 2020 at 14:17, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
>
>
> Jul 21, 2020, 12:13 by em...@daniel-korn.de:
>
> Am 21.07.2020 um 10:55 schrieb Tomas Straupis:
>
> 2020-07-21, an, 11:20 dktue rašė:
>
> Why do we need both variants and why don't we just say that
> waterway=riverbank is preferred?
>
> There is an original OpenStreetMap water schema with lakes as
> natural=water, reservoirs as landuse=reservoir, riverbanks as
> waterway=riverbank etc. It is a perfectly working schema.
>
> At some point there was a new schema proposed with a totally nerdy
> motivation "to make some sql's simpler". That new schema has no
> advantage in cartography, GIS or IT sense. It is totally NERDY. This
> nerdy scheme was ignored in the beginning but then came the iD which
> took a totally non-analytical and authoritarian attitude and not only
> chose to support nerdy water schema, but even decided to support ONLY
> it. And in recent year iD coders went even further and started lying
> to its users that original OpenStreetMap water schema is "deprecated'
> even when it never was.
>
> So this is the reason why we have two schemas. It is very
> unfortunate that there is no way to prohibit such nonsense nerdy
> schemas into OpenStreetMap :-(
>
> So why can't the wiki state: "If you tag, then please do so using
> waterway=riverbank" (as this is preferred by the *community*)?
>
> Because despite claims mentioned above - there are also people preferring
> the second schema,
> it is not case of "iD developers vs community" like it is/was with some
> case.
> ___
> 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] Waterway equivalent of noexit=yes?

2020-07-20 Thread Volker Schmidt
Manhole=drain has more than 2000 uses, most of them seem to be water
drainage grids with no access for humans.
But if you want to retag them with something different you would need to do
this manually.
I would not touch it, even if it is an unfortunate tagging.

On Mon, 20 Jul 2020 at 21:33, Alan Mackie  wrote:

>
>
> On Mon, 20 Jul 2020 at 11:28, Paul Allen  wrote:
>
>> On Mon, 20 Jul 2020 at 10:59, Volker Schmidt  wrote:
>>
>>> manhole=drain is widely used in OSM for water drainage grids, that are
>>> not suitable for people to entr - se the photo on the wikipage
>>> <https://wiki.openstreetmap.org/wiki/Tag:manhole%3Ddrain>
>>>
>>
>> People have used manhole=drain for that purpose and the wikipage
>> for manhole=drain documents that use.  However, that photo appears
>> to be of a UK storm drain which is not a manhole by my definition
>> (too small for entry by a person) or by the wiki's definition for
>> Key:manhole which states "Hole with a cover that allows access to
>> an underground service location, just large enough for a human to climb
>> through."
>>
>> In my opinion we should deprecate manhole=drain except where
>> it really is large enough for access by a person.  We need a
>> better tag.  Well, two tags.  One for storm drains and one
>> for sinks that are too small to merit natural=sinkhole with
>> any of the current sinkhole=* types.  Oh, and a tag for
>> spreads, too.
>>
>> --
>> Paul
>>
>
> I think we also need one for "entrances" to pipes/tunnels of unknown
> extent where the entrance is by horizontal movement of the water rather
> than by falling into a hole. The presence/absence of gratings or mesh may
> be useful for these too.
>
>
>
> ___
> 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] Waterway equivalent of noexit=yes?

2020-07-20 Thread Volker Schmidt
manhole=drain is widely used in OSM for water drainage grids, that are not
suitable for people to entr - se the photo on the wikipage



On Sun, 19 Jul 2020, 22:55 Martin Koppenhoefer, 
wrote:

>
>
> sent from a phone
>
> > On 18. Jul 2020, at 20:42, Alan Mackie  wrote:
> >
> > The closest I can find on the wiki is manhole=drain?
>
>
> but this is for manholes, not suitable for small grates where a person can
> not enter.
>
> 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 - (Ground)

2020-07-16 Thread Volker Schmidt
My idea was only trying to avoid to invent tag values for OSM without
consulting what other, technically more competent bodies, have done before.
Looks as the FAO classification could have  served as template for OSM
tagging approach years back. But we now are only after tag value for bare
soil, not a whole new table of  landcover values.

On Thu, 16 Jul 2020, 12:06 Michael Montani,  wrote:

> According to the document you shared
> , bare soil is
> mentioned in:
> *Primarily non-vegetated > Terrestrial > Bare areas*
>
> And within *Bare areas*, *Bare soil* is an available category, being
> distinguished by *Bare rock* whether the terrain is consolidated or not.
> Within *Bare soil*, further classification is made depending on a
> "stoniness" percentage (5 to 40% *Stony*, >40% *Very stony*) and on soil
> macropatterns (II level).
>
> I think this could be useful material for us to make a decision.
> *natural=bare_soil *targeting all the areas of unconsolidated ground
> material could be used whether or not a groundy area hasn't already a tag
> that suits better its representation (e.g. *natural=wetland +
> intermittent=yes*, *landuse=quarry*...).
>
> Thanks,
>
> --
> *Michael Montani*
> GIS Consultant, *Client Solutions Delivery Section*
> *Service for Geospatial Information and Telecommunications Technologies*
> United Nations Global Service Centre
> United Nations Department of Operational Support
>
> Brindisi | Phone: +39 0831 056985 | Mobile: +39 3297193455 | Intermission:
> 158 6985
> E-mail: michael.mont...@un.org  | www.ungsc.org
>
> --
> *Da:* Martin Koppenhoefer 
> *Inviato:* mercoledì 15 luglio 2020 10:08
> *A:* Tag discussion, strategy and related tools  >
> *Oggetto:* Re: [Tagging] Feature Proposal - RFC - (Ground)
>
>
>
> Am Mi., 15. Juli 2020 um 09:45 Uhr schrieb Martin Koppenhoefer <
> dieterdre...@gmail.com>:
>
> If you are interested in reading some interesting thoughts about landcover
> classification, there is the FAO landcover classification system, thought
> to be useful globally:
> http://www.fao.org/3/X0596E/X0596e00.htm
>
>
>
>
> there are only 8 main classes:
> http://www.fao.org/3/X0596E/X0596e10.gif
>
> and you can easily determine them through a decision matrix:
> 1. primarily vegetated or primarily non-vegetated?
> 2. terrestrial or aquatic/flooded regularly?
> 3. cultivated/man made/artificial or natural?
>
> then they add additional properties like life forms, crops, leaf types,
> climate, ...
>
> From the combination of these properties and classes, detailed land cover
> classes are determined:
>
>
> http://www.fao.org/3/x0596e/X0596e02a.htm#P1974_116516
>
> E.g. here:
>
> TABLE 3.4
> *Example of the formation of land cover classes*
>
> *EXAMPLE: "NATURAL AND SEMI-NATURAL TERRESTRIAL VEGETATION" (A12)*
>
> *Classifiers used*
>
> *Boolean formula*
>
> *Standard class name*
>
> *Code*
>
> Life form and cover
>
> A3A10
>
> Closed forest
>
> 20005
>
> Height
>
> A3A10B2
>
> High closed forest
>
> 20006
>
> Spatial distribution
>
> A3A10B2C1
>
> Continuous closed forest
>
> 20007
>
> Leaf type
>
> A3A10B2C1D1
>
> Broad-leaved closed forest
>
> 20095
>
> Leaf phenology
>
> A3A10B2C1D1E2
>
> Broad-leaved deciduous forest
>
> 20097
>
> 2nd layer: LF, C, H
>
> A3A10B2C1D1E2F2F5F7G2
>
> Multi-layered broad-leaved deciduous forest
>
> 20628
>
> 3rd layer: LF, C, H
>
> A3A10B2C1D1E2F2F5F7G2
>
> Multi-layer broad-leaved deciduous forest with emergents
>
> 20630
>
> Cheers,
> Martin
>
> PS: And the best: LCCS comes as a run time application, you do not need to
> have virtual basic installed !!11!!!
>
> ___
> 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] site relations for city walls?

2020-07-14 Thread Volker Schmidt
Sorry to keep riding this horse, but many of my examples have areas, ways
and nodes as members, so they cannot be described by any kind of polygon.
Lets take my favourite example of a dismantled railway.
It contains:

   - nodes: tourist information tables
   - ways: embankments, all kinds of highways
   - areas: former railway buildings, bridge structures, vegetation areas
   (that correspond to the former rail bed)




On Tue, 14 Jul 2020 at 18:17, Peter Elderson  wrote:

> https://wiki.openstreetmap.org/wiki/Multipolygon_Examples  example 1.7
> describes disjunct outers.
>
> Too bad you have to wrestle through some very complicated examples to get
> there if you start at the beginning. And, these complex examples should not
> be followed, because they advocate tying landuse to ways, borders to ways
> and other stuff you really should not do if you want to keep the map
> unbroken.
>
> Best, Peter Elderson
>
>
> Op di 14 jul. 2020 om 18:05 schreef Peter Elderson :
>
>> Just two outers is a regular use of multipolygon.
>> If the tags of two areas are the same, you can represent two or more
>> distinct areas as a multipolygon
>>
>> If you have one area as a multipolygon with an inner, a separate closed
>> way can be used as an extra outer, it will then get the attributes of the
>> multipolygon.
>>
>> Major renderers support this.
>>
>> One parking lot on two sides of a road is perfect for this method.
>>
>> Best, Peter Elderson
>>
>>
>> Op di 14 jul. 2020 om 16:55 schreef Lionel Giard > >:
>>
>>> Wouldn't a multipolygon with just two outers solve that parking case?
>>>> Best Peter Elderson
>>>>
>>>
>>> That's a bit of a stretch of the multipolygon definition as there is no
>>> inner ring.  I never used multipolygon for anything else than complex
>>> geometry (with inner ring(s)) and that seems to be what the feature is for.
>>>
>>> As we already have the site relation for grouping features that are part
>>> of the same thing, but disjoint, i think that it is good to use it. It also
>>> solves the problem when mappers use multipolygon for two polygons sharing
>>> the same edge (it is forming an invalid geometry), while with site relation
>>> it is not a problem. Another advantage is that it is quite easy to edit.
>>> You just need to add or remove a feature : no specific roles (yet) or order
>>> needed.
>>>
>>> Le lun. 13 juil. 2020 à 23:29, Volker Schmidt  a
>>> écrit :
>>>
>>>>
>>>>
>>>> On Mon, 13 Jul 2020 at 22:56, Martin Koppenhoefer <
>>>> dieterdre...@gmail.com> wrote:
>>>>
>>>>> actually all of these could be „grouped“ with tags alone, e.g
>>>>> distributed museums could have an identifying „network“ tag (or sth
>>>>> similar).
>>>>>
>>>> But why invent a new network tag, if we have  a site relation, waiting
>>>> to be used. (I was thinking of open air museums, where the various exhibits
>>>> are spread over the landscape)
>>>>
>>>>> For power plants a site might be appropriate, if an area does not do
>>>>> it and you don’t want to rely on only tags.
>>>>>
>>>> If you have ever looked at the complexities of a hydro-power-plant with
>>>> dams, lakes, pipes, turbines deep in the mountains or in dedicated
>>>> buildings . they are really complex, and only parts of it are visible on
>>>> the surface.
>>>>
>>>>> In theory objects like the Great Wall in China can and should be
>>>>> modeled as areas, although they seem to be linear in nature, they are also
>>>>> thick enough to „require“ an area representation in order to be well 
>>>>> mapped
>>>>> in the scale of OpenStreetMap (you can walk on it).
>>>>>
>>>> That's not true - you can walk on parts of it, other parts are
>>>> completely missing, others are heaps of stones.
>>>>
>>>>> In practice we would also want a way to have preliminary mapping as a
>>>>> line, and mixed geometry relations. A multipolygon relation for all parts
>>>>> of the great wall would likely be broken every day, and would be over the
>>>>> member limits for relations.
>>>>>
>>>> It's not a multipolygon - it is bits and pieces, some connected, same
>>>> not. Some may be linear (in first approximation).
>>>

Re: [Tagging] Feature Proposal - RFC - (Ground)

2020-07-14 Thread Volker Schmidt
I suggested this as a helpful guide when defining tag values. I don't think
it can be used one-to-one for OSM.
Bare ground, BTW, can be found also the area covered by CORINE, as it
includes the Sahara for example)

Volker

On Tue, 14 Jul 2020 at 18:01, Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 14. Jul 2020, at 17:36, mbranco2  wrote:
> >
> > Unluckily it's only about part of Europe (from 62°N to 28°S, from 14°W
> to 29°E)
>
> > The working scale of the project was 1/10, and the smallest mapping
> unit was 25 hectares.
>
>
> thank you for mentioning significant specification details and coverage
> area, these alone should demonstrate that CORINE data is not useful for
> inclusion in OpenStreetMap and it is probably also not helpful to copy the
> definitions for landcover from.
>
> 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 - (Ground)

2020-07-14 Thread Volker Schmidt
I am not a land cover expert, but have come across a great number of
obviously wrong land cover tagging in OSM.
Said this, why not try to use CORINE [1] definitions?

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

On Tue, 14 Jul 2020, 11:52 Christoph Hormann,  wrote:

>
>
> > Joseph Eisenberg  hat am 13. Juli 2020 um
> 22:34 geschrieben:
> >
> > https://www.flickr.com/photos/chrishunkeler/32097822997
> >
>
> I think this is a great example why more specific tags are advisable to
> use in OSM than a generic bare ground tag.
>
> What this picture shows is commonly known as desert pavement:
>
> https://en.wikipedia.org/wiki/Desert_pavement
>
> Apart from varying in size distribution and density as well as material of
> the stones these form a fairly characteristic surface that can and should
> be mapped distinctly.  As size of the larger stones strongly affects
> navigability, specifying that would be a valuable supplemental tag.
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> 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] site relations for city walls?

2020-07-13 Thread Volker Schmidt
On Mon, 13 Jul 2020 at 22:56, Martin Koppenhoefer 
wrote:

> actually all of these could be „grouped“ with tags alone, e.g distributed
> museums could have an identifying „network“ tag (or sth similar).
>
But why invent a new network tag, if we have  a site relation, waiting to
be used. (I was thinking of open air museums, where the various exhibits
are spread over the landscape)

> For power plants a site might be appropriate, if an area does not do it
> and you don’t want to rely on only tags.
>
If you have ever looked at the complexities of a hydro-power-plant with
dams, lakes, pipes, turbines deep in the mountains or in dedicated
buildings . they are really complex, and only parts of it are visible on
the surface.

> In theory objects like the Great Wall in China can and should be modeled
> as areas, although they seem to be linear in nature, they are also thick
> enough to „require“ an area representation in order to be well mapped in
> the scale of OpenStreetMap (you can walk on it).
>
That's not true - you can walk on parts of it, other parts are completely
missing, others are heaps of stones.

> In practice we would also want a way to have preliminary mapping as a
> line, and mixed geometry relations. A multipolygon relation for all parts
> of the great wall would likely be broken every day, and would be over the
> member limits for relations.
>
It's not a multipolygon - it is bits and pieces, some connected, same not.
Some may be linear (in first approximation).


> Would those that are in favour of using a site relation for a linear,
> circular, interrupted structure, 19km long and some meters wide, also see
> it as a good relation type for the Chinese Great Wall?
>
You lost me with your question here.

Volker


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] site relations for city walls?

2020-07-13 Thread Volker Schmidt
Looking back at the history of the site relation, it looks as if the
concept originated from schools, colleges, universities, airports,  and
military bases for situations where the objects are not within a well
defined perimeter. Documented uses include historical sites, even though
they are not quoted in recent versions of the wiki page.

Reading the wiki versions, I would say the "site" relation is extremely
vaguely defined.

I would think we are free to make it something useful.

At the risk of repeating myself, I believe there is a need  for something
like the site relation for a whole array of more or less widely scattered
objects that belong together. Just a few:

   - non-campus universities, research institutions, schools
   - the offices of public institutions (city, regional, country
   governments, the European Union institutions)
   - archaeological sites (aqueducts, Hadrian's Wall, the Limes in Germany,
   the Great Wall of China, The Iron Curtain, city walls, former Railways,
   former canals and other waterways, former underground mines, ...)
   - power plants (hydro-electric, wind power, ...)
   - active mines
   - distributed museums

Volker






Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] network tag on route relations

2020-07-13 Thread Volker Schmidt
I am not saying get rid of the network tag, I am saying we should be
> consistent.  In the above case, if  network=UK (instead of network=ncn),
> one would know it is national. First because the UK is a nation and there
> is no smaller jurisdiction that follows "UK" in the tag, and because there
> would be cycle routes all over the UK where network=UK.
>


Numbering in the UK reflects the "importance" of a route:
National routes carry two-digit numbers
Regional routes carry three-digit numbers
Local cycle routes are less consistently labelled.
OSM, born in the UK  has inherited this approach

The UK national bicycle network is managed by Sustrans - see
https://www.sustrans.org.uk/national-cycle-network

Similarly tiered systems exist in the Netherlands and Germany.

In Italy there is a similar approach, that mirrors the administrative
organisation of the country: National routes connect several regions.
Regional routes connect severela provinces and local routes are typically
within a single province.

Volker (Italy)






Virus-free.
www.avast.com

<#m_3447769538172802524_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] site relations for city walls?

2020-07-12 Thread Volker Schmidt
I do consider a site relation a fitting approach for a city wall.

On Sun, 12 Jul 2020, 22:35 Andy Townsend,  wrote:

> On 12/07/2020 20:13, Taskar Center wrote:
> >
> > Why is the relation type on the Berlin Wall a “collection” rather than
> > “boundary”?
>
> Over its history as an object in OSM it's had a whole variety of tags.
> Different people have said "This is important!  We should render it!"
> and have sometimes tried to do that by adjusting the tags until they
> found something that rendered.  Other people have tried to change tags
> to better reflect the current reality.
> http://osm.mapki.com/history/relation.php?id=6651797 tells the story.
>
> Personally, I don't think that "boundary" would be a good relation type
> for it because it isn't one - it's the route of a former barrier within
> a boundary.  Compare
> https://www.openstreetmap.org/relation/6651797#map=19/52.51616/13.37698
> with the suburb boundary just to the west.
>
> Best Regards,
>
> Andy
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] How to tag oneway restriction applying to pedestrians?

2020-06-24 Thread Volker Schmidt
I am not saying it's functional, but it is legally consequent. When this
stretch of foot-cycleway is busy, what happens is indeed that cyclists get
stuck behind pedestrians. It using line with the definition of shared
foot-cycle-ways: these are, legally, sidewalks on which bicycles are
tolerated, but pedestrians have precedence and cyclists have to dismount if
necessary.

On Wed, 24 Jun 2020, 21:05 Mateusz Konieczny via Tagging, <
tagging@openstreetmap.org> wrote:

>
>
>
> Jun 24, 2020, 18:05 by dieterdre...@gmail.com:
>
> On 24. Jun 2020, at 15:43, Volker Schmidt  wrote:
>
> I have just found a situation with mandatory oneway for pedestrians (and
> cyclists).
> https://www.mapillary.com/map/im/u7_0bEMY-iMrHiuafltvmg
>
>
>
> what makes you believe this is mandatory oneway for pedestrians? Looks
> like a regular oneway restriction according to the Italian CdS (i.e.
> applying to vehicles). AFAIK the CdS does not foresee oneway provisions for
> pedestrians.
> I could be wrong, but the picture doesn’t seem to prove otherwise
>
> And making illegal for pedestrians to let bicycle pass them
> (by moving to a different lane) would make
> this infrastructure even more dysfunctional.
>
> ___
> 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 oneway restriction applying to pedestrians?

2020-06-24 Thread Volker Schmidt
I have just found a situation with mandatory oneway for pedestrians (and
cyclists).
https://www.mapillary.com/map/im/u7_0bEMY-iMrHiuafltvmg


On Wed, 15 Jan 2020 at 19:31, Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 15. Jan 2020, at 12:05, Mateusz Konieczny 
> wrote:
> >
> > Pedestrian walking on the carriageway or shoulder is obligated to walk
> on the left side of the road.
>
>
> right. Now show me a oneway street that hasn’t a left side ;-)
>
> 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] Milk Churn Stands

2020-06-21 Thread Volker Schmidt
In addition I think there are (wooden) platforms for churns in the same
area. At least I think so, but until I find one, I cannot say for sure
whether they still exist or not.

On Sun, 21 Jun 2020, 15:37 Paul Allen,  wrote:

> On Sun, 21 Jun 2020 at 14:22, Volker Schmidt  wrote:
>
>> My point was only that we should be carefully looking for variants of the
>> concept, and try to make it mappable, avoiding too specialized tags.
>> Something like "milk collection point" would comprise both if we were to
>> distinguish active from historic ones.
>>
>
> It depends if we're tagging function or form or trying to handle both.  I
> have no
> objection to a milk_collection_point tag (or collection_point=milk) or
> whatever, as
> additional information but I'd like to have a tag for the physical form of
> these
> stands.
>
> In the UK, these are no longer used, or no longer used for their original
> purpose.  So man_made=milk_churn_stand + disused=yes is a better fit than
> just amenity = milk_collection_point + disused=yes because the latter on
> its
> own is just mapping history.
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Milk Churn Stands

2020-06-21 Thread Volker Schmidt
My point was only that we should be carefully looking for variants of the
concept, and try to make it mappable, avoiding too specialized tags.
Something like "milk collection point" would comprise both if we were to
distinguish active from historic ones.

<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Sun, 21 Jun 2020 at 15:09, Paul Allen  wrote:

> On Sun, 21 Jun 2020 at 13:13, Volker Schmidt  wrote:
>
>>
>> I looked around a bit (I am a city dweller, apologies, if this is new to
>> me)
>> In South Tyrol (Italy) they have an interesting variant of this concept.
>> The dairy uses refrigerated containers which are parked in designated spots
>> at scheduled times. The nearby farmers bring their milk to the container
>> and fill it up. The full containers are collected and carried to the dairy.
>> I found this photograph <https://www.instagram.com/p/BmnYj96Bc5h/> of
>> such a container on Instagram.
>> I suppose this is not a mappable feature.
>>
>
> It's not a milk churn stand because there is no platform.  If you find one
> of
> these with a platform then that would be a milk churn stand.
>
> It ought to be mappable, even so.  There is an area of paved surface
> adjoining
> the road.  It might be a small car park (mappable) or a lay-by (mappable)
> or
> a passing place (mappable).  So such areas are mappable, we just don't have
> tags for such areas with this particular function.  I see no reason why
> there
> could not be, especially if there is signage telling people not to park
> there
> because it is a collection point.  You could propose suitable tagging.
>
> Or, you could bodge it. :)  You could make the area where the containers
> are placed highway=service + area=yes.  You could ask the locals what its
> name is and they'll probably respond with the local language equivalent of
> "Milk Collection Point" or "Milk Collection Point 46" or some such which
> (in common with many things in rural areas) is a name that looks
> suspiciously
> like a functional description, so you can name it.  OSM purists will now be
> clutching their pearls, so add a fixme saying it should be retagged when
> suitable tagging becomes available.
>
> More seriously, we probably should find a way to map collection points
> because, on the ground, a tourist may think they're just parking spots and
> park there.  highway=collection_point + area=yes + collection_point=milk,
> maybe.  Some would argue it's not a highway, so maybe
> amenity=collectoin_point + access=private + collection_point=milk.
> I've purposely added a collection_point subtag rather than make it
> *=milk_collection_point so we can handle other things without
> over-burdening a top-level tag with more values.
>
> Of course, that would then have overlap for those milk churn stands
> that are still functional, and that complicates things.  So maybe we should
> forget those milk collection points exist. :)
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Milk Churn Stands

2020-06-21 Thread Volker Schmidt
Update.
I looked around a bit (I am a city dweller, apologies, if this is new to me)
In South Tyrol (Italy) they have an interesting variant of this concept.
The dairy uses refrigerated containers which are parked in designated spots
at scheduled times. The nearby farmers bring their milk to the container
and fill it up. The full containers are collected and carried to the dairy.
I found this photograph  of such
a container on Instagram.
I suppose this is not a mappable feature.



Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Sun, 21 Jun 2020 at 11:28, Philip Barnes  wrote:

> On Sat, 2020-06-20 at 19:25 +0100, Paul Allen wrote:
>
> On Sat, 20 Jun 2020 at 19:08, Martin Koppenhoefer 
> wrote:
>
>
> > On 20. Jun 2020, at 14:44, Paul Allen  wrote:
> >
> > They should probably have disused=yes or a disused lifecycle
> > prefix (cue endless arguments about which) except in parts of the world
> > where they actually are still in use (if they are).
>
> I think if any I would use disused=yes as they still remain „operational“
> I guess, although not actually used.
>
>
> True of brick/concrete/stone.  For wooden ones that are decaying,
> abandoned=yes
> may be more appropriate.  I've not had chance to take a look myself yet
> (and
> won't be able to look until there's a vaccine) but sources I cannot use for
> mapping indicate that the one nearest to me, embedded in a bank, has had
> the bank reshaped to cover the top of it (only the side is visible).  Using
> abandoned=yes in such cases would seem appropriate.
>
> The disused:key=value style seems more appropriate for functions (amenity
> etc.) than for physical descriptions (man_made).
>
>
> That is how I interpret it, but others on this list have a different
> opinion.  However,
> I'd go with was:man_made=milk_churn_stand if it had been repurposed
> in some way that it merited a different main tag.  A foolish consistency
> is the hobgoblin of little minds, according to Ralph Waldo Emerson.
>
> That leaves the question of the name.  For older British English speakers
> the
> containers are called milk churns, even though they are not for churning
> milk.  This may cause confusion to younger speakers of British English
> and those for whom English is a second language.  According to the
> Wikipedia article these are sometimes referred to as milk cans so
> maybe milk_can_stand would be better than milk_churn_stand.
>
> I can remember milk churns on these stands waiting for collection being a
> common sight when I was growing up.
>
> These days milk churns are a common period prop on preserved railway
> stations.
> For example here at Arley 
> https://www.geograph.org.uk/photo/4458834
>
> When children see these and ask what they are they will be told that they
> are milk churns rather milk cans.
>
> Phil (trigpoint)
>
>
>
>
>
> --
> Paul
>
> ___
>
> Tagging mailing list
>
> Tagging@openstreetmap.org
>
>
> https://lists.openstreetmap.org/listinfo/tagging
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Milk Churn Stands

2020-06-20 Thread Volker Schmidt
To my memory, these platforms for milk "container" collection are still in
active daily use at least in some parts northern Italy, and,  I think,
other parts of the Alps. So it is important not to make the tag "historic"
only. In some parts of Germany there used to be one-per-village small
buildings where the farmers would deposit their milk cans.I don't if any of
these are still active, but I imagine that same are still present as small
buildings.

On Sat, 20 Jun 2020, 20:44 Paul Allen,  wrote:

> On Sat, 20 Jun 2020 at 19:32, Joseph Eisenberg 
> wrote:
>
>>
>> I agree with mapping these as man_made=milk_churn_stand and adding
>> disused=yes when this is known, since a used vs disused stone or concrete
>> stand will look exactly the same.
>>
>
> The two will look different when milk churns are put on the stand for
> collection.
>
> However, in the UK they are all disused (as far as their original purpose
> goes).
> Surprisingly (to me) EU regulations still permit milk to be transported in
> churns
> but they must have some means of refrigeration so I doubt this happens in
> many places (the EU regulations mention "in-container refrigeration" which
> probably wouldn't fit in the old-style churns).
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Rail segment in a bike route

2020-06-18 Thread Volker Schmidt
I know several bicycle route segments on water: ferryboat, waterbus,
private on-demand boat.
On rail: One route contained a normal rail segment.
By Bus: scheduled buses on road segments with heavy traffic.
We should consider these other means as well in any proposal.
:

On Thu, 18 Jun 2020, 20:32 Francesco Ansanelli,  wrote:

> Dear all,
>
> I discussed with local mappers about the need of a role "take_train" or
> "public_transport" to fix bicycle routes...
> Would anybody be so kind to make a proposal about this post?
>
> Many thanks
> Cheers
> Francesco
>
> Il giorno lun 16 dic 2019 alle ore 13:49 Francesco Ansanelli <
> franci...@gmail.com> ha scritto:
>
>>
>>
>> Il lun 16 dic 2019, 10:56 Warin <61sundow...@gmail.com> ha scritto:
>>
>>> On 16/12/19 20:21, Martin Koppenhoefer wrote:
>>>
>>> Am Mo., 16. Dez. 2019 um 10:02 Uhr schrieb Volker Schmidt <
>>> vosc...@gmail.com>:
>>>
>>>> Can we come back to talking about a solution.
>>>> Maybe an appropriate new role value could be a solution:
>>>> role=take_train on the corresponding train section in the bicycle route,
>>>> for example.
>>>> However, this would provide an easy way to add train ride details.
>>>>
>>>
>>>
>>> I would add the train route relation as member, rather than the
>>> individual railway ways.
>>>
>>> If the entire train route is used then ok. But if only a section is used
>>> then I think the relevant ways only should be included.
>>>
>>> If a simple dataconsumer is not aware, it would should a hole in the
>>> bicycle relation (what IMHO is a good way to show that there is something
>>> special, in particular that you cannot simply ride your bike there), while
>>> a data consumer who specifically understands the situation could give
>>> specific directions. I agree a specific role also seems reasonable (could
>>> be extended to ferries, trams, aerialways, etc.)
>>>
>>>
>>> role=take_train would not work for ferries, buses, canoes etc.
>>>
>>>
>>> I think role=transport could work .. provided the way identifies what
>>> form of transport is used ... that could be a problem for bus routes?
>>>
>>> role=transport_train/transport_bus???
>>>
>>
>>
>> I agree with the 'transport' name, it's the same I was thinking too...
>> Also 'transport_relation' could be fine.
>> Since you are adding a relation as segment you will get the type of
>> relation from it.
>> At this point I'd remove all information from the rail, do a relation
>> ptv2 and add that to my route.
>>
>>
>>>
>>> ___
>>> 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] nhd tags - documentation page review

2020-06-14 Thread Volker Schmidt
Is it not possible to get people who were involved in the original import
to check these.things?
I would be wary to remove such things remotely and without knowing what
information these codes carry ore once carried,

I had a look at our imported waterways in Italy (which have mainly two
problems: imprecise geometry, and age, but the imported codes make sense,
and help checking flow directions (which seems to be similar to the reach
parameter in the US imports)


On Sun, 14 Jun 2020 at 22:21, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

> I created
> https://wiki.openstreetmap.org/wiki/Key:nhd:fcode
> https://wiki.openstreetmap.org/wiki/Key:nhd:ftype
> https://wiki.openstreetmap.org/wiki/Key:nhd:reach_code
> https://wiki.openstreetmap.org/wiki/Key:nhd:com_id
> about tags added in imports.
>
> Review is welcomed, especially the first two where I described tags
> with over 250 000 uses as pointless and unwanted.
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Should we map things that do not exist?

2020-06-14 Thread Volker Schmidt
Regarding power lines: it is helpful mapping razed power lines as razed and
not removing them completely, because in many cases some of the satellite
pictures still show the towers, or at least the concrete foundations. This
way you avd resurrection.
The same argument applies to other objects as well. Just on ecìxample which
thought me to be careful
Some years back, I had noticed a missing motorway access road and toll
station from different satellite photos. I had used the same motorway exit
about a year earlier. Another user complained, pointing out that that
section had been closed, and he had removed all traces from OSM. Had he
left them as disused or abandoned, I wouldn't have fallen into that trap.
And in effect large parts of the roadways and nearly all related buildings
are still there, but unused or with changed use.


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Sun, 14 Jun 2020 at 16:22, Paul Allen  wrote:

> On Sun, 14 Jun 2020 at 14:59, Niels Elgaard Larsen 
> wrote:
>
>>
>> Some stores are tagges as vacant or disused.
>> https://www.openstreetmap.org/node/3405891059
>>
>> Which makes some sense if there still is a physical separate store.
>> And it could be useful, e.g. for someone wanting to lease it.
>> But this one should not have the name.
>> And it is not really a shop. I think it should somehow be tagged as
>> retail space for lease.
>> Because maybe it will be leased by a dentist or an accountant.
>>
>
> That is where the was: lifecycle prefix and notes are useful: to prevent
> armchair mappers resurrecting something from imagery on the internet.
> I've encountered several images on Wikimedia and Geograph of buildings
> that no longer serve the purpose shown in the image.  But images aren't
> always dated (or not dated correctly) so it may not be possible to
> determine if the edit showing the object to be Fred's Shop pre-
> or post-dates the image showing it to be a cafe.
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Help explain the difference between path and track

2020-06-12 Thread Volker Schmidt
On Wed, 10 Jun 2020 at 19:41, Tod Fitch  wrote:


> For example, as mappers discover they can map a voie verte in France or a
> “Rails to Trails” in the USA as highway=greenway and not as arbitrary
> choice of track, path, cycleway or bridle path differentiated by a bunch of
> foot=designated, bicycle=designated, etc. tags they are likely to migrate
> to the simpler tagging. At some time in the future data consumers could
> begin to be more restrictive on their logic.
>

You mention the "greenways".
I know of some "things" that are labeled as "greenways". The ones I know
are certainly not "things" that are anything even remoty like types of
highways in the OSM sense..
Also the  Greenway Wikipedia article
  points in the
opposite direction. A greenway is a corridor that can be used for different
types of routes or even not be used for any kind of route. The "greenway"
label is often used to describe routes in the wider sense. I know a number
of examples that
I know a number of "greenways" carrying cycle routes that include not only
the actual highways that make up the cycle routes, but also refer to
ancillary services and features. A famous example:
https://www.avenuevertelondonparis.co.uk/. The Eurovelo network is made up
of cycle routes that contain all kinds of highways. The Rails to Trails in
the US is even more fragmented.
(I know some parts of some greenways directly as a cycle tourist).
In short words: the greenway concept is orthogonal to the highway type
concept, and, in addition, very broad - "greenway" is not a highway type.

Re: Via ferrata.
highway=wia_ferrata is different. It's an existing tag for waya, together
with the key via_ferrata_scale=* .
I guse, but have not checked that the best use would be on relations, as a
via ferrata normally is composed of pieces of diefferrent difficulty, but
that can be resolved.


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


Re: [Tagging] Feature Proposal - RFC - 3rd and 4th rail (Michael Reichert)

2020-06-11 Thread Volker Schmidt
 > Using electrified=rail to mean 3 rails and having a sub-tag for 4 rails
is a bad
thing.

+1

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


Re: [Tagging] Do we map pedestrian crossings twice?

2020-06-10 Thread Volker Schmidt
On Wed, 10 Jun 2020 at 17:45, Jack Armstrong  wrote:

>  To map a pedestrian crossing, place a node within the way representing
> the road, and set this highway=crossing tag on the node…
> footway=crossing and cycleway=crossing are sometimes used on ways which
> lead from a sidewalk to the crossing node (the node which has this
> highway=crossing tag). *This is not the preferred way of tagging.*
>
The sentence in bold has only recently been added. I have already written
to the author asking for the basis of this change.
I am waiting for an answer. If none will come that needs reverting.

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


Re: [Tagging] Help explain the difference between path and track

2020-06-10 Thread Volker Schmidt
Two points to get this thread back on track:

1) The highway=track tag has always been wider than agriculture and
forestry. There is an often overlooked "etc." in the description on the
wiki, and it has been there from the very first version of 26 May 2008.
(see also Duck_tagging )

2) "In my rendering of hiking maps I currently have to look at 13 tags and
their values to make a decision ..."
"I think we need some more values for the highway tag..."
These two statements together (made in the same message in this thread)
highlight the basic problem of this and other discussions:
If we need to look at X tags and values now, adding new values only makes
the list longer - there's no way around this.



On Tue, 9 Jun 2020 at 16:43, Andrew Harvey  wrote:

> If the way is used by "law enforcement, emergency, and maintenance staff"
> motor vehicles then I'd tag it highway=track and if it's designated for
> walking then foot=designated + motor_vehicle=private, since it's wide
> enough and occasionally used by vehicles, even for a path that is mostly
> used for walking. If you tag it as highway=path then you'd need to still
> indicate it's usable by motor vehicle with motor_vehicles=private (though
> that's only the legal use, not sure how you'd then tag the physical ability
> for it to accommodate motor vehicles).
>
>
>
> On Wed, 10 Jun 2020 at 00:32, Mike Thompson  wrote:
>
>> I know we have had this discussion before, but perhaps some of you that
>> are more elegant (and diplomatic) can comment on:
>> https://www.openstreetmap.org/changeset/85034574
>>
>>
>> These ways exist only to provide recreation to those on foot, bicycle or
>> horseback.  One will occasionally see a park maintenance vehicle, such as a
>> side by side ATV (I don't think one could even get a regular four wheeled
>> vehicle back there.), but the public is not allowed to operate motor
>> vehicles on these ways.
>>
>> Mike
>>
>> ___
>> 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 - Voting - electric_bicycle and speed_pedelec

2020-06-09 Thread Volker Schmidt
I missed the voting deadline.-my apologies.

I only today had time to look for official EU documentation and found this EU
fact sheet

that clearly supports the Wikipedia article I quoted earlier.
They use the term "electrical cycle" or "electrical bike" clearly for three
different types of vehicle and state that this is binding for all EU
countries (for a quick overview see the row of images in the upper part of
page 2.)
So, PLEASE lets reconsider this, even if already voted.

But even more generally, I fear we make a big mistake  introducing asny ny
tags for electrical bicycles. For access purpose we do not need neither of
the two new approved tags, at least in the EU, as the terms are clearly
mapped on existing categories:

   - a Pedelec is a Bicycle,
   - an S-pedelec is a Light Moped,
   - an E-bike with an accelerator grip is a Moped

We already have the keys bicycle, mofa (which I presume is a Light Moped in
OSM), and moped, so in which situations do you want to use the new tag
(apart form the naming error) highlighted above. The lawmakers have
deliberately mapped the new electrified bikes onto existing categories in
order not to have to rewrite all regulations.

Can you indicate any situation where the new tags will be used and the
existing categories don't work?

Of the examples given on the proposal page, only the the rental example may
need a new tag, even though we have already capacity:electric
For the Tuebingen example one could use moped:electric=yes
The same construction would work for the Belgium example.

By the way a similar problem must exist for motor_vehicles in general, with
the added complication that there may be more qualifiers: (fully electric,
hybrid, Diesel, petrol, and others) 

Regards

Volker

Volker


On Sun, 7 Jun 2020 at 13:56, Jan Michel  wrote:

> Voting has ended after 14 days. There were 28 votes, 27 'yes' and one
> 'abstain'.
> This means, the two keywords 'electric_bicycle' and 'speed_pedelec' have
> been approved for use and two new vehicle categories have been
> introduced. Let's see how this works out in our daily mapping tasks.
>
> There were some comments raised about the system used in some US states
> - unfortunately this wasn't mentioned during the 7 months of RFC. The
> system forsees three classes, numbered 1 to 3. To cope with this, I
> suggest to amend the 'electric_bicycle' tag with sub-categories like
> 'electric_bicycle:class2". I will leave this to a separate proposal,
> preferably written by someone more familiar with these classes.
>
> Thank you very much for your participation!
> Jan
>
>
> On 23.05.20 16:37, Jan Michel wrote:
> > The proposal for keywords for electric bicycles is now open for voting:
> >
> > https://wiki.openstreetmap.org/wiki/Proposed_features/ElectricBicycles
>
>
>
> ___
> 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] [OSM-talk] Should we map things that do not exist?

2020-06-08 Thread Volker Schmidt
Warin, Jack,

your comments are really off my main point.
We have an unfinished mailing-list thread where we have different opinions
on whether a razed (on the ground) railway can be mapped in OSM. In the
middle of that discussion the abandoned railway wiku page gets completely
rewritten by one of the participants in the thread explicitly stating that
razed railways should be *removed* from OSM.
This is basically against good practice in OSM.
In addition the statement that where roads trace razed/dismantled railways,
the reference to the fact that they do, should be removed is clearly wrong.
Worldwide there are many thousands of km of roads and cycle routes that
retrace exactly former railway lines . what is wrong with adding
railway=dismantled (orrazed)  to the ways that make up the road or the
cycle route.

Railway installations are major sites present in our environment, and there
is no good reason to remove them from the map, whether they are actively
used or only indirectly "visible".
Just two other observations to put this in context:
We have plenty of underground water courses, oil or gas pipelines where
only few objects on the surface indicate their underground existence -
no-one would object to having them in the map data, including the
underground parts.
Another completely different indication that old stuff could be of interest
to tourists: when I moved to the UK from continental Europe in 1978 I was
positively surprised to see, on the standard OS maps for hikers, references
to Roamn and Saxon sites galore, tyipiclley in the form of "site of ..."
and of many country paths and tracks labeled with their Roman or Saxon
names, even though the present-day structure is much younger - they only
retrace the Roman way like the present-day street in the first example on
the wiki page retraces a former railway..

BTW I am not saying that OSM map data are incomplete without mapping old
raylways, I am only asking to not remove those that are mapped, and to not
write in the wiki that they should be removed.
BTW 2: wiki pages in general should not invite mappers to remove already
mapped objects, but only correct mapping errors.


On Sat, 6 Jun 2020 at 05:03, Warin <61sundow...@gmail.com> wrote:

> On 6/6/20 8:02 am, Volker Schmidt wrote:
> > I need to reopen this thread.
> >
> >  I do object strongly to the invitation to remove the
> > razed/dismantled-railway tag in the case of railway tracks have been
> > replaced by roads with the same geometry. To the contrary this is one
> > of the more fortunate cases where the original route has been
> > conserved, and it is easy to travel along a historical railroad.
> > I admit that I have a faible for industrial archeology (like former
> > railways, watermills, old canals) but they do have touristic value and
> > for that reason should be in OSM.
>
>
> As a general tourist I would have no interest in traveling along a
> railway route here nothing remains of the railway.
>
> If something remains then map the remains, not the bits that no longer
> exist.
>
> Where an old railway route passes through private residential houses,
> commercial buildings, car parking area .. I don't think that should be
> in OSM yet people map it...
>
> A historian/archeologist may have interest in documenting the old
> railway route and facilities, they can and should use OHM.
>
>
>
>
> .
>
>
> ___
> 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 - Voting - electric_bicycle and speed_pedelec

2020-06-07 Thread Volker Schmidt
On Sun, 7 Jun 2020 at 13:56, Jan Michel  wrote:

> Voting has ended after 14 days. There were 28 votes, 27 'yes' and one
> 'abstain'.
> This means, the two keywords 'electric_bicycle' and 'speed_pedelec' have
> been approved for use and two new vehicle categories have been
> introduced. Let's see how this works out in our daily mapping tasks.
>
> There were some comments raised about the system used in some US states
> - unfortunately this wasn't mentioned during the 7 months of RFC. The
> system forsees three classes, numbered 1 to 3. To cope with this, I
> suggest to amend the 'electric_bicycle' tag with sub-categories like
> 'electric_bicycle:class2". I will leave this to a separate proposal,
> preferably written by someone more familiar with these classes.
>
> Thank you very much for your participation!
> Jan
>
>
> On 23.05.20 16:37, Jan Michel wrote:
> > The proposal for keywords for electric bicycles is now open for voting:
> >
> > https://wiki.openstreetmap.org/wiki/Proposed_features/ElectricBicycles
>
>
>
> ___
> 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] [OSM-talk] Should we map things that do not exist?

2020-06-05 Thread Volker Schmidt
I need to reopen this thread.

We have not arrived at a consensus so far in this talk,
Nevertheless the wiki page Demolished_Railway
<https://wiki.openstreetmap.org/wiki/Demolished_Railway> was completely
rewritten on 07:17, 27 May 2020 by Mateusz Konieczny
<https://wiki.openstreetmap.org/wiki/User:Mateusz_Konieczny>
In particular the wording
" Here railway is gone without any trace in terrain except possibly road
alignment. Its course is well documented, but such historic feature is out
of scope of OpenStreetMap, should not be mapped and should be deleted if
mapped"
in the caption of the first picture is certainly something we were talking
about, but had not agreed upon.
This rewrite in the middle of an inclusive discussion on the main aspect of
the page seems to me not correct. As far as I remember (I may not have read
all the contributions in all details) we did not talk about rewriting that
page. I do object strongly to the invitation to remove the
razed/dismantled-railway tag in the case of railway tracks have been
replaced by roads with the same geometry. To the contrary this is one of
the more fortunate cases where the original route has been conserved, and
it is easy to travel along a historical railroad.
I admit that I have a faible for industrial archeology (like former
railways, watermills, old canals) but they do have touristic value and for
that reason should be in OSM.

Volker

On Thu, 4 Jun 2020 at 16:56, Cornelis via Tagging 
wrote:

> I would like to add another interesting one. A railway that never has
> been finished completely, but you can clearly see it on the map,
> nonetheless: https://www.openstreetmap.org/#map=13/51.0885/6.6486
> Most of it is still visible, not only in the bigger picture. It's build
> as embarkment in large parts so you can easily recognize it. There still
> are several bridges crossing it. Short parts of the railway are named as
> „Strategischer Bahndamm“ (using highway=track and a name tag), but there
> is no complete relation for it or even the part between Neuss and
> Rommerskirchen from which the name is derived.
> For further information you may consult this wiki artice:
> https://en.wikipedia.org/wiki/Strategic_Railway_Embankment
>
> Maybe this one even serves as example for an old railway that in fact
> should be mapped to explain these clearly visible features that
> otherwise would lack an explanation?
>
> Best regards
> Cornelis
>
> Am 04.06.20 um 06:19 schrieb Mark Wagner:
> > On Wed, 3 Jun 2020 12:24:45 +0200 (CEST)
> > Mateusz Konieczny via Tagging  wrote:
> >
> >> Jun 3, 2020, 07:03 by mark+...@carnildo.com:
> >>
> >>> On Tue, 2 Jun 2020 12:39:14 +0200 (CEST)
> >>> Mateusz Konieczny via Tagging  wrote:
> >>>
> >>>> Jun 2, 2020, 03:52 by c933...@gmail.com:
> >>>>
> >>>>>
> >>>>> 在 2020年6月2日週二 09:26,Warin <> 61sundow...@gmail.com> >
> >>>>> 寫道:
> >>>>>> On 30/5/20 12:48 am, Volker Schmidt wrote:
> >>>>>>   > My main point is that out there are things that consist of
> >>>>>>   > visible objects plus objects which have left visible traces,
> >>>>>>   > and also some pieces that have been completely erased, but of
> >>>>>>   > which we have documented knowledge of where they once were.
> >>>>>>   > The entire thing makes sense only with all its parts. These
> >>>>>>   > things be of interest for some end users of OSM data, and
> >>>>>>   > hence, if someone has gone to the length of mapping them,
> >>>>>>   > should find space in OSM. In my view a general rule that any
> >>>>>>   > mapper can erase any object from the map, when he does not
> >>>>>>   > see any trace of it, is certainly not correct , he may be
> >>>>>>   > removing parts of the thing thsat only with all its
> >>>>>>   > partsmakes sense.
> >>>>>>
> >>>>>>
> >>>>>>   Where an old railway line has been built over by houses,
> >>>>>> factories, shops and roads I see no reason to retain the
> >>>>>> (historical) information in OSM.
> >>>>>>
> >>>>>>   The old railway station that still exists at one end - yes, but
> >>>>>> where there is nothing, not even a hint, left then no.
> >>>>>>
> >>>>> Except, it is relatively common for traces of old railway remain
> >>>>> visible even after new development (e.g. house, factor

Re: [Tagging] [OSM-talk] Should we map things that do not exist?

2020-06-03 Thread Volker Schmidt
Mark,
can you tell us the place? The photo seems to show a US city, but which one?
Even at thrìe small scale of the image I can see several traces that look
very much like ex-railway tracks (it's easy  in US cities as they do not
follow the block structure).

Please don't forget that I am not saying that we should map every single
ex-railway, I am only asking do not remove them, where someone has inserted
them.
Ex-railway corridors are often major landscape objects, in that sense they
are part of the geography. The argument has been made in this discussion
here; to map an ex-railway, only by mapping every remaining trace of it
(embankments,  roads; buildings only) but "seeing the e-railway is often
far easier on aerial photographs than on maps that's why it is helpful to
sometimes to add in the map even completely razed bits of ex.railways to
tie the visible bits together.

I invite you all to have a look at the excellent web site "
bahntrassenradwege.de <http://www.bahntrassenradwege.de>". Has nothing to
do with OSM, but illustrates why documenting ex.railways is important and
can also have a big impact on the economy when converted to a bicycle
tourist attraction.




<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Wed, 3 Jun 2020 at 07:05, Mark Wagner  wrote:

> On Tue, 2 Jun 2020 12:39:14 +0200 (CEST)
> Mateusz Konieczny via Tagging  wrote:
>
> > Jun 2, 2020, 03:52 by c933...@gmail.com:
> >
> > >
> > >
> > > 在 2020年6月2日週二 09:26,Warin <> 61sundow...@gmail.com> > 寫道:
> > >
> > >> On 30/5/20 12:48 am, Volker Schmidt wrote:
> > >>  > My main point is that out there are things that consist of
> > >>  > visible objects plus objects which have left visible traces,
> > >>  > and also some pieces that have been completely erased, but of
> > >>  > which we have documented knowledge of where they once were. The
> > >>  > entire thing makes sense only with all its parts. These things
> > >>  > be of interest for some end users of OSM data, and hence, if
> > >>  > someone has gone to the length of mapping them, should find
> > >>  > space in OSM. In my view a general rule that any mapper can
> > >>  > erase any object from the map, when he does not see any trace
> > >>  > of it, is certainly not correct , he may be removing parts of
> > >>  > the thing thsat only with all its partsmakes sense.
> > >>
> > >>
> > >>  Where an old railway line has been built over by houses,
> > >> factories, shops and roads I see no reason to retain the
> > >> (historical) information in OSM.
> > >>
> > >>  The old railway station that still exists at one end - yes, but
> > >> where there is nothing, not even a hint, left then no.
> > >>
> > >
> > > Except, it is relatively common for traces of old railway remain
> > > visible even after new development (e.g. house, factory, shop,
> > > road) have been made on top of their original site. So that cabnot
> > > be used as a criteria to determine whether that should be removed
> > > or not although the exact situation varies a lot in each individual
> > > cases.
> >
> > Can you give an example (photos) where entire factory was constructed
> > over former railway and this section of railway remains somehow
> > mappable in OSM?
> >
> > With road I can easily imagine this, with a single small building I
> > can also imagine special cases of this remaining true.
> >
> > But entire factory?
>
> It's not a factory, but how about a car dealership, two storage rental
> facilities, a school bus parking lot, a sports park, and about forty
> city blocks of other things?
>
> https://imgur.com/a/5YObPTP
>
> --
> Mark
>
> ___
> 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] Reviving the path discussion - the increasing, importance of trails in OSM

2020-06-02 Thread Volker Schmidt
On Tue, 2 Jun 2020 at 16:54, Tod Fitch  wrote:

> My translation of these two statements combined is roughy: “We can’t
> change any tagging”. I don’t find that helpful.
>

I fear your translation is correct.

At least for tags as heavily used as highway=path and highway=track.
Deprecating anything is nearly impossible due to the immense amount of work
involved.
You cannot undo old tagging, you have to carry it with you and any new
tagging you introduce is making life even more complicated, because you
have to support both old and new.
Maybe due to my way of inserting data, often along cycle routes or recorded
GPX tracks  (and Mapillary photos) I encounter so many cases were JOSM
reminds me of deprecated tagging in the data I downloaded, but data that I
have not touched at all. I keep ignoring these messages because I have no
knowledge of the situation on the ground, but the sheer number of these
warning messages is indicating that this approach of introducing new
tagging and then leaving to others the task of updating the old tagging, is
basically wrong.
If we feel that we need to introduce additional tagging you may consider
this, but changing existing tagging (or re-defining existing tagging, which
amounts to the same thing) is near to impossible.
In this specific discussion we may have an underlying problem (or advantage
?): In my part of the world quite a lot of minor highways (tracks, paths,
cycleways, footways) is already mapped (I would assume that in Germany this
even more the case), so any tag or wiki changes would cause a lot of work.
If you are in an area where the minor viability is still less well covered
in OSM, you may consider local tagging definitions which differ from the
ones used in other parts of the world, and try to control who is tagging in
"your" area (would be difficult here as we have many visiting mappers form
the northern side of the Alps)

I recently created a cycling map of my city. Bicycle tagging has already
gone through several major redefinitions of tagging and I had to take into
account all the different generations of tagging people have applied here.
And that is a local map and also it left out the surface (paved vs
unpaved). I know what we are talking about - don't repeat those mistakes.





Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Reviving the path discussion - the increasing, importance of trails in OSM

2020-06-02 Thread Volker Schmidt
On Tue, 2 Jun 2020 at 09:04, Daniel Westergren  wrote:

> I think the reason that this is so messed up because of the desire to tag
>> according to function.   A trail/path can have many users/functions, but
>> it's still a dirt path.
>>
>
> Right. But is there another way? Can we tag dirt paths/wilderness
> paths/forest paths/mountain paths with another main tag?
>
No you cannot inroduce another main tag, because of the existing stock of
"path" 8.7 million and "track".(18.7 million). This would only add
additional confusion with mappers and an enormous burden on renderers and
routers

> Can we somehow "enforce" additional tags for physical characteristics that
> will tell what this path|footway|cycleway actually looks like?
>
We have no way to "enforce" anything in OSM. But, as we do have the
necessary tags (maybe to many different ones, but they all are in use.and
we need to reamin backaward compatible in view of the enourmous numbers).
What we can do and need to do is to improve the description of the various
existing tagging options in the wiki (without touching their definition)

Don't forget dirt bikes & ATV's (<50 inchs, 127 cm) in this assessment.
>> Many trails are open to, and used by, everyone including motor vehicles.
>> Perhaps this just means that footway & cycleway are non-motorized, and path
>> could be.
>>
> We do have a more or less agreed set of default access restrictions tables
.
We cannot retrospectively change them.. For most countries this sets the
default access for "path" to foot|bicycle|horse (in the US also "moped").
Again these default values have been there for a while, hence many millions
of paths and tracks are tagged on that base.

One thing you can do for future tagging is to convince the JOSM and iD
people to create more specific presets (say an ATV preset which would check
that there is a width tag on the path with a value of at least 127cm, and
also set the access to motor_vehicle=yes (I don't know if we do already
have an ATV vehicle category)

>
> Yeah, something like "and possibly smaller motor vehicles" should be
> added. In Sweden, for example, cycleways are normally open for smaller
> mopeds. "...primarily intended for non-motorized vehicles and possibly
> smaller motor vehicles".
>
Tere is so far no table on the above wiki page for Sweden. If moped=yes
that is the default situation on cycleways in Sweden, it would be good idea
to add a new table for > shouldn't tag for a lousy renderer, but we should tag for the user &
>> sometimes the rules laid down are wrong.
>>
> We do not have laid down rules, and we cannot create any. The wiki
documents what mappers do,
I would say we should not define things that make life even more complex to
people who design renderers and routers, to mappers, and , last but not
least keep the end user in mind.

>
>> I'm OK with taking this off this list & I can add my comments to the
>> google docs doc.
>>
>
> Ok, I'll email those who have expressed interest in following or
> participating in the discussion. Suggestions and comments can also be done
> in the Google Doc.
>

As said before I would prefer that his discussion remain on one of the
tools of the OSM community, mainly for documenting the discussion.

Volker


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


  1   2   3   4   5   6   7   8   >