Re: [Tagging] [RFC] Feature proposal - Tag:natural=wadi

[Volker Schmidt]

The wadies I have encountered in the desert regions of the western US
states seem all to have ephemeral borders. Every time water flows down the
"border" changes. Also the center line in most cases is difficult to
determine.
BTW many of thr rivers here in Northern Italy that have their springs in
the mountains and their very wide riverbeds in the nearly plains in the
wider Po valley. The material here is pebble,  and not sand ad in the
desert-set wadies, but zhe variability of the shape of the riverbed, and of
the water course are similar. They are not called wadi, and I don't know
the proper term.

On Sun, 26 May 2024, 17:11 Kai Johnson,  wrote:

> > On 25 May 2024, at 22:38:20, Peter Elderson  wrote:
> >
> > I like this proposal very much.
>
> Thank you for the review and the comments.
>
> > One thing: by its nature, other naturals will overlap with natural=wadi,
> right? Any thoughts on that?
>
> I think that's a fairly common thing with features tagged with natural=*
> and
> we have some reasonable ways to handle it.
>
> First, where natural features overlap, their boundaries don't always
> coincide. In this case, the features can and should be mapped as separate
> elements. Mapping natural=scrub in an arid environment is a good example.
> There may be scrub in a wadi, but if so, there is likely also scrub in the
> areas outside the wadi's banks. So, the natural=scrub area need not share
> the same geometry as the natural=wadi area.
>
> Second, if the boundaries of the natural features do coincide precisely,
> the
> natural tag can have multiple values or the features can be mapped as
> separate ways with shared nodes. I don't know that this would be common
> when
> mapping wadis, but as a separate example, we use coincident ways when
> mapping sea stacks where the natural=coastline and natural=bare_rock
> polygons coincide but the two tags cannot be placed on the same element.
>
> Third, one of the defining characteristics of a wadi is a bed of
> unconsolidated and often poorly sorted alluvium. That is, sand, gravel,
> cobble, boulders, or the like. This can be mapped using surface=* in
> combination with the natural=wadi tag.
>
> > And, you say you can map it as a node. That seems a bit strange, because
> it's such an elongated feature.
>
> I don't think that's the preferred way to map a wadi, but just as
> natural=valley can be mapped as a node (per the wiki and established
> usage),
> it could be acceptable for natural=wadi.  As with a valley, even though the
> banks of the wadi may be distinct, the start and end of the wadi may not
> be.
> Rather than making an arbitrary decision about the boundaries, a mapper may
> prefer to place a node at a central location to map the wadi.
>
> To add to that, many wadis have well-established names and are important
> landmarks. So, placing the name on the map with a node is valuable even if
> the boundaries of the wadi have not been mapped.
>
> -Kai
>
>
> ___
> 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] [RFC] Feature Proposal - Deprecating demolished railway tags

[Volker Schmidt]

I put a comment in the discussion page, which is a pointer to the outline
of a counter-proposal.
Please have a look.
Thank you

On Mon, 26 Feb 2024 at 05:31, Ewrt1 OSM  wrote:

> This proposal aims to deprecate all Demolished Railway tags.
>
> https://wiki.openstreetmap.org/wiki/Proposal:Deprecating_demolished_railway_tags
> Please discuss this proposal on its Wiki Talk page.
> ___
> 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] tagging "loose" paving stones

[Volker Schmidt]

Sett around here looks very similar. It wiggles when I am on a bike, and
it's set in sand.

On Sun, 18 Feb 2024 at 00:35, Yves via Tagging 
wrote:

> Interesting, this could also be used to let water in the ground in order
> not to cause subsidence by drying out the underground. Maybe we shouldn't
> map the intent, but be more descriptive.
> Technically, it is possibly just sett, but loose?
> Yves
>
>
> Le 17 février 2024 22:59:08 GMT+01:00, Anne-Karoline Distel via Tagging <
> tagging@openstreetmap.org> a écrit :
>
>> I asked a local Green politician, and it's apparently called "subsidence
>> paving",  invented in earthquake zones in northern Italy.
>> On 17/02/2024 17:46, Åbn wrote:
>>
>> I think you should provide a picture.
>>
>>
>> On February 17, 2024 5:19:06 PM UTC, Anne-Karoline Distel via Tagging
>>   wrote:
>>
>>> I'm not sure I'm understanding the differences between surface=sett and
>>> surface=paved or if what I'm trying to map is covered by either. Where I
>>> live, there are some streets that are paved, but the stones aren't set
>>> firmly, so they wobble a bit when you drive/ cycle over them. It is
>>> perfectly safe, but it allows rainwater to drain quicker, at least I
>>> think that is the reason for this type of paving. It sounds a bit like a
>>> xylophone (well, lithophone, I guess), when going over them.
>>>
>>> Considering climate change and the higher likelihood of flooding etc, it
>>> would be important to map the difference between paved streets that
>>> don't allow for quick drainage and these loosely paved streets. There is
>>> probably some technical term for it.
>>>
>>> So, in short: Do we have a tagging scheme for those or not?
>>>
>>>
>>> Anne
>>> --
>>> 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] Proposal: Use description instead of name for route relations

[Volker Schmidt]

Could you give some more examples to illustrate what the problem is that
you want to resolve.


On Sun, 8 Oct 2023, 00:23 Kevin Kenny,  wrote:

>
>
> On Sat, Oct 7, 2023 at 4:50 PM Andrew Hain 
> wrote:
>
>> I have started a new proposal: that the name tag should be restricted to
>> the same meaning for route relations that it has on other elements and that
>> the description tag should be used otherwise.
>>
>
> The proposal is unclear and appears to deprecate route and way names of a
> form that are common around here for what I consider to be good reasons.
> (In any case, 'description' appears to be an inappropriate tag for whatever
> it is you are proposing.) More details on the talk page.
> --
> 73 de ke9tv/2, Kevin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Route names being applied to tracks/paths

[Volker Schmidt]

Thinking about why people may be doing this, and based on recent experience:
You come across a bicycle or hiking route sign "on the ground", but have no
idea what relation it is referring to. So you tag it as name, just for the
time being.

Il giorno sab 31 dic 2022 alle ore 18:50 Anne- Karoline Distel <
annekadis...@web.de> ha scritto:

> +1
>
> Anne
>
> --
> Sent from my Android phone with WEB.DE Mail. Please excuse my brevity.
> On 30/12/2022, 20:59 Peter Neale via Tagging 
> wrote:
>
>> +1
>>
>> PeterPan99
>>
>> Sent from Yahoo Mail on Android
>> 
>>
>> On Fri, 30 Dec 2022 at 20:02, Dave F via Tagging
>>  wrote:
>> On 29/12/2022 09:47, Warin wrote:
>> > Hi,
>> >
>> > I think the 'names' should be removed from these 'unnamed' things
>> > ..the 'name' is the name of the route not the individual tracks/paths
>> > some of which existed before some routes were created.
>>
>> +1
>>
>> DaveF
>>
>>
>> ___
>> 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] Tagging for the renderer : One-way "flow" bicycle tracks

[Volker Schmidt]

The problem is that we frequently have cycleways or food-cycle-ways that
are legally oneway for cyclists, but not for pedestrians. They are tagged
"oneway=yes". I agree we need a oneway tag for pedestrians, but it cannot
be a simple oneway=yes because that is already in use with a different
meaning, i.e. "oneway for vehicles".

On Mon, 11 Sep 2023, 08:03 Mateusz Konieczny via Tagging, <
tagging@openstreetmap.org> wrote:

>
>
>
> Sep 10, 2023, 23:37 by graemefi...@gmail.com:
>
>
> On Mon, 11 Sept 2023 at 01:25, Niels Elgaard Larsen 
> wrote:
>
> Volker Schmidt:
> > Be careful: oneway=* is a legal access tag, only valid for vehicles, not
> for pedestrians.
>
>
> We do have a lot of highway=footway,oneway=yes
>
>
> Also know of suspended Tree Walk walkways e.g.
> https://www.openstreetmap.org/#map=19/-28.23281/153.13822 which are
> signposted as oneway, & tagged the same
>
> And there are oneway hiking trails where it is a legal restriction.
>
> ___
> 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] Tagging for the renderer : One-way "flow" bicycle tracks

[Volker Schmidt]

Be careful: oneway=* is a legal access tag, only valid for vehicles, not
for pedestrians.

On Sat, 9 Sep 2023, 07:05 Andrew Harvey,  wrote:

> I have previously proposed the tag path=mtb
> https://wiki.openstreetmap.org/wiki/Proposal:Tag:path%3Dmtb as a way to
> say it's a purpose built mountain biking track (which if it has features
> like jumps, skinnies, berms etc would make it such). Unfortunately the
> proposal could not gain a consistent consensus about the best way to tag
> purpose built mountain biking tracks/trails and didn't develop further, so
> while it won't impact rendering, you can still use this proposed tag.
>
> On Sat, 9 Sept 2023 at 03:09, Bryce Nesbitt  wrote:
>
>>
>> I recently went on a hike, guided only by OSMAnd.  We ended up planning a
>> route
>> that took us uphill on what turned out to be a long series of one way 
>> downhill
>> mountain bike flow tracks.
>>
>> I have no problem with the flow track: just had it been clearly
>> delineated we would have planned a different route more suited to hiking.
>> But I was left without clear tagging ideas.
>>
>>
>>
>>
>> One of the trails was
>> https://www.openstreetmap.org/way/593945914#map=19/37.99250/-122.50667
>> highway  path
>> 
>> horse  no
>> name  Bunny
>> oneway:bicycle
>>  yes
>> 
>> surface  dirt
>> With a
>> clear direction, as it has jumps that can only be completed in a single
>> direction, and is all but impossible to cycle the "wrong way" on.
>>
>>
>>
>>
>> Is this trail tagged the best that can be?
>>
>> Is there a way to better hint to rendering that this should look
>> different from a "standard" hiking trail, perhaps tagged:
>> highway  path
>> 
>> name Hiking Trail
>> surface dirt
>> bicycle
>> 
>> permissive
>>
>>
>> I see that even *OpenCyclemap *does not draw directional arrows on the
>> "Bunny" trail or other oneway:bicycle=yes routes.
>>
>> ___
>> 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] Tagging for the renderer : One-way "flow" bicycle tracks

[Volker Schmidt]

This is a frequent tagging problem.
bicycle=* , oneway=* , and oneway/bicycle=* are tags describing the legal
access status.  So does highway=path (it implies, in many jurisdictions,
foot=yes and bicycle=yes).

There is a way to indicate a route is a MTB route, and also that such route
is technically unidirectional. If a highway=path is difficult to hike due
to the mtb jumping steps one could handle this by using sac_scale grading,
or by tagging the entire route with cai_scale.

On Fri, 8 Sep 2023, 19:08 Bryce Nesbitt,  wrote:

>
> I recently went on a hike, guided only by OSMAnd.  We ended up planning a
> route
> that took us uphill on what turned out to be a long series of one way downhill
> mountain bike flow tracks.
>
> I have no problem with the flow track: just had it been clearly
> delineated we would have planned a different route more suited to hiking.
> But I was left without clear tagging ideas.
>
>
>
>
> One of the trails was
> https://www.openstreetmap.org/way/593945914#map=19/37.99250/-122.50667
> highway  path
> 
> horse  no
> name  Bunny
> oneway:bicycle
>  yes
> 
> surface  dirt
> With a
> clear direction, as it has jumps that can only be completed in a single
> direction, and is all but impossible to cycle the "wrong way" on.
>
>
>
>
> Is this trail tagged the best that can be?
>
> Is there a way to better hint to rendering that this should look different
> from a "standard" hiking trail, perhaps tagged:
> highway  path
> 
> name Hiking Trail
> surface dirt
> bicycle
> 
> permissive
>
>
> I see that even *OpenCyclemap *does not draw directional arrows on the
> "Bunny" trail or other oneway:bicycle=yes routes.
>
> ___
> 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] Streets with gradually increasing widths

[Volker Schmidt]

maxwidth is a legal limitation, typically signposted.

width is used on barriers as physical width of the passage.

maxwidth:physical is sometimes used to indicate the same concept on roads.

width is used to indicate the physical width of the carriageway. It is
typically used to indicate that a vehicle with that width is likely to pass
the entire length of the way.

I am sceptical about the idea of trying to tag the very specific and rare
case that the width of a carriageway changes linearly from width1 at the
beginning of the way to width2 at the end of the way. What is realistic is
that roads have irregular shapes, typically in the context of historic
towns. In those case it may make sense to model the carriageway with
area:highway=* .



On Fri, 18 Aug 2023 at 20:24, Niels Elgaard Larsen  wrote:

> _ _:
> > Node is, I think the best solution, but it also require some changes to
> current
> > editors: if you move a way, you didn't always look on each of the moved
> nodes if
> > there is a tag width=* . So editors could automatically handle that by
> showing a
> > warning like when you move a big number of points or when you move an
> object outside
> > of your view, saying "Hey ! You are moving a tag with a width attribute,
> are you sure
> > this attribute will be still valid ?" or something like that...
> >
> > This information could be crucial for [oversize load]
> > (https://en.m.wikipedia.org/wiki/Oversize_load
> > ) and it's really cool
> to see some
> > people interested in mapping this !
> >
> > After all, I don't think that routing is going to happen immediately for
> these types
> > of transport, but it's by adding data that can be fed into these
> calculators that
> > they will appear.
>
>
> It does happen that width is used. I found out the hard way this summer.
>
> I was driving a van and had put the width  of the vehicle in OsmAnd as
> 2.05 m.
> Going to Oude Vos parking lot I was routed through some very small and
> narrow roads
> and ended up in a dead end.
>
> Later I found out that the problem was that
> https://www.openstreetmap.org/way/6525244
> had maxwidth=2.
> I believe that OsmAnd treat "width" the same way.
>
> I have checked with overpass turbo and found a lot of width and maxwidth
> values that
> look suspicious.
>
> We should be very careful not to tag width values that are too
> conservative.
> Even if the asphalt has eroded on a short section of a road so that it is
> e.g. 1.9 m
> wide, a 2.05m wide car could probably still pass.
>
>
> If there is a port, gate or building passage that it 1.9m wide, it is a
> different
> matter. But then the 2.05m width of my car is excluding side mirrors.
> Including
> mirrors it is 2.3 m.
>
>
> --
> Niels Elgaard Larsen
>
>
> ___
> 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] Streets with gradually increasing widths

[Volker Schmidt]

Two points.

(1) Do not redefine width as medium width.

(2) Do not propose tagging of ways that does not survive splitting the way

On Tue, 15 Aug 2023, 18:11 Sebastian Gürtler, 
wrote:

>
> Am 15.08.23 um 14:56 schrieb Greg Troxel:
>
> >> If there are no objections, I'lpl add a section about the above to the
> wiki.
> > I strongly object, because a data router that uses just width will
> > conclude that the way is usable when it is not.   It is a basic
> > principle of tagging that data consumers that read the basic tags rather
> > than the more complicated tags that are less used should not be misled.
> Agree completely.
> > If you want to keep "width=" as the minimum width over the way, and then
> > add the other things, then I don't see that as really helpful in the
> > grand scheme, but I don't see it as harmful.  I expect very few
> > circumstances where it is appropriate, almost no one to tag them, and
> > almost no routers to implement it.
>
> I would add: I expect many situations where data will be destroyed
> afterwards: If ways are split for whatever reason, this would result in
> two ways with identical start and end values describing another
> situation. (e.g if you have start=2m end=3m you will get the same
> section as 2m-3m/2m-3m). You couldn't split a way without measuring the
> width at the splitting point - as a mapper you would have to delete the
> width:start/end tags if you split a way without knowing the width on
> this point, but no one would dare or be aware of it.
>
> => "... I expect many [or at the moment: all] editors that would destroy
> the data."
>
> Sebastian
>
> ___
> 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] navigational aid relation

[Volker Schmidt]

I read this discussion with interest (as end user) and ignorance
router-wise.

Some unsorted early-morning thoughts on this subject:

When trying to reach a destination that is defined by a complete address
(city, street name, house number or name) is that the last meters of the
route are, potentially,  much different for a
ciclist/pedestrian/car-driver/delivery-van/ambulance/...
One of the many problems is that we would need for any given address a
navigation aid for each of the potential means of transport.

I have come across one aspect of this when I noticed that Amazon Logistics
staff systematically changed access tags on driveways around here from
"private" to "yes" (or similar).

Micromapping correctly the last meters for all the different means of
transport is the correct theoretical solution. But is it practical ?

Navigation aid?
In Italy the house numbers are assigned to the pedestrian entrance point
for the house/business/shop/airport/...
Take an address in a pedestrian area within a limited-access zone in my
city.
Take car access. During the night the car access for drop-down is somewhere
in walking distance outside the pedestrian area, but within the
limited-traffic zone (which is not active at night). During the day it is
most likely a park-and-ride location outside the city centre.

You can construct many more examples.

Volker






On Sat, 17 Jun 2023, 00:16 Minh Nguyen, 
wrote:

> Vào lúc 11:48 2023-06-15, Sarah Hoffmann via Tagging đã viết:
> > On Thu, Jun 15, 2023 at 09:38:44AM -0700, Minh Nguyen wrote:
> >> I neglected to mention another common heuristic: the geocoder can
> >> automatically bias the address point toward the street named in
> addr:street
> >> when coming up with a navigable point. The Mapbox Geocoding API is an
> >> example of a geocoder that does this [1][2], though unfortunately
> neither
> >> Nominatim nor Pelias has a similar feature so far.
> >
> > You need to remember that routers are only one kind of client of
> > Geocoders and certainly not the most important by far. While a nice
> > gimmick, I certainly wouldn't consider it a main task of a geocoder to
> > return a routeable point. The main task is to return the place/object you
> > were searching for. In that sense, the root of the issue is that
> > routers usually underspecify their search query. If the query is
> > 'airport Frankfurt', then the airport is what the geocoder returns. One
> can't
> > expect the geocoder to determine that what you actually wanted is the
> > street closest to the main entrance or the parking or the main bus stop.
> > 'parking near airport frankfurt' does yield results although we'd have
> > to do something about priority ordering.
>
> To be clear, all this talk about "navigable points" is about something
> that would supplement, not replace, the centroid coordinate that a
> geocoder already returns. If an end user searches for "airport
> Frankfurt", what Nominatim returns is quite sufficient for centering the
> map on the airfield. However, nowadays, the user also expects to see a
> row of buttons for navigating to a specific terminal, parking lot, or
> tram stop. This was not the case several years ago, but all you have to
> do is look at the most popular navigation applications to see why this
> topic keeps coming up.
>
> >> Then again, none of this complexity is necessary if OSM has a publicly
> >> accessible driveway or footpath leading right up to the building. A
> router
> >> should consider that driveway or footpath to be part of the most direct
> >> route.
> >
> > Exactly. It would be kind of counter-productive to add all this
> > functionality to a geocoder. A good router has all the right
> > data structures to make an informed decision about the navigation start
> point
> > and also the information about mode of transport etc. A geocoder's
> > data structures are rather unsuitable to solve these examples.
> >
> > The initial examples of Florian are quite telling in that way. The
> > closest road to
> >
> https://osm.zz.de/dbview/?db=addresses-nrw&layer=namemismatch#51.98796,8.57338,17z
> > would in fact be the service way right next to the buildings. The fault
> > is with the router who does not include non-accessible roads to
> > determine the access and thus finds the wrong road. If it would create a
> > full routing network that includes inaccessible service roads and
> footways,
> > it would be able to make the right decision and bring the car to the
> gate.
>
> I agree that routers should consider inaccessible service roads more
> than they do now. However, this would not be a panacea. For one thing,
> if the router finds the nearest inaccessible service road to an airport
> centroid, more often than not, it will be along a vehicle service road
> (VSR) for ground support equipment, surrounded by taxiways or even runways.
>
> Nominatim returns a centroid for the San Francisco International Airport
> that's about 80 meters from a VSR used only by airfield maintenan

Re: [Tagging] road accident memorials

[Volker Schmidt]

In South America wayside crosses with artificial flowers and, often, a
small mound, are very frequent. All the ones I looked at, were memorials
for road accident victims.

On Mon, 12 Jun 2023, 09:27 Marc_marc,  wrote:

> Le 11.06.23 à 13:29, Anne-Karoline Distel a écrit :
> > https://www.openstreetmap.org/node/10967549672
> >
> > subject=Sandy or subject=Sandy the dog or subject=pet?
>
> I consider subject=* to describe a category: if the dog is well enough
> known, I'll use subject=Sandy (and probably create a wikidata for it one
> day)
> if it's a dog that's only important to its owner, subject=dog seems
> more interesting to me
> but I hear that some would like Sandy is a dog which is a mammal
> which is an animal etc.
> for me it's not very useful information in osm, it's more a
> classification for wikidata
>
> > Maybe memorial:animal=dog would be an option.
>
> namespaces are used to avoid conflicts between 2 innfos with
> the same key (e.g. the name of a highway=* and the name of the bridge),
> so one of the 2 is prefixed with the namespace (e.g. bridge:name).
> here I can't see what conflict there could be, there are no other
> animal=* to put on the object
> so adding prefixes makes no sense
> likewise animal seems to me to be an information and not a key
> whose value provides information, which is why it seems preferable
> to me to have =animal
>
>
>
> ___
> 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] Area of young trees - saplings

[Volker Schmidt]

https://wiki.openstreetmap.org/wiki/Proposal:Plant_nursery
(approved)

On Wed, 17 May 2023 at 10:08, Anne- Karoline Distel 
wrote:

> Landuse=forest plus start_date then maybe? That would imply their age.
>
> --
> Sent from my Android phone with WEB.DE Mail. Please excuse my brevity.
> On 16/05/2023, 15:38 Dave F  wrote:
>
>> That appears to be for commercial purposes.
>> These samplings are 'out in the wild' planted in a publicly accessible
>> field.
>>
>> Cheers
>> DaveF
>>
>> On 16/05/2023 15:27, Anne- Karoline Distel wrote:
>>
>> A tree nursery? I think there's a tag for it.
>> My phone won't open the wiki right now, but maybe that helps already.
>>
>> Anne
>>
>> --
>> Sent from my Android phone with WEB.DE Mail. Please excuse my brevity.
>> On 16/05/2023, 13:49 Dave F via Tagging 
>>  wrote:
>>>
>>> Is there a tag for areas where you trees are planted? Too small to be
>>> self supporting they're often individually attached to a pole & encased
>>> in a protective tube.
>>>
>>> natural=wood seems inappropriate, as does scrub.
>>>
>>> I thought 'saplings' would be suitable, but taginfo return none
>>>
>>> DaveF
>>>
>>> ___
>>> 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] Tagging type of ownership of a road

[Volker Schmidt]

Ownership is not relevant if you think in terms of fixmystreet..
Just two extreme examples.

   - The Italian Motorway network is owned by the Italian via a
   state-majority public company, and operated by several different private or
   state-owned companies that to all effects own specific parts of the
   network. They take the road toll and do all the maintenance.
   - I lived for a couple of years in city (in the US) The street was
   property of the city, the drainage system was theirs, but I had to clean
   the street in front of the house up to the middle from the leaves falling
   from the trees that the city had planted. If the drainage does not work,
   who is the operator or owner?


Il giorno ven 14 apr 2023 alle ore 09:36 Jens Glad Balchen via Tagging <
tagging@openstreetmap.org> ha scritto:

> On 14.04.2023 09:13, Peter Neale wrote:
>
> Well, to me, "type of ownership" suggests values such as "freehold";
> "leasehold"; "rented", which I _don't_ think is what is intended.
>
>
> I agree that "type of" is ambiguous, but the same applies to "ownership".
> Neither is fully understood by just reading the subject. The point was to
> differentiate from tagging the identity of the owner.
>
> The wiki page on ownership=* refers to the "type of organization", so I
> guess we'll just have to live with the ambiguity and read the entire text
> so we can figure out what dimension, aspect, property, identity,
> classification, or category "type" refers to. :)
>
> Cheers,
>
> Jens
> ___
> 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] tagging the diameter of a mini-roundabout

[Volker Schmidt]

Yes, Phil, I overlooked your last point (and I have UK driving license).
In Italy there are no separate rules or road signs for traversable
roundabouts, hence no interdiction of U-turns. That needs addressing.
Country-specific defaults?

"My" traversable roundabout is in fact often used for U-turns, but only by
shorter vehicles. The articulated trucks I observe, are turning left, not
U-turning, on a four-way layout.



On Thu, 2 Feb 2023, 10:04 Philip Barnes,  wrote:

> A mini roundabout often doesn't usually have a diameter. Most are jus
> normal junctions which have been made mini-roundabouts to set a priority.
>
> So in terms of large vehicles it is the same problem as any other
> junctions, whether they can turn left or right.
>
> In the UK, U turns are prohibited at mini-roundabouts, which I would have
> thought would be the main usecase for a diameter.
>
> Phil (trigpoint)
>
> On 2 February 2023 03:31:39 GMT, Matija Nalis <
> mnalis-openstreetmapl...@voyager.hr> wrote:
>>
>> If the actual issue is that HGV cannot pass some road, why not simply mark 
>> it as
>> `hgv=no`? Besides being simple, it has the additional advantage that routers
>> will actually already use it and direct HGVs somewhere where they can 
>> actually
>> pass.
>>
>> Or if some lenghts of HGVs can pass, but others not, then maxlength=*
>> or maxlength:hgv=* or some of the other alternatives from
>> https://wiki.openstreetmap.org/wiki/Key:maxlength ?
>>
>> On Wed, 25 Jan 2023 21:25:32 +0100, Volker Schmidt  wrote:
>>
>>>  I see that I was not precise with my question: I am after a way to tag the
>>>  overall diameter of the round surface composed of the mini-roundabout road
>>>  surface plus the traversable central part. This is an important measure for
>>>  trucks. I happen to live near one of these with an outer diameter of 12 m,
>>>  and that attracts regularly articulated lorries like the cheese attracts
>>>  flies. This triggered the question.
>>>
>>>  Il giorno mer 25 gen 2023 alle ore 19:10 Peter Neale via Tagging <
>>>  tagging@openstreetmap.org> ha scritto:
>>>
>>>  According to the Wiki (with which I happen to agree), a mini-roundabout is
>>>>  defined as:
>>>>
>>>>  "...a special type of roundabout in which the middle can be traversed
>>>>  <https://wiki.openstreetmap.org/wiki/Traversable> by vehicles, and is
>>>>  typically used where there is only limited space available. Road traffic
>>>>  flows in one direction around a point in the middle and the traffic in the
>>>>  roundabout has right-of-way. The middle of a mini-roundabout is usually
>>>>  only a painted circle, but there might also be a low, fully traversable
>>>>  (mountable) dome or island."
>>>>
>>>>  As it is traversable, does it really have a diameter?  Or, if there is a
>>>>  painted circle (are traversable domed area) on the ground, perhaps that 
>>>> has
>>>>  a diameter, but does it matter to any prospective map user?
>>>>
>>>>  Regards,
>>>>  Peter
>>>>
>>>>  Peter Neale
>>>>  t: 01908 309666
>>>>  m: 07968 341930
>>>>
>>>>
>>>>  On Wednesday, 25 January 2023 at 17:53:55 GMT, Volker Schmidt <
>>>>  vosc...@gmail.com> wrote:
>>>>
>>>>
>>>>  Is there an established way to tag the diameter of a mini-roundabout?
>>>>
>>>>  We have the tag diameter, but I could not find it applied to
>>>>  mini-roundabouts.
>>>> --
>>>>  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] tagging the diameter of a mini-roundabout

[Volker Schmidt]

I do have a typical traversable roundabout close by. hgv=no is not correct,
there are commercial activities around that need hgv access. The roads are
adequate for that

The angle between incoming roads is not a suitabla measure, as the
traversable roundabout has a circular "belly", providing additional space
for turning longer vehicles. The diameter of this circular turning space in
this specific location is 12m. The maximum length for articulated trucks is
generally 16m in Italy.

The probable reason why I see relatively frequent problems there, is that
the junction is represented on big-G maps as a normal roundabout (they do
not have a specific way to represent traversable roundabouts) and the size
of this roundabout is a bit large on their map. This junction is on a route
to reach a company that repairs agricultaral machinery, that arrives on
long flat-bed articulated trucks.

Coming back to my original question: could we agree that:

1) highway=mini_roundabout outside the UK is used to describe traversable
roundabouts, provided the traffic rules are the same as on untraversable
roundabouts
2) diameter= x m can be used to describe the available turning area
diameter, if it is roughly circular.
3) we will look into defining an alternative way to describe the
traversable roundabout area in a way similar to bridge or road geometry
(and let us discuss that approach in a new thread)

Volker



On Thu, 2 Feb 2023, 09:58 Mark Reidel,  wrote:

> On Thu, 2023-02-02 at 04:31 +0100, Matija Nalis wrote:
> > If the actual issue is that HGV cannot pass some road, why not simply
> > mark it as `hgv=no`? Besides being simple, it has the additional
> > advantage that routers will actually already use it and direct HGVs
> > somewhere where they can actually pass.
>
> Adding an access-tag like maxlength isn't the correct way to tackle
> this, because:
> a) there is no *legal* restriction that disallows a vehicle of a
> certain length
> b) it's not only about the length, but mostly about the turning radius
> of trucks, which is not necessarily related to their length, especially
> when they have more than 1 trailer.
>
> But overall, I don't see how this is of special importance for a mini
> roundabout with a traversable surface, it being very much identical to
> a regular crossing when you are allowed to go over the inner circle.
> Shouldn't the angle between the two roads the vehicle wants to pass be
> the limiting factor in that case?
>
> --
> Mark aka Nadjita
>
> ___
> 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] tagging the diameter of a mini-roundabout

[Volker Schmidt]

The mm is because it's intended do describe water tubes and pipe threads,
and not roads. That is why I have doubts using it for the mini-roundabout.

On Sat, 28 Jan 2023, 09:20 Mark Reidel,  wrote:

> On Sat, 2023-01-28 at 00:53 +0100, Volker Schmidt wrote:
> > What I am after is tagging the dimension of mini-roundabouts. This seems
> > to be useful information for longer vehicles. The specific
> mini-roundabout
> > that triggered the question is this one, and it has a diameter of about
> > 12m, and, yes, it is a mini-roundabout.
>
> I would tag the diameter the same as a highway=turning_loop, meaning:
>
> diameter=12 m
> inner_diameter=XX m
>
> where inner_diameter is the size of the traversable area in the middle. If
> there is none to tag, then solely diameter=12 m.
>
> For whatever reason, diameter is mm by default, so be careful ;)
>
> - Mark aka Nadjita
>
> ___
> 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] tagging the diameter of a mini-roundabout

[Volker Schmidt]

Florian,
I saw that discussion on the German list. I don't understand it.
I am familiar with the difference between a roundabout and a
mini-roundabout. The difference is essentially the traversability of the
centre, and the size. In the UK, where the OSM tagging was born, they have
different road signs. Here in Italy they do not have different signs, and
the only difference is the traversability.
The rules are the same for both.

So the traversability being the difference between the two, it is useless
to discuss the traversability of junction=roundabout. If the center is
traversable it is, in OSM,  not a junction=roundabout, but a
highway=mini_roundabout. This is an old established tagging, and I do not
see any need to change that.
What I am after is tagging the dimension of mini-roundabouts. This seems to
be useful information for longer vehicles. The specific mini-roundabout
that triggered the question is this one
<https://www.mapillary.com/app/?pKey=1288570081954544>, and it has a
diameter of about 12m, and, yes, it is a mini-roundabout.
Volker


Il giorno ven 27 gen 2023 alle ore 22:35 Florian Lohoff  ha
scritto:

> Hi,
>
> On Wed, Jan 25, 2023 at 09:25:32PM +0100, Volker Schmidt wrote:
> > I see that I was not precise with my question: I am after a way to tag
> the
> > overall diameter of the round surface composed of the mini-roundabout
> road
> > surface plus the traversable central part. This is an important measure
> for
> > trucks. I happen to live near one of these with an outer diameter of 12
> m,
> > and that attracts regularly articulated lorries like the cheese attracts
> > flies. This triggered the question.
>
> There has been a pretty lenghty discussion in the German forum just a
> couple days back which i started.
>
> I started a discussion about mini_roundabouts here too a couple years
> back.
>
> I still find the concept of tagging a "mini roundabout" _broken by
> design_.
>
> The main difference we have in usage is - A mini roundabout will never
> cause any announcements like "3rd exit" it will be "turn left". This
> will be pretty confusing for anything larger that a small residential
> street.
>
> And i think the misconception is still what a mini roundabout is.
> A mini roundabout is not a mini roundabout because its center is
> traverseable. Its a matter of fixing a priority problem in busy
> junctions.
>
> So in case you have 12m diameter and a traversable center i would not
> say thats a mini_roundabout.
>
> And while at it - We should introduce a tag "traversable=yes" or
> something on the junction=roundabout way.
>
> Flo
> --
> Florian Lohoff f...@zz.de
>   Any sufficiently advanced technology is indistinguishable from magic.
> ___
> 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] tagging the diameter of a mini-roundabout

[Volker Schmidt]

I see that I was not precise with my question: I am after a way to tag the
overall diameter of the round surface composed of the mini-roundabout road
surface plus the traversable central part. This is an important measure for
trucks. I happen to live near one of these with an outer diameter of 12 m,
and that attracts regularly articulated lorries like the cheese attracts
flies. This triggered the question.

Il giorno mer 25 gen 2023 alle ore 19:10 Peter Neale via Tagging <
tagging@openstreetmap.org> ha scritto:

> According to the Wiki (with which I happen to agree), a mini-roundabout is
> defined as:
>
> "...a special type of roundabout in which the middle can be traversed
> <https://wiki.openstreetmap.org/wiki/Traversable> by vehicles, and is
> typically used where there is only limited space available. Road traffic
> flows in one direction around a point in the middle and the traffic in the
> roundabout has right-of-way. The middle of a mini-roundabout is usually
> only a painted circle, but there might also be a low, fully traversable
> (mountable) dome or island."
>
> As it is traversable, does it really have a diameter?  Or, if there is a
> painted circle (are traversable domed area) on the ground, perhaps that has
> a diameter, but does it matter to any prospective map user?
>
> Regards,
> Peter
>
> Peter Neale
> t: 01908 309666
> m: 07968 341930
>
>
> On Wednesday, 25 January 2023 at 17:53:55 GMT, Volker Schmidt <
> vosc...@gmail.com> wrote:
>
>
> Is there an established way to tag the diameter of a mini-roundabout?
>
> We have the tag diameter, but I could not find it applied to
> mini-roundabouts.
> ___
> 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] tagging the diameter of a mini-roundabout

[Volker Schmidt]

Is there an established way to tag the diameter of a mini-roundabout?

We have the tag diameter, but I could not find it applied to
mini-roundabouts.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature proposal - Voting - Utilities facility

[Volker Schmidt]

Hi François,

Il giorno gio 12 gen 2023 alle ore 19:44 François Lacombe <
fl.infosrese...@gmail.com> ha scritto:

> Hi Volker,
>
> Le jeu. 12 janv. 2023 à 12:02, Volker Schmidt  a
> écrit :
>
>> The present vs future tagging table is flawed.
>> The landuse column shows values that are rarely used. Industrial=water
>> (500 uses) in practice is tagged as man_made=water_works (30k+ uses).
>> "sewerage" land use exists and is in practice tagged as
>> man_made=wastewater_plant (75k uses).
>>
>
> man_made=water_works isn't relative to the activity for which the land is
> used.
> It is a feature combined with its perimeter.
>
> As mentioned during RFC, we miss a scope to allow mappers to state "it's
> water stuff" without knowing as much about what is going on exactly there.
> man_made=water_works isn't the only possible value, there is
> man_made=pumping_station, man_made=covered_reservoir...
> utility=water is way simpler and cover them all.
>
> https://community.openstreetmap.org/t/rfc-utility-facilities/5723/6?u=infosreseaux
>

Drinking water and sewage are really very different stuff, and at present
already mapped differently. And I guess there are very few plants that
handle both (water recycling in the International Space Station springs to
mind, but not many others).

Generally speaking I don't like the proposals of "wiki gardening" that
>> result in mappers being confronted with lists of "deprecation" warnings
>> every time they upload changesets that regard completely unrelated features.
>> Maybe I am atypical as I often map road features of interest to cyclists,
>> and I notice a steady increase of deprecation warnings.
>>
>
> Isn't this tagging gardening instead of wiki gardening?
>
I don't care how you name this, the effect would be a massive retagging
effort

It is actually possible in editors to disable warning on untouched features
> to stop being warned this way.
>
Turning it off does not do the job, as some deprecation regards stuff that
I am frequently mapping, and where I am interested to correct the tagging.

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

Re: [Tagging] Feature proposal - Voting - Utilities facility

[Volker Schmidt]

The present vs future tagging table is flawed.
The landuse column shows values that are rarely used. Industrial=water (500
uses) in practice is tagged as man_made=water_works (30k+ uses). "sewerage"
land use exists and is in practice tagged as man_made=wastewater_plant (75k
uses).

Generally speaking I don't like the proposals of "wiki gardening" that
result in mappers being confronted with lists of "deprecation" warnings
every time they upload changesets that regard completely unrelated features.
Maybe I am atypical as I often map road features of interest to cyclists,
and I notice a steady increase of deprecation warnings.


Il giorno gio 12 gen 2023 alle ore 10:47 François Lacombe <
fl.infosrese...@gmail.com> ha scritto:

> Dear all,
>
> The vote is now open on the Utility facilities proposal
> https://wiki.openstreetmap.org/wiki/Proposed_features/Utility_facilities
>
> The rationale gives many details about what it’s all about: providing
> consistent tagging across several features to describe in which essential
> infrastructure activity they are involved in.
>
> It is also proposed to replace existing tagging that was created with less
> global logic in mind. As utility=* key is now available, it is possible to
> bring more consistency in our tagging practice.
> I don’t plan to make a bot or mass edit to make this replacement. Quality
> control and editors presets will encourage mappers to carefully replace
> replaced tags when they found them.
>
> Feel free to vote at the bottom of the page following provided directions.
>
> Voting as also been announced here
>
> https://community.openstreetmap.org/t/feature-proposal-voting-utility-facilities/7783
>
> Best regards
>
> François
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] key covered=* applied to storage tanks

[Volker Schmidt]

I would say that storage tanks, as default, are closed. So a
man_made=storage_tank in OSM is closed.
Secondly if a tank is closed (at the top), this is called a roof. There are
fixed roofs and floating roofs.
See as an example this manufacturer's web site:
https://www.wermac.org/equipment/storage_tanks_vessels_general.html
So this would translate to roof=yes/no/floating/fixed in OSM speak to
indicate that a tank is closed-
covered=yes would be correct to indicate an open or closed storage tank
under some separate kind of covering structure.

Il giorno gio 12 gen 2023 alle ore 09:28 Warin <61sundow...@gmail.com> ha
scritto:

>
> On 12/1/23 08:28, António Madeira wrote:
> > Open tanks are common in wild fires territories, like in Portugal, and
> > I'm probably in Spain and Greece.
> Not in Australia.
> > They're used by helicopters and firefighters, who depend on them in
> > heavy mountainous regions, where it's impossible or very difficult to
> > get water.
>
> Helicopters here use rivers, dams, not tank water.
>
> Firefighting trucks here use tank water, and they have to pump it out
> thought a hose to a nozzle, so contaminates can be a problem.
>
> > We're talking about water tanks of all sizes and formats, some of them
> > are really huge, which are only used for fight forest fires, so it
> > doesn't matter if they're contaminated.
> > For helicopters, they're marked with white and red stripes, so that
> > they can be easily spotted from the air.
> > Some of them rely on rain water to be filled, but most are refilled by
> > firefighters with river water or other sources.
>
>
> Tanks here as a first option take rainwater. If necessary then water
> would be trucked in. In remote areas with no population there are no
> tanks so trucks would have to suck water from anywhere. In rugged remote
> areas there are probably no roads!
>
> Remote areas here with populations have extremely large tanks for
> drinking water... that can be used for fire fighting. Extremely large =
> at least a years water supply with no rain fall.
>
> >
> >
> > Às 05:54 de 11/01/2023, Warin escreveu:
> >>
> >> On 10/1/23 03:49, António Madeira wrote:
> >>> Greetings.
> >>>
> >>> There are closed and open storage tanks, and I think is important to
> >>> differentiate them, specially those used by firefighters and rural
> >>> communities to fight wild fires.
> >>> The approved proposal for the key covered=* states "C. denote an
> >>> area such as an underground parking lot, a covered reservoir/cistern
> >>> or even such things as an aquarium (e.g., Kelly Tarlton's, Auckland,
> >>> NZ), when the covering is not a man-made structure that would allow
> >>> layer differentiation."
> >>>
> >>> I would like to know what the community thinks about elaborate that
> >>> line a bit more, to include emergency storage tanks so that people
> >>> know it's ok to add covered=* to those structures.
> >>>
> >>>
> >>
> >> Storage tanks around me are all covered, at least all the one I
> >> remember are. This includes ones used or emergency fire fighting.
> >> Uncovered ones would be very rare in my country due to the
> >> possibility of contamination by drowned animals, dirt, dust, tree
> >> leaves and tree limbs. There are probably regulations about them
> >> being covered to prevent the breading of mosquitos! So would think
> >> covered is part of being a storage tank at least here.
> >>
> >>
>
> ___
> 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 a point-of-interest sign

[Volker Schmidt]

Thanks, Brad. It is a pass, as there are two identical signs in opposite
directions, 175 meters apart. The pass may have a name, after all, which is
on another sign. Anyway I will check with a local person.
The signs in question can be considered as geographical information boards.

On Fri, 30 Dec 2022, 03:05 brad,  wrote:

> I think you should check your data.   Looking at USGS topo, that point
> does look very close to the continental divide.
> Usually, but I suppose not always,  when you go over the divide you are
> going over a pass.  This one seems to be fairly flat so perhaps never got
> named.
> I don't use mapillary, but according to the USGS topo loaded into
> qmapshack the divide crosses that road at
> N35.005307° W108.081164°
>
> I have seen a similar sign in NM that wasn't on the divide & I assumed it
> was a joke put up by a local prankster, but this one seems right.
>
> On 12/29/22 11:52, Volker Schmidt wrote:
>
> I have now checked on Gmaps: that sign is not on the continental divide,
> but it is announcing the continental divide. About 175m further there is an
> identical sign on the other side of the road, and facing the opposite
> direction. Hence there is a pass, but the highest point itself is not
> marked. I have added a mountain pass in the middle between the signs with a
> provisional name, which I will have checked by a local, whom I happen to
> know.
> .The "Continental Divide" is not a pass, but a watershed that is several
> thousand km long.
>
> Il giorno gio 29 dic 2022 alle ore 16:40 Joseph Eisenberg <
> joseph.eisenb...@gmail.com> ha scritto:
>
>> This example should also be mapped as a pass, with a node tagged
>> mountain_pass=yes on the highway, with the elevation
>>
>> On Wed, Dec 28, 2022 at 2:26 PM Volker Schmidt  wrote:
>>
>>> I would like to tag signs that do refer to Points of Interest like this
>>> example <https://www.mapillary.com/app/?pKey=192002416097005>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> 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 
> 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] Route names being applied to tracks/paths

[Volker Schmidt]

I know this problem from cycle routes. Individual ways that are part of a
hiking or cycling route should normally not carry the name of the route.
First because in most cases it will be factually wrong, but also such
invented names will make it difficult to find ways with genuinly missing
names in our database.

On Thu, 29 Dec 2022, 19:08 Peter Elderson,  wrote:

> I have seen some paths which actually had the same name as the hiking
> trail running over it. Normally this is not the case, the path usually has
> is own local name or no name at all. So most of the time this would be an
> error, but you can't be sure without survey.
>
> Fr Gr Peter Elderson
>
> Op 29 dec. 2022 om 18:28 heeft Tod Fitch  het
> volgende geschreven:
>
> It makes sense to me that each segment of a long distance walking/hiking
> route should be looked at individually. It might have no name (uses a
> section of a driveway), it might have a name of its own (the “San Clemente
> Beach Trail” near me is part of the long distance “California Coastal
> Trail”), or it might have been purpose built for that long distance route.
>
> My issue with hiking routes is that people seem to want to use the name
> field as a description. And they sometimes want to use the ref field as a
> description too. That makes it really hard for a data consumer to make use
> of the information. I wrote some stuff about that a bit over a year ago [1].
>
> Cheers,
> Tod
>
> [1]
> https://retiredtechie.fitchfamily.org/2021/09/12/california-hiking-routes-in-openstreetmap/
>
> On Dec 29, 2022, at 7:59 AM, Zeke Farwell  wrote:
>
> I've heard the assertion that a way has no name but the route that passes
> over it does many times.  While this is true in some cases, in others it is
> not.  Where the primary purpose of the way is not for the route, this does
> make sense.  For example mentioned by Jmapb where the Appalachian trail
> follows an unnamed driveway or sidewalk.  In these cases, the primary
> purpose is a driveway or sidewalk for local use, and the Appalachian Trail
> just happens to follow it as well.  Here putting the name Appalachian Trail
> on the way makes no sense.  However, there are also dedicated sections of
> trail built first and foremost to be a part of the Appalachian Trail and
> that have no other name.  Omitting the name Appalachian Trail in a case
> like that makes no sense to me.  That section of trail is indeed called the
> Appalachian Trail.  The whole route is also called the Appalachian Trail
> and that's ok.
>
>
> On Thu, Dec 29, 2022 at 10:38 AM Jmapb  wrote:
>
>> On 12/29/2022 10:13 AM, Zeke Farwell wrote:
>>
>> Yes, the way name tag should be the most local trail name.  However,
>> sometimes there is no local trail name and the long distance route name is
>> the only name.  In this case putting the long distance route name on the
>> ways also makes sense.
>>
>> I've been doing some mapping on the Appalachian Trail lately and this
>> appears to be the common practice, although the AT is dominant enough that
>> constituent trails sometimes lose their local names over time.
>>
>> Some mappers will take it a little too far and tag sections of sidewalk
>> and driveway that the AT follows with name=Appalachian Trail (or even
>> name=Appalachian National Scenic Trail... IMO this is an official_name, and
>> probably only belongs on the route superrelation.)
>>
>> It's common to see ref=AT as well, which is fine on trails (even locally
>> named ones) and perhaps ok on the sidewalks, but adding it to a vehicular
>> road seems iffy.
>>
>> 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
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to tag a point-of-interest sign

[Volker Schmidt]

I have now checked on Gmaps: that sign is not on the continental divide,
but it is announcing the continental divide. About 175m further there is an
identical sign on the other side of the road, and facing the opposite
direction. Hence there is a pass, but the highest point itself is not
marked. I have added a mountain pass in the middle between the signs with a
provisional name, which I will have checked by a local, whom I happen to
know.
.The "Continental Divide" is not a pass, but a watershed that is several
thousand km long.

Il giorno gio 29 dic 2022 alle ore 16:40 Joseph Eisenberg <
joseph.eisenb...@gmail.com> ha scritto:

> This example should also be mapped as a pass, with a node tagged
> mountain_pass=yes on the highway, with the elevation
>
> On Wed, Dec 28, 2022 at 2:26 PM Volker Schmidt  wrote:
>
>> I would like to tag signs that do refer to Points of Interest like this
>> example <https://www.mapillary.com/app/?pKey=192002416097005>
>>
>>
>>
>>
>>
>>
>> ___
>> 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] How to tag a point-of-interest sign

[Volker Schmidt]

I would like to tag signs that do refer to Points of Interest like this
example 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Crossing cleanup and deprecation

[Volker Schmidt]

This proposal is incorrectly giving the impression that it is in the spirit
of the crossing:markings tag.
This tag was meant to complement and refine the existing tagging of
crossings in some cases, but certainly not to replace, wholesale the
"crossing" key
The crossing:markings key describes the painting on the road surface, not
the legal situation for the traffic participants, and it also leaves out
the vertical signals (which BTW here in Italy have precedence over the
horizontal signs in case of conflict)

The statement
" As such, I propose to approve crossing:signals=* and additionally
deprecate crossing=* (except crossing=no)." is not in the spirit of the
crossing:markings wiki page
is unworkable: there are some several million crossing=* tags and it als
cannot replace the existing tagging (example: "crossing:markings=pictogram"
does not replace the tagging highway=path plus bicycle=designatet plus
foot=designated plus segregated=yes on the crossing way)

Also what is the meaning of crossing=no?

Please note that I am not saying that the actual tagging practice is good
or uniform.

Volker
(mapping cyclist in NE Italy)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] service vs. unclassified, conflicting definitions

[Volker Schmidt]

Most of the highway objects along waterways around here (Po Valley,
Northern Italy) that are not open to public motor traffic, and wide enough
for dual-track vehicles, are, in my view correctly,  tagged as
highway=track. They are used for waterway maintenance and for agricultural
purposes on the adjacent properties. They may, in addition, explicitly
carry cycling, or foot-cycling paths or cycle routes.
They may in addition serve as service roads to reach private residences.
Often these private residences are on a first, better maintained, part of
the road, and this continues as a more track-like road further down.
In those cases you could argue the first part is residential.

Many of these tracks have also names, even if there are often no signs.







On Sat, 12 Nov 2022, 12:21 Greg Troxel,  wrote:

>
> Warin <61sundow...@gmail.com> writes:
>
> > On 1/10/22 20:25, stevea wrote:
> >> Makes sense to me, too, Greg.  I don't know if it helps or hinders
> >> wider understanding, but I understand what Greg is saying here, and
> >> while his perspective is "Eastern USA" (and mine is "Western USA"),
> >> these don't seem far apart or even different at all, and there may
> >> likely be a further possible refinement here:
> >>
> >> "unclassified" roads, as a "real legal roads" are "in public," and
> subject to traffic rules/laws/ordinances, and
> >>
> >> "service" roads, as "private driveways, parking lot aisles and other
> >> roads not in the public grid of road network" are "on private
> >> property" and not (as) subject to traffic rules/laws/ordinances.
> >
> > That would mean a crash on them would not have road laws applied to it
> > .. so the insurance companies could not attribute blame based on road
> > laws.. that could get very difficult in court.
>
> This is not an actual problem in practice (mass.us).  Well, traffic
> laws and enforcement/liability *are* a mess, but they aren't
> differentially messy in this case.
>
> It is true that you have to file an accident report with the police on
> real roads, but not for crashes in parkings lots and driveways.   But
> liability is from tort law which doesn't care where.  And criminal law
> about negligent operation (similar for drunk driving) says:
>
>
> https://malegislature.gov/Laws/GeneralLaws/PartI/TitleXIV/Chapter90/Section24
>
>   Whoever upon any way or in any place to which the public has a right of
>   access, or any place to which members of the public have access as
>   invitees or licensees, operates a motor vehicle recklessly, or
>   operates such a vehicle negligently so that the lives or safety of the
>   public might be endangered
>
> which means business/shopping driveways/lots count.
>
> But what the law says is not relevant in how we tag.  I didn't really
> mean "service is not subject to law".  I meant that here we have a
> concept of a legal road (referred to by "way" above) and places where
> you can drive which are not legal roads (referred to by the other text).
>
> > I know the old definition of our 'motor traffic act' said something
> > along the lines of a road is 'any place open to, or used, by the
> > public' .. that includes private driveways, car parks etc etc as they
> > are 'used by the public'.
>
> Sure.  It is not surprising that law prohibits negligent behavior on
> places the public normally goes, even if that is not a legal road.
>
> But there is still a difference legally in  many places.  Even if not, I
> still think that unclassified for things that feel like actual roads and
> service for things  that feel like drivways and parking lots, makes
> total sense.
> ___
> 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 - Street vendors

[Volker Schmidt]

Just to make the list complete:
Around here (or at least in my city and nearby towns) we have regular open
air markets with assigned locations for specific stalls.
Do we already have a mapping approach to that type of stalls? (I couldn't
find one).
If we really don't have one already, it might be worth looking at how to
map stalls in general as I cudl see a lot of similarities.
I do part of my shopping in such markets, and I go to specific stalls for
specific goods.

Il giorno lun 7 nov 2022 alle ore 17:03 Joseph Eisenberg <
joseph.eisenb...@gmail.com> ha scritto:

> I disagree with classing if all “street vendors” and one feature.
>
> This proposal seems to assume conditions in contemporary Europe, where
> shops are usually located in permanent buildings due to climate conditions.
>
> In many subtropical and tropical regions the air temperature is never
> cold, so a fully enclosed permanent building with walls and heating is not
> very necessary.
>
> In this case many “street vendors” will have a tent and some storage which
> stays at a certain place, but is closed up at night. In that regards it is
> similar to a shop which is closed up with a metal gate at night, making it
> poorly visible except during opening hours.
>
> But consider shop=kiosk - in North America these are often small stands on
> a sidewalk of pedestrian street or mall, with one person wgo sells
> newspapers, snacks etc to pedestrians, functioning quite like a common kind
> of street vendor, except that they are in a tiny shed. Is it really better
> to have a totally different way of tagging a similar business which instead
> uses a mobile push-cart or a tricycle instead?
>
> In Southeast Asia, many of the businesses that Westerners might call
> street vendors sell newly cooked food, thus they are more like
> amenity=fast_food - and often an enclosed eatery will have only the kitchen
> indoors, with customers eating outside under a canopy.
>
> Even here in Oregon, in the United States, we have small restaurants which
> are ambiguous under this proposal: they are “food carts” because they are
> small kitchens in trailers with wheels, which can be moved by attaching
> them to a truck. But usually they are semi-permanently installed on rented
> private land, with the landowner providing hook-ups for electricity and
> water, and usually covered seating with a canopy and picnic tables. So
> while they look similar to at more mobile “food truck” (which has its own
> engine and drivers seat, and thus can be moved every day) they are more
> permanent.
>
> Rather than approving this proposal I would recommend more use of property
> tags. The existing street_vendor=yes tag is probably best, but building=no
> is also common (10k uses) and makes it clear that a feature is not a
> building.
> https://taginfo.openstreetmap.org/tags/building=no
>
> - Joseph Eisenberg
>
>
>
> On Sun, Nov 6, 2022 at 9:31 PM map...@t-online.de 
> wrote:
>
>> Hi all,
>>
>>
>>
>> I propose to deprecate street_vendor=* and to tag mappable street
>> vendors with amenity=street_vendor + vending=* + opening_hours=* instead.
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Street_vendors
>>
>> Please discuss this proposal on its Wiki Talk page.
>>
>>
>>
>> Cheers,
>>
>>
>>
>> Freetz
>>
>>
>>
>> 
>> ___
>> 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 - historic

[Volker Schmidt]

I think the best way out is to think detached from the meaning of the
strings of characters we use for tagging.
Let's document that we have have certain values for the key "historic" that
describe objects that are not historic, and not even old.
After all the purpose of the wiki is to describe the tagging as is, not as
it should be an ideal tagging system.

On Thu, 3 Nov 2022, 14:05 Brian M. Sperlongano, 
wrote:

> The main issue I have with this proposal is that there is a longstanding
> controversy regarding the historic key.  Namely, the question of whether it
> is used for things that are historic or merely old.  I don't see how a
> proposal centered around this key can move forward with that fundamental
> debate unaddressed.
>
> On Thu, Nov 3, 2022, 8:56 AM Anne-Karoline Distel 
> wrote:
>
>> Thanks for pointing that out, I've closed the vote again, and will open
>> again tomorrow. I don't know if that it the procedure when you correct
>> an oversight on the proposal page.
>>
>> Anne
>>
>> On 03/11/2022 12:16, Daniel Capilla wrote:
>> > Please,
>> >
>> > Check the wiki talk page of this proposal before opening the voting
>> > time. Some issues are not cleared resolved.
>> >
>> > Thank you.
>> >
>> >
>> > Regards,
>> >
>> >
>> > Daniel Capilla
>> >
>> >
>> > ___
>> > 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] improve the proposal procedure

[Volker Schmidt]

I would like to contribute to this discussion my, maybe subjective,
impression that we have an inflation of proposals. Many of them are
interesting, others look less so. In any case, personally I have de facto
stopped contributing to these proposals for simple lack of time.
I also would like to add that too much wiki "gardening" is going on below
the radar of most contributors.

My impression is that we are running the real risk that we are adding too
much tiny bits of information and are losing out on the core part our
project, i.e. data collection for making maps.

Adding continously many tiny bits of information means that we are losing
out on maintaining and improving our core data. We simply do not have the
manpower.

I am a near daily mapper, mostly regarding cycling related information, and
I am often surprised, how easy it is to encounter bad or
missing information in our data base.  I consider cycling-related data
particularly important, as it is a sector where OSM is leading over the
competition, as most cycling-related route-planning sites and most bicycle
navigation devices use OSM data.

Volker



On Fri, 21 Oct 2022, 02:41 Illia Marchenko, 
wrote:

>
>
> пт, 21 окт. 2022 г., 2:37 Frederik Ramm :
>
>> These people could use their free time to make one successful proposals
>> instead of five unsuccessful ones that waste everyone's time because
>> they are half-hearted.
>>
>
> Most of the rejected proposals are good written, but fundamentally broken.
>
> The OSMF should not be involved but the OSMF's definition of an "active
>> contributor" could nonetheless be used. It would make it less likely to
>> get proposals from people who don't map and therefore are unlikely to be
>> able to make a good proposal.
>>
>
> I am has been an active contributor in the past, but currently do not map,
> and not an "active contributor" in formal sense. I am unlikely to be able
> to make a good proposal?
>
> Keep in mind that the proposal process isn't a one-way street. It can
>> only work as long as for every one proposal there are dozens of people
>> who can read and constructively participate in the development of the
>> proposal. The capacity for new proposals is limited.
>>
>
> I am agree with clause that capacity is limited, but limit are known? For
> example, minimal RFC stage may be raised to 30 days, if it is necessary.
>
> "As do I, but I get a bit concerned when RFCs / proposals are raised for
> discussions that are still going on e.g. the recent very involved
> discussions re fountains / drinking-water / water-taps, when in-depth
> conversations were still proceeding over multiple threads, but there are
> actual proposals being raised"
>
> My apologies. This proposal has been withdrawn very quickly.
>
> ___
> 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] dinosaurs

[Volker Schmidt]

Do you have a feeling how many "archeologic" sites in OSM are in reality
palaeontological? I fear this is a frequent error, but difficult to spot.

On Sun, 16 Oct 2022, 17:33 Anne-Karoline Distel, 
wrote:

> Hello all,
>
> I'm doing a huge tidy-up amongst the values for "site_type", documented
> in a diary post:
> https://www.openstreetmap.org/user/b-unicycling/diary/400151
>
> I've come across a few dinosaur footprints, but that is not archaeology,
> because archaeology is about man made structures. Is there a way to
> implement a warning into the editors not to combine
> "archaeological_site" with dinosaurs? I will replace the few I found
> with geological=palaeontological_site
> (
> https://wiki.openstreetmap.org/wiki/Tag:geological%3Dpalaeontological_site
> ).
>
> Maybe this is the wrong mailing list for it...
>
> Anne
>
>
> ___
> 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] Hvad stiller vi op med tour de France ruterne?

[Volker Schmidt]

On Sat, 15 Oct 2022, 20:02 Marc_marc,  wrote:

> Hello,
>
> Le 15.10.22 à 18:55, Volker Schmidt a écrit :
> > (
> > It is certainly not something that can be represented
> > by a bicycle route relation.
>
> witch issue did you see ?
>

It's not signposted.
At least parts of it are off-limits for bicycles (e.g. motorway)

Volker

>
> Regards,
> Marc
>
>
>
> ___
> 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] Hvad stiller vi op med tour de France ruterne?

[Volker Schmidt]

(using Google's English translation of the Danish text)

In addition a bicycle route has to be signposted.

I doubt that the the fact that the TdF in a given year ran over a certain
set of roads is something that is to be inserted in a geographical
database, as is OSM.
It is certainly not something that can be represented by a bicycle route
relation.




Il giorno sab 15 ott 2022 alle ore 18:13 Niels Elgaard Larsen <
elga...@agol.dk> ha scritto:

> Fx
> https://www.openstreetmap.org/relation/13488959/
> https://www.openstreetmap.org/relation/14315474
>
> Enten skal de slettes.
>
> Eller hvis der er cyklister, der synes at det er sjovt at cykle på
> historiske ruter,
> så skal de ændres så de bruger cykelstier i stedet for vejstykker hvor man
> ikke må
> cykle.
>
> Eller route tagget skal ændres til noget andet end "bicycle", fx
> "historic:bicycle"
> og kalde ruten "Tour de France 2022 inspireret".
>
> For vejene var jo kun afspærret til brug for cyklister en enkelt dag.
>
> Vi kan ikke have cykelruter, der bruger veje tagget med bicycle=no
>
>
>
>
> --
> Niels Elgaard Larsen
>
> ___
> 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 - pickup

[Volker Schmidt]

The parcel locker that I use is both for picking up goods and for returning
goods.
I presume that this is the standard functionality for parcel lockers.

Il giorno sab 15 ott 2022 alle ore 17:46 Illia Marchenko <
illiamarchenk...@gmail.com> ha scritto:

>
>
> сб, 15 окт. 2022 г., 18:36 Volker Schmidt :
>
>> amenity=parcel_locker is used 26k times.
>> amenity=vending_machine + vending_machine=pickup is use 16 k times and
>> deprecated
>> So why should we abandon  amenity=parcel_locker and create a new key with
>> duplicate meaning .
>>
> I agree. amenity=parcel_locker & parcel_pickup=* is perfectly suitable for
> self-service pickup points.
>
>> ___
> 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 - pickup

[Volker Schmidt]

amenity=parcel_locker is used 26k times.
amenity=vending_machine + vending_machine=pickup is use 16 k times and
deprecated
So why should we abandon  amenity=parcel_locker and create a new key with
duplicate meaning .


Il giorno sab 15 ott 2022 alle ore 14:48 Illia Marchenko <
illiamarchenk...@gmail.com> ha scritto:

>
>
> сб, 15 окт. 2022 г., 11:41 Volker Schmidt :
>
>> Around here we have many instances of self-service parcel-locker inside a
>> shop that is inside a building. The shop does not occupy the entire
>> building, the locker is only accessible during shop opening times.
>>
>> There are also pick-up points in shops where a human being handles the
>> operation (I know of a prinhong shop and a petrol station). So there is a
>> case for distinguishing between self-service and human-handled pick-up
>> points.
>>
> I suggest office=pickup for human-handled and amenity=pickup_locker for
> self-service points.
>
>> ___
> 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 - pickup

[Volker Schmidt]

Around here we have many instances of self-service parcel-locker inside a
shop that is inside a building. The shop does not occupy the entire
building, the locker is only accessible during shop opening times.

There are also pick-up points in shops where a human being handles the
operation (I know of a prinhong shop and a petrol station). So there is a
case for distinguishing between self-service and human-handled pick-up
points.



On Sat, 15 Oct 2022, 06:28 Evan Carroll,  wrote:

> On Tue, Oct 11, 2022 at 4:20 PM Marc_marc  wrote:
>
>> Le 11.10.22 à 21:33, Evan Carroll a écrit :
>> > We could map these onto the building polygon explicitly
>>
>> please : one element = one object
>> building <> the user of the building.
>> so imho it's best to have one object for the buildinng,
>> another for the shop or the pickup or whatever.
>> ex of issue : name on a object building+shop : it's the name
>> of the building or the name of the shop ?
>>
>
> I don't understand what you're trying to say.
>
> 
> Evan Carroll - m...@evancarroll.com
> System Lord of the Internets
> web: http://www.evancarroll.com
> ph: 281.901.0011 <+1-281-901-0011>
>
>
> ___
> 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 - Payment denominations

[Volker Schmidt]

On Tue, 11 Oct 2022, 09:16 Martin Koppenhoefer, 
wrote:

> in Italy, one and two cent coins have been abolished, they are not
> accepted any more in shops, and while prices are still ending mostly with
> 9, the sum gets rounded.
>

OT for this discussion:  Where I live in Italy, one and two €cent coins are
certainly still in use.

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

Re: [Tagging] Feature proposal - RFC - Tag capacity on benches without separation or not?

[Volker Schmidt]

Can we not finish this useless discussion?
The amenity=bench tag was created just for that purpose, benches.
Some time later someone created the key seats to indicate how many people
can sit on a bench, adding explicitly that the key capacity should not be
used in that case.
The addition that key seats should be used only for benches that have
separate seats by an author who obviously had not looked at the actual
usage of the two tags. (this has been reverted in the wiki)
The proposal to replace seats with capacity, keeping exactly the same
meaning does not make any sense to me.

A different argument is if we need a separate tag for benches with
separated single-person seats (I guess we are talking about waiting chairs
or multiseat chairs).
This could amenity=chair (used 800 times only) with a new default of
seats=1, and an optional seats=x

BTW. It is not clear if seats is a noun or a verb.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] OSM Wiki

[Volker Schmidt]

A practical comment from an end user: it is helpful to know if a
drinking-water point can be used to fill water bottles. Bubblers are tricky
in that regard.

BTW: a shower in many parts of the world may not "waste" drinking water,
for example by using rain water.

On Mon, 3 Oct 2022, 13:47 Warin, <61sundow...@gmail.com> wrote:

> An interesting collective of comments on 'bubbler' from Australia
>
>
> https://www.macquariedictionary.com.au/resources/aus/word/map/search/word/bubbler/The%20Riverina/
>
>
> On 1/10/22 11:03, Martin Koppenhoefer wrote:
> >
> > sent from a phone
> >
> >> On 1 Oct 2022, at 02:38, stevea  wrote:
> >>
> >> There's water_tap, there's fountain (water fountains, same as drinking
> fountains / bubblers, not the same as big fountains in the park or Las
> Vegas), there's bubblers, are we (largely?) on the same page about these?!
> Good discussion so far!
> >
> > there is also a whole tagging scheme for all of this.
> >
> > amenity=drinking_water
> > fountain=drinking/bubbler/…
> > drinking_water=yes/no/…
> > man_made=water_tap
> > amenity=watering_place
> > amenity=fountain
> > …
> >
> > the tags can be combined to get to a useful description.
> >
> > FWIW, the water tap tag is often used for water that is not potable
> (because otherwise the standard is amenity=drinking_water
>
>
> amenity=drinking_water does not signify a tap, nor a bubbler nor a
> stream, nor a spring nor a pond .. it could be any of those and more ..
> a 'well' for instance.
>
> All amenity=drinking_water implies is 'drinking_water=yes', and
> hopefully the legal status too.
>
>
> Only ~16% of man_made=water_tap carry the tag 'drinking_water=no'. I
> don't think that supports the comment 'often used for water that is not
> potable'.
>
> See
> https://taginfo.openstreetmap.org/tags/man_made%3Dwater_tap#combinations
> for more.
>
>
> A bubbler would normally be drinking water and have a tap. A shower too
> would normally be drinking water and have one or more taps. I don't
> think that the tag 'man_made=water_tap' should be applied to these things.
>
>
> A web comparison of 'bubbler' vs 'drinking  fountain'
>
> https://www.dictionary.com/compare-words/bubbler-vs-water%20fountain?root=bubbler
>
>
> I do like the distinction that a bubbler 'spouts water' where as a
> drinking fountain 'supplies water'. It is the "upward" 'spout' that
> makes human drinking easier.
>
>
> 
>
> Tagging combinations can get overly verbose?
>
>
> man_made=water_tap
> drinking_water=yes
> material=brass
>
> should not need added tags to further describe the water  .. such as
>
> amenity=drinking_water ... I think this is just tagging for the render,
> possibly necessary for some.
>
> And then adding
>
> fountain=drinking ... adds no new information?
>
>
>
>
>
>
> ___
> 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] Terminology primary feature, main tag, etc..

[Volker Schmidt]

On Mon, 3 Oct 2022, 12:20 Marc_marc,  wrote:

> imho only one main feature/objet : the stream bed
> and car use it, a bit like a bicycle uses a road.
>
OT, but I cannot let it pass:
Roads, in most cases, are dedicated to vehicles (including bicycles),
pedestrians, horse riders, ..., unless there are suitable sidewalks (for
pedestrians), or suitable cycle paths (for bicycles). Most roads are not
motorroads.







> but we don't really have a secondary tag to say that
> the stream bed is usable by a car... so we end up
> describing this secondary use with a 2nd main tag...
> this is not perfect
>
>
>
> ___
> 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] Can we assume surface=cobblestone:flattened to be an exact duplicate of surface=sett?

[Volker Schmidt]

Sett <-> flattened cobblestone:
Sett are roughly rectangular blocks, hewn from big blocks of stone (granite
or basalt).
Flattened cobblestones are made from roughly round cobblestones by
flattening the part that faces the road surface.
Cobblestones and pebbles are essentially the same: pebblestones are small
cobblestones.
See wikipedia for more details.

On Fri, 30 Sep 2022, 11:40 Mateusz Konieczny via Tagging, <
tagging@openstreetmap.org> wrote:

>
>
>
> Sep 30, 2022, 10:56 by marc_m...@mailo.com:
>
> Hello,
>
> Le 30.09.22 à 04:20, Mateusz Konieczny via Tagging a écrit :
>
> maybe it should be changed and be treated as missing surface info
>
>
> I don't see how cobblestone:flattened could mean unhewn_cobblestone in
> some case, imho it's a alias for sett
>
> but if cobblestone:flattened (as said in the surface template)
> should not be used to avoid confusion with sett or unhewn_cobblestone, why
> are you willing to ask if ti's asphalt etc like any missing
> surface objet ?
>
> 1) it could be repaved in meantime and actual surface be now different
>
> 2) it would require extra effort to support this
> (about one day of work in total + increased maintenance effort)
>
> 3) it would be more confusing to user to have several different interfaces
> depending something unclear to user, especially given that it could in
> meantime changed to surface=asphalt (or badly tagged in the first place)
> ___
> 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 - highway=scramble

[Volker Schmidt]

Preliminary remark: I have walked and hiked, done a couple of via ferrata,
but so far only heard of scrambled eggs.
My only source is the Wikipedia article on "scrambling".

I have detected that in  fact I have done some scrambles. Two of them close
by. I went back to the tagging and they are tagged with sac_scale
=demanding_mountain_hiking
(No ropes or similar are present, so they are bordercase to T3).
Both are a short pieces of a longer hiking trail (route=hiking) that
overall is rated with cai_scale
=EE
The route is the Alta Via dei Colli Euganei
, the to scrambling pieces
are way 136822484  and way
136822487 
Non ci sono ancora foto su Mapillary. Ho messo un esempio su G-drive.

The interesting thing is that cai_scale (Club Alpino Italiano) is applied
to the entire hiking route, i.e. a relation in OSM, whereas the
sac_scale (Swiss
Alpine Club scale) is applied to the singular way.
The concept is that the cai_scale indicates the maximum difficulty of the
entire route.

This model could be adapted to include scrambles.
I think that scrambles could be part of a longer hiking route and can be
way properties. The SAC scale could be used (and is being used) to declare
ways as scrambles. If an entire route is scrambled we could think about
route=scramble, but I fear that many poeple do scrambles without knowing
the term.






On Thu, 15 Sep 2022, 00:30 martianfreeloader, 
wrote:

> I am a hiker and a climber, but I made experiences similar to Peter's on
> more than one occasion. I have been led along ways by osmand which were
> mapped as highway=path; obviously by other climbers. They were
> definitely not suitable for folks without climbing experience that want
> to go on a physically demanding hike, but don't want to die.
>
> Imo, scramble would not only include via ferrata. There are many
> paths/scrambles where via ferrata equipment is useless, but where you
> will still very much need your hands and in many cases risk serious
> injury or death if you fall. Yet, these kind of paths/scrambles are
> often not considered "real climbing" in the narrower sense (mountaineers
> would usually still go without rope).
>
> On 15/09/2022 00:03, Peter Elderson wrote:
> > I am a hiker, not a climber. I remember lots of sections I would have
> avoided if the map had shown them as scrambles. More adventurous people
> probably would seek them out. I like this proposed highway value. I would
> probably apply it to the actual scramble sections, though, not including
> path sections leading up to the scramble part. Renderers can then show the
> actual scramble sections. For routers, it doesn't really matter, because
> when a section of a path is a scramble and you use say a no scramble
> profile, the route over the path will get high penalty and will not gain
> preference.
> >
> > If a sign says a path will make you scamble somewhere, map the sign and
> the actual scramble(s), that's what I would do.
> >
> > Peter Elderson
> >
> >> Op 14 sep. 2022 om 23:47 heeft martianfreeloader <
> martianfreeloa...@posteo.net> het volgende geschreven:
> >>
> >> In the real world, you will *always* find borderline cases for *any*
> property.
> >>
> >> I don't think it should be an argument against a good proposal. If it
> were, then it could be used against literally *any* tag on osm. (and
> funnily it reliably does come up with any new proposal)
> >>
> >>
> >>
> >>
> >>> On 14/09/2022 22:59, Mateusz Konieczny via Tagging wrote:
> >>> The main problem here is that different people will need (or do not
> need) to use hands,
> >>> it also heavily depends on weather and other considtion
> >>> How we would deal with such borderline cases?
> >>> via ferrata value is far more likely to succeed and I would recommend
> trying to get it first
> >>> Sep 14, 2022, 11:42 by hungerb...@gmail.com:
> >>> It is proposed to create the tag highway=scramble as a base tag for
> >>> hiking paths, where use of hands is required, be that for keeping
> >>> balance or be it for pulling up.
> >>> Please discuss this proposal on its Wiki Talk page,
> >>>
> https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/highway%3Dscramble
> >>> <
> https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/highway%3Dscramble
> >
> >>> Thank you in advance
> >>> Asa
> >>> ___
> >>> 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 - guard stone

[Volker Schmidt]

On Tue, 22 Dec 2020, 01:02 Paul Allen,  wrote:

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

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

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

Volker

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

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

[Volker Schmidt]

I forgot to follow up on two other aspects of this, sorry.

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

?

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

.

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

(predecessors of guardrails I suppose)

Volker


Virus-free.
www.avast.com

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

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

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


Virus-free.
www.avast.com

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

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

[Volker Schmidt]

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

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

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

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

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

[Volker Schmidt]

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


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

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

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

[Volker Schmidt]

The OSM wiki page Traffic_calming defines

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

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

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

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

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

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

[Volker Schmidt]

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


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

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

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

[Tagging] Continuous shoulder rumble strips (CSRS)

[Volker Schmidt]

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

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

[Volker Schmidt]

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

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

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

[Volker Schmidt]

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

Please don't do it

Volker

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

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

Re: [Tagging] Rapids (whitewater) on rivers

[Volker Schmidt]

There are area hazards around, like shooting ranges, and high electric
fields around radio transmitters, and more likely others.

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

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

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

Re: [Tagging] cable:ferry

[Volker Schmidt]

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

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

> Hi,
>
> This article https://wiki.openstreetmap.org/wiki/Tag:route%3Dferry
> mentions ferry:cable=yes as a reaction ferry -  a specific type of cable
> ferry. While the article has a picture of a non-reaction cable ferry, it
> offers no tagging suggestion for that. So I'm guessing that in practice,
> there is no tag for reaction ferry at all, and the wiki definition of
> ferry:cable should be changed.
>
> --
> Joost Schouppe
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rapids (whitewater) on rivers --> Hazards

[Volker Schmidt]

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

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

Volker

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




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

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

Re: [Tagging] Rapids (whitewater) on rivers

[Volker Schmidt]

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



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

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

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

[Volker Schmidt]

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


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

> François, thank you for your hard work on this proposal!  I will most
> likely support this version.  I have a few questions:
>
> 1. The proposal states "It is proposed to discourage the use of
> undocumented pump:type=* to state pump mechanisms in favour of new
> pump_mechanism=*."  It is not clear what is meant by "discourage" in this
> context.  Given the other threads today regarding reservoirs, it is
> important to communicate clearly what we mean when we propose to stop using
> a tag.  I would ask that instead of "discourage", that the proposal should
> explicitly say "deprecate" so that there is no confusion that you intend
> for us to stop using pump:type and document it as deprecated in the
> deprecated features list.  Otherwise, I would ask that you clearly and
> explicitly state what you mean by "discourage" and where those words of
> discouragement would go.
>
> 2.  You propose to deprecate man_made=pumping_rig and propose to replace
> it with the (far more popular) man_made=petroleum_well.  Both of these are
> combined with the substance=* key.  I would ask whether there are usages of
> pumping_rig that are being used with substance=* tags for non-petroleum
> products (i.e. not oil/natural gas) which would be lost by abandoning this
> pumping_rig?  If the answer is "yes", then I would support simply changing
> the description of pumping_rig to explicitly exclude petroleum products,
> and if the answer is "no" then I agree with deprecating it.
>
>
> On Sun, Dec 13, 2020 at 1:48 PM François Lacombe <
> fl.infosrese...@gmail.com> wrote:
>
>> Dear all,
>>
>> Following some rework to take care of comments received during the first
>> voting round of pumping proposal, here is a second proposed version
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Pumping_proposal
>>
>> IanVG and I spent time to improve wording and make rationale section
>> clearer.
>> Classification of pumps is now done with pump_mechanism and is still
>> equivalent to which available on Wikipedia. Numerous references are made
>> toward it.
>>
>> Additional examples and illustrating gifs have been added at the bottom
>> as well.
>>
>> This message opens a second RFC period and is expected to be shorter.
>> Vote could begin by next Saturday.
>>
>> Best regards
>>
>> François
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Volker Schmidt]

Missing at first glance: what is the mapper expected to do with pumping
stations.
We have around here in the Po valley, thousands of them for draining
purposes., and I presume that places like the Netherland have considerably
more of them. Many are housed in dedicated and locked buildings and they
often house several large pumps.
Normally you find the name of the operator posted somewhere.
Sometimes they have signs outside, giving the pumping capacity.
Sometimes, I can see the pipes, and that gives me an idea how many pumps
there are.
I also know that nowadays , apart from museums, pumps are operated by
electrical power.
The rest I don't know, and I would have to consult the web site of the
operator, as it may give some information.
But I think that goes far beyond what a normal mapper without specific
knowledge in pumps would ever do.
I am already happy if people map a man_mde=pumping_station and not only
building=industrial.







Virus-free.
www.avast.com

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

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

>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Pumping_proposal#Examples
>
> Looking at the first example - I see nothing clearly indicating that pump
> is operated
> by muscle power.
>
> Is it intentional to not include this distinction?
>
>
> Dec 13, 2020, 19:45 by fl.infosrese...@gmail.com:
>
> Dear all,
>
> Following some rework to take care of comments received during the first
> voting round of pumping proposal, here is a second proposed version
> https://wiki.openstreetmap.org/wiki/Proposed_features/Pumping_proposal
>
> IanVG and I spent time to improve wording and make rationale section
> clearer.
> Classification of pumps is now done with pump_mechanism and is still
> equivalent to which available on Wikipedia. Numerous references are made
> toward it.
>
> Additional examples and illustrating gifs have been added at the bottom as
> well.
>
> This message opens a second RFC period and is expected to be shorter. Vote
> could begin by next Saturday.
>
> Best regards
>
> François
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Volker Schmidt]

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

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

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




Virus-free.
www.avast.com

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

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

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

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

[Volker Schmidt]

My apologies, wrong link!
The corner guard stone is here:
https://www.mapillary.com/map/im/USu9htX8nw95mW77kSeZ7Q

Volker

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

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

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

[Volker Schmidt]

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

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

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

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

[Volker Schmidt]

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

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


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

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

[Tagging] Many historic=wayside_cross are not historic

[Volker Schmidt]

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

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

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

[Volker Schmidt]

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


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

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

Re: [Tagging] Feature Proposal - RFC - Hazards

[Volker Schmidt]

Traffic lights triggered by avalanches! Is that close enough, Martin?

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

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

Volker

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

>
> >
> > Also at much larger airports. Brize Norton
> > (https://en.wikipedia.org/wiki/RAF_Brize_Norton), for example.
>
>
> you guys are finding real world examples for every weird situation that
> nobody expected to even exist. Traffic lights for rock fall somewhere?
>
> Cheers Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Hazards

[Volker Schmidt]

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

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

Signed hazards should be mapped.

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

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

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

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

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

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


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

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

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

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

Volker


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

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

Re: [Tagging] Animal trails

[Volker Schmidt]

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

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

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

[Tagging] Segregated foot-cycle path with different surfaces

[Volker Schmidt]

How do I correctly tag this way: OSM way 434742113
,  Mapillary image

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

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

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

[Volker Schmidt]

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

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




Virus-free.
www.avast.com

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

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

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

Re: [Tagging] Defining the meaning of capacity tag for tourism=camp_site

[Volker Schmidt]

Looks like a good idea.

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

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

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

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

Volker



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

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

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

[Volker Schmidt]

I am confused on what the tag electricity= is intended for.

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

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

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

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

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

Volker



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

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

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

[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?

[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?)

[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

[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?

[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

[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

[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

[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

[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?

[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

[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

[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

[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?

[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

[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

[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

[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

[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 cou

Re: [Tagging] Confusion bicycle_road <> cyclestreet

[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

[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

[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

[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

[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

[Volker Schmidt]

What about
highway=footway
bridge=yes
layer=*
bridge:structure=canopy_walkway
?


<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_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&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Canopy Walkways

[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

[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

[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&utm_source=link&utm_campaign=sig-email&utm_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=*

[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