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


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

2020-06-02 Thread Volker Schmidt
On Tue, 2 Jun 2020 at 05:06, Warin <61sundow...@gmail.com> wrote:

> How much time do you think I should spend searching for these people who
> might know of it? And then once found how much time should I spend trying
> to contact them?
>
> Think about what you are asking an unpaid mapper to do?
>
> I would think contacting the author and/or past editors of the item in OSM
> is enough.
>
I am asking even less work, I am asking to leave an object that is tagged
as razed railway in the database and not remove it without contacting the
mapper who inserted it.

Anyway the examples you find in OSM are few and in all cases I know the
completely erased bits are a tiny part of the overall ex-railway.

The same argument applies also to ex-roads. A thing which springs to mind
would be tagging the ex-Route 66, of which huge stretches still exist in
different forms. (I rode it on bicycle) This would be a very interesting
and pertinent job in OSM.

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] Covered walkways?

2020-06-02 Thread Volker Schmidt
Simple mapping: covered=yes
Elaborate mapping: building=roof; layer=1 (useful if the geometry matters,
e.g. roof wider than footpath)

Il mar 2 giu 2020, 07:36 Graeme Fitzpatrick  ha
scritto:

> Doing some mapping around one of the local schools & wondering about the
> best way to map covered walkways?
>
> https://www.openstreetmap.org/edit#map=19/-28.06022/153.42615
>
> A lot of skinny roofs, with highway=footway + covered=yes drawn under
> them, or simply just footway + covered, which would indicate there is a
> roof there?
>
> Is either "better"?
>
> 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] Reviving the path discussion - the increasing, importance of trails in OSM

2020-05-31 Thread Volker Schmidt
Daniel,

you wrote

On Sun, 31 May 2020 at 09:18, Daniel Westergren  wrote:

> But words like path & footway is telling a different story and confusing
> most mappers.
>
> And some say that highway=path either can mean a wilderness path or, if
> used with foot/bicycle=designated, a combined, urban foot- and cycleway.
> No, it can't, because often the latter case is tagged without access tags
> and therefore impossible to interpret based on the highway tag alone.
>
> And herein probably lies the fundamental error of
> 1. using words that people normally would associate with physical
> characteristics, but to only mean function
> 2. the default OSM rendering not considering physical characteristics
> (particularly for non-urban ways) together with underestimating the extent
> of tagging for the renderer (obviously people want their tagging to be
> confirmed)
>
you are touching on an essential misunderstanding in this conversation, a
misunderstanding that we encounter in many different discussions in OSM.

Those " words that people normally would associate ...", i.e. "path",
"footway", "track", ... are *code* words, they do not have any intrinsic
meaning. Their meaning is defined by their use.
The "path" problem is not a problem. A way in OSM tagged with highway=path
(without any other tag) means a narrow, unpaved track,  on which you are
allowed to walk, cycle, and (in most jurisdictions) ride on a horse or on a
donkey. A way in OSM tagged with the tag combination highway=path plus
bicycle=designated plus foot=designated means a combined or segregated
foot-cycleway.
We could also have chosen, in the beginning of OSM, to define keys
differently. We could have chosen "trail" or "sentiero" or "pfad" or
"òkljdgpiodjg" instead of "path", the result would have been exactly the
same. The convention in OSM to use British English terms for keys and
values is a convenience and is meant to help memorizing keys and values.
___
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-05-30 Thread Volker Schmidt
> Ok, I hope this will be my final post in this long thread. I will try to
> summarize what I understand from the discussion as the main issuesa and
> what needs to be addressed to make it easier for mappers and data
> consumers.
>
As said before, whatever you do to the tagging it will life more difficult
for data consumers,  because you cannot redo the existing hiking network in
OSM.
We may work on explaining better to mappers (wiki) how to use the *existing*
zoo of tags.


> I would also suggest that instead of filling the inboxes of each and
> everyone on this tagging list, we create a smaller "working group" that can
> come up with a concrete suggestion to solve the major issues. What do you
> think about that? Who would like to work with such a proposal?
>

I don't know if we need a working group, we should in any case document
what we are doing in one of the existing  formats: wiki discussion page;
mailing list, forum. Working group sounds nice, but we would need to be
extremely careful with documenting the discussion

Your list below is missing the most important goal: compatibility with the
existing data.

It is extremely important to take into account that there are parts of the
world where most of the hiking paths and tracks are already mapped. That
mapping can be improved both from the geometry point of view as well as
adding information, but always using the existing set of tags.

I am happy to participate in the work.


> *Major issues*, as I understand it:
>
>1. How do we treat highway=path and highway=footway that has no
>additional tags?
>2. Is highway=path a type of way (wilderness trail or whatever term we
>use) or a way for non-specified/mixed use? That is, are we talking about
>the physical characteristics of a way or its function? *Btw, this
>would likely mean that 99 % of path/footway/cycleway in Sweden should be
>path, if the latter interpretation is to be used.*
>3. #1 & #2 makes it really difficult for data consumers, they have to
>depend on (often non-existing) subtags.
>4. Additional tags must be used to denote accessibility for
>pedestrians/cyclists of ordinary ability, that is "this is NOT a hiking
>trail/wilderness trail!. But which would these tags be?
>5. Additional tags must also be used to tell !this IS a wilderness
>trail! (or whatever term we use).
>
>
> *Subtags*
> To specify the physical characteristics of a highway=path or
> highway=footway we have a multitude of tags, with no particular
> recommendation about which ones must or should be used (see #4 & #5 above):
> surface, smoothness, width, trail_visibility, sac_scale, mtb:scale and
> possibly incline.
>
>
> *An additional issue:*
> 6. sac_scale is currently the only tag (possibly together with mtb:scale)
> to denote the difficulty of a hiking trail (that is, the way, not the
> route). But it's very geared towards alpine trails and there is not enough
> nuance in the lowest levels. Could the Yosemite Decimal System (YDS),
> Australian Walking Track Grading System and others complement or expand on
> sac_scale?
>
>
> *What needs to be done?*
>
>1. We have to rely on subtags...
>2. We need to decide what subtags to be used to tell this is an
>accessible path or this is a wilderness trail.
>3. We need a way to better nuance hiking trails.
>4. Documention needs to be much more clear and specific, in order for
>mappers and data consumers to really know when different kinds of highway
>tags should be used and what subtags must/should be used.
>5. Editors need to be improved to encourage tagging that will make it
>easier for data consumers.
>6. Better default rendering of non-urban paths, to encourage the use
>of mentioned subtags.
>
>
> Would this be a fair summary? What have I missed? Who is interestet in
> continuing this work in a smaller group? Or should we continue to spam this
> mailing list?
>
> /Daniel
>


>
>
>
>
> Den fre 29 maj 2020 kl 17:26 skrev Volker Schmidt :
>
>> Unfortunately it is more difficult to map properly the minor roads and
>> ways, in comparison with the major roads. There much more variegated in
>> appearance, in use, in rules ecc, and, at least in my part of the world
>> there are also simply more in numbers.
>> It is also correct that the available sets of tags of keys are not
>> orthogonal, but whatever we invent in additional new tagging, won't make
>> the existing tagging go away. So whatever we add, we make life for data
>> consumers even more complicated. And redefining the meaning of the existing
>> tags is also out of the question.
>> What we can do is to improve the documentation, which

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

2020-05-29 Thread Volker Schmidt
Unfortunately it is more difficult to map properly the minor roads and
ways, in comparison with the major roads. There much more variegated in
appearance, in use, in rules ecc, and, at least in my part of the world
there are also simply more in numbers.
It is also correct that the available sets of tags of keys are not
orthogonal, but whatever we invent in additional new tagging, won't make
the existing tagging go away. So whatever we add, we make life for data
consumers even more complicated. And redefining the meaning of the existing
tags is also out of the question.
What we can do is to improve the documentation, which is overlapping and
dispersed abd, maybe, we can do better in documenting country-specific
tagging traditions, but not more.
Also when doing so we have to avoid absolutely anything that my appear to
be wiki fiddling.




On Fri, 29 May 2020 at 17:13, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
>
>
> May 28, 2020, 22:05 by kevin.b.ke...@gmail.com:
>
> So I return to, 'what's the minimalist set of attributes that we can
> use to guide a data consumer, and conversely, the minimum set of tags
> that a data consumer needs to recognize?' Specifying every attribute
> in excruciating detail is fine if you're trying to map your area
> artistically and say as much as possible; it shouldn't be necessary
> for a mapper to do so, or for a data consumer to understand
> everything, in order to get reasonable approximate results.
>
> Depends on what you want to achieve.
>
> surface=* goes a long way toward distinguishing it,
> but there are still unpaved park footways in city centers
> and paved path inaccessible to many.
>
> surface=* + wheelchair=no where applicable seems
> to cover basically everything of what I mapped -
> except unpaved paths in parks.
> ___
> 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-05-29 Thread Volker Schmidt
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.
Anyway i am against removing apparently useless data without consultation
with the author, with the exception of clear errors.

Volker

Volker

On Fri, 29 May 2020 at 00:46, Clifford Snow  wrote:

>
>
> On Thu, May 28, 2020 at 3:29 PM Paul Allen  wrote:
>
>> On Thu, 28 May 2020 at 23:14, Mateusz Konieczny via Tagging <
>> tagging@openstreetmap.org> wrote:
>>
>>>
>>> I agree that it is good example of something on a boundary (assuming
>>> that both "rails completely gone" and "track of former railway is
>>> recognisable"). Do you have some good images showing both?
>>>
>>
>> I didn't map it (somebody else did), but I can observe the path of a
>> former railway
>> because some of the route has the tree-lined hedges typical in this part
>> of the world.
>> Often between such hedges is a farm track, or a road, occasionally a
>> footpath, but
>> there is no highway along this route.  It is an otherwise inexplicable
>> pair of tree-lined
>> hedges, or gaps in woodland.  With the occasional bridge, embankment and
>> cutting.
>>
>> Yes, you need historical knowledge to figure out what the route was, but
>> you
>> can identify it from aerial imagery.  See if you can figure out which bit
>> on the
>> map it is: https://www.openstreetmap.org/#map=16/52.0496/-4.6166
>>
>> Is the existence of those actual, verifiable features sufficient to
>> justify
>> mapping an abandoned railway as explanation and to deter other mappers
>> from guessing there is a footpath or track where one doesn't exist?  Is it
>> sufficient to justify mapping the whole abandoned line, even though it is
>> less obvious along much of the route?
>>
>> I might not map such a line myself, but I'd be very reluctant to remove
>> it.
>> Especially as I suspect there are bridges, culverts, cuttings and
>> embankments
>> along it that still exist but have not yet been mapped.
>>
>
> I concur with Paul. I've helped do some preliminary work for a new bike
> route. The preliminary plan was to use the road for the bike route. When
> looking at OSM, next to the road was an abandoned railway. The tracks
> appear to be gone, but the raised bed is visible. Without the existence of
> the abandoned railway it most likely would have been missed. If this bike
> route ever comes into existence, the planners can now consider using the
> old railway. They may not due to cost, but at least they have the option.
> And they wouldn't have found the old railway from Google or local
> county/city drawings, just OSM.
>
> With no artifacts left, I agree it can and should be removed. But I'm
> really cautious with railway lines because they can be repurposed easily.
>
> Best,
> Clifford
>
> --
> @osm_washington
> www.snowandsnow.us
> OpenStreetMap: Maps with a human touch
> ___
> 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-05-28 Thread Volker Schmidt
This is a "problem" that is being exaggerated, in my view. There are very
small percentage of historic "things" in the OSM database that really do
not exist anymore in the sense that they are truly invisible.

There are plenty of historical "things" in OSM of which large parts still
exist today, like the Colosseum in Rome or  the Great Wall of China, just
to name two big ones.
But many of the smaller bits you still see today are part of historical
artefacts, the remaining parts of which have disappeared, and then there
are those in.between cases where bits are still indirectly "visible" on the
ground.

One extreme example that springs to mind is The Ridgeway
 on the Berkshire Downs in
Southern England, believed to be Europe's oldest long-distance road.  Even
if it's exact course has been lost over the millennia it is today a major
tourist attraction for hikers and MTB fans as the prehistoric monuments are
aligned on its course like the pearls on a necklace. Most of it is today a
National Trail, but bits are missing, and no longer visible in the
landscape, mainly due to human intervention. I have not checked on OSM how
it is mapped - I know it from walking it in pre-OSM times.

Fast forward in history..

There was a railway form Ostiglia on the Rover Po to Treviso in Veneto
, Italy, built in
the early 20th century and abandoned in 1987. No rails remain, but nearly
all station buildings and other ancillary buildings and many bridges are
still there (or have been restored). More than half of it has been
converted so far into a foot-cycle route, one of the busiest in the
country. The entire course is still visible in the landscape, easily
spotted from satellite imagery. This
 is the OSM bicycle route
relation of the (existing) foot-cycleway and this is the site relation of
the original railway 
course and (most of) the buildings and some other artefacts. Planning work
is under way to complete the entire foot-cycle route from Treviso to
Ostiglia. I will obtain the planing material with the aim of inserting it
in OSM as proposed cycling route.

Another frequent situation is city walls that have been incorporated in
more recent buildings.

Yet another example in my own city, Padova. We have three Roman bridges two
of which are completely interred, a third one is interred, but partially
excavated, Also the canal (formerly a river) theay are spanning, has ben
interred completely, but its course is perfectly visible and the road it
has been converted to is aptly named "Riviera dei Ponti Romani".

I think that in all these cases we are talking about more or less important
attractions which need the historic context.
And if an OSM mapper has inserted that context information, in the extreme
case in the form of razed railway tags on a hedge, or similar trivial
objects, this information is a valid contribution to OSM, and I would
consider removing it as vandalism.

Thanks for having read to the end.

Volker

On Thu, 28 May 2020 at 06:12, Skyler Hawthorne  wrote:

> On May 25, 2020 15:35:44 Jack Armstrong  wrote:
>
>> I agree with Mateusz Konieczny. If there is some vestige of the object
>> remaining, then mapping it in some way seems reasonable. But, if the
>> railway, building, highway, etc., are completely removed and there are
>> absolutely no visible remains of what was once there, it can be removed.
>>
>> I don't see the need to map something that does not actually exist.
>>
>> - Jack Armstrong
>> chachafish
>>
>
> I agree. OSM is not a historical object database. If it doesn't exist, it
> shouldn't be in the data.
> --
> Skyler
> ___
> 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] line=* tag on railway lines

2020-05-28 Thread Volker Schmidt
I just had a quick go on the key:line.

There seems to be a plethora of meanings of this tag, some so obscure that
I have not the faintest idea what they mean.

Try this  overpass turbo Wizard search search
“type:way and highway=* and line=*”
and try to make sense of the results.

 Volker

On Thu, 28 May 2020 at 22:24, François Lacombe 
wrote:

> Hi
>
> Le jeu. 28 mai 2020 à 21:14, Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> a écrit :
>
>>
>> Yes, name tag is for name of the object.
>>
>
> I agree
> I'd be in favour of removing such mention on wiki wouldn't you?
>
> Le jeu. 28 mai 2020 à 21:56, Jack Armstrong  a
> écrit :
>
>> If the rail is tagged name=* but the railway also has a relation with
>> the same name, isn't this naming something twice? it seems to me the
>> relation is sufficient and the rail itself should not be named?
>>
>
> We had the question on power lines as well.
> At least it's not the same name : name of the physical line, the rails
> versus the name of the commercial service
>
> François
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging 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-05-27 Thread Volker Schmidt
On Wed, 27 May 2020 at 20:34, Daniel Westergren  wrote:

> And there is (c) a non-urban trail with legal access for bicycles but in
>> practice only usable with a mountain bike but lacking a MTB scale tag as
>> the hiker, like me, who mapped it has no clue what MTB scale to put on it.
>>
>
> This is likely the default way of interpreting highway=path with no
> additional tags.
>

What I called a "hiking" path without additional tags is highway=path with
sac_cale=hiking

>
> *I still think the distinction needs to be much more clear between
> path|footway|cycleway for all the cases when no additional tag is being
> used. *
>

The real world situation is much more variegated.
When I see something that look like a track, feels like a track, wide
enough for a tractor, but has a foot-cycle-way blue disk sign (in many
Europens countries) I tag this as a highway=track plus its appropriate
properties tags plus bicycle=designated plus foot designated plus
segregated=no (there is no white line on the forest track.. If it is half
width, it's a path.

> Fine with JOSM messing up combined foot- and cycleways (I tried to look,
but couldn't find an issue tracker to discuss that misbehaviour with the
JOSM developers). In JOSM I get a warning if I add a combined foot- and
cycleway without adding a segregated tag. *If highway=path with no surface
tag would get the same warning in both JOSM and iD, we'd be getting at
least somewhere.*

JOSM is not messing anything up, it only uses as presets a way of tagging
foot-cycle-ways that is widely used in Germany, Italy, and other countries.
iD does take a different approach, possibly also because the situation in
the US is different.
I don't think it's JOSMs fault. That tagging was already in wide use before
JOSM had it as preset, if I remember well.

> Good that this discussion has lead to some improvement of the description
of sac_scale. As has been mentioned, *sac_scale and mtb:scale need values
for "no"* as well, to actively say that "although this is a path, it
doesn't qualify for a hiking path or an mtb singletrail". *And the
description for those tags would need to emphasize when not to use the tag,
or use the "no" value. Otherwise sac_scale=hiking makes no distinction
whatsoever between a paved path and a hiking path that may be quite
technical.*

I agree with the need for a default value for sac_scale. It should be
sac_scale=hiking. MTV_scale does not need a separate default value, as the
SAC scale "hiking" is clear enough for an  MTB rider as well (I think). The
problem may be that MTB scale=0 assumes no positive gradient (but I am not
an MTB expert)







>
>

> ___
> 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] Reviving the path discussion - the increasing importance of trails in OSM

2020-05-27 Thread Volker Schmidt
When I used the term ""hiking" path" that was meant inclusive of bicycle
(MTB) use, an , in most countries also horses.
The default access settings

for path in most countries are foot, bicycle, horse


On Wed, 27 May 2020 at 16:29, Tod Fitch  wrote:

> And there is (c) a non-urban trail with legal access for bicycles but in
> practice only usable with a mountain bike but lacking a MTB scale tag as
> the hiker, like me, who mapped it has no clue what MTB scale to put on it.
>
___
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-05-27 Thread Volker Schmidt
On Wed, 27 May 2020 at 15:15, Andrew Harvey 
wrote:

> The way I see it is there are two main views of highway=footway,path in
> OSM.
>
> 1. Is that footway is urban and path is remote/forest
> 2. Is that footway is for primary walking paths (including remote/forest
> paths) and that path is for non-specified usage or mixed use paths
> (including urban paths).
>
> This does not describe the situation

   - *highway=footway* is "urban", implies foot=designated, usage can be
   expanded with tags like bicycle=yes|permisive||designated to describe
   mid-use ways

   - *highway=cycleway *implies bicycle=designated, usage can be widened
   with tags like foot=yes|permissive|designated to describe mixed-use ways
   (this

   - *path* is being used for two completly different  things:

(a) a "hiking" path, mostly in non-urban situations, including mountain
hiking
(b) with the additional tagging foot=designated plus bicycle=designated
plus segregated=yes|no as a mixed use foot-cycle-way

All of these are widely used and I think it will be impossible to undo the
tagging.
What has been proposed is to add a new way of tagging of what with the
present tagging could be:described with
highway=path plus sac_scale=hiking
with a new combination of
highway=path plus path=hiking
___
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-05-27 Thread Volker Schmidt
Just to demonstrate that "hiking" paths with sac_scale=mountain_hiking
properties and combined foot-cycleways are not mutually exclusive: a
real-world Mapillary shot
from Padova, a
bustling city in the flatlands of the Po Valley (not photoshopped!)
Just accept this as my contribution to lessen the psychological stress of
this never-ending discussion.
___
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-05-27 Thread Volker Schmidt
On Wed, 27 May 2020 at 11:30, Daniel Westergren  wrote:

> To confuse things more (or maybe less...), I just realized that iD is
> using highway=cycleway, bicycle=designated, foot=designated for a "Cycle
> and foot path". But in JOSM, the preset for the same is using
> highway=path...  Similarly, iD is using highway=footway as default for a
> sidewalk.
>

Daniel,

this difference in presets between JOSM and iD for foot-cycle-ways is well
known. And there are more than just these two variants, unfortunately..
I have been saying all the way that we have to live with these - it is much
too late to re-tag them.
What we are discussing now is how to make sure that a hiking path (not a
foot-cycle-way) is tagged correctly as such.
This is not helped by the fact that we do have hundreds of thousands of
ways that are tagged as highway=path and we are discussing how to indicate
that a path is a hiking trail. It has been proposed to introduce a new
value path=trail or path=hiking for that purpose.
As we do already have the sac_scale tagging for level of difficulty of
hiking paths and the lowest level of that is sac_scale=hiking. This would
correspond exactly, in my view, to the new proposed tag value(s) without
introducing a new tagging.
sac_scale=hiking is used 319 785 times - so I do not see a need to create a
new tagging meaning exactly the same thing.
___
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-05-26 Thread Volker Schmidt
We have now been reviving the path discussion in 73 messages, and counting
...
I still feel we are not understanding each other (or is it only me who is
lost?)
To me a highway=path is a concept that is well defined in the wiki, and the
various types can be described with existing tags.
A hiking route (sometimes called a hiking trail) is a concept that is
clearly defined in the wiki.
Both are very widely, and successfully used.
Dictionaries do not agree on whether a path is a type of trail or a trail
is type of path or whether they are synonyms. And I think this is at the
base of the discussion.
I would like to remind us that the British-English language words that we
use in OSM tags are code words to make life easier, the meaning of the code
words is defined by the mapping practice and that mapping practice is
documented in the wiki. The common language meaning of these code words is
in principle independent of the OSM meaning of the codes, and in that sense
irrelevant.

I still do not understand why we cannot describe well a mountain hiking
path with the existing tagging.
And what would the additional value path=trail (whatever it means) add
other than making life even more complicated for hiking routing developers?

In the context of this discussion, I would like to point to a recent new
tag which may help hiking trail mappers: Triggered by the collaboration
between OSM and the Italian Alpine Club (CAI), we do have now an additional
tagging instrument to characterize the difficulty of an entire hiking trail
relation with the tag cai_scale
. While
sac_cale is applied to every single way of a hiking trail relation,
cai_scale is assigned to the relation.

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


Re: [Tagging] oneway=yes on motorways

2020-05-26 Thread Volker Schmidt
Please come back to my original question: *I would like to eliminate the
contradiction in the wiki. What wording do you propose?*

On Tue, 26 May 2020 at 10:23, Jean-Marc Liotier  wrote:

> On 5/26/20 5:44 AM, Paul Johnson wrote:
>
>
> It can't hurt to specify oneway=yes. I have noticed that the JOSM style
>> that shows lane counts and lane use will sometimes not show ways
>> properly if oneway=yes isn't there, but that's probably a bug in the
>> style more than an indictment of implying oneway=yes.
>>
>
> I'm on the side of "team tag explicitly" on this.  If anything, it gives
> validators more to work with if you start doing something weird.
>
> Isn't that what oneway=no is for ?
> ___
> 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] oneway=yes on motorways

2020-05-24 Thread Volker Schmidt
I am aware of the histroy - I only wanted to bring up the contradiction
between the two wiki pages *before* changing the wiki.

On Sun, 24 May 2020 at 23:11, Florian Lohoff  wrote:

> On Sun, May 24, 2020 at 10:26:19PM +0200, Volker Schmidt wrote:
> > I just noticed an apparent contradiction regarding the use of the oneway
> > tag between the wiki pages key:oneway
> > <https://wiki.openstreetmap.org/wiki/Key:oneway> and motorway
> > <https://wiki.openstreetmap.org/wiki/Tag:highway%3Dmotorway> .
> > The former states:
> > "Some tags (such as junction
> > <https://wiki.openstreetmap.org/wiki/Key:junction>=roundabout
> > <https://wiki.openstreetmap.org/wiki/Tag:junction%3Droundabout>, highway
> > <https://wiki.openstreetmap.org/wiki/Key:highway>=motorway
> > <https://wiki.openstreetmap.org/wiki/Tag:highway%3Dmotorway> and others)
> > imply oneway=yes and therefore the oneway tag is optional,
> > the latter states:
> > "These ways should all point direction of travel and be tagged with
> oneway
> > <https://wiki.openstreetmap.org/wiki/Key:oneway>=yes"
> > <https://wiki.openstreetmap.org/wiki/Tag:oneway%3Dyes>
> >
> > What is the agreed standard, if any?
>
> In ancient OSM history roundabouts and motorways had oneways. This has
> since been obsoleted and implicitly assumed on those ways.
>
> At least thats my memories from 1 1/2 decades.
>
> 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] Change of wiki page Key:access

2020-05-24 Thread Volker Schmidt
I would like to bring this up in the list.
I am not happy with the recent change of the key:access page of the wiki

-- Forwarded message -
The OpenStreetMap Wiki page Key:access has been changed on 24 May 2020
by Flohoff, see https://wiki.openstreetmap.org/wiki/Key:access for the
current revision.

To view this change, see
https://wiki.openstreetmap.org/w/index.php?title=Key:access=next=1994688
-
In my country (Italy) there are literally thousands of ways where it is
most likely legal to pass by bicycle, but there is no (practical) way of
finding out.
Essentially two classes:

   - plenty of ways that look from the layout like combined foot-cycle
   paths but have  no signage at all
   - plenty of service roads which show the "no transit for any vehicle"
   sign , but in reality you
   can happily pass with your bicycle and no policeman will ever say anything,
   or even know that "no vehicle" legally includes "no bicycle", There are
   plenty of cases where even signposted cycle routes follow such roads.

I am consistently using bicycle=permissive in these cases, well being aware
that I do not know of he owner has given permission. Basically any
cycle-routing would come to a halt without this trick.

The strict wording introduced by Florian is simply not practically
applicable here.
My questions are:
Is Italy the only country with this problem?
Is there any better proposal for tagging the situation "from all I can see
on the ground, you are allowed ride through with your bicycle"
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] oneway=yes on motorways

2020-05-24 Thread Volker Schmidt
PS: The standard rendering assumes junction=roundabout, highway=motorway,
and highway=motorway_link to be oneway=yes by default
(https://github.com/gravitystorm/openstreetmap-carto/pull/1363)

On Sun, 24 May 2020 at 22:26, Volker Schmidt  wrote:

> I just noticed an apparent contradiction regarding the use of the oneway
> tag between the wiki pages key:oneway
> <https://wiki.openstreetmap.org/wiki/Key:oneway> and motorway
> <https://wiki.openstreetmap.org/wiki/Tag:highway%3Dmotorway> .
> The former states:
> "Some tags (such as junction
> <https://wiki.openstreetmap.org/wiki/Key:junction>=roundabout
> <https://wiki.openstreetmap.org/wiki/Tag:junction%3Droundabout>, highway
> <https://wiki.openstreetmap.org/wiki/Key:highway>=motorway
> <https://wiki.openstreetmap.org/wiki/Tag:highway%3Dmotorway> and others)
> imply oneway=yes and therefore the oneway tag is optional,
> the latter states:
> "These ways should all point direction of travel and be tagged with oneway
> <https://wiki.openstreetmap.org/wiki/Key:oneway>=yes"
> <https://wiki.openstreetmap.org/wiki/Tag:oneway%3Dyes>
>
> What is the agreed standard, if any?
>
> Volker
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] oneway=yes on motorways

2020-05-24 Thread Volker Schmidt
I just noticed an apparent contradiction regarding the use of the oneway
tag between the wiki pages key:oneway
 and motorway
 .
The former states:
"Some tags (such as junction
=roundabout
, highway
=motorway
 and others)
imply oneway=yes and therefore the oneway tag is optional,
the latter states:
"These ways should all point direction of travel and be tagged with oneway
=yes"


What is the agreed standard, if any?

Volker
___
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-05-24 Thread Volker Schmidt
Path and trail are confusingly near in meaning.
The first Google search result  on
the difference between the meaning of path and trail says
*: *"*Pat**h** (is) a trail* for the use of, or worn by, pedestrians".
So path=trail does not work semantically anyway.

Creating a new path=trail tag will not do any good, as it will be
practically impossible to re-tag all the existing "highwa=path" ways that
fall into the new category. Which means the only effect it will have that
routers and renderers need to ad this as an additional possible tagging to
their already complicated evaluation

This proposal is not going to fly, unfortunately. As I said before the big
issue, at least in central Europe, is the massiv use of highway=path (with
the additional "designated" tags) for foot-cycleways. We will have to live
with that. The non-foot-cycle "paths" can be handled by surface, smootness,
and sac-scale tags.





On Sun, 24 May 2020 at 16:33, Daniel Westergren  wrote:

> Well said John. When we now have highway=path, we need a subtag.
>
> Question is, on what criteria would we differentiate a trail from another
> "path"? Groomed vs beaten may not be specific enough. But by using some
> combination of dictionary definitions of trail, in the sense of path, could
> we come up with some verifiable criteria for when such a subtag should be
> used? What I'm looking for is to differentiate forest and mountain paths
> from urban paths or groomed, smooth paths. When people have been clearing
> forest to make a path more visible and passable, that's still a beaten path
> to me.
>
> And yes, path=trail would probably need to be used for trails tagged as
> footway too, although I personally see footway as an urban path and always
> use path for a trail.
>
> Whatever subtag , we're still stuck with all those cases when highway=path
> is not combined with any other tag (whether it should be path=trail or
> anything else). How would we treat those? Obviously we can't take it for
> granted that those cases should have path=trail.
>
>
>1. Can we agree on whether or not we need a subtag like path=trail?
>Since it's probably too late for highway=trail, which by all means would
>have been the best option.
>2. If we introduce path=trail, what would be the criteria for when it
>should be used?
>3. What about all the cases of highway=path that don't have and will
>not have path=trail? Old or new. Some probably should (like when
>surface=ground), others should never have path=trail. It will still make it
>difficult to render those cases and for data consumers to choose a fallback
>value for those cases.
>4. What about edge cases? It may have been a beaten path that has been
>groomed with better surface material to make it more accessible for
>example. Would it still be considered for path=trail?
>
>
> /Daniel
>
> Den sön 24 maj 2020 kl 16:05 skrev John Willis via Tagging <
> tagging@openstreetmap.org>:
>
>> The sac=scale is a attribute of trails.
>>
>> Yet we do not explicitly state “this is a trail”
>>
>> We should have a path=trail subtag.
>>
>> The presence or absence of a sac_scale Tag shouldn’t mean it is a trail.
>>
>> Imagine we had no highway=track. That we dumped all tracks into
>> highway=service. That is what we are doing now with trails.
>>
>> Would you want to depend on the tracktype=* tag for denoting that it is,
>> in fact, a track? At least track type has “track” in the key name.
>> If someone didn’t set it, it would map like the parking lots and
>> alleyways in cities. Madness.
>>
>> Sac_scale is an arcane attribute for hiking nerds - it is great to have,
>> but shouldn’t be the tag that differentiates a hiking trail from a sidewalk
>> in OSM. That should have been a separate tag from day one, but we are now
>> stuck with the monstrosity that is path=.
>>
>> At least subkey it.
>>
>>
>> Javbw
>>
>> On May 24, 2020, at 10:03 AM, Andrew Harvey 
>> wrote:
>>
>> 
>>
>>
>> On Sun, 24 May 2020 at 07:42, John Willis via Tagging <
>> tagging@openstreetmap.org> wrote:
>>
>>> =path is such a horrible catch-all tag and one that is extremely
>>> entrenched - I am surprised no one has implemented a path=trail subtag,
>>> similar to sidewalk, so we can separate all the hiking trails and other
>>> “hiking” paths, and then apply different hiking limitations you wouldn’t
>>> expect to find on a sidewalk or playground way.
>>>
>>
>> Right now you can use
>> sac_scale=hiking,mountain_hiking,demanding_mountain_hiking to indicate if a
>> path is a hiking trail. Though you can't really currently say something is
>> not a hiking trail.
>>
>> On Sun, 24 May 2020 at 10:01, Kevin Kenny 
>> wrote:
>>
>>> On Sat, May 23, 2020 at 5:42 PM John Willis via Tagging
>>>  wrote:
>>> >
>>> > =path is such a horrible catch-all tag and one that is extremely
>>> entrenched - I am surprised no one has implemented a path=trail subtag,
>>> similar to sidewalk, so we can 

Re: [Tagging] track vs footway, cycleway, bridleway or path

2020-05-21 Thread Volker Schmidt
Please use full tagging and don't create implicit values after the fact.
We do have the width or est_width tags,tets use them, where they are needed.

On Thu, 21 May 2020 at 21:35, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
>
>
> May 21, 2020, 19:20 by miketh...@gmail.com:
>
> So are we saying highway=path/cycleway/footway implies width<3 (or some
> similar value)?
>
> Yes, but it may be larger. Especially busy cycleway, or cycleway on curve,
> or cycleway
> on a slope may be noticeably larger.
>
> There is also an old problem how large footway should be to qualify as a
> pedestrian road,
> with varied opinions.
> ___
> 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-05-21 Thread Volker Schmidt
I am not a fan of the confusing use of highway=path  for foot-cycleways and
narrow mountain hiking ways, but that is a fact in OSM, and we need to live
with that.

However I would like to underline that highway=cycleway or highway=path +
foot=designated + bicycle=designated do not necessarily imply the
suitability of the way for normal bicycles.. These tags only tell you about
he legal access of the way. Surface, smoothness, and width (or est_width),
together with the elevation profile (data that is not in OSM) are also
needed for bicycle routing..
For hiking paths you have in addition SAC-scale and MTB-scale.

Examples of unpaved cycleways in my city:
https://www.mapillary.com/map/im/Ezjn-npOmRSQ-dHkMztzl
  (cycleway)
https://www.mapillary.com/map/im/DWHevDzL7i9eQDYSNbvCJcg
 (foot-cycleway)
https://www.mapillary.com/map/im/lAnBsThrDjTxjhvfXhB0Yg (cycle lane)

The problem is guessing by routers in case of incomplete tagging. Just to
get myself an idea I checked:
My city shows 1533 ways tagged as cycleways and foot-cycleways, of which
91.7% with surface, 54.7% with smoothness, 52.1% with width
(This excludes all cycle lanes and a few cycleways that are not present as
separate ways in OSM)

Basically we have the instruments - let's use them instead of inventing new
tags.



On Thu, 21 May 2020 at 16:15, Adam Franco  wrote:

> For those who missed it, a related discussion was just had on this list
> about differentiating mountain-biking trails from cycleways.
> See the resulting proposal for path=mtb
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:path%3Dmtb and
> threads from April in Tagging:
> https://lists.openstreetmap.org/pipermail/tagging/2020-April/051864.html
>
> On Thu, May 21, 2020 at 8:51 AM Andy Townsend  wrote:
>
>>
>> On 21/05/2020 10:50, Mateusz Konieczny via Tagging wrote:
>>
>>
>>
>> Similarly anyone creating
>> highway=footway + danger="you will be shot" + "access=no" + foot=yes"
>> should probably switch to pickpocketing, telemarketing or other less
>> harmful activity.
>>
>> While "danger" isn't a much used tag (and I'm sure wasn't a serious
>> suggestion here - https://taginfo.openstreetmap.org/keys/danger#values
>> ), sometimes "foot=yes" is correct and other tags need to be taken into
>> account.  I've used the area around
>> https://www.openstreetmap.org/way/431056034 as an example of that
>> before.  Here "foot=yes" is correct - there is a legal right of access.  "
>> sac_scale
>> =demanding_alpine_hiking"
>> also makes sense here I think.
>>
>> I take Frederik's reference to Andy Allan's point about "a
>> multi-billion-dollar-revenue organisation that were rendering anything with
>> a highway tag the same as their most minor road style" but frankly there's
>> simply no solution to that - presumably "highway=dangerouspath" (to make up
>> a nonsensical value) or
>> https://taginfo.openstreetmap.org/tags/highway=via%20ferrata would still
>> get shown as a "road".
>>
>> Map styles need to be clear about what they're showing and what they're
>> not showing and people using maps need to be able to read maps so that they
>> understand what they're being told.  This isn't really a tagging issue,
>> unless OSM mappers aren't using appropriate other tags when they should
>> (sac_scale, trail_visibility, surface, etc.)
>>
>> Best Regards,
>>
>> Andy
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Recreational route relation roles

2020-05-21 Thread Volker Schmidt
Critically those things say there is a trail here, but don't say where the
> trail goes as part of a route, so in that case without knowing the exact
> route, I don't see how it can be marked out as a recreational route.
>
> A series of trail blazes or way marks tells me that I most likely on a
trail that someone has marked as a  hiking trail. If I persist and follow
the trail, finding more and more of these blazes I will, in most case
encounter a signpost  or guidepost that tells me more about the trail
(name, ref, destination, ...)
This leads me to what I really wanted to say:
Trail route relations (and cycling route relations) could or should (?)
include the guideposts, and for that purpose we need a role for these
nodes: role=guidepost
The only mention in the wiki is this one:
https://wiki.openstreetmap.org/wiki/DE:Wandern#In_die_Relation_aufnehmen

In Italy the Club Alpino Italiano has recently started a collaboration with
the OSM community (under the "roof" of the Italian Wikimedia association)
that aims at transferring the 50k km trail network of the Club into OSM.
Part of this is the use of hiking relations and the guideposts will be
inserted in the hiking route relations. Details are documented on the wiki
page CAI  (in Italian).

The new roles in the proposal do not bother me too much. I am not against
them, but I do not see any great benefit in having them. As an end.user, I
regularly plan (cycling) tours using various route planning tools (who
typically give preference to cycling routes), but in that context it does
not matter what role a particular part of relation has, the only important
thing is whether a way is part of a route or not.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Recreational route relation roles

2020-05-21 Thread Volker Schmidt
This wikipedia "Trail blazing" 
article (which takes trailblazed and wayarked as meaning the same thing),
has a nice picture collection of way markings.

On Thu, 21 May 2020 at 15:22, Andy Townsend  wrote:

> On 21/05/2020 13:48, Mateusz Konieczny via Tagging wrote:
>
>
>
>
> May 21, 2020, 14:17 by kevin.b.ke...@gmail.com:
>
> It's still tricky. Around here, few trails are actually signposted;
> some don't have a sign anywhere! They're marked with paint blazes in
> the woods, guideposts in the fields, and cairns above the tree line.
>
> Not a native speaker, but I thought that paint blazes,
> guideposts, cairns, signs, surface markings, special traffic signs,
> information boards, markings by cutting on trees, ribbons,
> wooden poles etc all may be used to signpost a trail.
>
> My 2p from England:
>
> I suspect it'd vary around the world but I'd certainly say "that trail is
> signposted" if all there was was a characteristic paint blaze that
> "everyone recognises" as matching a particular trail.
>
> 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] Proposal of new tag for technicality of trails for running

2020-05-18 Thread Volker Schmidt
There is at least one other scale: cai_scale
 which is
similar in concept to sac_scale,but is applied to hiking relations. It's
increasingly used in Italy.

On Mon, 18 May 2020 at 16:48, Daniel Westergren  wrote:

> Hi there,
>
> I would like to discuss the possibility of a new tag, trail_technicality,
> to be used on ways with highway=path.
>
> One way this can be used is aid in finding trails to run on and to get
> suggested routes with tools like Trail Router (www.trailrouter.com),
> Komoot (www.komoot.com) or Open Route Service (
> https://maps.openrouteservice.org/).
>
> *What tags are already available?*
> *sac_scale *is the obvious choice to determine trail difficulty. But it's
> geared towards mountain trails and I doubt it's being used much outside of
> mountain trails.
>
> *mtb:scale* is closer to what I'm proposing, but geared towards
> single-trail technicality for MTB, not for running (or hiking).
>
> Then there's *surface*, *width*, *trail_visibility*, *smoothness *(for
> wheeled vehicles) that can all be used to determine what kind of path it
> is, but they don't really tell anything about the technicality of
> single-trails.
>
> *How to use the tag?*
> It would only be used for single-trails, that is in ways with
> highway=path. I don't have a set suggestion of values, but I'm thinking
> something similar to mtb:scale, basically with runnability as the
> determining factor. It would obviously leave room for subjective judgement,
> just like smoothness and trail_visibility. But with image examples and
> clear factors describing each value it would still give a lot of useful
> information to route planners and renderers.
>
> Some factors to determine values: stability/softness of surface, obstacles
> (rocks, roots etc.), running rhythm (short ups/downs, sharp turns etc.) and
> attention required.
>
> *Use-cases*
> As mentioned, trail_technicality could be used together with other values
> in route planners and renderers, to suggest routes based on user preference
> (technical trails <-> road running), but also to roughly estimate running
> time (in addition to elevation/slopes).
>
>
> What do you think?
>
> /Daniel Westergren
> ___
> 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 - Dog hazard

2020-05-13 Thread Volker Schmidt
The hazard tagging has a problem, when you try to apply it.

A dog hazard is a hazard to people by dogs or is a hazard to dogs by
mountain lions or whatever.
In a different thread we are discussing dooring hazard.
I would love to see a more general approach to hazard and danger tagging,
but do not have a proposal ready.
I would love to be able to tag hazards of all kinds mainly for cyclists in
my case.
One of them was hazard by free running dog packs.



Virus-free.
www.avast.com

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

On Wed, 13 May 2020 at 13:14, ael  wrote:

> On Tue, May 12, 2020 at 03:26:07PM -0700, Tod Fitch wrote:
> > dog=yes|no|leashed already exists for a totally different semantic
> (letting dog owners know if their pet is allowed).
> >
> > If this goes forward I would prefer reversing thing and make it
> hazard=dog. That would also allow other types of hazards to be mapped.
> >
> > Checking taginfo it seems hazard=* [1] is in use. Why not go with it?
>
> You beat me to it. The existing hazard tag is the obvious choice which I
> use quite often. Although it does not seem to be well supported by data
> consumers. I have used it in Cornwall to flag open mine shafts, and in
> one case to warn of dangerous (illegal) dogs on a right of way through a
> farmyard.
>
> 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] Tag:amenity=motorcycle_taxi not approved

2020-05-12 Thread Volker Schmidt
In this context:
I have just realised that at Venice Aiport there are  (at least) the
following services and corresponding counters and stop positions.

busses to various destinations. They depart from a bus-stop area, but have
different counters according to the bus company
water busses (separate counter, I believe)
taxi (cabs) (you just go and pick them up)
shuttle minibuses (operated by a taxi company with Internet and phone
booking - I am not aware of a counter in the airport)
water taxies

And I am sure there are more services.

Add to add to the confusion on the water: looking for a tag for water taxi,
I consulted the EN Wikipedia article for "water taxi", and I find the
English term "water taxi" includes what I would call water busses, but in
Venice that is certainly wrong - they are completely different transport
methods: motoscafo are water taxicabs on wayter  and vaporetto are
scheduled buses on water.
Another thing that EN Wikipedia tells me is that taxi=taxicab in English.

Luckily enough there are no gondolas venturing out to the Airport, they are
a kind of human-powered taxis on water (or at least they once had that
function).

Bottom line: more we look into this taxi business more interesting and
confusing it gets.





On Tue, 12 May 2020 at 15:10, Paul Allen  wrote:

> On Tue, 12 May 2020 at 14:01, Martin Koppenhoefer 
> wrote:
>
>>
>> if they expect both to have the same main tag, yes. After a while when
>> they have had their unpleasant experience and keep using crowd sourced
>> maps, they will be more cautious, I agree.
>>
>
> Or, after they have had an unpleasant experience, they will stop using
> crowd-
> sourced maps.
>
> --
> 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] Doorzone bicycle lanes

2020-05-06 Thread Volker Schmidt
My thinking was more general, more along the lines of these old proposals
Talk:Proposed features/hazard
<https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/hazard>
i.e. a structured tagging appraoch for hazards of all types.
For my taste "dooring" is one type of many that may be of interest to
cyclists (incidently: the "dooring" hazard is a "cyclists-passing-close-by"
hazard for motorists)
I want to have easy means to find all hazards for cyclists an a given
route, or also I want a router to be able to take into account the hazards
when selecting a route.
Maybe we should start out with a list of possible hazard types, to get a
better feeling on how we should approach this.

On Wed, 6 May 2020 at 13:20,  wrote:

> "highway=path,footway,cycleway is in a doorzone
> bicycle:doorzone=yes (the bicycle lane of the path,footway,cycleway is in
> a doorzone) https://www.mapillary.com/map/im/ewtPBxYM_289cWusHEWytw
> <https://deref-web-02.de/mail/client/tX1wLGYFGQI/dereferrer/?redirectUrl=https%3A%2F%2Fwww.mapillary.com%2Fmap%2Fim%2FewtPBxYM_289cWusHEWytw>
> "
>
> I agree with that, but then note that for "justice" we would need a
> foot:doorzone=yes, too, because when a sidewalk is in the parking car's
> doorzone (I think most sidewalks next to parking:lane=parallel are), there
> is hazard for pedestrians, too. It might be not soo dangerus because
> pedestrians have much lower speed than cyclists often have, but if we want
> to tag that hazard I think we would have to affect both, foot and bicycle.
>
>
> *Gesendet:* Dienstag, 05. Mai 2020 um 04:56 Uhr
> *Von:* "Andrew Harvey" 
> *An:* "Tag discussion, strategy and related tools" <
> tagging@openstreetmap.org>
> *Betreff:* Re: [Tagging] Doorzone bicycle lanes
> On Tue, 5 May 2020 at 02:35, Jan Michel  wrote:
>
>> On 03.05.20 19:16, Volker Schmidt wrote:
>> > I would advocate a more generic approach that remains open to other
>> > types of hazards (there are many, unfortunately).
>> > A generic
>> >
>> hazard:bicycle=yes|dooring|pedestrians_on_cycleway|dangerous_exit|whatever
>>
>> I agree, but I would rather use
>> cycleway:(left|right|both|):hazard
>> 'hazard:bicycle' suggests that it is an hazard to all bicycles, but it's
>> more like an hazard that is a "feature" of the cycleway. Everybody close
>> to the cycleway is part of the hazard (whether active or passive) but
>> bicycles in other places of the road are not affected.
>
>
> On Tue, 5 May 2020 at 04:33, Volker Schmidt  wrote:
>
>> You are right that in case of cycling infrastructure tagged on the road
>> (like typically cycling lanes) we need a way to indicate to which part of
>> the road it refers, in addition to the type of haxard.
>>
>
> Agree with Volker here.
>
> cycleway:both:hazard becomes an issue when there are multiple hazards that
> apply, so "doorzone" should be part of the key not the value.
>
> I originally proposed cycleway:lane:doorzone=yes but then since seeing
> https://www.mapillary.com/map/im/ewtPBxYM_289cWusHEWytw changed it to
> cycleway:doorzone=yes, but based on what Volker has said about indicating
> which part of the road it applies to maybe after all:
>
> cycleway:lane:doorzone=yes (both sides of the road have a
> doorzone cyclelane)
> https://www.mapillary.com/map/im/MXuDWHZY_R9UkGcOk0FZUw
> cycleway:lane:left:doorzone=yes (left side of the road has a doorzone
> cyclelane)
> cycleway:lane:right:doorzone=yes
>
> highway=path,footway,cycleway is in a doorzone
> bicycle:doorzone=yes (the bicycle lane of the path,footway,cycleway is in
> a doorzone) https://www.mapillary.com/map/im/ewtPBxYM_289cWusHEWytw
>
> The third scenario for dooring is just a regular road with no bicycle
> infrastructure, but parked cars can still lead to dooring eg
> https://www.mapillary.com/map/im/6YlYnuZPdlziwUsF1m7yWA I guess in that
> case where there is no bicycle infrastructure the dooring hazard should be
> determined by a parking:lane:parallel=* and some kind of parking:lane
> buffer tag?
>
> Are there any other scenarios where dooring is a hazard?
> ___ 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


  1   2   3   4   5   6   7   >