Re: [Tagging] incline=up_and_down

2022-09-26 Thread Tobias Knerr

On 26.09.22 02:21 Mateusz Konieczny wrote:

But what can be done in cases where there is no real incline but
path goes through series of up and down hops?

I would intuitively prefer if you put the information about the presence 
of "hops" into a specialized tag instead of making the value space of an 
established and approved key more messy.

Leave incline=* to describe the overall incline of the way in that case. 
That is: Do you end up lower or higher than you were in the start?

Tagging mailing list

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

2020-09-18 Thread Tobias Knerr
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

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

Re: [Tagging] Addition of highway=emergency_bay and priority_road=yes to Map Features?

2020-09-16 Thread Tobias Knerr
On 16.09.20 09:57, Martin Koppenhoefer wrote:
> emergency bays are quite common in Italy and Germany when there isn’t an 
> emergency lane.

The pertinent question isn't so much if emergency bays are common, but
if this particular tagging for them is established.

In my opinion, mapping what amounts to a short lane (no physical
separation) as a separate way is contrary to what we usually do, e.g.
with bus bays. And seeing how the tag currently has less than a thousand
uses on ways, I feel that the practice of using highway=emergency_bay on
ways should not be recommended on Map Features.

Tagging mailing list

Re: [Tagging] How to tag body height limits on attractions?

2020-09-12 Thread Tobias Knerr
On 10.09.20 15:07, Mateusz Konieczny via Tagging wrote:
> 3 is clearly out, 5 seems overly complex

I agree with both of these statements. As this is not specific to
attractions (might also apply to aerialways, for example), I would also
avoid option 2.

Because I feel there's a slight difference between passenger
minheight/maxheight and vehicle minheight/maxheight (which is what these
tags usually refer to when used on roads), I have a mild preference for
a new value – such as option 4 or something like maxheight:passenger.

But in practical terms, we probably won't need a vehicle maxweight and
passenger maxweight on the same feature, so I guess using the same key
(option 1) would not cause any issues either. And our the main priority
should be to stop the problematic use of min_height.

In any case, we might want to define an analogous key for passenger
weight restrictions while we're at it.

Tagging mailing list

Re: [Tagging] Status of proposed roof:ridge / roof:edge ?

2020-08-31 Thread Tobias Knerr
On 31.08.20 20:06, Oliver Simmons wrote:
> Does anyone know if this tagging:
> Is accepted and ok to use?
> It has “proposed” in the title but there’s none of the usual proposal
> stuff saying if it was accepted or not.

It never went through the proposal process, and dates back to the era a
decade ago when the first 3D renderers in OSM showed up.

Over the years, the approach has seen some use in the database, but it's
far behind the roof:shape tagging from Simple 3D Buildings in
popularity. Application support is very limited, I don't know if any
software except OSM2World supports it. Still, it's the most popular
approach for modelling roofs with geometry (as opposed to picking from a
catalogue of typical shapes) if that's what you're looking for.

My recommendation is to only consider it if the roof shapes from Simple
3D Buildings aren't sufficient to describe a given roof. (Even then, you
could still add the closest roof:shape tag for compatibility reasons.)


Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - more parking types

2020-08-07 Thread Tobias Knerr
On 07.08.20 15:36, Matthew Woehlke wrote:
> That said... now I'm on the fence. FWIW, the amenity=parking page
> mentions parking_space=disabled as being supported by at least one
> renderer, while one has to do quite some digging for how to use
> access:*. Clearly we *do* need to improve the documentation here! Also,
> it's less obvious how one would apply access restrictions for e.g.
> charging, compact.

I've always felt that using "disabled" as an access _key_ (i.e.
disabled=* or access:disabled=*) was somewhat at odds with the usual
logic of putting groups of users in the _value_ of access tags.

I like that parking_space=disabled sidesteps this issue.

Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - more parking types

2020-08-07 Thread Tobias Knerr
On 06.08.20 22:52, Matthew Woehlke wrote:

I like it, thanks for working on this topic! Two suggestions:

Could you add a short definition of "compact"? I can guess that it's
supposed to mean parking spaces for compact cars, but the first Google
result for me is some parking system for trucks at motorways. Better to
avoid the ambiguity.

Also, I guess we need to decide if we need to be able to map something
that fits more than one class, like a takeaway parking spot reserved for
users with disabilities. If so, we could consider a solution something
like parking_space:takeaway=yes, or a clearly defined meaning for
semicolon-separated values.

Tagging mailing list

Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging

2020-07-24 Thread Tobias Knerr
Hi Tobias,

congratulations on your successful microgrant proposal! :) Maintenance
of existing data is a growing concern as OSM matures, so it's important
that we explore workflows for it.

On 23.07.20 18:06, Tobias Zwick wrote:
> 2. Always record check_date or avoid tagging it where not absolutely
> necessary?

I think it would help with community acceptance of a potentially large
number of meta tags if you're somewhat frugal when it comes to adding
new ones. There is some cost in mappers feeling obligated to update a
"companion tag" every time they update a regular tag, as well as in
visual clutter. These downsides will both be lessened with better
tooling, but as of today that isn't widely available yet.

In practice, this could mean ...

* ... not adding key:check_date when the key is first added, or when the
value is changed as opposed to confirmed. (But update check_date tags
that already exist on the object, of course.)
* ... only using check_date where regular re-survey is plausible and
useful. This ties in with your observations on re-check intervals. For
example, there should be an opening_hours:check_date, but probably no

I don't have any strong opinions on this, and you seem to have given
this a lot of thought already. Just adding my gut feeling to the wisdom
of the crowd here.

Tagging mailing list

Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging

2020-07-24 Thread Tobias Knerr
On 24.07.20 14:13, Peter Elderson wrote:
> In comparable cases (non-OSM, but comparible checking schemes), I do not
> record the date it has been checked, I record the future date when it
> should be checked (again).

When it should be checked is opinion-based, though.

The date when you last checked a shop's opening hours it is a fact. But
opinions on how often one should revisit a shop to check the opening
hours again may vary a lot between mappers. So I think the former is
more suitable to be added to the OSM database.

There are some comparatively rare cases where you know in advance that
something will change (e.g. with construction that is scheduled to be
finished by a particular date), but imo that's more the domain of
opening_date or temporary tags.

> The routine is then, ask if check_date is absent OR when the current
> date is past the check_date.

I don't think this is a big benefit compared to "... OR when the current
date is X months past the check_date".

Also, I tend to prefer making software a little more complicated if it
lightens mappers' manual workload, so making at least some use of
history (e.g. so that no check_date needs to be set when a tag is first
added) seems reasonable to me.

Tagging mailing list

Re: [Tagging] Automated edit of image tags suggestion

2020-06-28 Thread Tobias Knerr
On 27.06.20 11:18, Mateusz Konieczny via Tagging wrote:
> unlike other many image gathering sites, images there are
> likely to be reusable and with at least basic info being
> machine readable

None of this changes if the Commons image is linked from the image tag,
though. And in fact, I feel these traits (open license, machine-readable
metadata) should be turned into requirements for any image linked from

> I would prefer to not mix it with image=*

Would you consider it desirable to have multiple images linked for the
same object (one per hosting platform)? If so, how should a data
consumer select one of them to display?

(Of course, this points at the fundamental issue that the selection of
an image for image=* and similar tags is inherently subjective, so
arguably a poor fit for OSM in the first place. But I guess that's one
of those "it's sufficiently useful/popular to make an exception from the
rules" scenarios.)

Tagging mailing list

Re: [Tagging] Automated edit of image tags suggestion

2020-06-26 Thread Tobias Knerr
On 25.06.20 19:57, pangoSE wrote:
> I recently started discussing the problems related to urls and
> File:filename.* that links to wikimedia_commons using the tag. See
> Talk:Key:image#Discourage_linking_to_commons_files_and_migrate_all_File:filename..2A_values_and_direct_urls_to_wikimedia_commons

By your own numbers, there are over 8 image=* tags containing links
to Commons. That makes it the most popular key for images on Commons at
the moment. I don't think there's an established consensus for
deprecating this tagging style.

Because I haven't seen convincing arguments to replace image=* with one
key per hosting platform, I would instead favour doing the opposite:

* Deprecate wikimedia_commons=* (because it unhelpfully mixes links to
categories, images, and other media types – I agree that's an issue)
* Move category links to commons_category=*
* Move image links to image=*

In summary: We first need a consensus how links to Commons should be
tagged. Then we can use an automated edit to standardize the tagging.

Tagging mailing list

Re: [Tagging] Name for new wiki pages about roles of members in route relations?

2020-06-26 Thread Tobias Knerr
On 25.06.20 19:46, Joseph Eisenberg wrote:
> Should individual pages for these roles be located at something like
> Role:main and Role:alternative?

So far, I believe roles are typically documented on the wiki page for
the relation type, rather than their own pages. I don't think there's an
established convention for wiki pages about individual roles yet.

Tagging mailing list

Re: [Tagging] site relation definition

2020-06-17 Thread Tobias Knerr
On 17.06.20 12:27, Martin Koppenhoefer wrote:
> Can we remove the "man_made" requirement?

I'm ok with removing the requirement for objects to be man-made. I only
added this aspect back in because it had been silently lost during the
transition from the proposal page to the Relation:site page a day prior,
which I felt wasn't ok – this is a significant change that should be
done on its own, not as part of an unrelated rewrite where it's easily
missed. But I do not actually have any personal preference on this
matter one way or the other.

Tagging mailing list

Re: [Tagging] Points vs Polygons

2020-04-19 Thread Tobias Knerr
On 19.04.20 20:33, Paul Allen wrote:
> On Sun, 19 Apr 2020 at 19:29, Justin Tracey  > wrote:
> Another major exceptions where mapping as an internal node is
> better, IME, are notable (historical) buildings that currently house
> a business. More generally, if the tags of the building and business
> would conflict (e.g., name), then it makes sense to keep them as
> separate features.
> If the building's name is still used as the house name, that's not a
> problem. Otherwise old_name=* takes care of it.

Not in the general case (the name may continue to be in use, but not as
part of the address). And there are other tags which may warrant a
distinction between the building and the business, such as start_date.

I would say the cleanest way to solve this, where necessary, is by
creating separate features for the business and the building. Separate
features don't have to mean a node for the business, it can mean two

Of course, that's more work than either of the two popular shortcuts, so
these still have their place. But polygons for businesses work no matter
whether there's multiple tenants or just one, and it even works for
indoor maps and other micromapping use cases.


Tagging mailing list

Re: [Tagging] Points vs Polygons

2020-04-19 Thread Tobias Knerr
On 19.04.20 19:51, Shawn K. Quinn wrote:
> I have noticed an issue putting things like the address on large
> buildings. Sometimes software that generates routings (OsmAnd) doesn't
> handle it gracefully and routes you to the wrong place.

My preferred way to handle this is to tag a node of the building polygon
as entrance=yes or entrance=main to mark the location of the entrance.
This allows routing software to know where it should guide you.

(Whether any given routing software already supports this is a different
story, of course, but at over 2 million uses this is a thoroughly
established tagging practice.)

Tagging mailing list

Re: [Tagging] addresses on buildings

2020-01-05 Thread Tobias Knerr
On 05.01.20 19:22, Rob Savoye wrote:
>   I assume the right place for tags like 'addr:housenumber' &
> 'addr:street' are on the building way, and not a standalone node ?

If there is a 1:1 relationship between buildings and addresses, the
building way is the most sensible location for addr tags.

My subjective experience with unconnected address nodes is that I often
end up confused about which building outline(s) they were originally
meant to belong to.

Tagging mailing list

Re: [Tagging] state of a proposal

2019-12-08 Thread Tobias Knerr
On 08.12.19 18:37, Catonano wrote:
> What' s the state of this proposal ?

Well, I wouldn't hold my breath for a vote unless the author (or someone
who takes over the reins) reboots it, but this doesn't necessarily mean
the idea is abandoned – not all proposals are adopted through voting,
some are simply adopted by people starting to use it.

In the case of this particular proposal, some people have experimented
with using it for mapping and development (myself included, I described
some very preliminary results during my SotM talk last year). From that
development perspective, I still feel Marek's proposal is the most
promising take on the area:highway idea so far.

Note that, although someone has later written wiki pages for
Key:area:highway¹ and related tags, they describe the wiki editors' own
take on the key, rather than any of the formally proposed versions. As a
result, that content is different from and incompatible with the
proposal you linked to. Which is unfortunate, as it lacks the clear
definitions regarding separation of junction areas from the connecting
road areas etc., which I found helpful when experimenting with software
support for it. I'm concerned that, contrary to the proposal, it may not
be as well suited for use cases that go beyond uniformly "painting" an area.



Tagging mailing list

Re: [Tagging] How to tag pedestrian lanes?

2019-10-21 Thread Tobias Knerr
On 21.10.19 12:12, Tobias Zwick wrote:
> Though, in regards of software support,  I  my earlier suggestion is better, 
> as no modification on existing software is necessary to understand that a 
> sidewalk without kerb is still for pedestrians and used the same as a 
> sidewalk, regardless of whether in (Oxford) English, one may or may not call 
> this thing "sidewalk".

Me too. As I see it, the core of the question comes down to whether the
OSM data model should put a pedestrian road section without a kerb in
the same general category as one with a kerb, or whether these should be
treated as separate concepts.

To me, it makes more sense to consider them as roughly the same thing
and model the distinction with an additional tag. For most use cases,
data users can likely handle them very similarly, even though I
acknowledge that there may be exceptions (such as Markus's example of
navigation for blind users).

In general, I don't think the definition of OSM keys should
automatically duplicate all nuances of the English dictionary,
especially ones that many non-native speakers will be unaware of.


Tagging mailing list

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

2019-10-05 Thread Tobias Knerr
On 28.09.19 10:31, Valor Naram wrote:
> now I'm ready to open a new proposal which you can see here

I agree with the basic goal of ending the co-existence of phone and
contact:phone. I don't care that much about which one "wins", but having
multiple competing tagging styles around makes it just that little bit
harder for new mappers to learn the ropes (and for editor developers to
optimize usability). This particular co-existence has gone on for a
decade, and we should finally come to a decision.

That being said, I find the proposal a bit confusing as currently
written. It isn't clear to me if you are proposing any changes besides
deprecation of contact:phone, because there's a lot of text on that page
about country codes, the value syntax and such. Is this just
describing/affirming the status quo?

What adds to the confusion is that there are now multiple proposals on
the same wiki page, which is unexpected and messes with links and
categories. For example, that page is now in both the "rejected" and
"proposed" categories at the same time. Unless there's a strong reason
I'm missing, I suggest taking the conventional route of creating a new
page for your proposal.

Tagging mailing list

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

2019-09-08 Thread Tobias Knerr
On 08.09.19 18:26, Janko Mihelić wrote:
On Fri, Sep 6, 2019, 15:05 Janko Mihelić wrote:
> "*A Wikidata item cannot be connected to more than one OSM item*".
> If one wants to tag all route segments with a wikidata tag, I
> propose a general usage "*part:wikidata=**" which would be used when
> a single wikidata tag just isn't viable. Proposal wiki page here:

Seems reasonable enough to me. It upholds the (generally desirable) 1:1
relationship while offering a realistic solution for items where there
is no single OSM element representing the feature as a whole. Streets
are probably the most prominent example where this would be used.

Tagging mailing list

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

2019-09-05 Thread Tobias Knerr
On 05.09.19 18:41, Jeremiah Rose wrote:
> Here's a proposal for marking indoor routes within a building mapped with 
> Simple Indoor Tagging. 

I can see some value in mapping routes through a room which is full of
obstacles, but I don't like the idea of using this where a routing graph
could be calculated from indoor=corridor/area/room polygons just fine.
While the slow progress of OSM-based routing engines in this regard is
regrettable, trading extra mapper hours for something that could be
realistically automated always seems wasteful to me.

Of course, if someone feels it's worth spending their time, that's
ultimately up to them and I'm not going to stop them. Even with that in
mind, though, there are some aspects of this proposal which I find
problematic as they might have collateral effects on many other data
consumers besides the ones it's designed to help:

* the lack of a clear statement that this tagging is to be used in
addition to the SIT tags on polygons and should not replace them
* use of highway=footway, rather than a new tag which would have no
effect data consumers which don't opt in
* sharing the same tag for both use cases (hints for routers without
good indoor support which should be ignored by more advanced routing
engines, versus routes which should always be preferred over
automatically derived routes).


Tagging mailing list

Re: [Tagging] tag templates in the wiki

2019-08-12 Thread Tobias Knerr
On 12.08.19 20:27, Martin Koppenhoefer wrote:
> AFAIK the template is not filled from but rather from a wikidata 
> installation on OpenStreetMap-Foundation servers (or for OpenStreetMap but on 
> another server), with information harvested in the osm wiki. It is a parallel 
> system to by wikimedia.(?)

Yes. The OSM "data items" use the same software as Wikidata, but it's an
entirely separate installation on Technically,
it's just an add-on (extension) for the wiki software.

There *is* a Wikidata link on some key and tag pages, but that is simply
an outgoing external link which doesn't do anything magical and is
unrelated to the above.


Tagging mailing list

Re: [Tagging] Charging stations: socket::output -- which format for the value?

2019-08-04 Thread Tobias Knerr
On 31.07.19 09:34, Warin wrote:
> There is no present default unit for power - see
> Adding a default would be good

Why would it be good to add a default value?

I believe explicit units are generally preferable because they avoid
ambiguity and misunderstandings. With other tags, values without an
explicit unit are already common in the database, so this usage needs to
be documented. But introducing a default for a tag that is generally
used with explicit units doesn't seem useful unless you *want* people to
start omitting the units and rely on the default.

> And the wiki could also state that a space is required between the
> numeric values and the units, if any.

The wiki mentions this as a general rule: "The following units can be
explicitly specified by adding them after the numeric value, separated
by a space". But I agree that this recommendation should also
be repeated on Key:* pages.


Tagging mailing list

Re: [Tagging] [Indoor] is indoor=level walled ?

2019-07-26 Thread Tobias Knerr
On 23.07.19 13:42, PanierAvide wrote:
> So according to wiki, indoor=level doesn't involve having a implicit
> wall following the geometry. Is it something we agree on ?

indoor=level does not add an implicit wall.

However, building and building:part probably do have outer walls by
default, regardless of indoor=level or any other indoor mapping. There's
no solution for switching these walls off yet. We can't really assume
that the absence of an indoor=wall or indoor=room element means there's
no outer wall – fully indoor-mapped buildings are the exception, not the

Therefore, my suggestion would be to include a tag like wall=no on your
indoor=level polygon for these unwalled levels.

> According to wiki, indoor=wall can only be used on
> lines, so if I create a closed line, it should not render as an area
> (same behaviour as footways). Is it also something we agree on ?

Yes, a closed way with indoor=wall should be considered a line, not an area.

> Last question, if I want to create a wall as an area (imagine for
> example a wide pillar where no one can enter), should I just use
> indoor=wall + area=yes ?

Using area=yes makes sense here, yes.

Conceptually, I'm a bit uncomfortable with wall polygons because they
break the logic for doors and windows (which are nodes on the wall
ways). But for something completely solid like a pillar, this is
probably not going to cause problems.


Tagging mailing list

Re: [Tagging] Removing an ATM

2019-07-09 Thread Tobias Knerr
On 09.07.19 15:04, MARLIN LUKE wrote:
> I have an ATM mapped in a street which does not exist anymore
> (apparently since 2014).

Historic features should not be mapped in OSM:

Therefore, an object which no longer exists can simply be deleted.
The editing history is still stored in our database even after an object
is deleted, so you don't need to worry about permanently losing data.


Tagging mailing list

Re: [Tagging] one feature one element

2019-07-05 Thread Tobias Knerr
On 05.07.19 11:57, Mariusz wrote:
> On 05.07.2019 07:05, Joseph Eisenberg wrote:
>> [Examples of bad situations:] "An area object representing a
>> single-use building with a point object inside it. Move the tags to
>> the area object and delete the point."
> This is common and widly accepted practice. Don't try to change mappers
> behaviour by editing wiki.

It's true that shop tags on building outlines are a common practice.
However, POI nodes inside buildings are likewise common. So I believe it
was a good idea for Joseph to remove this statement. It did present a
widely accepted practice as a "bad situation" in need of fixing, after all.

> It is fine to map multiple real objects with one osm element

It'd say it's ok as a shortcut during initial mapping, but it is far
from ideal. As soon as you want to add tags which only apply to one of
the features (you mentioned "start_date" or "operator" as two examples,
but of course there are more), using separate elements becomes necessary.

> Nothing new, this problem already existed with roads and bridges and was
> fixed by putting bridge name into bridge:name tag.

It wasn't properly fixed until the introduction of man_made=bridge –
that is, a separate OSM element for the bridge.

The bridge:name tag was only a band-aid for a single symptom of a deeper
issue. It did little to address the other symptoms, such as multiple
roads running across the same bridge, and tags other than name.


Tagging mailing list

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

2019-05-22 Thread Tobias Knerr
On 08.05.19 01:30, Nick Bolten wrote:
> Would it be fair to say you're suggesting something along the lines of
> crossing:marking=*, where * can be yes, no, or a marking type? You make
> a good point about the simplicity of avoiding a subtag for markings.

Yes, this is pretty much what I'm suggesting. And I believe it would be
an useful tag no matter whether we make crossing mapping fully
orthogonal or just mostly orthogonal.

Taking a step back to explain my thoughts on splitting off signals...

The core of the issue seems to be that there are two conflicting
mindsets: Mapping "types" of crossings versus having a "construction
kit" of several tags which each describe one facet of the crossing.

If we want to have "types of crossings" at all, it would be highly
unexpected to ignore the presence of traffic signals for that purpose.
And the crossing=* key clearly seems to be intended for mapping the type
of the crossing. That meaning is suggested by the name of the key
itself, not just the current set of values, so I believe it's
counter-intuitive to turn it into just one of several equally important
orthogonal keys.

What else could we do with crossing=*? In theory, we could just get rid
of it entirely, but realistically, that's not going to fly, and I'm not
even sure if it would be desirable. People _do_ tend to mentally put
things to categories, and describing the most common crossings with just
one tag is certainly convenient.

So what I would probably do is mix the two approaches instead of going
for a conceptually pure implementation. Use
for a basic classification of the crossing's type, and then add
orthogonal subtags like crossing:island=*, crossing:marking=* etc. as
needed. It lacks the elegance of full orthogonality, but covers all
practical use cases.


Tagging mailing list

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

2019-05-07 Thread Tobias Knerr
On 07.05.19 23:08, Nick Bolten wrote:
> This proposal suggests the deprecation of crossing=traffic_signals and
> replacing it with crossing:signals=yes, i.e. placing pedestrian
> signalization on a dedicated tag that is separate from crossing=* values.

I agree with separating orthogonal characteristics of crossings into
different tags. A single tag cannot easily express both the presence of
traffic signs and the presence of markings.

However, it seems odd to "demote" traffic signals to a sub-tag when
their presence or absence is perhaps the biggest influence on the
crossing's overall character.

In comparison, it seems somewhat less important whether a signalled
crossing also has painted markings on the road. So I would suggest using
a separate tag for the markings instead. We need a tag for the _type_ of
the markings anyway (as different patterns for marked crossings can have
entirely different legal meanings in some jurisdictions), and we can use
that same tag for presence/absence by also allowing yes/no values.


Tagging mailing list

Re: [Tagging] RFC - Feature Proposal - area of steps for pedestrians.

2019-05-06 Thread Tobias Knerr
On 06.05.19 15:36, Martin Koppenhoefer wrote:
> Am Mo., 6. Mai 2019 um 14:06 Uhr schrieb Martin Koppenhoefer
> If you can get the second one working I don’t understand why the
> first one is different (presuming it is split). For the second one
> to work there must also be polygonal ramps (basically the same as
> steps, just without the steps) at the border.I just added them:

Looks like I misinterpreted the shape based on the original photograph.
Seeing it from the top makes it clear that it's pretty much the same
problem as the Cologne example and is not going to work either, sorry.


Tagging mailing list

Re: [Tagging] RFC - Feature Proposal - area of steps for pedestrians.

2019-05-04 Thread Tobias Knerr
On 03.05.19 19:00, Christoph Hormann wrote:
> That illustration does not show the original data so it does not tell 
> very much.

Here's the raw data if you'd like to examine it:
Please excuse the sloppy mapping, those are just intended as tests.

> Like for example classic curved stairs:

Indeed. Winding/curved steps are a separate category from the straight
steps this algorithm is designed to solve. As I said previously:

On 11.04.19 23:28, Tobias Knerr wrote:
> Note that the method I describe above does not even try to work for
> winding steps (i.e. those which you don't ascend in a straight line).
> But there are other algorithms that would work for those, and the two
> classes of steps could potentially be distinguished with a tag.

While you correctly point out several further limitations, I think it's
important to keep in mind that this isn't an attempt to define a data
model that works for everything. It's about finding a sweet spot that
works for a sufficiently large class of steps to be worth it and is
still relatively simple.

As for that data model that works for (almost) everything, I believe
that will have to be drawing a way across the edge of each step.
Increasingly complex staircases could then be modelled accurately by
simply adding more information (if the mapper is in the mood for

1. Just draw a way.
2. Additionally draw a polygon around the steps.
3. Additionally draw a way along the edge of each step.

Each level of detail would just add more data on top of what's already
there, which I believe is a desirable property.


Tagging mailing list

Re: [Tagging] RFC - Feature Proposal - area of steps for pedestrians.

2019-05-04 Thread Tobias Knerr
On 03.05.19 18:20, Paul Allen wrote:
> Or this
> You will note that there are narrow, normal-size steps within big
> steps.  It's complicated.

Yeah, there's absolutely no chance to make that guess from just a
polygon OR the relation originally proposed in this thread. :)

On 03.05.19 17:49, Martin Koppenhoefer wrote:
> Can it cope with cases like these?

Only if we split it into a bottom and top part:

As splitting is likely necessary to properly model the landing in the
first place, you may or may not consider that acceptable.

> Or similarly these

Also would have to be split into multiple parts (three, to be exact) for
the algorithm to work, unfortunately. The multiple quasi-right angles
make this shape ambiguous.

> This one shows a common problem, occurring when the surroundings are not
> completely leveled (steps that do not run across the whole width):

The second example will work fine, the first one won't. This, too, is a
limitation shared by the relation originally proposed in this thread, by
the way.


Tagging mailing list

Re: [Tagging] RFC - Feature Proposal - area of steps for pedestrians.

2019-05-03 Thread Tobias Knerr
On 11.04.19 23:28, Tobias Knerr wrote:
> A decent heuristic is to connect each node from the upper border to the
> closest point (not necessarily a node) on the lower border, and vice
> versa. Then you place steps at regular intervals along these connections.
> For common step shapes, this should produce the expected results. I
> might be able to cobble together a proof of concept over the next few
> days if that could help convince you?

So I finally got around to building that prototype to test my idea. The
code only needs a highway=step way and an area:highway polygon as input,
and produces sensible results for common shapes of straight stairways.
I'm pretty happy with the results:

This image shows a few examples of steps with a basic 3d rendering
alongside a debug view that highlights the algorithm's internal view of
the data (in particular the automatic decomposition into left/right and
front/back parts of the outline, and the construction of the steps).


Tagging mailing list

Re: [Tagging] Verifiability wiki page: "Geometry" section added

2019-04-28 Thread Tobias Knerr
On 28.04.19 13:51, Mateusz Konieczny wrote:
> "A place=hamlet often lacks verifiable borders. Hamlets in farming areas
> often have scattered houses and farms extending outward for several
> kilometers. In this case the approximate center of the place may be
> well-know, but the outer limits are not clearly determined,
> so mapping as an area is not verifiable."
> is a good description of a common situation. Are you claiming that it
> never happens?

I agree that this is a common situation. However, I'm claiming that we
actually know _more_ than just the hamlet's center in that situation.
There will often be houses that are well known to be part of that
hamlet, and other houses (in fact, almost 100% of the world's houses)
that everyone will agree are not part of that hamlet.

So the world's houses and farms can be (somewhat simplistically) divided
into 3 sets:
A: Verifiably part of the hamlet.
B: Verifiably not part of the hamlet.
C: May or may not be part of the hamlet.

In my opinion, verifiability is not a valid reason to stop people from
attempting to map the sets A and/or B.


Tagging mailing list

Re: [Tagging] Verifiability wiki page: "Geometry" section added

2019-04-28 Thread Tobias Knerr
On 28.04.19 11:43, Joseph Eisenberg wrote:
> Please suggest any improvements to the wording or corrections:

I'm afraid I can't support the addition of this new rule.

Yes, it's often not possible to agree on a precise border for these
features. But nevertheless, there are typically areas that are
definitely part of them, and other areas there are definitely not part
of them.

The above is verifiable geographic information, so it ought not be
off-limits for OSM. I've always thought of mapping features with fuzzy
boundaries as an unsolved challenge for our data model, not as something
that should be categorically excluded from OSM. One could imagine, for
example, a relation containing two polygons for the feature's "minimum"
and "maximum" extent (describing the parts of the world that are
verifiably part of/not part of the feature), with a grey area of
uncertainty in between.

With your recommended solution of placing a node "near the center of the
feature", capturing this useful knowledge is not possible. It also
doesn't make logical sense to me: If it were indeed impossible to
verifiably establish even an approximate boundary of the feature, how
can we verifiably establish the feature's center?


Tagging mailing list

Re: [Tagging] Comments on documenting winter speed limits tagging

2019-04-24 Thread Tobias Knerr
On 04.04.19 13:33, Jyri-Petteri Paloposki wrote:
> The feedback was quite limited and you or anyone else expressed no
> definite stance against documenting the current practice.

At least in my case, that's because I expected my mail to be a
contribution to a discussion that would (hopefully) end with a
consensus. I did not interpret your original mail as a "call for vetos".

As it stands, there was no response to the criticism in the original
thread. Rather, a wiki page suddenly (from my point of view) came into
existence, and had I not pre-emptively added that page name to my wiki
watchlist, I wouldn't even know.

But enough about past misunderstandings, and thanks for summarizing the
discussion on #osm-fi. I can at least understand the reluctance to go
with conditional restrictions in that case. I do still wonder about the
reasons for ruling out the other alternatives, though. As I said before:

> On 3.4.2019 19.40, Tobias Knerr wrote:
>> Even if we keep "winter" in the key, the
>> ":seasonal" should definitely be dropped. After all, we use
>> maxspeed:forward (not maxspeed:directional:forward) and maxspeed:hgv
>> (not maxspeed:vehicular:hgv).

The pros and cons of conditions are more complex, but maxspeed:winter
seems like a straightforward improvement:

* It's shorter and simpler.
* It follows the same format as firmly established keys like
maxspeed:hgv or maxspeed:forward.
* It's a bit easier for data consumers because keys like
maxspeed:winter:forward are often handled by splitting at every ':'
character, which would also break apart the "seasonal:maxspeed".

So far, I believe, no one on this list has argued that
maxspeed:seasonal:winter is actually better (as opposed to more common)
than maxspeed:winter.


Tagging mailing list

Re: [Tagging] junction=yes as a polygon. Who uses them?

2019-04-19 Thread Tobias Knerr
On 19.04.19 18:35, Dave F via Tagging wrote:
> Following a discussion on OSM-Carto, I'm curious what software uses
> junction=yes as a polygon.

Polygons with junction=yes + area:highway=* are part of some variants of
street area tagging, e.g.

That's if the streets themselves are also mapped as areas in addition to
ways, of course. Mapping _only_ the junction as an area, as shown in the
image on that wiki page, isn't something I'm familiar with.


Tagging mailing list

Re: [Tagging] Was barrier=jersey_barrier approved in a proposal?

2019-04-14 Thread Tobias Knerr
On 14.04.19 11:56, Joseph Eisenberg wrote:
> Thanks, Martin! I couldn’t find that link.

On many wiki pages, the infobox template will show an icon next to the
status (e.g. "approved"). Clicking that icon links to the proposal.

The link is based on the "statuslink" field of the template, and I find
it very useful for locating the proposal that a tag originated in.


Tagging mailing list

Re: [Tagging] RFC - Feature Proposal - area of steps for pedestrians.

2019-04-11 Thread Tobias Knerr
On 10.04.19 00:45, Warin wrote:
> But then if they are curved or have corners then in order to project
> that correctly form one way to the other they would need to have
> corresponding nodes.
> Say if is curved at the top but not at the bottom .. if the curve goes
> straight down .. ok .. but what if it recedes to the side as it goes down?
> Not convinced either way!

A decent heuristic is to connect each node from the upper border to the
closest point (not necessarily a node) on the lower border, and vice
versa. Then you place steps at regular intervals along these connections.

For common step shapes, this should produce the expected results. I
might be able to cobble together a proof of concept over the next few
days if that could help convince you?

Note that the method I describe above does not even try to work for
winding steps (i.e. those which you don't ascend in a straight line).
But there are other algorithms that would work for those, and the two
classes of steps could potentially be distinguished with a tag.

> Only by using an incline tag on the upper/lower ways ... I think at this
> stage.
> Then you also have the thought of unequal number of steps (Relation:
> 9441459)
> or uneven rise/run... (no example as yet)
> All good questions.

From my point of view, what we're discussing here is what the "medium
complexity" solution for steps should look like.

On the simple end of the spectrum, most steps can be represented just
fine as a single way.
On the super-detailed end, I'm sure that we'll want an approach based on
mapping individual steps as ways. It's easy to understand _and_ it works
for pretty much every weird special case (e.g. uneven rise/run).

So what we should be looking for, imo, is something in between that
saves us from having to use that kind of extreme micro-mapping for too
many steps.

To me, this means is that it's ok if it doesn't work for everything. Of
course, it should still work for a sufficient amount of cases to be
worth bothering with, and you gave an example (the shape with lots of
right angles) where a relation works, and a polygon does not. That's
indeed a downside.

What this also means, though, is that it actually has to feel less
complex than the detailed solution to mappers. And that's what I'm not
so sure about with relation-based solutions. I've seen many mappers
avoid relations in favour of approaches that arguably involve
duplication and extra work (e.g. using addr:street instead of
associatedStreet). Based on that, I feel that polygons might be a better
candidate for that "medium complexity" sweet spot than relations: A bit
less powerful, but (perceived to be) much more approachable.


Tagging mailing list

Re: [Tagging] RFC - Feature Proposal - area of steps for pedestrians.

2019-04-09 Thread Tobias Knerr
On 29.03.19 07:05, Warin wrote:

Detailed steps would be great for 3d rendering, so I'm very interested
in the topic as a data consumer. However, reading the proposal leaves me
with open questions. Could you describe the intended logic for
constructing the geometry of the individual steps from an area_steps
relation? I can think of several good heuristics myself, but the notable
"same number of nodes" rule makes me think you have something specific
in mind.

I do have some concerns regarding ease of mapping:

- I'm not convinced that a relation (rather than an area:highway
polygon) is necessary in typical cases. Usually, the most acute angles
of the polygon mark the point where the bottom/top border is separated
from the side border. It would seem sufficient to draw explicit lateral
ways only in cases where that assumption doesn't hold.
- Requiring the same number of nodes for the upper and lower way seems
very fragile. It's unexpected that inserting nodes into a way (or
removing them from a perfectly straight line) would invisibly break data.

Also, you suggest that different step_count values for the left and
right side could be modelled using your relation. But I don't see how I
could tell whether the steps are "missing" from the top or bottom?


Tagging mailing list

Re: [Tagging] Comments on documenting winter speed limits tagging

2019-04-03 Thread Tobias Knerr
On 28.02.19 11:16, Jyri-Petteri Paloposki wrote:
> – maxspeed:seasonal:winter for winter maxspeed, and :forward/:backward
> appended as necessary

Despite the feedback that maxspeed:conditional would be better suited
for this use case, this key has now been documented on the wiki:

I find that rather disappointing because the key is a poor fit with
several existing conventions. Even if we keep "winter" in the key, the
":seasonal" should definitely be dropped. After all, we use
maxspeed:forward (not maxspeed:directional:forward) and maxspeed:hgv
(not maxspeed:vehicular:hgv).

Conditional restrictions still strike me as the best solution, though,
and there are a few hundred examples in the database already.

Tagging mailing list

Re: [Tagging] Power transformers wiki page translations

2019-03-24 Thread Tobias Knerr
On 24.03.19 20:55, François Lacombe wrote:
> I lost the template name to indicate the translation is outdated, may
> someone remind me its name please?

You may be looking for the "translation out of sync" template:

Tagging mailing list

Re: [Tagging] Mapping curb (kerb) lines as the home of curb, parking, etc information

2019-03-05 Thread Tobias Knerr
On 05.03.19 01:01, Nick Bolten wrote:
> What would you think
> of a new 'associatedStreet'-style relation that would organize the
> various features that should be associated between streets and the
> surrounding environment?

That approach could work, yes – and it's one of the few practical
options I can think of at the moment. (The other would be drawing an
area:highway polygon around all the individual ways.)

Unlike associatedStreet, which contains all street ways sharing the same
name and can thus contain networks of essentially unbounded complexity,
these relations should probably only span the stretch between two
junctions, though.

While I would want to cobble together a proof of concept implementation
to be sure that I'm not overlooking anything, such a relation would
probably to solve the issue from a data consumer point of view. Of
course, it would have to actually be used by mappers to be helpful.

> Just to clarify, the road can keep all of its same data as is currently
> mapped. This would be an additional piece of information that tends to
> go unmapped.

In theory, the two approaches could peacefully coexist as long as tags
for kerbs, parking:lane etc. on the street ways themselves (and
highway=crossing nodes) remained available after drawing the separate
ways – at the cost of duplication and therefore additional maintenance.

There are some hurdles, though. Even mapping just sidewalks as a
separate way tends to break stuff. For example, people understandably
connect incoming footways only to the sidewalk way, not to the street
way. So an application that filters out these separate ways, hoping to
instead rely on tags on the street way, will find itself with missing
connections to the pedestrian network.

Of course, connecting the sidewalk to the highway with a relation would
likely offer a solution to that issue, too.


Tagging mailing list

Re: [Tagging] Mapping curb (kerb) lines as the home of curb, parking, etc information

2019-03-04 Thread Tobias Knerr
On 03.03.19 20:12, Nick Bolten wrote:
> I wanted to get a discussion started to see what people think of
> mapping curbs as ways.

Can we please first define a solution (e.g. a relation) for connecting
such separately mapped components of a road to the highway?

Painting lines next to each other fails to express the important
information that this kerb/sidewalk/cycleway is part of that highway
over there. Such missing information may be easily guessed by a human
viewer, but it's currently not available in a machine-readable form.

This fundamental limitation really needs to be addressed before we
consider splitting roads into even more parallel ways.

Tagging mailing list

Re: [Tagging] Comments on documenting winter speed limits tagging

2019-02-28 Thread Tobias Knerr
On 28.02.19 11:16, Jyri-Petteri Paloposki wrote:
> – maxspeed:seasonal:winter for winter maxspeed, and :forward/:backward
> appended as necessary

Have you considered Conditional restrictions[1]? You mentioned them as
one of the existing tagging solutions (you had "80 @ winter" as the
example), and to me, they seem like a good fit. It makes a certain
intuitive sense to treat seasons similarly to how we already treat dates
and weather.

> On motorways with variable speed limits I've additionally added a
> maxspeed:variable:max to indicate the highest (summer) speed limit
> allowed on the highway.

If I understand the approved "Dynamic maxspeed" proposal[2] correctly,
it suggests tagging the maximum maxspeed using the regular maxspeed tag,
and adding maxspeed:variable=yes to indicate that the maxspeed is variable.



Tagging mailing list

Re: [Tagging] sleepable:physical=yes/no? Re: How to map Hostile Architecture? e.g. benches you can't lie/sleep on?

2019-02-28 Thread Tobias Knerr
On 28.02.19 16:15, Rory McCann wrote:
> What about `sleepable:physical=yes/no`? It's clear that it's about "can
> you *physically* sleep on this bench".

Seems sufficiently verifiable and neutral to me. If we're going with a
single-purpose tag, it's a good candidate.

I don't think it's the best possible solution, though. As mentioned on
Reddit, I prefer tags that have more than one use case. Information
about the physical properties of a bench can be used by sleepers, but
also by those looking for benches with armrests that help them get back
up, for 3d models, etc. A dedicated "sleepable" tag is not useful for
anything else.

> Tagging
> armrests might be interesting, but it doesn't answer the question of
> "can someone physically sleep here (and has it been modified/designed to
> prevent that)".

It doesn't answer that question on its own, but it does when combined
with other tags (e.g. for non-horizontal surfaces).


Tagging mailing list

Re: [Tagging] start_date variants

2019-02-22 Thread Tobias Knerr
On 15.02.19 11:03, Stephan Bösch-Plepelits wrote:
> Example: There is this museum, which openened in 2011, but the building is
> much older, it was built in 1725: 

The root of the issue is that two different features (a building, and a
museum inside that building) are mapped as a single OSM element. That's
ok as a shortcut in simple cases, but when the two features have
different names, different Wikipedia links, and different start dates,
they should really be split into two elements: One for the building, one
for the museum.

Generally, I believe that following a "One feature <=> one OSM element"
principle will lead to cleaner data.


Tagging mailing list

Re: [Tagging] units and notations for maxstay

2019-02-21 Thread Tobias Knerr
On 21.02.19 20:15, Andrew Errington wrote:
> If there is no limit then omit the maxstay tag. No tag, no limit.

Personally, I would indeed not set a maxstay tag if there's no limit.

However, even if we never want to tag maxstay=unlimited, such a value
would still be useful in the context of conditional restrictions: It
allows us to naturally express situations where there's normally a
maxstay, but unlimited stay is allowed under certain conditions – e.g.
at certain times, or for a certain group of people. For that, we
probably want maxstay:conditional = unlimited @ (somecondition).


Tagging mailing list

Re: [Tagging] units and notations for maxstay

2019-02-21 Thread Tobias Knerr
On 20.02.19 00:46, Warin wrote:
> On default units ..

I don't think there's a single unit that would be the obvious default
for maxstay, as both minutes and hours will be common. Omitting the unit
will lead to misunderstandings in that situation.

Therefore, I would define no default, treat missing units as a mistake,
and encourage people to always explicitly write down a unit for maxstay.

Tagging mailing list

Re: [Tagging] units and notations for maxstay

2019-02-21 Thread Tobias Knerr
On 20.02.19 00:08, Warin wrote:
> 24/7 is used for opening hours - so for consistency I would tend to go
> for that.

Maxstay values are durations, opening_hours values (such as "24/7")
refer to time intervals. Those are separate concepts, so I don't think
consistency is called for.

If we want an explicit value for unlimited duration, I recommend
"unlimited". It's a simple and unambiguous solution.


Tagging mailing list

Re: [Tagging] tree rows vs individual trees

2019-02-09 Thread Tobias Knerr
On 09.02.19 15:23, Tom Pfeifer wrote:
> "Tree rows ... This approach can also be combined with individually
> mapped trees for further details."
> IMHO this violates the one object - one OSM element principle. Either I
> choose the coarser approach to map a way for the row, or I refine it to
> individual trees, but should not use the row anymore.

Because the two feature types exist at different levels of abstraction
(a tree is *part* of a tree row), I do not see this as a violation of
one feature, one element.

Instead, I consider it comparable to mapping building:part areas within
a building=residential outline within a landuse=residential, or mapping
amenity=parking_space areas within an amenity=parking.

> If a renderer wants to cluster any trees that can be done algorithmically.

Writing an algorithm to reconstruct tree rows from individual tree nodes
is probably possible, but it's more complex than what OSM renderers
usually bother with – even for features that are much more significant
than tree rows. Checking whether a tree node is part of a tree_row way,
on the other hand, is far easier and only requires relatively standard
OSM tooling. So the latter seems like the more practical solution to me.


Tagging mailing list

Re: [Tagging] The actual use of the level tag

2019-02-03 Thread Tobias Knerr
On 22.01.19 22:18, Tobias Zwick wrote:
> First, I am still in the dark a bit how this affects SIT with S3DB
> compatibility, perhaps Tordanik can explain.

My comment regarding S3DB compatibility was about the related issues
that were brought up in this thread (e.g. indoor features outside of a
building outline). Your suggested tagging for non-numeric levels would
not harm S3DB compatibility, as long as mappers reliably add the levels tag.

To respond to the points from your previous mail:

On 21.01.19 20:16, Tobias Zwick wrote:
> In the current SIT scheme*, in this case, it is required to add 5
> additional outlines, one for each floor (indoor=level)

Using the currently documented tags, that's mostly true (the levels
where the number is actually used as the ref wouldn't require the
indoor=level) element. I admit that this is more work than one would
want for a simple case.

However, in addition to your suggestion, there are multiple other
possible approaches for making this easier. One is the level:ref key.
Independently from SIT, this has been proposed for use on individual
indoor elements alongside level. When you have a building that isn't
actually fully indoor-mapped, but simply has a few POI with level tags
(which is likely to be the much more common case), this might be an option.

If we wanted to do something similar to your suggestion (i.e. place a
tag on the building outline), this would be possible without redefining
level to allow non-numeric levels: We could invent a new key – say,
"level:refs" – that would be added to the building to indicate the
locally used level labels:


Then, if you want to know what to display for an element tagged as
level=0, you can just look it up in that list. This approach is pretty
much the precise mirror image of the one you suggested earlier, and
requires the same amount of elements and tags.

So which approach is the best? To be honest, I'm not sure about that
yet. But I agree that the current SIT definition leaves room for

Tagging mailing list

Re: [Tagging] The actual use of the level tag

2019-01-21 Thread Tobias Knerr
On 21.01.19 22:38, Roland Olbricht wrote:
> I do consider both to be SIT compliant.

I'm not sure if it's clear from the written text of SIT, but neither
fractional levels nor indoor features outside of a building outline were
part of SIT's design. (And yes, these are obvious omissions that will
need work.)

> In particular, there is no object that could or should carry tags
> applying to all involved objects.

Levels only have meaning within a single structure, though. Level "2" in
the neighbouring building (or even building part) might represent an
entirely different absolute elevation.

An important assumption (and limitation, because this isn't always true
in reality) of SIT is, therefore, that there is some kind of outline
within which a level number refers to a single, fixed elevation.

I didn't really raise that point so far because I don't have a better
solution to offer yet, but your station mapping does contradict the
assumptions we had when writing SIT, and I feel we should collaborate to
define the semantics of such a situation.

> But I do not see yet why there should be a mapping of levels to integers
> at all.

One reason that's of particular interest to me is that SIT is intended
to be compatible with 3D rendering, allowing for the creation of 3D
models that represent both the inside and outside of buildings at the
same time.

At the moment, Simple 3D Buildings has no support for "half" levels, so
if we want to preserve that feature of SIT, we would need to update both
tagging standards at the same time.

Tagging mailing list

Re: [Tagging] The actual use of the level tag

2019-01-20 Thread Tobias Knerr
On 20.01.19 19:37, Tobias Zwick wrote:
> - a shop on level M with "level=M"
> - the mall building with "levels=P2,P1,G,M,1-12,14-99" (the order of the
>   levels). If levels is missing, a numerical order is assumed

So essentially, one uses the local level reference in level=*, and
provides a mapping onto a standardized level sequence with separate,
building-wide tags.

Admittedly, I haven't really considered that yet. It's also interesting
because I would have suggested the exact opposite: Using standardized
level numbers in the level=* tag, and defining a mapping onto the local
level references for display purposes. This is pretty much the current
logic behind SIT.

One comparatively minor issue with your approach is that it becomes
harder for editors to provide basic indoor mapping support: Something
like the level switcher currently available in JOSM won't work any more,
because there would no longer be a consistent order of levels across
buildings. You would need to select a building to edit first, and use a
building-local level switcher. Manually-defined tag filters would
likewise need to be updated, e.g. in order to support level ranges
properly (a staircase tagged level=G-1 should be visible while editing
level M).

The main challenge I see with your proposal, though, is that the
levels=* tag on the building would be utterly required to make any sense
of the order of floors. Without it, applications would have no idea
whether "M" is above or below "P2", for example. So at the very least,
adding levels=* should explicitly be documented as mandatory when using
non-standard levels.

If we can get our fellow mappers to largely stick with such a rule, your
idea would work. So would the existing solutions, though, and that "if"
is something I am worried about.

Tagging mailing list

Re: [Tagging] The actual use of the level tag

2019-01-20 Thread Tobias Knerr
On 20.01.19 18:06, Roland Olbricht wrote:
> I am also a bit surprised: a common interpretation of the text of
> (which is where
> refers to) is that the level tag keeps the level numbering scheme of the
> operator whenever it is sufficently tied to numbers (that's almost
> always the case).

That's true, and having entrances at different "street levels" is
therefore not a problem: You can just follow the operator's choice.

Being "sufficiently tied to numbers" is an issue, though. SIT assumes
integer level numbers, where the level above level=n is level=n+1

So from a SIT perspective, the problem isn't that the US (and other
places) call the ground level "1". It's that the level below that is
called "-1" rather than "0". You could still make it compatible with
Simple Indoor Tagging by adding a skipped_levels=0 tag to the building,
but this tag has only been used five times so far.

Tagging mailing list

Re: [Tagging] The actual use of the level tag

2019-01-20 Thread Tobias Knerr
On 20.01.19 14:49, Tobias Zwick wrote:
> 2. generally, tagging definitions that are not intuitive to use (in a
> region) will not be used consistently (in that region), leading to
> ambiguous data.

I believe the high number of (potential) errors is temporary, resulting
from the relative lack of software support for indoor mapping. Once
application support is commonplace, mappers will likely notice that it
"renders wrong", and fix their data accordingly. Proper editor support
would be valuable, too, of course.

Tagging mailing list

Re: [Tagging] Quick Building tracing question...

2019-01-11 Thread Tobias Knerr
On 10.01.19 11:28, Allan Mustard wrote:
> My understanding of the 3D aspect of building:part is that if you draw a
> portion of a building using building:part you have to do the rest of the
> building using building:part as well or the whole building will not
> render in 3D, since 3D software is programmed to ignore the base
> building footprint if building:part is present, is that correct?

Yes, that is correct (according to Simple 3D Buildings tagging).

So if you want to represent the situation in question as a building with
two parts, you could draw a building:part=roof area for the roof, and a
building:part=yes area for the rest of the warehouse. Then surround both
of them with a building=warehouse area, probably re-using the nodes of
the building parts.

Some 3D renderers will attempt to figure out what the mapper might have
intended if this rule isn't followed. But that's undefined behaviour and
will vary considerably between programs, so it shouldn't be relied on.


Tagging mailing list

Re: [Tagging] Facts and opinions

2019-01-09 Thread Tobias Knerr
On 07.01.19 16:12, Bryan Housel wrote:
> we can’t use the same key `service=*` to contain both things like `tyres` (a 
> few thousands) and `driveway` (a few millions).  Sorry, but the 
> `service=tyres` has to go.

These two different meanings of 'service=*' would not need to coexist on
the same element, so it's not impossible to use the same key. I happen
to agree that it's not a good idea, but it's not a foregone conclusion.

Therefore, it makes me a little uncomfortable that this kind of change
would be promoted through iD, instead of convincing mappers to make an
active, informed decision to switch to a new tagging scheme. I've been
silent on this recurring issue so far because, well, most of your
decisions have actually been quite reasonable, and it felt a bit silly
to object based on purely hypothetical concerns. Also, I don't feel
strongly about vehicle services in particular.

But with great power comes great responsibility, if you forgive the
stale quote. And while I'm not opposed to doing some sanity checking
(i.e. not automatically supporting poorly thought out tags just because
they are common), I do feel that the default editor on should
generally only promote clearly established tagging styles.

> I encourage everyone to just disregard everything that’s on the wiki and go 
> by what taginfo says as far as how the tags are used and what the accepted 
> values are.

The wiki is an invaluable source for understanding OSM tagging, and I
use it all the time during mapping and when coding software that works
with OSM data.

Taginfo is an awesome resource as well, and I use it almost daily, but
it cannot fully replace the wiki. It tells you that foo=bar has been
used thousands of times, but it doesn't tell you what that tag means¹.
It also doesn't tell you about the conventions for its use (default
values, directionality, lots of other essential details). Ultimately,
Taginfo isn't documentation – the wiki is.

Besides documenting current tagging practice, the wiki is also a useful
tool for coordinating and spreading new ideas (even though the specifics
of the process can be controversial at times). If you're not a software
developer or one of a few highly respected community members,
discussions on community channels and wiki proposals are pretty much
your only good options to make your genius tagging idea known to the
world. Without this first step, that idea is unlikely to get enough
traction to even show up in Taginfo to a meaningful extent: Using the
tag yourself only gets you so far.

For all these reasons, I consider the wiki a key asset to our project.
As a result, I spend a lot of time improving it, as do many other
community members. It hurts to see that some developers of core OSM
infrastructure seemingly value these contributions so little. To me,
people discussing and documenting our data model are a vital part of our
community. So are software developers, of course! It's my belief that
the project can only thrive if there's mutual respect between these groups.


¹ Taginfo actually does provide a definition, but that's because it
extracts them from wiki pages.

Tagging mailing list

Re: [Tagging] amenity=taxi vehicle type

2019-01-05 Thread Tobias Knerr
On 05.01.19 02:19, Warin wrote:
> On 05/01/19 10:34, Tom Pfeifer wrote:
>> taxi_type = car|motorcycle|rickshaw, etc,
> What does 'type' add to the above?

The key taxi=* is already in use to tag access permission for taxi
vehicles, with values such as yes|no|designated|destination|permissive.

So adding a "_type" here avoids clashing with an existing key that has a
different meaning and a different set of values.

Tagging mailing list

[Tagging] Feature Proposal - RFC - Top up

2018-12-27 Thread Tobias Knerr
On 26.12.2018 19:05, bkil wrote:> top_up:phone:‹brand›=yes;no
> top_up:transport:‹brand›=yes;no
> top_up:credit_card:‹brand›=yes;no
> This is not the same wording as discussed above, but I still like this one.

I'd prefer if the supported brands were part of the value – as most
brand-related strings currently are. Like this, for example:

top_up:phone = Brand1;Brand2

Otherwise, we would end up with a very large, unbounded number of keys,
which likely isn't as easy to support for editing tools. And (although
this is the least important reason) brands are likely to use characters
such as uppercase letters or non-ASCII characters that should be avoided
in keys where possible.

Description: OpenPGP digital signature
Tagging mailing list

Re: [Tagging] 2 meaning for crossing=zebra

2018-10-26 Thread Tobias Knerr
On 26.10.2018 11:11, Mateusz Konieczny wrote:
> In general crossing tag is attempting to tag several different things
> at once - for example how I am supposed to tag crossing with island,
> traffic lights and zebra markings in Poland?

The presence of an island is quite commonly tagged as crossing:island=yes.

There's currently no established tagging for a crossing that has both
traffic lights and a zebra pattern, which calls for the invention of a
new tag.

Tagging mailing list

[Tagging] 2 meaning for crossing=zebra

2018-10-26 Thread Tobias Knerr
On 26.10.2018 16:24, Tom Pfeifer wrote:
> Do you see the contradiction? If the crossing is unmarked, the ground
> object already does not provide any guidance. As we map what's on the
> ground, there is nothing to map.

It's not uncommon for a crossing to be physically evident on the ground
(e.g. because of lowered kerbs) even if there are no painted markings.
To me, that would be a typical example of an unmarked crossing.

Tagging mailing list

Re: [Tagging] 2 meaning for crossing=zebra

2018-10-26 Thread Tobias Knerr
On 26.10.2018 01:18, Bryan Housel wrote:
> Oh!  I don’t like `crossing=zebra` either.  Not sure whether you caught the 
> end of that issue #4788, but anyway I've decided I'm tired of hearing people 
> complain about `crossing=zebra` so going forward iD will support these 2 
> presets: 
> - `crossing=marked` which is labeled “Marked Crosswalk"  
> - `crossing=unmarked` which is labeled “Unmarked Crossing” 

There already is a perfectly fine value for marked crosswalks, which is
called "uncontrolled". Replacing this with the barely-used "marked" (100
times fewer uses than "uncontrolled") seems unhelpful. After all, the
issue that gave rise to the "zebra" value isn't to distinguish marked
from unmarked crossings. It's to distinguish two different types of
marked-but-uncontrolled crossings.

Tagging mailing list

Re: [Tagging] Opening hours too long for OSM

2018-10-12 Thread Tobias Knerr
> Am 12.10.2018 um 01:27 schrieb Simon Poole:
>> We have a number of keys for which the values can easily exceed 255
>> chars besides opening_hours, lane destinations and conditional
>> restrictions are good candidates. Not to mention changeset tags. With
>> other words it is a general problem which should be tackled with a
>> general solution.

I agree that this problem calls for a general solution, as it's not
specific to opening hours. And yes, an extension syntax seems like a
good choice for now. While it's going to be entered manually at first,
it would allow transparent editor support, and possibly an automatic
conversion if any future API revision should support longer values natively.

We need to make sure that this can be implemented in a key-agnostic
manner, though, i.e. by simply concatenating the values. This means: No
key-specific exceptions such as omitting semicolons in an opening hours

I don't have any strong opinions on the syntax, but it should be
something that doesn't clash with existing uses. Tobias' suggestion to
use _2 suffixes would overlap with things like name_2 that are currently
used in the database, so I'd prefer using something else. Maybe double
underscores, or a character such as # that's not typically used in keys
at all?

Tagging mailing list

Re: [Tagging] highway=crossing used on ways

2018-10-12 Thread Tobias Knerr
On 12.10.2018 09:25, Gerd Petermann wrote:
> In November 2015 I fix nearly all such ways, since then the number increased 
> again to 488. I don't know about iD, but JOSM prints a warning
> when you use this tagging, still many edits were made with JOSM. I wonder if 
> that means that we should accept highway=crossing as a shortcut for 
> highway=footway + footway=crossing?

The highway=crossing tag has been used 2787469 times, according to
Taginfo. So these 488 occurrences on ways don't even represent a tenth
of a percent of the tag's total uses. I don't think this is a strong
reason to change the tag's definition.

Having some amount of "noise" in the data is one of the downsides we
accept with our open tagging model, and in my experience, you will find
a similar amount of non-standard uses, misspellings and other errors for
most tags. However, it's still beneficial to clean up every now and
then, so thank you for your past efforts to fix the errors in the
database and improve the documentation! And it's encouraging to hear
that JOSM validator catches this kind of problem, I hope other editors
will also eventually add more error-checking tools.

Tagging mailing list

Re: [Tagging] Traffic_sign discussion

2018-10-09 Thread Tobias Knerr
On 09.10.2018 17:42, yo paseopor wrote:
> So Please , let's talk about it. What will be the correct way to tag a
> traffic sign?

How about the existing tagging scheme for traffic signs on nodes,
documented at ?

To sum it up:

- Place a node for the traffic sign into the highway=* way.¹
- Tag the node as traffic_sign=:.
- As with your suggestion,  is the ISO country code.
-  is composed of one or more country-specific traffic sign ids, as
an ordered list separated by commas.
- If there are multiple groups of traffic signs, these groups are
separated by semicolons.
- Custom inscriptions on a sign are appended to the sign id in square
brackets [].

¹ The page also documents how to map traffic signs next to the way, but
I understand you would like to talk about mapping them as part of the way.

I haven't seen a convincing reason for changing this yet. I'm aware of
the general argument against semicolon-separated or comma-separated
lists of values, but imo this is less critical for keys that have
well-defined semantics for such characters.

> traffic_sign:direction=forward/backward/both
> Also accepts other facing directions like 90/270...

In my opinion, traffic signs should use the normal direction=* key for
angles such as 90 or 270. This usage is part of the approved proposal of
that key:

Using traffic_sign:direction specifically for the "forward" and
"backward" values, as discussed in the recent iD-related thread, is fine.


I find it hard to discuss this proposal because it includes so many
different ideas:

- introducing a system of "categories" for signs: caution, warning, etc.
- using :2, :3 etc. instead of comma-separated ids
- using human-readable values instead of unambiguous national IDs
- re-purposing maxspeed (and maxspeed:hgv etc.) for traffic sign mapping
- adding a side=* key
- improving destination sign and roundabout mapping

Trying to change all that at once likely leads to discussions that mix
all sorts of loosely related topics. And there's not really a reason why
e.g. introducing the side=* key would also require using numeric
suffixes. These are independent changes that could easily be discussed

Tagging mailing list

Re: [Tagging] building:min_level, building:max_level, min_level, max_level

2018-10-08 Thread Tobias Knerr
On 08.10.2018 15:55, Martin Koppenhoefer wrote:
> Version A is used and defined here:
> Version B mentions the tags for buildings, but doesn't specify the details:
> Do we really need 2 ocmpeting tags for this?

These aren't intended as competing tags, but as complimentary tags. A
perfectly mapped building (indoor mapping + outdoor 3D modelling) should
currently use both sets of tags. The tags mentioned in A are used for
describing the outer shape of the building, whereas the tags from B are
used for indoor mapping.

These different use cases result in somewhat different conventions for
the tags:

- A is only counting above-ground levels (because only those can be
verified without entering the building), whereas B includes underground
- B allows for things like "skipped levels", to reflect naming
conventions chosen by the building owners, whereas A is strictly about
counting levels, and does not take local customs for naming levels into
account at all.

The goal of mapping both is to match up the outdoor and indoor
rendering. Or putting it differently, it answers the question which
floor should be visible behind which row of windows.

Of course, we can imagine alternative approaches for achieving this. For
example, there could be some kind of tag that explicitly expresses
"outdoor-level 0 corresponds to indoor-level -1". If we find a solution
for the problem that's easier to understand and use that the currently
documented one, it may be worth considering. But the S3DB building:*=*
tags on their own are not a suitable replacement for Simple Indoor
Tagging's min/max levels.

Tagging mailing list

Re: [Tagging] Traffic sign direction tagging..

2018-10-02 Thread Tobias Knerr
On 02.10.2018 16:44, yo paseopor wrote:
> Also it is not the best call "undersigns" . There are signs too, with
> their code, and you can put in on second place or third place , like
> traffic_sign:2 as Finnish people does.

Or put them in a comma-separated list, which is the international
standard tagging that's documented on

There's no reason to reinvent the wheel here. Plus, as far as I can
tell, the suffix (:2) solution doesn't  work when there's more than one
"main" traffic sign.

Tagging mailing list

Re: [Tagging] double doors?

2018-08-17 Thread Tobias Knerr
On 17.08.2018 14:10, seirra wrote:
> should these be split into two separate door elements, or should it be
> tagged as just a really wide door?

Assuming we're talking about a hinged door with multiple wings, there's
a proposed door:wings key with 178 uses at the time of writing. Using
that, you would simply add the door:wings=2 tag to the door node.

Tagging mailing list

Re: [Tagging] Put the name in sidewalks and cycleways

2018-08-06 Thread Tobias Knerr
On 06.08.2018 05:59, Andrew Harvey wrote:
> I like the idea of adding the sidewalk to the associatedStreet relation,
> perhaps role=sidewalk?

Streets can branch into an arbitrarily complex network where all the
branches still share the same name. A single relation containing all
streets and sidewalks with the same name is therefore unfortunately not
sufficient to solve the underlying problem.

Tagging mailing list

Re: [Tagging] Put the name in sidewalks and cycleways

2018-08-05 Thread Tobias Knerr
On 05.08.2018 17:16, yo paseopor wrote:
> So what is the correct way to map it: with name? or without name?

Adding name tags to separately mapped sidewalks is an attempt to fix
just one of the symptoms of a deeper problem: The lack of a
machine-readable link between the sidewalk way and the road it belongs to.

This fundamental shortcoming of the current approach for
sidewalk-as-a-way mapping also causes several other issues, though,
which aren't as easily compensated for. There's nothing wrong with
copying the name per se, but needing to do so is a red flag.

So my recommendation is to stick with sidewalk tags. Alternatively,
create a relation between each highway way and the one or two sidewalk
ways belonging to it. (You'll probably balk at that, but something along
those lines would be needed to actually _solve_ the inherent flaws of
the sidewalk-as-a-way approach.)

Tagging mailing list

Re: [Tagging] Let's get (quite) rid of units and their multiples in OSM values

2018-07-27 Thread Tobias Knerr
On 26.07.2018 21:26, François Lacombe wrote:
> Then store voltage=40 is far way better but harder to be read by
> humans also.

I currently prefer explicit units in the database because they document
the mapper's intent and avoid ambiguity.

Defaults aren't always obvious. For example, people mapping pipelines
have documented millimetres as the default for diameter=*, but it seems
tree mappers haven't gotten the memo and (reasonably) assume it's
defaulting to metres like height=*, width=* or circumference=*.

When a value is actually signposted on the ground, it's most likely
preferable to use the original unit and avoid conversions. Apart from
that particular case, I can see some benefits of your suggestion – _if_
you can convince the community to reliably agree on how unit-less values
are interpreted.

> doesn't help
> regarding such issues.

It helps by providing data consumers with information they need to
support both explicit and implicit units. Some have gotten around to
implementing that feature, others haven't yet – but in principle, it
seems entirely possible to support queries like [voltage>20 kV], to use
your example.

Tagging mailing list

Re: [Tagging] landuse=sand

2018-07-19 Thread Tobias Knerr
On 18.07.2018 07:43, Warin wrote:
> I have already changed a few. Are there any comments on changing
> landuse=sand, before it becomes like landuse=grass etc,?

I fully agree with you that landuse=sand should not be used. Existing
tags like natural=sand and surface=sand already cover sand-related use
cases just fine. So thanks for keeping an eye on this!

Tagging mailing list

Re: [Tagging] building=clubhouse

2018-07-19 Thread Tobias Knerr
On 19.07.2018 05:15, Warin wrote:
> Would it not be best to combine all theses into building=clubhouse?

I'm not opposed to the general idea of having a sport-independent tag
for clubhouses, if we can agree on a suitable tag.

However, please remember that the value of building=* does _not_
indicate what the building is used for. So I don't think it's a good
choice for this purpose.

Tagging mailing list

Re: [Tagging] `amenity=shelter` implies `building=yes`?

2018-06-18 Thread Tobias Knerr
On 18.06.2018 17:22, Kevin Kenny wrote:
> Would it be feasible to say that building=yes is a default (except,
> perhaps, for rock_shelter, sun_shelter) and that mappers are expected to
> place an expected building=no on the exceptions? 

Using building=no is a bad idea, as any object tagged building=* is
defined as representing a building – no matter the value. In particular,
data consumers should be able to fall back onto building=yes for all
unknown building values.

Tagging mailing list

[Tagging] wall and block that aren't a barrier

2018-06-11 Thread Tobias Knerr
On 09.06.2018 23:13, marc marc wrote:

Based on this picture, the current mapping is clearly incorrect. This
basin doesn't qualify as a barrier=retaining_wall even if we allow for a
very generous reading of the tag's definition.

For most use cases, I believe it would be entirely sufficient to draw an
area for the fountain, and add subtags as desired. For map users who are
interested in how the fountain looks, the image and wikimedia_commons
tags are already available.

The mapper seems to be interested in going beyond that and creating a
relatively detailed model of the fountain, which is a legitimate goal
and might be useful in some applications, e.g. 3D rendering. However,
I'd argue that our editors and data model aren't really the right tools
for that job. It would seem more practical to create a model of the
fountain in Blender or SketchUp, which could then be uploaded to the 3D
Model Repository and linked with OSM.

If we to try to model the fountain using OSM ways and areas anyway,
though, then I'd rather see specialized tags for fountain micromapping
(nano-mapping?) introduced. Re-purposing existing tags for this use case
isn't a good idea imo.

Tagging mailing list

Re: [Tagging] brand=* necessary?

2018-05-10 Thread Tobias Knerr
On 10.05.2018 16:23, Martin Koppenhoefer wrote:
> The reason why it is done differently is not an educated decision but the 
> result of poor presets and mappers filling them in without further reflection.

Sure, but uneducated decisions reveal a lot about people's intuitions
and interests – two factors that deserve to be taken into account.

When mappers can fill in data without further reflection and still
produce useful results (which I argue is the case here) then that
strikes me as a huge usability win!

> It is also a result of how the tags have been introduced

It's true that brand was introduced later than name, and that it has
been at a disadvantage due to rendering support and the key's history.

That's probably not a coincidence, though. I assume it was introduced
and adopted more slowly precisely because not that many people were
interested in making the distinction in the first place.

Tagging mailing list

Re: [Tagging] access=disabled

2018-05-10 Thread Tobias Knerr
On 10.05.2018 05:04, Johnparis wrote:
> access=no
> disabled=yes
> be consistent with other such, like 
> access=no
> bus=yes

Unlike "bus", "disabled" is not a mode of transport, so it should not be
used in the key of access tags.

Tagging mailing list

Re: [Tagging] brand=* necessary?

2018-05-10 Thread Tobias Knerr
On 10.05.2018 09:52, marc marc wrote:
> Imho it us the opposite : name should be added only if it us not the
> same as brand 

That approach is different from real-world usage of the tags and appears
to offer little practical benefit.

As far as I can tell, many – probably most – mappers look at the store's
sign and add that appellation to the name tag, no matter whether it's
the name of an individual store or the brand of a chain of stores.

It turns out this usage matches the usual expectations of data consumers
and map users, so I don't see a strong incentive to change it.

I appreciate that there's technically a distinction to be made. And of
course I'm also ok with people who care about these subtleties adding
operator=* and brand=* tags. But personally, I find the intricacies of
corporate organization and branding very uninteresting and would like to
stick with a solution that allows most mappers to not care about it.

Tagging mailing list

Re: [Tagging] Small gate only for foot access

2018-04-20 Thread Tobias Knerr
On 20.04.2018 14:03, wrote:
> Just because it’s not as often used in this way doesn’t mean it’s wrong.

In my opinion, it's indeed wrong, but not so much because of the low
number of uses. Instead, it's wrong because it contradicts the
relatively well-defined syntax of access tagging.

With access tags, the key is always used for mode of transport (vehicle,
foot, bicycle, hgv, etc.). The value is reserved for a completely
different set of possible entries, describing user groups and level of

> It would be in line with the usage I’ve seen in the access:lanes tag,
> e.g. access:lanes=yes|yes|bus or access:lanes=bicycle|yes|hsv

It's clear what people are trying to express here, but these tags
nevertheless contradict the general system for access tagging mentioned
above. So I hope this usage doesn't spread.

Tagging mailing list

Re: [Tagging] RFC - Key: spacing=*

2018-04-18 Thread Tobias Knerr
Hi Peter,

On 18.04.2018 13:53, Peter Elderson wrote:
> I am exploring the possibility of proposing a new key for spacing of
> more or less regularly distributed objects along a way or over an area.

I like the idea. Way back, during the the tree row proposal, it was
suggested that either this key or a "number of trees" key should be
documented, and it makes a lot of sense in my opinion.

What I'm not convinced about is the "nodes" value:

> - I'm thinking of adding a special value to indicate that the exact
> location of the objects is given by the nodes mapped on the way. The
> value could be 0 or 'free'or 'nodes'.

I'm worried that mappers would easily miss the special meaning of these
untagged nodes. They might end up removing "unnecessary" nodes from
straight sections of the tree row, for example. The currently documented
solution (using natural=tree) makes it obvious that the nodes represent
real-world objects.

Apart from that difference, the current convention enables all the same
use cases, such as different rendering for trees that are part of a tree
row. Even the idea of "inheriting" subtags like height or tree species
from the way can be implemented for the current tagging. So I don't see
a strong need to change this aspect of tree rows.


Tagging mailing list

Re: [Tagging] AutoEdit rename roof:slope:direction to roof:direction

2018-02-18 Thread Tobias Knerr
On 12.02.2018 01:06, marc marc wrote:
> the POC for the first part

Not sure if you're still waiting for feedback on your proof of concept?
In any case, I've had a look at those changes, and they're looking good
to me! I'd be happy to see the edit proceed.

Tagging mailing list

Re: [Tagging] AutoEdit rename roof:slope:direction to roof:direction

2018-02-11 Thread Tobias Knerr
On 10.02.2018 17:55, User Rebo wrote:
> Update: Since now I have 4 positive responses (via OSM messages or
> forum). And no objections.
> Can start renaming?

I think the consensus is sufficiently clear to proceed. Nevertheless, it
would still be nice to create a small wiki page to document your plans
as mentioned in the Automated Edits code of conduct¹. Some of the things
you mentioned here (such as the conversion table between
roof:ridge:direction values and roof:direction values) would be a good
example of what to put on that page.

Have you already decided what tool you're going to use to perform the
change? I believe you initially mentioned that you weren't sure yet what
software would be best to use.

Also keep in mind that the code of conduct recommends the following:
"Execute only a small number of edits with a new bot before requesting
and waiting for feedback before proceeding with larger edits." So after
doing your first handful of changes, it would be nice to inform the list
so we can review them. Alternatively, you could share the planned
changes with us as an .osm file or in a similar format before uploading
them – whatever works best with your intended tools.


Tagging mailing list

Re: [Tagging] Proposed definition for surface=cobblestone/sett/paving_stones

2018-01-22 Thread Tobias Knerr
On 22.01.2018 17:25, Fernando Trebien wrote:
> - sett: hewn stones with flat top (...) [2] (...)> - cobblestone: hewn stones 
> with slightly arched top (...) images [3]
and [4]

I don't believe requiring mappers to make a distinction between these
two is a good idea. Let's look at your images:

> [2]
> [3]
> [4]

If I read your mail correctly, you suggest that [3] and [4] belong in
the same category, while [2] is a fundamentally different surface type.

But when I look at these, [2] and [3] feel a lot more similar to each
other than [4] is to either of them.


Tagging mailing list

Re: [Tagging] How to tag shop areas in a shopping mall ?

2018-01-21 Thread Tobias Knerr
On 21.01.2018 17:48, OSMDoudou wrote:
> When I tag the perimeter with indoor=room instead of building=yes, JOSM 
> raises an error "Overlapping ways" for the segment B->C in this kind of 
> layout:
> If I change the tags from indoor=wall to building=yes, no error is raised 
> anymore (but then of course, Osmose will report overlapping building, which 
> is the start of this discussion).

It's just a case of JOSM's validator not knowing about indoor=* yet. So
it produces incorrect warnings that can safely be ignored

There was a recent mention of the same problem on

I believe the list of tags that needs to be extended to fix the issue is
the same as it was with a similar issue (overlapping way warning with
waterway=riverbank), but I'm not very familiar with JOSM's codebase:

> It seems indoor walls cannot overlap. Same if I try indoor=room.

Note that unlike indoor=room, overlapping indoor=wall segments are
indeed an error.

Tagging mailing list

Re: [Tagging] How to tag shop areas in a shopping mall ?

2018-01-18 Thread Tobias Knerr
On 17.01.2018 23:16, OSMDoudou wrote:
> There is a shopping mall here [1] for which a mapper detailed the inside
> shops with a node for the "identity" and an area for the "physical
> perimeter" of the shop inside the mall. [...]
> Can you suggest tagging improvements ?

My suggestion (based on Simple Indoor Tagging¹) is to tag the areas with
their shop tag, level, and and other attributes such as name. So you get
a closed way with some basic tags, for example:

name = Jack & Jones
shop = clothes
level = 0

There's no reason to keep the nodes around once you have mapped the
shops as areas, so move all other tags such as opening hours to the area

At this point, you have a perfectly valid representation of the mall, so
you can stop here if you want. But if you're interested in adding more
details, there's a lot of possibilities: Add indoor=room or indoor=area
tags to the shop areas (depending on whether they're fully enclosed with
walls or not), and add walls (indoor=wall), corridors (indoor=corridor),
doors, elevators, staircases and so on.



Tagging mailing list

Re: [Tagging] area=yes on object without kind

2018-01-12 Thread Tobias Knerr
I sometimes use surface=* as a stand-alone tag for areas with an unclear
or uninteresting purpose. Doing so captures the physical reality on the
ground pretty well in my opinion.

From this point of view, the area in question is already tagged
correctly. Maybe we can find out what it's being used for, in which case
adding that information would further improve the data. But I don't
believe there should be a requirement to map the function of an area
before you can map the fact that it's covered with gravel.

On 12.01.2018 00:15, marc marc wrote:
> landcover=gravel

That would indeed be another possibility. It doesn't provide any new
information when compared with surface=gravel, though.

Tagging mailing list

Re: [Tagging] Proposal: logo tag. Opinions?

2017-09-20 Thread Tobias Knerr
On 19.09.2017 23:41, Martin Koppenhoefer wrote:
> AFAIK wikidata's notability requirements should not be an issue, because
> it is sufficient there is a link to a commons page [1] to comply.

> [1]

The notability requirements specifically mention "sitelinks", though,
not just any link. My understanding is that, at for example, only the link in the
"Other sites" section is a "sitelink" – the value of the "logo image"
property probably isn't.

If that interpretation is correct, there would have to be a Wikipedia
article, Commons page (not just a related image), or similar entry in
the Wikimedia ecosystem to meet the notability criteria.

Tagging mailing list

Re: [Tagging] Proposal: logo tag. Opinions?

2017-09-19 Thread Tobias Knerr
On 19.09.2017 16:27, José G Moya Y. wrote:
> It's up to
> the rendering app creators to decide if they want to display some shops
> using its logos. In that case, the app would probably have some other
> way to display them.

What way would that be?

Unless we want each render style author to maintain their own worldwide
database of company logos (which would not only be redundant, but also
far too much work for most rendering development teams), the logos need
to be available either directly in OSM or in an external resource – such
as Wikidata – linked from OSM.

For what it's worth, I think a logo tag could have it's place. I prefer
using Wikidata where possible, but Wikidata has notability guidelines
that will probably prevent creating an item for smaller stores that are
not part of a major national or international brand. What I particularly
like about the proposal is the focus on using Commons, as their
machine-readable license templates give us at least a chance at managing
the legal issues.

Tagging mailing list

Re: [Tagging] Proposal: "slogan" tag. Opinions?

2017-09-19 Thread Tobias Knerr
On 19.09.2017 09:46, SwiftFast wrote:
> Imagine an app where you'd click a shop, then you'd get a popup with a
> logo(see my other proposal), a slogan, and a description. All of these
> help a user understand what they're looking it.

While I accept the argument that logos allow easy visual identification
(assuming we're allowed to display them – not sure about the legal
situation here), I do not personally expect slogans to be particularly
helpful for the user. To me, slogans are advertising, not useful

Slogans also aren't always visible on the ground, and feel quite far
removed from geographic data: It's the slogan of the operator of the
shop at this location – which is one jump further than what is typical
for OSM data.

>> Moreover, in your exemple, I don't see the point to repeat on all
>> McDonald's the same tag. A separate database with brand data would
>> fit more your need (Wikidata?).
> Although I agree it's a problem, it's unrelated to the proposal.

Still, the proposal could help address it by promoting a "unless the
feature has a Wikidata item, in which case the slogan/logo should be
added over there" guideline.

> The same could be said about cuisine, name
> translations, website, operator, etc.

Website doesn't fit into that list because it should only be used for
the website of that particular feature – not the website of the
brand/operator. But yes, it's true that the problem isn't new.

Tagging mailing list

Re: [Tagging] Feature Proposals - RFC for multiple features - Education Reform - Magnetic Levitation Trains

2017-09-17 Thread Tobias Knerr
On 17.09.2017 07:54, Erkin Alp Güney wrote:
> This brings education key instead of amenity=school.

In my opinion, and speaking broadly, the job of the OSM tagging system
is to answer two questions:

- What kind of feature is this?
- What properties does this feature have?

The first question can usually be answered by a single word, such as
"university" or "driving school". The second is more naturally answered
with key-value pairs: The "name" is "Foobar University", the "website"
is "; and so on.

So while our key-value tags lend themselves well to the second job, they
are a bit of an awkward fit for the first job. We need to put something
in the key even though it does not add any meaningful information. An
education=university would not be any different from an
amenity=university – all the information is already there in the value.

My preferred response to this situation is to minimize the significance
and required brain space for this vestigial key. If we were to reform
the tagging system, my ideal solution would be a "type"/"thing"/"class"
key that is used for the main tag of all features. Other than this
unlikely step, the next best solution is continued use of amenity as a
catch-all for most features.

Contrary to this, some mappers (and your proposal) prefer to use the
superfluous key as a makeshift category system. I feel that's the wrong
way to go, though: How to best group features into categories depends on
the application you have in mind, and providing a categorization is not
any more the tagging system's job than making rendering style decisions
is. OSM data tells you that there is an education ministry in that
location. Whether that feature is filed under the "education", "office"
or "government" heading is an application developer's responsibility,
and should be of no concern for the OSM data model.

tl;dr: Keys are not categories.


Tagging mailing list

Re: [Tagging] contact:* for review websites

2017-09-16 Thread Tobias Knerr
On 16.09.2017 00:56, Tom Pfeifer wrote:
> IMHO these are not means of contact, instead these are review websites.
> While I personally think that we do not need them in OSM at all, they
> certainly do not belong in the contact:* namespace.

I agree that these aren't contact channels, and it makes no sense to put
them into that namespace.

Regarding your second point, I'm also not a big fan of having these in
OSM at all. I appreciate links to open content sites (Wikipedia,
Wikidata and so on), as well as the official website of an entity. But
advertising non-open third-party sites – and inevitably favouring them
over their competitors – doesn't feel right. This group of keys also
seems to be a favourite of SEO spammers and their ilk.


Tagging mailing list

Re: [Tagging] Simplify building:part areas

2017-08-18 Thread Tobias Knerr
On 18.08.2017 10:01, Tom Pfeifer wrote:
> If e.g. the lower floors of the apartment building is wider than the
> upper floors, you can tag the outline with both, building=apartments and
> building:part=yes and the appropriate 3D-properties, and the narrower
> upper floors with building:part=yes and 3D-properties, but without
> building=*.

It's not a good idea to use building and building:part tags on the same
way. Doing so typically gives incorrect information to data consumers,
because the number of levels for the building as a whole is not the same
as the number of levels for the building part.

In your example, the building part for the lower levels would be tagged:

+ building:part = yes
+ building:levels = 

And as you said, one important function of the building outline is
backwards compatibility for non-3D-applications. Such an application
will conclude that this building has  levels,
which is not the case.


Tagging mailing list

Re: [Tagging] Formally informal sidewalks

2017-07-16 Thread Tobias Knerr
On 15.07.2017 19:06, Nick Bolten wrote:
> It can't properly describe
> crossings, since they've been condensed into a node, but important
> information like length, the curbs at each side (direction of
> traversal + curb type both matter), APS directionality, etc, are all
> essentially linear features.

You can tag the curbs at each side of a crossing using left/right tags,
and you can find out the length by looking at the road's width (or
estimate it from the number of lanes). It's not perfect, but at least
there are good enough ways to deal with this.

The same cannot be said for the problems caused by sidewalks mapped as
separate ways. Drawing a sidewalk way next to the road produces just
that: Two ways with no machine-readable semantic relationship to each other.

From personal experience: I'm rendering sidewalks in a 3D renderer. It
works pretty well with lane-like sidewalk tagging, but separate ways
prevent pretty much everything I would like to do with them: I can't
draw the kerbs, because I cannot easily determine whether I'm on the
left or the right of the street. I can't make sure that the sidewalk is
at comparable elevation to the road on hilly terrain. And the sidewalk
and road will always have random gaps or overlap each other, because
they are never really accurately drawn.

Other applications have similar problems: Want to make sidewalks into a
part of the road's line style? You can't – instead you end up drawing
them as separate lines, which looks ok at detailed zooms, but stops
working as you zoom out. Want to show routing instructions such as
"follow the right sidewalk of Foobar Road"? Doesn't work, because we
don't know which road this sidewalk is the sidewalk of. Want your
pedestrian router to cross smaller roads anywhere, which is an integral
part of how pedestrians typically navigate street networks? Again, you
can't – you need to hope the mapper has drawn "virtual crossings" at
semi-regular intervals (or even at all).

Yes, separate sidewalk geometries allow for nice details like telephone
poles on a sidewalk. But they lose information that's a lot more
fundamental: The semantic connection with the road.

> If the curb is raised, every time a driveway
> or alley intersects the sidewalk, the curb changes to lowered or flush.
That's only a problem if you map this lowering of the kerb as a property
of the highway way. I believe it may be feasible to map this as the
property of the junction and crossing nodes instead.

Plus, drawing separate ways only seems easier because you are omitting
essential information, as described above. If you actually were to
express the relationship between the sidewalk and the road with a
relation for each section of sidewalk, it would very quickly stop being

> Hope this makes some sense... it feels a bit ranty.

Yeah, I know the feeling. In fact, I couldn't resist the urge to write a
rant of my own in response. ;)

Tagging mailing list

Re: [Tagging] Time is now: tag ALL traffic signs in OSM

2017-05-22 Thread Tobias Knerr
On 21.05.2017 22:23, yo paseopor wrote:
> As you can see in with Kendzi3D JOSM
> plugin you can locate the traffic signs belonging to a way.

Of course it's always possible to guess a place next to the road, but
even with your proposed side=* tagging, that's not nearly as good as
being able to map the actual location.

Also consider that not all signs clearly belong to a single road, for
example [1]. Plus there are traffic signs which are not next to a way at
all, but e.g. on a pedestrian square or a parking space, which can only
be mapped using separate nodes.

Likewise, the direction key in your proposal is currently limited to
forward and backward. However, there are also signs facing sideways as
in [2], or at an arbitrary angle.

Using a separate traffic_sign node together with the direction=
tagging (that has already been approved, by the way!) works in all these

Happy mapping!


Tagging mailing list

Re: [Tagging] Time is now: tag ALL traffic signs in OSM

2017-05-21 Thread Tobias Knerr
On 21.05.2017 14:05, Colin Smale wrote:
> So, in simple language, WHY do we put traffic signs into
> OSM?

The use case I'm interested in is having the location of the physical
object available, e.g. for 3D rendering. This is also why I'm in favour
of placing signs in their actual on-the-ground location.

I also find it useful to know the exact traffic sign combinations that
the other tags are derived from, as ambiguities in tagging can cause
that information to be muddled (e.g. the path/designated/official
issue). If it's only about that use case, though, I tend to use the
traffic_sign tag on ways, rather than separate nodes.

Tagging mailing list

Re: [Tagging] wikipedia links and copy + paste in tag definitions

2017-04-30 Thread Tobias Knerr
On 29.04.2017 22:26, Martin Koppenhoefer wrote:
> Don't link to WP, especially not in the beginning (as if their definition 
> automatically was equal to ours), because even if the current state is fine, 
> we don't control WP and don't know how they will structure their lemmas in 
> the future.

Thanks for highlighting this issue, I fully agree with you.

Some wiki editors seem to be under the false impression that a Wikipedia
link should somehow be a standard part of any tag page. Including such
links should be the exception, rather than the rule, and they need to be
carefully checked and maintained in the future to make sure that they
are about the same thing as the OSM tag.

Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - bus bay

2017-04-06 Thread Tobias Knerr

On 06.04.2017 19:40, Martin Koppenhoefer wrote:

why do you define this as a node? bus_bay=right or left does not make
sense on a node, and bus bays have a certain length anyway, I'd make it
a way.

It should not be a separate way if there is no physical separation. But 
I agree a node is not a good choice either.

So in my opinion, there are two obvious options here:

A) Create a bus_bay:left/right tagging similar to sidewalk=*, 
cycleway=*, shoulder=* and the parking:lane:* tags.

B) Map them as bus-only lanes using the :lanes syntax.

Tagging mailing list

Re: [Tagging] simple 3D buildings, proposed redefinition of building:levels and building:min_level for building:part

2017-03-09 Thread Tobias Knerr

On 08.03.2017 18:32, Martin Koppenhoefer wrote:

building:levels - building:min_level < 0
yes: new
no: old

I believe you are mistaken here. Consider the following example:

building:levels = 2
building:min_level = 1

According to the Simple 3D Buildings standard, this means that there is 
a building part with one "real" level. According to your idea, there 
would be two "real" levels. And there's no way to tell which 
interpretation was intended by the mapper.

Your proposed change would, therefore, make data mapped using these keys 
mostly useless due to the unresolvable ambiguity. In my opinion, that 
kind of cost is not worth it.

Tagging mailing list

Re: [Tagging] how to map simple buildings

2017-03-04 Thread Tobias Knerr

On 04.03.2017 18:05, "Christian Müller" wrote:

Thanks for the examples and conclusion given.  This is a strong reason to
demand its usage in wiki docs and IMO we should even suggest their usage
generally, regardless of the construction site's complexity.

Situations complex enough to require type=building relations are 
possible, sure. As Martin observed, though, those are exceptional cases. 
The existence of a small proportion of buildings that call for relations 
does not feel like a good reason to demand relations for every single 3D 

> Even when neither multi-layered nor nested buildings exist, they may aid
> in data validation and plausibility checks.

If I tried to find the most common mapping errors with 3D buildings, I 
would probably look for some of the following situations:

* Building parts that cannot be unambiguously matched with a building 

* Buildings that aren't fully covered in building parts.
* Floating building parts that don't touch the rest of the building.

And probably a few more. None of these requires relations.

Yet they may ease maintenance
work for oneself and other mappers, since they usually convey an overview
of all the parts present. But of course it depends on mapping workflow if
this is true to a particular mapper.

While there are mappers who love using relations as part of their 
workflow, the relatively low usage numbers of the building relation (and 
other optional relations) strongly suggest that this preference is not 
shared by the majority of mappers.

Tagging mailing list

Re: [Tagging] Invalid voting of proposed feature motorcycle_friendly=*

2017-03-02 Thread Tobias Knerr

Hi Michael,

On 02.03.2017 20:21, Michael Reichert wrote:

Because the proposal violated the guideline, I would like to
- remove the status "proposed" from its feature documentation page
- reset the status of the proposal to "RFC"
- to declare the voting as invalid by adding a note at the top of the
voting section
- add a note to the feature documentation page linking to this email and
explaining that the voting was invalid.

I agree with your observations and your proposed actions. While it's ok 
to overlook minor "rule violations" sometimes, things like not 
announcing the vote do clearly have a big impact on the outcome. It's 
obvious to me that the vote is invalid and needs to be repeated.

Thanks a lot for your vigilance!


Tagging mailing list

  1   2   3   4   >