Add drive-through information to place page and iOS editor

[dvdmrtnz]

Add drive-through information to place page

• Closes Highlight that drive through is available for a POI #7209

[NeatNit]

There's no Hebrew term for this. The Wikipedia article uses a transliteration: דרייב ת'רו, which is better than nothing I guess, but makes me want to puke... Wish I could just leave this blank.

That goes double for no drive-through. Can't we let users assume there's no drive-through unless specified?

[Misalf-git]

de suggestions

[Jean-BaptisteC]

Why not use our custom car icon on Android?

[dvdmrtnz]

Why not use our custom car icon on Android?

What custom car icon?

I took the shop=car icon and added the rearview mirrors to create the icon:

[Misalf-git]

Can't we let users assume there's no drive-through unless specified?

I second that.
For wheelchair access it's reasonable or even essential to show yes/limited/no.
For drivers I'd say it's "nice to know" if there is a Drive-Through.

[matheusgomesms]

We have to start to think about redesigning the Place Page. It's very useful to have all this info, but when a POI has a lot of details, it gets too cluttered.

[matheusgomesms]

PT and PT-BR okay.

[dvdmrtnz]

We have to start to think about redesigning the Place Page. It's very useful to have all this info, but when a POI has a lot of details, it gets too cluttered.

Related issue:

• Add way to view additional tags #2119

[biodranik]

Showing "No drive-through" looks unnecessary and not useful, no?

[muralito]

Showing "No drive-through" looks unnecessary and not useful, no?

Yes, and it is worse in locations when this a rare feature, because waste screen that could be useful for other info.

[billpcs]

Added Greek suggestions, since we generally use "drive-through", so I just transliterated it.

[dvdmrtnz]

Consensus seems to be that "No drive-through" is unnecessary. I will remove it

[dvdmrtnz]

Added Greek suggestions, since we generally use "drive-through", so I just transliterated it.

@billpcs Where? Did you submit your suggestion?

[d4f5409d]

@biodranik I'm sure we could find a place for POI editing related dates like in #6811, as we did here ;)

[dvdmrtnz]

Are there many boolean or enum-like types in OpenStreetMap.org that can be displayed in the place page?

drive_through=yes/no
takeaway=yes/no
delivery=yes/no
wheelchair=yes/no/limited
smoking=yes/no/outside
toilets=yes/no
changing_table=yes/no

What and how is stored/supported already in our code?

I don't understand what you are saying here

[dvdmrtnz]

The order of fields is defined in the ios and android code.

Where exactly in the iOS code? I can't find it

[biodranik]

Do we store drive_through=no too?

Check the order in the viewDidLoad of PlacePageInfoViewController

[dvdmrtnz]

Do we store drive_through=no too?

Yes, we store it too. Even if we are not showing it in the place page, it's needed for the editor to be able to show yes/no.

[biodranik]

Most of these yes/no cases can be stored in one or two bits of information (considering yes/no/unknown). So your examples above can fit into 7*3 = 21 bits of information (3 bytes).

Compare it with the existing implementation where the data takes from 8*3=24 bytes (for type=no) and even more for longer strings.

[dvdmrtnz]

Most of these yes/no cases can be stored in one or two bits of information (considering yes/no/unknown). So your examples above can fit into 7*3 = 21 bits of information (3 bytes).

Compare it with the existing implementation where the data takes from 8*3=24 bytes (for type=no) and even more for longer strings.

I understand. Do any of the other metadata properties use this kind of conversion to bits for optimized storage? Metadata is used all over the app and I'm not sure how to implement this change. If this is implemented somewhere else it would be helpful as an example

[dvdmrtnz]

Check the order in the viewDidLoad of PlacePageInfoViewController

That's the Place Page. I am talking about the editor interface.

[dvdmrtnz]

I've added a tri-state segmented selector in the editor to be able to distinguish empty value from "no". Idea taken from #5724 (comment).

[dvdmrtnz]

The order of fields in the editor seems to be determined by the Metadata::EType order. I will leave it as is.

organicmaps/indexer/editable_map_object.cpp

Lines 180 to 194 in 3c9c54e

	vector<MapObject::MetadataID> EditableMapObject::GetEditableProperties() const
	{
	auto props = m_editableProperties.m_metadata;
	if (m_editableProperties.m_cuisine)
	{
	// Props are already sorted by Metadata::EType value.
	auto insertBefore = props.begin();
	if (insertBefore != props.end() && *insertBefore == MetadataID::FMD_OPEN_HOURS)
	++insertBefore;
	props.insert(insertBefore, MetadataID::FMD_CUISINE);
	}
	return props;
	}

[dvdmrtnz]

I have added drive_through to the iOS editor. It can be added to the Android editor in a separate PR.

[vng]

I like it. Prefer to keep 2 commits:

• all actual changes
• [strings] Regenerated.

[dvdmrtnz]

I like it. Prefer to keep 2 commits:

• all actual changes
• [strings] Regenerated.

I actually like to keep some changes separated into different commits (for example iOS vs Android changes and placepage vs editor). I will try to squash some commits but trying to keep logical changes separated if you don’t mind

[vng]

ok

[dvdmrtnz]

Squashed commits

[d4f5409d]

All fine.