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

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

[Volker Schmidt]

Simple mapping: covered=yes
Elaborate mapping: building=roof; layer=1 (useful if the geometry matters,
e.g. roof wider than footpath)

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

> Doing some mapping around one of the local schools & wondering about the
> best way to map covered walkways?
>
> https://www.openstreetmap.org/edit#map=19/-28.06022/153.42615
>
> A lot of skinny roofs, with highway=footway + covered=yes drawn under
> them, or simply just footway + covered, which would indicate there is a
> roof there?
>
> Is either "better"?
>
> Thanks
>
> Graeme
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Volker Schmidt]

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

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

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

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

Volker


Virus-free.
www.avast.com

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

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

[Volker Schmidt]

On Tue, 2 Jun 2020 at 09:04, Daniel Westergren  wrote:

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

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

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

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

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

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

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

Volker


Virus-free.
www.avast.com

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

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

[Volker Schmidt]

On Tue, 2 Jun 2020 at 16:54, Tod Fitch  wrote:

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

I fear your translation is correct.

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

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





Virus-free.
www.avast.com

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

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

[Volker Schmidt]

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

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

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




<https://www.avast.com/sig-email?utm_medium=email&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 Wed, 3 Jun 2020 at 07:05, Mark Wagner  wrote:

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

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

[Volker Schmidt]

I need to reopen this thread.

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

Volker

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

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

Re: [Tagging] Feature Proposal - Voting - electric_bicycle and speed_pedelec

[Volker Schmidt]

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

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

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

[Volker Schmidt]

Warin, Jack,

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

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

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


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

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

Re: [Tagging] Feature Proposal - Voting - electric_bicycle and speed_pedelec

[Volker Schmidt]

I missed the voting deadline.-my apologies.

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

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

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

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

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

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

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

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

Regards

Volker

Volker


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

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

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

[Volker Schmidt]

Two points to get this thread back on track:

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

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



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

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

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

[Volker Schmidt]

On Wed, 10 Jun 2020 at 17:45, Jack Armstrong  wrote:

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

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

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

[Volker Schmidt]

 > Using electrified=rail to mean 3 rails and having a sub-tag for 4 rails
is a bad
thing.

+1

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

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

[Volker Schmidt]

On Wed, 10 Jun 2020 at 19:41, Tod Fitch  wrote:


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

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

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


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

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

[Volker Schmidt]

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


Virus-free.
www.avast.com

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

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

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

Re: [Tagging] nhd tags - documentation page review

[Volker Schmidt]

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

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


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

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


Virus-free.
www.avast.com

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

Re: [Tagging] Rail segment in a bike route

[Volker Schmidt]

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

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

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

Re: [Tagging] Milk Churn Stands

[Volker Schmidt]

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

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

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

Re: [Tagging] Milk Churn Stands

[Volker Schmidt]

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



Virus-free.
www.avast.com

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

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

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

Re: [Tagging] Milk Churn Stands

[Volker Schmidt]

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

<https://www.avast.com/sig-email?utm_medium=email&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 Sun, 21 Jun 2020 at 15:09, Paul Allen  wrote:

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

Re: [Tagging] Milk Churn Stands

[Volker Schmidt]

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

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

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

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

[Volker Schmidt]

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


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

>
>
> sent from a phone
>
> > On 15. Jan 2020, at 12:05, Mateusz Konieczny 
> wrote:
> >
> > Pedestrian walking on the carriageway or shoulder is obligated to walk
> on the left side of the road.
>
>
> right. Now show me a oneway street that hasn’t a left side ;-)
>
> Cheers Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Volker Schmidt]

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

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

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

Re: [Tagging] site relations for city walls?

[Volker Schmidt]

I do consider a site relation a fitting approach for a city wall.

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

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

Re: [Tagging] network tag on route relations

[Volker Schmidt]

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


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

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

Similarly tiered systems exist in the Netherlands and Germany.

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

Volker (Italy)






Virus-free.
www.avast.com

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

Re: [Tagging] site relations for city walls?

[Volker Schmidt]

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

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

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

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

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

Volker






Virus-free.
www.avast.com

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

Re: [Tagging] site relations for city walls?

[Volker Schmidt]

On Mon, 13 Jul 2020 at 22:56, Martin Koppenhoefer 
wrote:

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

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

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

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


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

Volker


Virus-free.
www.avast.com

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

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

[Volker Schmidt]

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

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

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

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

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

[Volker Schmidt]

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

Volker

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

>
>
> sent from a phone
>
> > On 14. Jul 2020, at 17:36, mbranco2  wrote:
> >
> > Unluckily it's only about part of Europe (from 62°N to 28°S, from 14°W
> to 29°E)
>
> > The working scale of the project was 1/10, and the smallest mapping
> unit was 25 hectares.
>
>
> thank you for mentioning significant specification details and coverage
> area, these alone should demonstrate that CORINE data is not useful for
> inclusion in OpenStreetMap and it is probably also not helpful to copy the
> definitions for landcover from.
>
> Cheers Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] site relations for city walls?

[Volker Schmidt]

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

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




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

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

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

[Volker Schmidt]

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

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

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

Re: [Tagging] Waterway equivalent of noexit=yes?

[Volker Schmidt]

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



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

>
>
> sent from a phone
>
> > On 18. Jul 2020, at 20:42, Alan Mackie  wrote:
> >
> > The closest I can find on the wiki is manhole=drain?
>
>
> but this is for manholes, not suitable for small grates where a person can
> not enter.
>
> Cheers Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Waterway equivalent of noexit=yes?

[Volker Schmidt]

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

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

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

Re: [Tagging] Riverbanks

[Volker Schmidt]

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

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

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

Re: [Tagging] Farmlands subject to rotation of crops

[Volker Schmidt]

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

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

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

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

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

[Volker Schmidt]

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

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

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




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

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

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

[Volker Schmidt]

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

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

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

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

[Volker Schmidt]

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

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

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

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

[Volker Schmidt]

Guidebooks in a hiking/cycling route should be fine, provided they carry
the role=guidepost tag.

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

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

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

[Volker Schmidt]

On Wed, 22 Jul 2020 at 22:51, bkil  wrote:

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

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

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

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

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

Re: [Tagging] amenity=customer_service RFC

[Volker Schmidt]

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



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

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

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

[Volker Schmidt]

... and if the fingers are nailed on a shed, a common practice in the
mountains around here?
No post? Or the building is the post?


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

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

Re: [Tagging] amenity=customer_service RFC

[Volker Schmidt]

Careful with "access".
access=customers on an office building would imply you can drive into this
building with any means of transport, provided you are a customer.

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

> On Thu, Jul 23, 2020 at 3:39 PM Volker Schmidt  wrote:
>
>> So it would have to be customer_service=yes|no at least.
>> That would also permit to check which offices have been evaluated by
>> mappers for the presence or less of customer_service.
>>
>>
> access=customers/private would also solve this without having to invent a
> new top level tag.
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] kerb=regular vs. raised

[Volker Schmidt]

Problem: what is "regular" ?
(and hence: what is "raised" and "lowered" ?)

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



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

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

Re: [Tagging] kerb=regular vs. raised

[Volker Schmidt]

Please revert this wiki change.
The kerb hight values have been used in at least one project documenting
wheelchair accessibility.

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

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

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

[Volker Schmidt]

On Tue, 4 Aug 2020 at 16:27, David Dean  wrote:

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

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

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

Volker


Virus-free.
www.avast.com

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

Re: [Tagging] new page for tree_lined=*

[Volker Schmidt]

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

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

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

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


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

Re: [Tagging] 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

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

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

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

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

[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] "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

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]

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

[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] "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

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

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

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

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

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

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

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