#1392 - Priorities of multiple types in a single feature - for naming (rendering is fixed) - organicmaps/organicmaps - Organic Maps: Community-driven, open-source mobile maps app for travelers, tourists, hikers, and cyclists, based on OpenStreetMap data

Misalfgit commented

2021-10-09 13:38:26 +00:00

(Migrated from github.com)

("Parkbank" is german for "bench")

50.990302, 7.058869
https://omaps.app/84JGAMwAVj

![shelter_bench.png](/uploads/ded90070c64766e3a330e2ea9782b8b6/136659829-45682600-c766-475a-a7e7-68756802971f.png) ("Parkbank" is german for "bench") 50.990302, 7.058869 https://omaps.app/84JGAMwAVj

biodranik commented

2021-10-09 20:25:50 +00:00

(Migrated from github.com)

assigned to @vng

assigned to `@vng`

pastk commented

2022-01-31 18:49:59 +00:00

Owner

mentioned in issue #1919

pastk commented

2022-01-31 18:52:18 +00:00

Owner

Another example is amenity=shelter + bench=yes here https://www.openstreetmap.org/node/720550914

Another example is `amenity=shelter` + `bench=yes` here https://www.openstreetmap.org/node/720550914 ![Screenshot_1643653448](/uploads/c77044ad9135bf67ac09168adfee95c6/151854457-f0e97073-a2d2-464d-8dc5-185e6ad7be8e.png)

pastk commented

2022-01-31 19:08:01 +00:00

Owner

Our mechanism to prioritize several types coexisting inside one feature doesn't work here
as we need to keep both benches and shelters in the low priority list here:

c4f4f7a7f4/indexer/feature_data.cpp (L117-L144)

But the list is not order-sensitive. So its just both of them having same low priority compared to types not in the list.

Its possible to refactor it to make the list case-sensitive, but an overall better solution would be to use z-index from the styles - its not hardcoded and all/most of the types are prioritized there already. And this list above could be used for some special types like psurface and hwtag if needed.
What do you think @vng ?

Our mechanism to prioritize several types coexisting inside one feature doesn't work here as we need to keep both benches and shelters in the low priority list here: https://github.com/organicmaps/organicmaps/blob/c4f4f7a7f478c0331e5c98eb1b8b7bc194639ccf/indexer/feature_data.cpp#L117-L144 But the list is not order-sensitive. So its just both of them having same low priority compared to types not in the list. Its possible to refactor it to make the list case-sensitive, but an overall better solution would be to use z-index from the styles - its not hardcoded and all/most of the types are prioritized there already. And this list above could be used for some special types like psurface and hwtag if needed. What do you think `@vng` ?

biodranik commented

2022-01-31 20:00:10 +00:00

(Migrated from github.com)

I would not set a style dependency. Then the same feature may display different info after switching styles.

pastk commented

2022-01-31 20:06:05 +00:00

Owner

Do you have a situation in mind when we'd want to draw feature B over the A, but see it named A still?

Upd: for me its sounds logical - feature's looks and name should correspond to each other. If we change the looks (via styling), but keep the old name - it'll look strange.

Do you have a situation in mind when we'd want to draw feature B over the A, but see it named A still? Upd: for me its sounds logical - feature's looks and name should correspond to each other. If we change the looks (via styling), but keep the old name - it'll look strange.

pastk commented

2022-01-31 20:20:09 +00:00

Owner

But I have a pro-using-z-index example:
https://www.openstreetmap.org/way/78047524
has highway=track and piste:type=nordic
On a "regular"/"summer" map we'd want to show it as a track and name as a track.
On a "Snow map" we'd want to display it as a piste and name as such too.

But I have a pro-using-z-index example: https://www.openstreetmap.org/way/78047524 has `highway=track` and `piste:type=nordic` On a "regular"/"summer" map we'd want to show it as a track and name as a track. On a ["Snow map"](https://git.omaps.dev/organicmaps/organicmaps/issues/1577#issuecomment-1025788515) we'd want to display it as a piste and name as such too.

vng commented

2022-01-31 20:37:20 +00:00

(Migrated from github.com)

Make shelter better than bench/waste_busket, etc, no?

Make shelter _better_ than bench/waste_busket, etc, no?

pastk commented

2022-01-31 22:17:20 +00:00

Owner

Make shelter better than bench/waste_busket, etc, no?

Introduce another list of "useful types" in addition to "useless types"? So we'll have 3 priority tiers instead of two.
But I think we need 4 already:

bus_stop
public_transport = platform
shelter
bench

> Make shelter _better_ than bench/waste_busket, etc, no? Introduce another list of "useful types" in addition to "useless types"? So we'll have 3 priority tiers instead of two. But I think we need 4 already: 1. bus_stop 2. public_transport = platform 3. shelter 4. bench

pastk commented

2022-03-14 17:06:41 +00:00

Owner

changed title from {-Shelter with a bench always named "bench".-} to {+Priorities of multiple types in a single feature - for proper rendering and naming+}

changed title from **{-Shelter with a bench always named "bench".-}** to **{+Priorities of multiple types in a single feature - for proper rendering and naming+}**

pastk commented

2022-07-04 17:38:21 +00:00

Owner

mentioned in issue #2511

RedAuburn commented

2022-12-15 16:20:29 +00:00

Member

another example: https://www.openstreetmap.org/way/783876180

tagged as bench=yes, leisure=park

the proper fix would be to introduce subtags, which would only be used for searches & place-page info

another example: https://www.openstreetmap.org/way/783876180 tagged as `bench=yes`, `leisure=park` <img width="794" alt="Screenshot 2022-12-15 at 16 15 09" src="/uploads/4edc9b77b51e4c20823d4c133d64ad9e/207912630-5954e365-1c15-49d7-88fb-8cebc108d235.png"> the proper fix would be to introduce subtags, which would only be used for searches & place-page info

biodranik commented

2022-12-15 17:21:25 +00:00

(Migrated from github.com)

What does it mean, an area Park, marked with Bench?.. Each bench should be mapped separately, no?

vng commented

2022-12-15 17:39:37 +00:00

(Migrated from github.com)

Oh, probably, it means that park in general has benches, but this is hilarious .. Ok, I can make park type higher than bench, but ...

Oh, probably, it means that park in general has benches, but this is hilarious .. Ok, I can make _park_ type higher than _bench_, but ...

biodranik commented

2022-12-15 17:48:26 +00:00

(Migrated from github.com)

That's clearly a mapping mistake, right? Benches should be drawn ON TOP of the park area.

pastk commented

2023-01-21 15:11:14 +00:00

Owner

This issue is similar to #655

pastk commented

2023-01-21 15:14:14 +00:00

Owner

Make shelter better than bench/waste_busket, etc, no?

Introduce another list of "useful types" in addition to "useless types"? So we'll have 3 priority tiers instead of two. But I think we need 4 already:
1. bus_stop

2. public_transport = platform

3. shelter

4. bench

Partly this issue could be solved by preserving e.g. bench=yes, shelter=yes as secondary tags / attributes of the main feature tag, which is a bus stop here.
Both PP and map icon should show the primary/main feature.
See a similar issue at #655 (comment)

> > Make shelter _better_ than bench/waste_busket, etc, no? > > Introduce another list of "useful types" in addition to "useless types"? So we'll have 3 priority tiers instead of two. But I think we need 4 already: > > 1. bus_stop > > 2. public_transport = platform > > 3. shelter > > 4. bench Partly this issue could be solved by preserving e.g. `bench=yes`, `shelter=yes` as secondary tags / attributes of the main feature tag, which is a bus stop here. Both PP and map icon should show the primary/main feature. See a similar issue at https://git.omaps.dev/organicmaps/organicmaps/issues/655#issuecomment-1067333596

pastk commented

2023-01-21 16:47:30 +00:00

Owner

mentioned in issue #4314

biodranik commented

2023-01-28 14:08:45 +00:00

(Migrated from github.com)

Our current types-system does not support primary and secondary styles, like OSM tags are doing. The main question: can we guess/hardcode the priorities and avoid introducing primary/secondary types? What are the cases where it won't work? E.g. when both options are valid:

amenity=primary
secondary=yes

and

amenity=secondary
primary=yes

Our current types-system does not support primary and secondary styles, like OSM tags are doing. The main question: can we guess/hardcode the priorities and avoid introducing primary/secondary types? What are the cases where it won't work? E.g. when both options are valid: amenity=primary secondary=yes and amenity=secondary primary=yes

pastk commented

2023-02-26 20:28:29 +00:00

Owner

mentioned in issue #4590

pastk commented

2023-09-17 15:19:32 +00:00

Owner

mentioned in merge request !6004

pastk commented

2023-09-17 15:19:58 +00:00

Owner

changed title from Priorities of multiple types in a single feature - for {-proper -}rendering {-and naming-} to Priorities of multiple types in a single feature - for {+naming (+}rendering {+is fixed)+}

changed title from **Priorities of multiple types in a single feature - for {-proper -}rendering {-and naming-}** to **Priorities of multiple types in a single feature - for {+naming (+}rendering {+is fixed)+}**

pastk commented

2023-09-17 15:21:56 +00:00

Owner

Rendering of a proper/main (priority-wise) icon was fixed in #4590.

So now the issue is about displaying a proper corresponding title in the place page.
We should discard the "UselessTypes" system and refer to style-set priorities instead.

Rendering of a proper/main (priority-wise) icon was fixed in #4590. So now the issue is about displaying a proper corresponding title in the place page. We should discard the "UselessTypes" system and refer to style-set priorities instead.

pastk commented

2023-09-17 15:23:53 +00:00

Owner

unassigned @vng

unassigned `@vng`

pastk commented

2023-11-20 11:19:28 +00:00

Owner

mentioned in merge request !6615

vng (Migrated from github.com) closed this issue

2024-02-09 17:54:51 +00:00

Rows
Columns

Priorities of multiple types in a single feature - for naming (rendering is fixed) #1392