Modify

Opened 6 years ago

Closed 4 years ago

#15637 closed defect (fixed)

multi-values are not handled properly by autofilters

Reported by: sergey.karavay@… Owned by: team
Priority: normal Milestone: 20.02
Component: Core Version:
Keywords: autofilter Cc:

Description

Attachments (0)

Change History (10)

comment:1 by Tordanik, 6 years ago

I've noticed the same issue. In addition to semicolon-separated level values, JOSM also does not appear to evaluate level ranges.

Expected behaviour would be as follows: A feature tagged level=0;1 is matched if either level 0 or level 1 is selected. A feature tagged level=0-2 is matched if either level 0, 1, or 2 is selected.

Relevant wiki documentation is found at https://wiki.openstreetmap.org/wiki/Simple_Indoor_Tagging#Multi-level_features_and_repeated_features.

in reply to:  1 comment:2 by Don-vip, 6 years ago

Keywords: autofilter added
Owner: changed from team to sergey.karavay@…
Status: newneedinfo

Replying to Tordanik:

JOSM also does not appear to evaluate level ranges.

Yes it does. Can you please attach a sample data set where the problem occurs?

comment:3 by Don-vip, 6 years ago

Also please attach a status report. Thanks.

comment:4 by scai, 6 years ago

Just open this node in JOSM: https://www.openstreetmap.org/node/4919201409

Currently it is tagged with level=0;1;2. The level switch in JOSM "disables" this node, independent of the selected level. Changing the tagging to level=0-2 leads to the exact same result, i.e. disabling of the POI.

JOSM 13170 here.

Last edited 6 years ago by scai (previous) (diff)

comment:5 by cmuelle8, 6 years ago

we're actually talking about a vertical line here:

  • would we map three ways running above each other at same lat/lon with just one osm-way that is tagged level=0;1;2 ?
  • if that is not the case, then maybe its better to duplicate the node in question for each level as well

after all, an elevator may have different features on each level (for example on which side the doors open)
well, this could still be tagged using a single node, I guess,
and osm wiki actually has documentation to this:
http://wiki.openstreetmap.org/wiki/Key:level#Multiple_values

But for the store level abstraction above this does not seem to apply. These are three distinct building levels and
using the indoor mapping proposal they will be represented by one object each. So shouldn't the node that seems like
a predeccesor to that in this case also exist distinctly for each level?

If the three building levels were already indoor-mapped, the store would probably be expressed as a relation
to these, after all.

All I'm saying is, that wrt this ticket, a node that represents an elevator would be a better example, since it is a
less questionable valid data example.

Last edited 6 years ago by cmuelle8 (previous) (diff)

comment:6 by scai, 6 years ago

if that is not the case, then maybe its better to duplicate the node in question for each level as well

No, this is a bad idea. This is one object (https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element), with one name, one address, one opening hours value, one website and so on. Unnecessarily duplicating features is not an option and just introduces additional problems.

Last edited 6 years ago by scai (previous) (diff)

in reply to:  6 comment:7 by cmuelle8, 6 years ago

Replying to scai:

This is one object (https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element).

This is not true. And the multiple values in the levels tag already tell you about it:

It's an object made of other objects. To represent this, relations are used.

A correct statement would have been: It may be viewed as one object, depending on your perspective. We actually have a building, building levels, an address and a store that is being talked about here. Since the address is usually assigned to the building, it may even be possible that multiple stores use the same address. But this is not being discussed within the scope of this ticket.

The issue of the ticket seems valid however, since the recommendation you referenced from the osm wiki seems less challengeable for (at least the common types of) elevators. (Of course, an elevator is made up of multiple objects as well, but afaik this is currently not expressed by OSMs data features, so there is some atomicity about that. Even if we were to tag the elevator as area or volume we'd have exactly one feature in OSM representing the lift shaft. Building floors and rooms on different levels however are multiple features if the indoor mapping proposal is taken into account.)


If you want to simply tag the store (as a node/POI) with an address without going too much into details, it might be better to not use the levels tag at all. It is ambiguos anyway: If the different building levels are not mapped in detail, e.g. you will not know

  • if level=1;2;3 means "a store with 3 shopping floors"
  • if level=1;2;3 means "a store with 1 shopping floor" but 3 levels in height (i.e. one large hall) within a larger building that has adjacent levels with smaller bureaus/apartments/stores
  • http://wiki.openstreetmap.org/wiki/Key:level#Multiple_values e.g. seems to talk about the latter
Version 8, edited 6 years ago by cmuelle8 (previous) (next) (diff)

comment:8 by Don-vip, 6 years ago

Owner: changed from sergey.karavay@… to team
Status: needinfonew
Summary: JSOM fails to handle multi-level tags for indoor amenities properlymulti-values are not handled properly by autofilters

Confirmed. But not easy to fix.

comment:9 by Don-vip, 5 years ago

Ticket #17128 has been marked as a duplicate of this ticket.

comment:10 by simon04, 4 years ago

Milestone: 20.02
Resolution: fixed
Status: newclosed

Fixed in r15838: CompiledFilter uses extracted/parsed numeric values from OSM primitives.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.