Re: [Tagging] Basic cartography features missing, why?

2020-11-08 Thread Allroads
Toponym key
Used at a import.
Toponyms are used to still be able to apply a name = * to a large area, even if 
this has been divided into tens to hundreds of small pieces due to the import.
The existing AND polygons with a name = * will remain, but will be tagged to 
landuse = forest of natural = wood with a name convert to toponym = forest + 
area = yes.

Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - parking=street_side

2020-10-25 Thread Allroads

All landuse what is used for legally public roads, laid down in a zoning 
plan by the Government "bestemmingsplan" should be called landuse=highway
no, because the content of a bestemmingsplan is what is politically desired 
and legally permitted, it is a plan. Landuse is not about the zoning plan, 
it is about the actual current landuse, regardless of its compatibility 
with the legal situation.

That's the irrevocable plan, then all is shaped.

For Netherlands  law 
describing what belongs to a road.

wegen: alle voor het openbaar verkeer openstaande wegen of paden met 
inbegrip van de daarin liggende bruggen en duikers en de tot die wegen 
behorende paden en bermen of zijkanten;

roads: all roads or paths open to public traffic, including bridges and 
culverts situated therein and the paths and verges or sides belonging to 
those roads;

All landuse=highway.

Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - parking=street_side

2020-10-25 Thread Allroads

For me,  the value "parking_space" what key, single space problem must
be fixed first to say something about "street_side". As it comes to a 

Could you elaborate?

amenity=parking_space can be used as usual within amenity=parking. This
of course also works with amenity=parking/parking=street_side:

Our proposal doesn't affect the documented use of amenity=parking_space;
you would use it just the same as with parking=surface.

Reading parts over the years about parking.
A lot of people do no see amenity=parking as a good tag for street side 

Mainly prompted by wiki (image) en carto, the visualisation of P. street side parking is the only 
method in given on this page.
The main tag covering most conventional car parks, coach parks etc. Many 
additional tags are listed on this page.

We will always have that opposition.
Also a question for me, must we split the tagging there, when we still can.
amenity is mostly with a sign

amenity=parking_space can only be tagged on a amenity=parking?
Why is this a relation and not only polygon tagging. (That is a other 
discussion, but rubs against it)

If some, we, not use amenity=parking, how to tag the parking_space as a 

There spots, where people park in the verge, on the grass, or other surface 
grass_paver, what is permitted. In or outside the residential area. ( 
"bebouwde kom") 
have not a effect on the verge, the EU rule is no_parking on the 
carriageway. The operating force of a traffic sign may not be expanded. 
Outside the residential area "bebouwde kom" it is prohibited to park on the 
carriageway, but not on the verge.

How do we do that with parking, amenity=parking?

Also the structure of the area:highway methodology, which needs to be 
further developed in detail.
All landuse what is used for legally public roads, laid down in a zoning 
plan by the Government "bestemmingsplan" should be called landuse=highway, 
inside this polygon the objects are area:highway

There is area:highway=traffic_island
there should be area:highway=verge, the busbay is also not well documented. the polygon equivalent is 
area:highway=shoulder. the polygon equivalent is 
area:highway=verge (verge:access:motorcar=no when parking on the verge is 
expressly prohibited.)

But there is this used area:highway=parking_space, and not for only one 
space. What a space should be.

area:highway is a used key.
All these parking area, should get a tag area:highway, but which? Or both 
amenity=parking. Or is amenity parking only for lots. ["area:highway"="parking_space"] or is it 
area:highway=service service=parking_space if it is one space, with multiple 
not drawn in space, service=parking.

That is why I wrote.

For me,

The search for good cohesion. 

Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - parking=street_side

2020-10-24 Thread Allroads

The two methods:

1. Tagging on the way line. When a road, highway=*
2. Tagging a polygon. When a road, area:highway=*

Will always be used next to each other. We have to take that into account.

New mappers, see a parking plot/space and want to draw that in, that is 
logical behaviour. It is obvious for them to draw a polygon. And want them 
to see on a map.
It is not obvious for them to tag parking:lane on a highway=*, the method 
for wayline parking.  Originated with the first development of 
Openstreetmap, then the system evolved, area:highway was developed later.
We must give them the opportunity to do so, polygon mapping. Topographical 

Also for on the lane parking, we need the polygon to draw in, because space 
lines are painted on the road or different paving, indicating parking 
spaces, parking traffic signs refer to it.

In the mind of general people there is no difference on the carriageway or 
beside, for them it is both street side parking. street_side is also on the 
lane parking. It is more a general term. (I think, maybe more for not native 
UK people).
Do not make a difference between carriageway (painted, surfaced) and beside 
parking by choosing street_side  value as a tag for one (beside).

Polygon: Where the transportation modes can walk/ride/drive on a polygon, we 
tag area:highway=* ,  that is a base tag.

On a way, highway=* we have residential and service and 
service=parking_aisle, this is on a amenity=parking.

For a polygon on lane and beside we have area:highway=service, even when you 
draw in a amenity parking, you have area:highway, there the lane is 
area:highway=service service=parking_aisle, parking spaces are a kind of 

The plot/space on a amenity=parking, , there is 
no much visual difference, when there is a parking_space on a amenity and or 
on the (marked parking) carriageway or beside parking.

The value should/could also be used. There everywhere, places for disabled 
parking and electric parkin a spaces

On the lane road with no marking, there is only  the (1.) wayline tagging, 
parking:lane possible,

A carriageway, can have,
wayline tagging highway=residential with parking:lane=no_parking,
polygon highway tagging area:highway=residential, the lane to 
polygon parking tagging area:highway=service service=parking 
parking=street_side on lane and beside parking:condition=free

In this example there is a no_parking traffic_sign on both side of the road,
EU rules, determine that such traffic_sign, no_parking  only prohibited 
parking on the lane, and not the marked parking spaces or the verge. So w 
must have the opportunity to tag it properly, this is a example both methods 
of tagging are needed (line polygon).

Use area:highway for polygon and parking!

The combination area:highway=service and service=parking, should be enough 
indication for the render to not set a P. (Carto) Even when there is a 
amenity=parking is set. (wrongly?)
parking= street_side could be used there is no conflict parking=* on amenity 
with parking

The only point for me is, can also the value "parking_space" be used, with 
what key? area:highway=service service=parking parking=parking_space(?) (Do 
we need street_side?) Or is it parking:street_side=parallel
People, want to draw in a single space. We have to take that into account. 
But others draw in several spaces as a one object, parking_space, this is 
not correct.
It must be clear that there is a single spot. Somewhere the value 
"parking_space" must fit in.

parking_space=disabled, this must not be different then on a 
amenity=parking, if, that is confusing for a lot of people ( taggers), now 
with electric cars there lots op spaces where only they can park, 
traffic_sign prohibition next to the space, single space are more drawn in 
the future. Prohibited access on the space.
Netherlands Government, are going to draw in all these spaces, each space 
get a ref, for linked data, the cost of electric charging, and more.
Amenity parking and carriageway parking, space tagging must be with the same 
tags. If they look the same and the use is the same.

So, we must prepared for more detailed mapping.

This kind of tagging is almost impossible on a wayline, all these way cuts, 
visualisation and control the data. A polygon visualisation is more clear.

For me,  the value "parking_space" what key, single space problem must be 
fixed first to say something about "street_side". As it comes to a vote. 

Tagging mailing list

Re: [Tagging] Link to stream of webcam

2020-09-04 Thread Allroads
It is important to mention the website with the embedded stream.
But also the stream itself for direct use.   
Sometimes multiple different extension streams are available for different kind 
off devices.
Such as radio stations with a webcam stream.
Live streams.
Image streams with from time to time a update.

From: Jmapb via Tagging 
Sent: Friday, September 4, 2020 11:16 PM
Cc: Jmapb 
Subject: Re: [Tagging] Link to stream of webcam

What's wrong with just url=*? To quote the url=* wiki page, "it is advised not 
to use this tag when more specific alternatives are available." Like website=*, 
it doesn't specify that it's a camera feed, so it might be used for other 
purposes. And in fact I happened to see a couple of nodes using url=* for 
picture *of* the camera, rather than pictures taken by the camera.

Tagging mailing list

Re: [Tagging] How to map "piers" on land?

2020-07-28 Thread Allroads
Could be a groundy path go over in a bridge=boardwalk, change material, change 
fixation to a pier, a pier could also be floating.

From: Paul Allen 
Sent: Tuesday, July 28, 2020 10:09 PM
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] How to map "piers" on land?

On Tue, 28 Jul 2020 at 20:44, Matthew Woehlke  wrote:

  Please see This is a pier 
  with a platform on land that extends into the water. Carto cuts off the 
  part that is on land.

There is no part of a pier on land.  Not according to the wiki: "A pier is a 
walkway over water..." and "Lastly, connect the pier with other ways on land,
otherwise it will result in a "island" that can't be used for routing."  The 
then goes on to give a misleading or contradictory mention to connecting
to the last node of the pier on land.

Since your pier connects to a footpath, replace the bit of the pier on land
with a closed way tagged area=yes + highway=pedestrian, or similar
(I don't know if area=yes + highway=footway works).  Just because
the surface the person walks on is continuous doesn't make the bit
that's on land a pier.



Tagging mailing list
Tagging mailing list

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

2020-07-25 Thread Allroads
with extra text, for pushing carry a bicycle. 
"fietsen meenemen niet toegestaan"
"not allowed to bring bicycles"

This is a privat acces_sign, guaranteed by access law, expressed by “access in 
an apparently way for him is prohibited by the rightholder”.
They use look a like smaller traffic_sign images. To express, that you can not 
bring a bicycle.

Traffic_signs have have agreed sizes.

I mentioned bicycle=explicit_no, here is a sign that give the explicit reason 
on a sign.
But I am now aware that does not fit every situation for a hard no, the 
combination, different laws working next to each other asked for a hard no. But 
it is not explicit on a sign.

Need a better value for all transportation modes, I hope we do not get for each 
transportation mode a new key, this is not a decision only for bicycles. 
riding/driving, shuffling, carrying, transportation, inside vehicle, outside 
(roof, backside, trailer). (if possible)

The earlier mentioned,
This is for me, leave the bicycle behind at the sign.
More native English speakers can give a comment on that?

So, now we need also a hard yes. That you must bring a bicycle with you.

Tagging mailing list
Tagging mailing list

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

2020-07-22 Thread Allroads
The image are  traffic_signs, described in traffic law. Traffic_signs must have 
set dimensions.

There is also property access rules mentioned in law. Art. 461 in Wetboek van 

The owner can express by sign with text, images, sometimes they use familiar 
images. Like here. 
“Hij die, zonder daartoe gerechtigd te zijn, zich op eens anders grond waarvan 
de toegang op een voor hem blijkbare wijze door de rechthebbende is verboden, 
bevindt of daar vee laat lopen, wordt gestraft met geldboete van de eerste 
express “access in an apparently way for him is prohibited by the 
rightholder”..“is punishable by a fine of the first category”
This is a access_sign. NOT a traffic_sign.
“fietsen meenemen niet toegestaan”
bicycles are not allowed
here you need a hard bicycle=no.

Other situation:
Area rules, a access_sign, property access rules mentioned in law. Art. Wetboek 
van Strafrecht.
owner express “in an apparently way for him” He choose the icons. free walking 
( also next to the road )

The last not translated sentence.
“In andere gevallen verboden toegang Art. 461 Wetboek van Strafrecht.”
“In other cases prohibited access” 
With a horse, riders on designated path. Riders is mentioned, corresponding to 
the image
With a horse, walk with a horse. I do not see such image. horse with a leash. 
It is forbidden.
Where walking freely is allowed,  everywhere, you can not walk with a horse, 
because “In other cases prohibited access” no horse with a leash, there the 
horse is a hard no.
Even this asphalt road. When it is no designated path.

The owner determined. Sometimes it doesn't make sense.
We must follow, what he express,“in an apparently way for him”.
Otherwise you are in violation.

From: bkil 
Sent: Wednesday, July 22, 2020 10:49 PM
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] Is there a good way to indicate "pushing bicycle not 
allowed here"?

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 

bicycle=no is usually used on busy motorways where dismounting isn't feasible:

Tagging mailing list
Tagging mailing list

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

2020-07-22 Thread Allroads
It is annoying for me too.

A router discussion.
Talk about a situation the use of use_sidepath and dismount. And the 
bicycle=no, which is not a hard no.
Some qoutes.
“Hm, but in very most cases, bicycle=no is used effectively in sense of 
bicycle=dismount, not in in sense No bicycles here.”
“In my experience, bicycle=dismount is used very rarely, mostly if there is an 
explicit request to do it, in agreement with OSM intention for short way 
segments only, like e.g. narrow bridges, passes, collision danger etc.”
The only relevant interpretation of bicycle=no is the OSM tagging intention, 
not what I or you think about it. And that is clear - red/white traffic sign 
with a black bicycle, or legal equivalent.

The routing itself is for bikers, not bicycles. Pushing bicycle is a legal and 
frequent mode of bicycle transportation. Bikers may then use such profiles that 
either penalize it either forbide it ( CF=1 for total ignoring, or  for 
navigation hint consideration )”

Nothing changed.

What they saying is, it is common accepted, OSM intention. bicycle=dismount is 
not often used, but very often should it be used, so routers take the common 
accepted. =no also = dismount. A hell of a job to set all these =dismount, 
tagging, what is really prohibited is better, OSM method. (new value?). 

Talking to route developers is now  a past station! Conclusion: no is not a 
hard no. Unfortunately, we must go further. A new value! This not only a 
bicycle problem.


No, new access key
dismounted_bicycle all others must also have a equivalent, unworkable, more 
typing. Better one value, that fits all, fits the access systematic hierarchy.
You must always look at this hierarchy to make routing decisions.
The choose for a key make everything more complicated.
Also for visualization. 

From: Tod Fitch 
Sent: Wednesday, July 22, 2020 4:53 PM
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] Is there a good way to indicate "pushing bicycle not 
allowed here"?

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.


Tagging mailing list
Tagging mailing list

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

2020-07-22 Thread Allroads
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
- 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 
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 


  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 

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 mailing list

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

2020-07-21 Thread Allroads
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!
horse_pushed=no ;-)

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

I need this value to do it correctly. Where the bicycle is no allowed. Or a 
other value meaning the same.
Tagging mailing list

Re: [Tagging] source=RTK_GNSS

2020-07-21 Thread Allroads
Thanks for the accuracy link

“you should mark the approximate accuracy of the given measurement as returned 
by the instrument in the given instant.”

That is also better.

It is just, that you get a hint, source, accuracy, that the data is measured 
in. Before you drag a node.___
Tagging mailing list

[Tagging] source=RTK_GNSS

2020-07-21 Thread Allroads
There is data, what is measured.

With RTK GNSS, there is 1cm accuracy possible.

Should we tag this mapped data, so that we know the accurancy level of this 

Greetings Allroads.___
Tagging mailing list

Re: [Tagging] Tagging small areas of bushes, flowers, non-woody perennials, succulents, etc

2020-02-10 Thread Allroads
+1 landcover

+1 on a hierarchy index and a well and a thoughtful methodology.

landuse, should describe more the use of the land.

For example:
A road, this include the footway, cycleway, the verge, the barriers, 
traffic_islands, the trees.
The verge, that is a part of the use, landuse=highway, the area is 
area:highway=verge, landcover=grass, landcover fits in nicely. And how it is 
managed can be set.
The hedge as, a separation between road parts, can be a part of 
landuse=highway, area:barrier=hedge, hedge_type=? landcover=shrubbery/or else, 
species. And how it is managed can be set.
The hedges on traffic_island, roundabouts, is a part of the landuse=highway , 
is a part of a area:highway=traffic_island, is the area:barrier=hedge, 
hedge_type=? landcover=shrubbery/or else, species.
The same for flowerbeds, etc.
The apron at a roundabout. 
At the end all parts must be named.
greenery versus shrubbery, is it the same or is the one a part of the other? 
hierarchy thinking.
From: Peter Elderson 
Sent: Sunday, February 9, 2020 11:59 AM
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] Tagging small areas of bushes, flowers, non-woody 
perennials, succulents, etc

The landcover key covers this nicely. 

Tagging mailing list
Tagging mailing list

[Tagging] key, name, long or a partial abbreviation?

2020-01-27 Thread Allroads
This is a question only about how to choose a new keyname.

Is it possible to use a partial abbriviation?

For example:

There is motor_vehicle, with one underscore.
to express a categrory with a more then one track or more then 2 wheels.
We can choose for:
multi_tracked_motor_vehicle, with 3 underscore, quite a long name to type in, 
must that be avoided?

Avoid long names with multiple underscore.
Which weighs heavier when considering a name.

Is it allowed to choose for?
partial abbriviation, “mt” stands for multi_tracked
Does this express the category well enough?
Do people understand that?

When there is a mt_motor_vehicle, there is “st” partial abbriviation, 

Is it a “do” or is it a “don’t”.

Give me your opinion.

Tagging mailing list

Re: [Tagging] footway=crossing in detailed tagging

2019-12-15 Thread Allroads

On 15/12/19 12:30, Mateusz Konieczny wrote:
Let's say that we have footway mapped separately from the road, road has 
footways on both sides.

Footway has surface=paving_stones, road has surface=asphalt.

There is a crossing, made from three ways:
- (1) highway=footway surface=paving_stones (for a bit from centerline of 
sidewalk to the curb)

- (2) highway=footway surface=asphalt (for part on the carriageway)
- (3) again highway=footway surface=paving_stones for part from curb to 
the centerline

How footway=crossing tag should be applied?

To all three or just carriageway surface - (2) segment?

in my opinion there should be no doubt in assigning only to 2, from kerb to 


Agree, from kerb to kerb. Is the most correct to do it.
If people draw in (in the future) a area:highway=* inside this area:highway 
the surface on the highway and area must be equal.
Because people started to draw in, I liked to see what is drawn in. 
(Experimental style)

A image say, give you a hint, much more then a writing.

dark red yes is crossing:island=yes


Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - Small electric vehicles

2019-12-12 Thread Allroads
As I wrote earlier:
>>So I must make a icon for speedpedelec, for use my style.
>>This is needed because, government write speedpedelec with text on 
>>traffic_sign (undersigns). Even estate owners could make signs with 
At the bottom of the diagram speed_pedelec is needed, because govenment use 
then a text (or which icon) on traffic_sign.
A direct translation is needed.

Key is needed.

In the Netherlands a speed_pedelec is a moped, by rule, follow the rules of 
moped, BUT, then the govenment can use the text speed_pedelec to express a 
other behavour,  “uitgezonderd” except.
The base tag speed_pedelec must be there.

*: electric=* This have nothing to do with base tag of a vehicle. There could 
be speed_pedelec:electric=yes. Maybe in the future a other kind of power is 

So I did not say moped:electric= is a speed_pedelec, moped:electric can be a 
much bigger group. Earlier I posted a link with “special mopeds”
In the Netherlands the speed_pedelec must know that they have to follow the 
moped rules, so also moped:electric=yes. He can use that road.

So is a segway, is also a moped. Because in text or icon, prohibited.
Key segway or a other key?  Does a icon that looks like a segway mean a bigger 
group ( the motorcar problem, this mus be avoided )

Then there are hoverboards (self-ballancing scooter)

All small electric vehicles. How to put them in a access diagram?

Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - Small electric vehicles

2019-12-11 Thread Allroads
>.>they? Why didn’t you do something about it? 
> (or are you asking for bicycles with sidecars?)
>generally I agree, exceptions apply. In the motorcar example they are grounded 
>in real life particularities (best reason I’d say).

I am a part of the they, then it was not within my area of focus, scope, in the 
given time range when it originated and was implemented, now after a while we 
all have more knowledge, then the question is how we can solve it in a way that 
does justice to, where the tagged does not be destroyed in such a way, that it 
remains applicable. That is my approach now.
So leave motorcar as it is, people who want to use it, because it is used so 
Don't let us stop implementing the following.
Give people the opportunity, to tag more correctly, this means for me the 
introduction of multi_tracked_motor_vehicle, /mt_motor_vehicle. This does 
justice to the principle “generally I agree”. 

Where I am working on: 
Traffic_sign translation. I miss keys for transportation, to make a tag 
combination. So I am interested in the access diagram.
Ended up to make a style, to see and control the tags. Get hints in Josm 
Far from ready. Under construction. I must totally rewrite it, because of new 
insights, new wishes, things are not possible in mapcss and still learning, 
time as stumbling block.
Focus on road tagging.

When it comes to a voting about a key/value.
Give people the opportunity, to tag more correctly, at a voting, which 
arguments are more important. Saying “no” “yes”, the why is more important.
When I make a proposal, multi_tracked_motor_vehicle. Many are fine with 
motorcar, If they do not see the need for others and there vote is “no”, this 
“no” has for me a lesser value.
This could have a negative effect on the development of OSM.
Which interest is greater than the others, what to decide.

Lately I wrote down for myself some thoughts. 
1. A traffic sign (combination) should preferably be tagged with as few tags as 
2. A traffic sign should preferably be tagged as directly as possible with tags.
3. Neutralizing, opposite tagging should be avoided as much as possible.
4. The diagram access hierarchy is not complete, missing keys.
5. When developing key value, the decision hierarchy must be considered.
6. Every way of transport must have equal opportunities to achieve good routing.
7. Possible conflicting keys/value must be solved. (Dual explanation).
8. A traffic signs wiki is very important. (Also combination signs on pages.) 
Carefully selected, customized for possibility of use in presets.

multi_tracked_motor_vehicle, the possibility of use, used in presets, (it is a 
correct key) maybe over 10-15 years, we see, it is a established key, more 
important then motorcar. ;-) The life of a key. Mission accomplished.
Give it a try?

So I must make a icon for speedpedelec, for use my style.
This is needed because, government write speedpedelec with text on traffic_sign 
(undersigns). Even estate owners could make signs with ..

small electric vehicles, as a group, which vehicles, where is it placed in the 
hierachy, which icon should I use.
hydrogen, ...must these vehicle have also their own group? (future)

or is a key needed that gives which type of motor is used.

moped=no  and moped:electric=yes

In the Nedertherlands on a G13 traffic_sign “not mandatory cycleway” a mofa can 
use it, BUT, ..
“Bestuurders van snorfietsen uitgerust met een verbrandingsmotor mogen het 
onverplichte fietspad slechts gebruiken met uitgeschakelde motor.”
“Drivers of light mopeds equipped with an internal combustion engine may only 
use the non-mandatory cycle path with the engine switched off.”
This means that you can use it with a electric motor or bicycle pedals (if on 
it), manually.
Then the access is mofa=no mofa:electric=yes mofa:manual=yes.
This is a translation of a traffic_sign and law rules.

*:electric=* is lower in hierarchy  not used yet,

Is this better to appoint electric use?

I think so it could also be used for all type of vehicles.

See the practise of emission zones and rules, what we see translated on 
traffic_signs. even the age of a 
vehicle is now used.

Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - Small electric vehicles

2019-12-10 Thread Allroads
>it really depends. I guess we agree that the meaning of tags in OSM is based 
>on their common usage, so motorcar=yes means an automobile (i.e. not including 
>for example busses or trucks), while motorcar=no means any multi-tracked 
>motorized vehicle is excluded (implies hgv=no, tourist_bus=no, etc.).
>This is based on the legal meaning of the common traffic signs that get 
>translated into this tag (and may be different in some jurisdictions, I am 
>only referring to places I know, i.e. western / central Europe).
I disagree.
I used this as example, that a key must have distinct meaning, that is in OSM a 
common practice. The method is more decisive, more important. 
If you see the beginning of the key motorcar in the wiki, it was only 
automobiles, because of motorcar abuse, they wrote the controversy in it. A 
problem to be solved. We all know how a wiki developed, evaluates, a few can 
change the content. They did not want to solve the problem then. There are 
quite a few mappers, who are annoyed by this.
Now you have a sidecar, it is a motorcycle but also multitracked vehicle. This 
get very complicated to write a routing and parking script for sidecars.
This is a disadvantage for the sidecar group.
I believe each category must have equivalent method of treatment. In 
particular, it should not work to a disadvantage.
“The meaning of tags”, is a key/value combination, both key and value must be 
distinctive, so the combination can not mean something else, waht both say. 
Contradiction must be avoided. That is common method usage.
If I ask a lot of people about the method, than the outcome is your right. So 
the motorcar usage is not common practice, it is a problem.
It is a bit off topic, it is a example, how things can go wrong.
That is my message in this topic.
The development of new key / value tags, must meet certain method conditions.
In the Netherlands, the Government have a group “Bijzondere bromfietsen”  
special moped
See the links in the list
Some of them are electric.
How must they fit in the access hierarchy?___
Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - footway=link

2019-12-10 Thread Allroads

Why should we need to tag the part of the path inside road area
specifically (e.g. as footway=connection), but not the part of the
track inside the road area?

(e.g. as path=connection)

Yes, why, that I asked myself too! Why, use it everywhere. It could be used

That is why we discuss it here, to figure out, what is necessary or not and

The original question for me was, what to use as a equivalent for a
*=crossing, that is a T connection.
From kerb to middle wayline.

In other cases, is there the need to use it also?

Openstreetmap, is always to find a balance, where to tag something or not.
Not every tag have to be set everywhere, sometimes it is so obvious, in some
cases it is useful, tagger decide where.
I work as a volunteer tagging for a project "traveling independently" for
people with an intellectual disability, people with a brain injury, people
with a psychiatric disorder or seniors. "Learned early, gives confidence, 
gives independence".

On their daily traveling, now there picked up by a privat (taxi) bus from
home and bring to the accommodation, they often go to. This cost also a lot
of money. Parents does not have they time often.

At kerb, what (voice) note, "step on the road" "step on the footway" both
side of the kerb is a highway=footway. Which direction, which call.
footway=connection is a option.

Comparing with, at the area:highway=* inside the polygon, can I draw the
conclusion, that we must split, not going for one value, because it's
different in behavior, because, the carriageway and the sidepath, there is a
hierarchy, how we look at them, use them.
Cycleway and sidepath, also a hierarchy between them.

Outside of the box: (mind triggering)
We do not tag in a polygon area:highway=unclassified, the part inside the
polygon, highway=track track=crossing crossing=unmarked.
This is what I mean find the balance of using a value, where it is more
appropriate, our decision have something to do with how we feel about the


Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - Small electric vehicles

2019-12-10 Thread Allroads
Together with the introduction of the new tag, would it also be possible to 
have a new access category tag that contains all singe-tracked motorized 

The hierarchy in access is important, very important for routing. (their 
scripts). Changing, hierarchy have a major impact!!

The hierarchy in a diagram. 
From German access page.

Now, where does it fit in.

Laws in countries are different.
Does the speedpedelec gets its own icon by law, a own prohibition sign, or 
is it just text at a undersign.

A undersign often tells by text or icon, that the above sign, leading sign, 
the rule for a group "does or does not" not apply to those mentioned on the 
bottom plate (undersign).
The conclusion is that the mentioned is part of the category mentionedon the 
leading sign (prohibition sign)

A yellow plate is a moped plate, so in the hierarchy the speedpedelec is a 
moped and then The Netherlands it is under de "bromfiets" moped icon in 

oneway:moped=no in the Netherlands, also applies to the speedpedelec,

If you want a single_tracked_motor_vehicle, the logic says then there is 
also a double_tracked_motor_vehicle, long name dt_motor_verhicle.

double_tracked_motor_vehicle os probably not right.
Laws often speak about "more then two wheels" or "more then one tracked 
vehicles, a treewheeler, then a 
tag like multi_tracked_motor_vehicle or mt_motor_vehicle would be 
multi_tracked_motor_vehicle, solve the problem of abusive use of motorcar, 
which is a personal car. Not a total group of vehicles on two wheels. Major 
hierarchy impact for routing systems.
Back to single_tracked_motor_vehicle, st_motor_vehicle, this also means a 
motorcycle, this key is good for inclusive motorcycle.

motor_vehicle, include always, moped, mofa, motorcycle, and much more, also
We also have disabled vehicles, like a wheelchair, but also motorized 
disabled vehicle, which are not a "bromfiets" moped. " RFC - Small electric 
vehicles" also included?
Then you get disabled_vehicle and also disabled_motor_vehicle. Al must fit 
in the hierarchy of access.
These categories are mentioned on prohibitions traffic_signs C13 C15

Find out in which countries a speedpedelec is a moped, where not, how this 
must be placed in the access diagram.

C12 tagging: motor_vehicle=no & motorcycle=yes & moped=yes & mofa=yes & 
The problem is the needed opposite tagging, to exclude from motor_vehicle, a 
multi_tracked_motor_vehicle would be welcome.
Now we see, that often for small groups categories the tagging is not 
correct. A negative effect for those. Better to avoid "these needed 
opposite" tagging.
This argument gives impulse to use good overthought collective categories, 
such as dt_motor_vehicle, st_motor_vehicles.

A group for moped and mofa, difficult, these are 
low_speed_single_tracked_motor_vehicle. lsst_motor_vehicle. Just a thought.

Overall it is not easy to place new categories in the middle of the access 

This have a major impact in routing scripts.

Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - footway=link

2019-12-08 Thread Allroads
Took the wrong link.

Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - footway=link

2019-12-08 Thread Allroads


I made a mistake. i thought it was a pedestrian square, but it is a 
livingstreet, so a T connection from steps to middle livingstreet 

This need a *=connection  value tag.

My mistake, there you see difference livingstreet and pedestrian area, 

Mostly in a livingstreet there is a kind of lane created with different 
stones to guide the vehicles.
Besides this lane, could we speak of a sidewalk or more a pedestrian zone. 

Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - footway=link

2019-12-08 Thread Allroads

Markus example:

Let's use a nearby example:

It does not matter if the stairs are parallel or not!

Draw this image over the example, JOSM changes (not uploaded) drawn in.
The area:highway=footway is correctly drawn in, but the footway is all 
footway=sidewalk, your still walking on the sidewalk.

In a area we draw lines like this highway=pedestrain area:yes example, 
area=yes should give area routing.
This image comes from this site:

Only way lines inside a area:highway=*, which have "not" equivalent value, 
should get the value, *=connection or link. Nothing else. We need this tag 
only from kerb to middle wayline carriageway, and can be used for 
pedestrian, footway, path, cycleway if there is the need to use it.
*=crossing value is cleary defined, *=connection must be the equivalent of 
*=crossing, at T connection on carriageways. This must also be clear 

(We do not draw a crossing further then the kerb of the road, so not as far 
as the middle line of the sidewalk)!!

Other perpendicular waylines inside a area:highway does not need that, if so 
then a other kind of value (I do not see the need for that)
Be aware that some people think that at a wide sidewalk, also a polygon, 
highway=footway footway=sidewalk area=yes, can be used just like the 
pedestran example ( a polygon and a wayline drwans in for pedestrian.)
When you are on a sidewalk, it feels  you are on a sidewalk, then it called 
a sidewalk.

I use my own style, far from complete, just working on sidewalk and crossing 
tags visualisation. I just missed a quick hint what is tagged.

Where do you need it, I think where kerbs are it is more important, and when 
you use area:highway, *=connection we could render visualise it slightly 



Like now, in Carto a polygon is rendered above the wayline, the example is 
area=yes pedestrian visualisation.

Nick Bolten examples:
Shelter crossing
In front of the shelter (left) (busstop?) could a highway=platfrom be used 
as a tag.
I never draw a line over a shelter. right of the shelter middle of the way 
the wayline.

Steps building
steps, perpendicular footway to steps is footway=sidewalk, when you could 
draw the polygon area:highway=footway footway=sidewalk, this is inside the 
polygon, equivalent value. So =sidewalk.


Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - footway=link

2019-11-25 Thread Allroads

Then there is a tag as placement=transition.

This have also a kind of connection link function.

When we split a road by a traffic island we use placement=transition for 
that part from middle of the road to middle of the lane.

(1) placement

 -- lane
road  ooo

I asked myself, when you go from a road to the designated cycleway, that 
connection, is that also placement=transition.

 - - - - - - - - -  cycleway

Or at a junction where cycleway have two oneway to connect.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - cycleway
   \ /
  \  / (1)
=== road

If we think about it further, where more does this tag fit?


Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - footway=link

2019-11-23 Thread Allroads
Was just a example,  to make my situation description, more understandable.
First drawn al the polygons, area:highway, then all what is inside this polygon.
Kerb as a polygon, because it is a polygon, so a polygon.
The more advanced mapping. People can choose.
If they do we must think about, that how to fit in.

This is not a lowered kerb, this is a driveway kerb and these kerbs are 
wheelchair=no, the incline of these driveway kerbs is to high.
There are rules for that.

From: Peter Elderson 
Sent: Saturday, November 23, 2019 1:07 PM
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] Feature Proposal - RFC - footway=link

Looks good. I think mapping the lowered kerb separately for simple exits is a 
bit overdone.  

Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - footway=link

2019-11-23 Thread Allroads
I worked out a visualisation image.
>From the situation I linked in my earlier post.

Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - footway=link

2019-11-22 Thread Allroads
Now your questions @ Markus.
Your example:
Example (to be displayed with a fixed-width font):

  ┃  ┆  ┃
  ┃  ┆  ┃ <- driveway
  ┃  ┆  ┃
━━┛  ┆  ┗━━
┄┄┄1┄┄┄ <- sidewalk
┈┈┈ <- residential road


>1: highway=service + service=driveway?
In my example image, same as yours, (1 horizontal),  it is highway=footway 
footway=sidewalk  ( 1 vertical) for the service road is is highway=service 
service=crossing Why service=crossing, the driveway start at the private 
property, sidewalk is public, but could be highway=service service=driveway 
driveway=crossing, Inside that polygon.
>2: highway=residential?
highway=service, but is there also a *=connection possible?

We must work things out. How to use *=connection or else.


Tagging mailing list 
Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - footway=link

2019-11-22 Thread Allroads
The variation of drawing and setting tags.
1. People draw in the carriageway road as a wayline. Wayline middle of the 
road. Exactly, where it is.
1.1 Then they decided that there is a sidewalk, on the right, tagging 
sidewalk=right, this says there is somewhere a sidewalk on the right next to 
the road. But not exactly, where it is.

2. People want to drawn in the sidewalk as a wayline next to the road, in the 
middle of the sidewalk, safe walking route. tag it: highway=footway 
footway=sidewalk. Best is to connect it !! correctly for routingpurpose!!, that 
was there goal. (kids routing on the sidewalk, the routing track line lays in 
the middle of the sidewalk, no complaints parrents.)
2.1 On the carriagewayline, the tag sidewalk=right is changed to 
sidewalk=separate. Because, routing is drawn in correctly on the sidewalk, 
routing could use that, then not  on carriage road  for pedestrian.
2.2 Also on the road wayline, foot=use_sidepath is set. !! All when 
routingconnections is well done !! Or when traffic_sign foot prohibited, foot= 
no. The routing know now it is more legal.

3. People want to draw in the sidewalk as a area. then the tag: 
area:highway=footway footway=sidewalk is set. Topographic visualisation.

All these variation of drawing must fit together.

What I wrote: inside the drawmethod 3 polygon:  (area:highway=footway 
footway=sidewalk ) only  drawmethod 2 lines can be drawn in with that specific 
tag: highway=footway footway=sidewalk, because the way line is drawn in the 
middle, there is a perpendicular part from the middlewayline to the outline of 
the polygon, where the barrier kerb is.
At this point you step on the road, there comes this new tag in operation, tag: 
highway=footway footway=link or better *=connection, you walk further on the 
road. These are T connections !!

There is one exception: 
A.  When you have a cross X connection, we speak of a crossing.
 When the polygon is crossed with a wayline by a road crossing! (mind 

Your problem drawing at a service (driveway). @ Markus

The choice, at the polygon, is it an area:polygon =service or a area: polygon 

drawmethod 3 polygon:  (area:highway=footway footway=sidewalk ) 
Now you must set your mind to a new thinking, 180 degrees, what we used to do.
Normaly, the pedestrian crossed the road. We set footway=crossing.
image example:
location :
What you see is that the sidewalk footway surface at the driveway has been 
extended, on-going. Same paving as all the footway. 30x30 paving stones. It is 
the footway.
Then the polygon is drawn in as a area:highway=footway footway=sidewalk
But at a service (driveway), there the car crosses the footway. The car must 
always give priority to the pedestrian.
The footway is more important then the service way.
So the wayline highway=service  gets “service=crossing” inside this polygon 
(area:highway=footway footway=sidewalk). That is the exception !

The driveway construction is here with a driveway kerb. But could be else too. 
Decision of the mapper.
The on-going pavement of the footway but also on a cycleway, priority of way, 
gives a different relationship to each other, ending up in saying 

In the Netherlands we have the privilege, to use Goverment data, license agreed 
with OSM.
(Site under construction) Sitemap with layers where we have a agreement on.
Zoom in, then check on, BGT standaard V2, we could use these polygons for 
See the pink colors polygon these are mostly sidewalks in a village town.
Then you see where sidewalks are on-going, and where a pedestrian must cross 
the road.
We now use these BGT layers to line out Openstreetmap highways waylines, this 
is more accurate then doing it with aerial 
(note: use map overpass uncheck with much panning and zooming)

Combining these variation of drawing in, these wayline footway=* connecting 
(link) could be used for T connections. From kerb to middle carriage road 

perpendicular: footway=sidewalk, go on the footway left to the kerb. The 
outline of the polygon.
At the kerb a disabled person must get the message, step on the road and follow 
the road to the right. Is there, this new value helping? You do not want that a 
audio message say, step on the footway and follow the footway. (this is only at 
a crossing)

Tagging mailing list
Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - footway=link

2019-11-18 Thread Allroads
When there should be a footway=link
then there should also be a

This is then a new method to tag a virtual  T connection on the road.

This must be well thought out.
Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - footway=link

2019-11-18 Thread Allroads
All waylines inside a area:highway=footway footway=sidewalk is a 
highway=footway footway=sidewalk
When there is a connection to the road, inside the area:highway=footway, 
footwalk=sidewalk is till the barrier=kerb.

Only on the road from barrier=kerb till the centerline of the road (wayline) 
could be highway=footway footway=link.

When the footway crossed the total road, then footway=crossing is used.

This is a example, where the highway=footway footway=sidewalk, is drawn till 
the barrier=kerb from a cycleway, then a unmarked crossing.

Tagging mailing list

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

2019-11-06 Thread Allroads
Their are Government rules and landowner rules.
These landowner rules are mostly expressed on the border of their land with a 
access_sign >   access_sign rules

>“typically not traffic rules but additional”
equally important
In the rural, their lots of these access_signs.
Mostly written what is prohibited.
“Access on roads and paths”
“Forbidden for bicycles”
“Forbidden for motorvehicles”

Their access_sign, with written on it, what is allowed and end with “others 
To catch all these others in tags.

Lately I was in contact with a landowner of a estate, because of financial 
benefits, he can open up the area for use, setting the rules by himself. (Their 
are regulations, what he can do or not).
Then I asked, if it is allowed to push a bicycle. No, you are not. And this is 
very common on many nature reserves and natural environments.
He also wanted only walking, not running. running=no? Area located next to a 
residential area, with sports accommodation in the nearby area. He did not want 
(organized) running groups to use his area.
No, dogs.
He expect from me to tag it right, I mentioned that OSM does not have that 
strict forbidden tags.
He find that strange.

That’s why, my thoughts, also other transportation modes are not allowed to 
push in the area.
vehicle=no_vehicle, then I catch all the transportation mode in a one tag 
If it is a key, I must have all these key variations.

From: Martin Koppenhoefer 
Sent: Wednesday, November 6, 2019 3:17 PM
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] Is there a good way to indicate "pushing bicycle not 
allowed here"?

  We need a hard and strict no.

I would agree with this, altough these are typically not traffic rules but 
additional, arbitrary rules like dress codes, gender based restrictions, etc.
People want to express those rules, so we should have a tag that unambigously 
expresses the rule.

Tagging mailing list

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

2019-11-06 Thread Allroads

Yes, indeed, and not only for motorcycle.
also moped and mofa.
There is law that says, pushing the mofa, moped, motorcycle, you must follow 
the rules of a pedestrian.
It also says, where the pedestrian should walk, first on a footway, if that 
is not there, on cycleway, if that is not there, the verge or the side of 
the road.
Law says, the "vehicle" the "motorcycle" is forbidden to use the lane of the 
road after this sign, when passing the sign. The above rule overrules is, 
pushing is then allowed, rules of the pedestrian to follow.

Or undersign, where in text "the vehicle" is mentioned/forbidden.

Then there are these privat access_signs, with text,  where mostly "the 
vehicle" is mentioned in text, not the mode of transportation.

Not only for bicycle dismount is used. These mofa moped motorcycle, need 
also wiki pages.

Where "the vehicle" is forbidden, by sign or by text.
Take a value, that others can use too.

? Just a thought!
If you can solve it with a value, do not use a new key!
Otherwise the two keys can be used next to each other, we must avoid this. 
no_vehicle is a hard no.

Easier to use for routers, I think, then checking multiple tags.
My point is, which method to use, it should be useable for more kinds of 

If? use a new key, other transportation modes need also such a key.
Do not vote for one key, make them all at once.

to document why it is used and why it is anyway duplicate of bicycle=no.

Routers, do not use the bicycle=no as strict as, because "OSM tagging 

quote from Brouter discussion, 19/20 September
Hm, but in very most cases, bicycle=no is used effectively in sense of 
bicycle=dismount, not in in sense No bicycles here.
The only relevant interpretation of bicycle=no is the OSM tagging 
intention, not what I or you think about it.

We need a hard and strict no.
I need to express the access, so that routers do not use no as a dismount.
I know it is the routers choice. But I want no bicycles there when i set a 

People use also:
bicycle=privat, what is the meaning of that? pushing a bike is allowed?


-Oorspronkelijk bericht- 
From: Martin Koppenhoefer

Sent: Wednesday, November 6, 2019 8:05 AM
To: Tag discussion, strategy and related tools
Subject: Re: [Tagging] Is there a good way to indicate "pushing bicycle not 
allowed here"?

sent from a phone

On 6. Nov 2019, at 01:25, Warin <> wrote:

Does motor_vehicle=no mean I can push one though there? I did think not 
... at least not on a regular basis

indeed, moto_vehicle=no does not prevent you from pushing your motorcycle.

Cheers Martin

Tagging mailing list

Re: [Tagging] lanes = 0

2019-06-24 Thread Allroads
So there are lanes and virtual lanes.

We must make a good distinction, I must be able to see immediately, whether I 
am dealing with a marked lane or a virtual lane, that has no marking.

Do not expect from a mapper, at a marked lane, also to set  marked = yes. (or 
else) to make the distinction.
See wikipedia and else, there all marked. 

A two-way road without a marking in our country, does not have lanes!  (law). 
Although, you can pass each other. There, we could have also a new 
tagcombination! But not lanes=* , these are marked! (law)
To make a good distinction, it must be immediately clear.

What do you think of:

lanes: virtual = (number),   lanes that have no markings. Not a second tag 

The same method as there is used highway: virtual = pedestrian, to make a route 
line over a pedestrian area. Or over a field, a beach.

You could say, lanes are created in the UK, lanes are created in OSM, these 
lanes where written down as marked lanes, to use lanes=* for virtual lanes was 
a abuse of the tag lanes=* , if you do use it, you make the definition unclear 
and that should be avoided, there is a new tag needed.
Problem solved.

Quote: yo_paseopor
In Spain is easy: when there is no marks =  lanes=1

Also when they are a passable, two way road?

When there are no marking there are no lanes.
lanes=1, like on a highway link, is indicating one way, one direction.

A lot of lanes=1 are deleted in our country, because they are not a lane 

Tagging mailing list

Re: [Tagging] lanes = 0

2019-06-14 Thread Allroads
First, the consensus in OSM is, that only the tag key  lanes=* is used, when 
there is are visual markings for lanes.
Then the question is, are there lanes? Yes or no. How many?

lane_marking= no, we agreed (OSM), when no visual lanes there are no lanes, 
lane_marking, it is referring to lanes, that are not there, so useless tag.

If lanes=no is not right, lanes=0 zero means, that there are no lanes, zero is 
I tagged a few , as you named two way road with no lane marking lanes=1, they 
told me that is wrong, I agree, it have no lanes/rijstroken/fahrstreifen, 
retagged them.

Width tag is way to go. For roads without lanes.
Estimation is difficult, maybe one day Mapillary can measure the width of the 
In JOSM you can measure the width of a road, drag a line and see width.

Some countries, Goverment produce open data, look or agree with them if you can 
use it in OSM. (lisence)
Here a third party, visualise the data. We can use it. To 
realign roads.
(A lot of the data is measured in, correct) We can not do better ;-).

Wider use of  lanes. We can not do that.
Just read all the dictionaries, wikipedia, etc. according to lanes, it is 
always lanes/rijstrook/fahrstreifen (images with markings)
First these must be rewritten, global accepted. This is not happening.
So OSM stays, lanes are a part of a road with markings.

lanes= is used for lanes, when there are no lanes, there should me a 
possibility to give a tag, lanes= is used, either it is lanes=no or lanes=0.
Tagging mailing list

Re: [Tagging] lanes = 0

2019-06-13 Thread Allroads

A carriageway can have lanes or not.
A lane is a part of a carriageway with visual markings.

In Dutch law we have.
rijbaan = roadway = fahrbahn
and with visual marking, we have
rijstrook = lane = fahrstreifen
If there are no visual markings, there are no rijstroken / fahrstreifen / 

A two way roadway with no visual markings do not have lanes. lanes=no
There could be lanes=yes, better is to give the number of lanes lanes=2 and 
set lanes:forward lanes:backward.

Now, I do not set lanes=no, I like to, so that we can control, if on all 
roads lanes tags are set. To see, if there are data gaps.

nolanes=yes is not logic for me.
Are there lanes on a road?  Yes or No.  The answer is no, then the value 
must be, no,  so it must be lanes=no.
You do not ask: Are there no lanes on the road? People have problems with 
such a questions, mixed answers, failure rate is higher.

Negative question, we must avoid that!
Therefore,  avoid nolanes.

Tagging mailing list 

Tagging mailing list

Re: [Tagging] iD adding highway=footway to all railway/public_transport=platform ways and relations

2019-05-23 Thread Allroads
For me it is highway=platform, ID, is doing it wrong.

In a discussion, I drawn out a visualisation.


Tagging mailing list

Re: [Tagging] highway=crossing used on ways

2018-10-16 Thread Allroads

As I used it

On a node:
This only say not so much, it could be also unmarked,  crossing with a 

Mostly I tag a crossing_ref.

On a way:
crossing=uncontrolled or else, this is for the whole crossing.
(crossing=island can not be used, you can only use crossing once)
if there is in the middle a crossing island, that little part, where
pedestrian could wait, often there is a traffic light for pedestrian,
tag crossing:island=yes
but on this little part there can not be a crossing_ref=zebra

That part as a polygon area
The last 3 tags could be retrieved from the way!

On a way:
crossing=uncontrolled or else
if there is in the middle a crossing island, that little part, where cyclist
could wait. often there is a traffic light for bicycle ( more wider busy
tag crossing:island=yes

That part as a polygon area
The last 3 tags could be retrieved from the way!

crossing=uncontrolled or else
if there is in the middle a crossing island, that little part, where
pedestrian could wait. often there is a traffic light for pedestrian,
tag crossing:island=yes
but on this little part there can not be crossing:ref=zebra

That part as a polygon area
The last 3 tags could be retrieved from the way!

The other parts, where you do not walk/ride/drive.
area:highway=traffic_island for the areas.
On the polygon way barrier=kerb  with no area=yes ( this should mean that
the whole island is a kerb, it is not).


From: Gerd Petermann
Sent: Tuesday, October 16, 2018 7:24 AM
Subject: Re: [Tagging] highway=crossing used on ways

I think I found one reason for the mistagged ways. The wiki page
proposes to use highway=crossing + crossing=island to map a traffic island.
It says that this should be used on nodes but a mapper looking for a
replacement of a landuse tag might miss that.
It also claims to show numbers from taginfo for this combination, but in
fact it shows the numbers for
just crossing=island:
This tag can be used on ways, together with e.g. footway=crossing, but that
would not be used to map the area of the traffic island.

AFAIK taginfo doesn't allow to ask for tag combinations. No idea if this
occurs on other wiki pages, if so,
it is very misleading.

I think the said wiki page should be changed so that highway=crossing is not
mentioned at all.


Sent from:

Tagging mailing list 

Tagging mailing list

Re: [Tagging] Opening hours too long for OSM

2018-10-12 Thread Allroads
Thinking loud, I like a set of subcategories.
Basic set for a year, others for the fast change.
I find this a practical understandable solution. 

From: OSMDoudou 
Sent: Friday, October 12, 2018 5:22 PM 
To: 'Tag discussion, strategy and related tools' 
Subject: Re: [Tagging] Opening hours too long for OSM 

As to improving (thinking out loud here...), ..

Tagging mailing list

Re: [Tagging] motorcar definition changed recently

2018-10-03 Thread Allroads

It is time to give this twofold meaning a split, into two separate keys.
Within openstreetmap it can not have a twofold meaning!

The law in many countries also speaks of double tracked or more then two 

It is clear to me the new key must be double_tracked_motor_vehicle or short, 
dt_motor_vehicle, or else, give it a better name.

Allready, fitted in the access hierarchy. With a OSM icon (front car)
As explained here:
All description and structure already indicate that a split has to be done!

(includes all double-tracked motorised vehicles when used as restriction) 
this must be removed.

It is unworkable. It is a monster. motorcar=no, meaning else.
So many key conditions have to be investigated to find out what is meant by 
motorcar. if and

I am working on a JOSM  test style to express the access on highway and 
barriers in the road.
For control/check reasons, better to see a icon then watch the written key, 
get the hint, that's why we make maps, make it more understandable.

A key must have one meaning.  If not, it is almost impossible to express the 
access for one type of vehicle. Where can I ride or drive, where not, where 
conditional. Why could I not router there.
Test site:

Also working on a preset. Translating law to tags.
There must be one more hierarchy step, in the lineup to motorcar.
We make it hard for ourselves to deal with this developmental error, 
motorcar two meaning.
Despite, what people give as a meaning to motorcar, Openstreetmap have to 
choose, one meaning, give the others a other key.

Working on this style/site, translating traffic law to keys/value, more keys 
are needed.

non motorized vehicles, what keyname, see disabled vehicles. Small groups, 
maybe they have more benefits than others.

A better hierarchy structure is needed.

So the definition have to be changed once again.


From: SelfishSeahorse
Sent: Wednesday, October 3, 2018 10:03 AM
To: Tag discussion, strategy and related tools
Subject: Re: [Tagging] motorcar definition changed recently

On Mon, 3 Sep 2018 at 17:58, Martin Koppenhoefer  

Thank you, I have now reverted the change wrt to motorcar.

I've also reverted the change on the page and tried to make the
different meanings of that tag when either used as permission or
restriction clearer.


Tagging mailing list 

Tagging mailing list

Re: [Tagging] Traffic sign direction tagging..

2018-10-02 Thread Allroads

Traffic_sign is on a node beside of above a road. There where, it is.
This is the basis, the derivative is tagged on the road, as ...

The direction=* says, the facing direction of the sign/shield. Important: 
indicates the direction in which the law applies. This could be various. 
Depends on sign and undersign.
A combination of trafficsign and undersign is important, it indicates a 
combined rule, summarized in a value.
But there could be more trafficsigns on a node even a highway=street_lamp, 
the direction=* can not be used.

traffic_sign:1:direction=*  facing direction is used.

Then the derivated on the way.

This could be the whole way.

But also on a node of a way ( not the first and last node) like give_way.
The most directly derived tagging is tagging the traffic sign itself. First 
degree derived tagging.

Second degree tagging are the access tags.
If you have first degree tagging, the second degree could be controlled, if 
it is correct.
In the Netherlands we started to tag the traffic_sign on a cycleway, then 
knowing which vehicle key/value is needed
Now with overpass we can control if tagging is correct on the cycleway G11 
(mofa designated), G12a (mofa mofa designated), G13.

This way we get more qualitative data.

Then on a waynode. like give_way.
C6 traffic_sign.
The working-out of the law, says, that goes into effect when you pass the 
shield at the front. And must be repeated after each crossing.

This traffic sign can stand on one side of the road.
If you come from the other side, there is no shield, drive in and you visit 
a house, a plot, or you decide to turn around, this is allowed by law.
This you could do, for example 10 meters from the back of the shield, turn 

This place is a like a give-way construction on a node., with access
traffic_sign:forward=NL:C6  (first derivated tagging, could used to control 
the other tags)


some use a 10 meters way to set the tags.

forward, indicates the direction of operation of the law in relation to the 
Openstreetmap drawing direction.


Here direction is facing direction on the sign.
And can not be used a working-out direction of the law.
traffic: forward= and traffic_sign:backward is correct.

I do not agree!

In combination with traffic_sign, direction can only be used  on separated 
node besides the road (or above), given the facing direction, there are 
signs with undersign with a left or right arrow, indicating in which 
direction the sign works,
then the facing direction must be correct, often this is 90 degrees on the 
driving direction, or on other side of a T junction.

If the traffic_sign (first degree derivated) is not tagged it is almost 
impossible to control tagging. With all combinations and undersigns.


-Oorspronkelijk bericht- 
From: Marc Gemis

Sent: Tuesday, October 2, 2018 2:04 PM
To: Tag discussion, strategy and related tools
Subject: Re: [Tagging] Traffic sign direction tagging..

>  To keep things simple, we'll do the same thing for traffic signs:

Please , for doing traffic_sign:direction is better to put direction=* 

> I still highway=give_way and highway=stop with
direction=forward/backward (which is used by OsmAnd AFAIK).

And what about the other traffic signs. Are they not important? Why don't 
erase it...from the World if they are not important?

I don't map other signs, for most other signs I map the result on the
way (e.g. maxspeed sign, no overtaking). Why would I map the sign
separately ?
Give ways and stop signs are slightly different, because they usually
indicate a single place on the road where one has to stop. The result
of the sign is commonly mapped as a node, not as a tag on the way
(yes, I know there are cases where a relation might be needed).

So yes, for me the position of the other signs is not important. Feel
free to add them if you feel they are important.



Tagging mailing list 

Tagging mailing list