[routing] Extended navigation info about next turn street/road #2658

zyphlar · 2022-06-01T17:15:53Z

AntonM030481 commented

2022-06-01 17:15:53 +00:00

(Migrated from github.com)

2nd iteration for #849

Extended info about next street/road:

for next street it will show "[ref] name" .
for highway links - "[junction:ref]: [target:ref] > target".
If no target - it will be replaced by name of next street.
If no [target:ref] - it will be replaced by [ref] of next road.

2nd iteration for #849 Extended info about next street/road: - for next street it will show "[ref] name" . - for highway links - "[junction:ref]: [target:ref] > target". If no target - it will be replaced by name of next street. If no [target:ref] - it will be replaced by [ref] of next road.

vng (Migrated from github.com) reviewed 2022-06-02 09:32:31 +00:00

indexer/feature_meta.cpp

					
				@ -77,2 +77,4 @@

				  else if (k == "destination:ref")

				    outType = Metadata::FMD_DESTINATION_REF;

				  else if (k == "junction:ref")

				    outType = Metadata::FMD_JUNCTION_REF;

vng (Migrated from github.com) commented

2022-06-02 09:29:02 +00:00

Is there any difference in junction:ref and ref tag?
For highway=motorway_junction we already should take refs into (like) name. Can we make the same with junction:ref.

I suspect that we can merge ref and junction:ref

Is there any difference in junction:ref and ref tag? For highway=motorway_junction we already should take refs into (like) name. Can we make the same with junction:ref. I suspect that we can _merge_ ref and junction:ref

routing/route.hpp

vng (Migrated from github.com) commented

2022-06-02 09:30:32 +00:00

put to the end (after strings)
bool m_isLink = false; and you don't need constructor

- put to the end (after strings) - bool m_isLink = false; and you don't need constructor

routing/routing_session.cpp

vng (Migrated from github.com) commented

2022-06-02 09:31:44 +00:00

Wrong indentation.

AntonM030481 (Migrated from github.com) reviewed 2022-06-02 09:48:50 +00:00

indexer/feature_meta.cpp

					
				@ -77,2 +77,4 @@

				  else if (k == "destination:ref")

				    outType = Metadata::FMD_DESTINATION_REF;

				  else if (k == "junction:ref")

				    outType = Metadata::FMD_JUNCTION_REF;

AntonM030481 (Migrated from github.com) commented

2022-06-02 09:48:50 +00:00

The reason why do we have all these tags separately to have an ability to handle incomplete data.
E.g. only JUNCTION_REF exists for link, but we can find calculate DESTINATION_REF from main road (by it's REF).

The reason why do we have all these tags separately to have an ability to handle incomplete data. E.g. only JUNCTION_REF exists for link, but we can find calculate DESTINATION_REF from main road (by it's REF).

vng (Migrated from github.com) reviewed 2022-06-02 09:51:16 +00:00

indexer/feature_meta.cpp

					
				@ -77,2 +77,4 @@

				  else if (k == "destination:ref")

				    outType = Metadata::FMD_DESTINATION_REF;

				  else if (k == "junction:ref")

				    outType = Metadata::FMD_JUNCTION_REF;

vng (Migrated from github.com) commented

2022-06-02 09:51:16 +00:00

I agree with destination:*, but I suspect that ref and junction:ref are the same and should be processed identically, e.g. transfer into name and draw on the map.

AntonM030481 (Migrated from github.com) reviewed 2022-06-02 09:54:52 +00:00

routing/route.hpp

AntonM030481 (Migrated from github.com) commented

2022-06-02 09:54:52 +00:00

OK

vng (Migrated from github.com) reviewed 2022-06-02 09:58:05 +00:00

indexer/feature_meta.cpp

					
				@ -77,2 +77,4 @@

				  else if (k == "destination:ref")

				    outType = Metadata::FMD_DESTINATION_REF;

				  else if (k == "junction:ref")

				    outType = Metadata::FMD_JUNCTION_REF;

vng (Migrated from github.com) commented

2022-06-02 09:58:05 +00:00

Ah, I understood. junction:ref is used for outgoing highway way, not in motorway_junction ..

Ah, I understood. junction:ref is used for _outgoing highway way_, not in motorway_junction ..

AntonM030481 (Migrated from github.com) reviewed 2022-06-02 09:58:21 +00:00

routing/routing_session.cpp

AntonM030481 (Migrated from github.com) commented

2022-06-02 09:58:21 +00:00

OK

AntonM030481 (Migrated from github.com) reviewed 2022-06-02 10:21:17 +00:00

indexer/feature_meta.cpp

					
				@ -77,2 +77,4 @@

				  else if (k == "destination:ref")

				    outType = Metadata::FMD_DESTINATION_REF;

				  else if (k == "junction:ref")

				    outType = Metadata::FMD_JUNCTION_REF;

AntonM030481 (Migrated from github.com) commented

2022-06-02 10:21:17 +00:00

tags for exit:
junction:ref is number of the junction (exit).
destination:ref - ref of next main road. Normally should match it's ref.

Added comment at RoadNameInfo definition definition.

tags for exit: junction:ref is number of the junction (exit). destination:ref - ref of next main road. Normally should match it's ref. Added comment at RoadNameInfo definition definition.

AntonM030481 (Migrated from github.com) reviewed 2022-06-02 11:09:21 +00:00

indexer/feature_meta.cpp

					
				@ -77,2 +77,4 @@

				  else if (k == "destination:ref")

				    outType = Metadata::FMD_DESTINATION_REF;

				  else if (k == "junction:ref")

				    outType = Metadata::FMD_JUNCTION_REF;

AntonM030481 (Migrated from github.com) commented

2022-06-02 11:09:21 +00:00

Right, currently I don't care about motorway_junction.
But of course it would be better to get it, and use it's tag ref instead of tag junction:ref of link it last tag does not exist.
But I don't know how to do it properly.

Right, currently I don't care about `motorway_junction`. But of course it would be better to get it, and use it's tag `ref` instead of tag `junction:ref` of link it last tag does not exist. But I don't know how to do it properly.

AntonM030481 (Migrated from github.com) reviewed 2022-06-02 12:42:06 +00:00

indexer/feature_meta.cpp

					
				@ -77,2 +77,4 @@

				  else if (k == "destination:ref")

				    outType = Metadata::FMD_DESTINATION_REF;

				  else if (k == "junction:ref")

				    outType = Metadata::FMD_JUNCTION_REF;

AntonM030481 (Migrated from github.com) commented

2022-06-02 12:42:05 +00:00

@vng maybe you can guide me how to merge it in proper way? Or just change the code if it's easier than to explain 😄

vng (Migrated from github.com) reviewed 2022-06-02 13:25:52 +00:00

indexer/feature_meta.cpp

					
				@ -77,2 +77,4 @@

				  else if (k == "destination:ref")

				    outType = Metadata::FMD_DESTINATION_REF;

				  else if (k == "junction:ref")

				    outType = Metadata::FMD_JUNCTION_REF;

vng (Migrated from github.com) commented

2022-06-02 13:25:52 +00:00

No need to merge. Yes, this tags are used for highway ways, so everything is fine.

AntonM030481 (Migrated from github.com) reviewed 2022-06-03 03:43:10 +00:00

indexer/feature_meta.cpp

					
				@ -77,2 +77,4 @@

				  else if (k == "destination:ref")

				    outType = Metadata::FMD_DESTINATION_REF;

				  else if (k == "junction:ref")

				    outType = Metadata::FMD_JUNCTION_REF;

AntonM030481 (Migrated from github.com) commented

2022-06-03 03:43:10 +00:00

I just want to clarify.
Some links have junction:ref tag, and some have not.
So we can fill missed data by finding appropriate junction point (motorway_junction) in the beginning of link, and using it's ref tag.

I just want to clarify. Some links have `junction:ref` tag, and some have not. So we can fill missed data by finding appropriate junction point (`motorway_junction`) in the beginning of link, and using it's `ref` tag.

AntonM030481 commented

2022-06-03 11:29:56 +00:00

(Migrated from github.com)

I hope now everything is ready.
I will add full name tests later, when maps will be regenerated with new tags.

I hope now everything is ready. I will add full name tests later, when maps will be regenerated with new tags.

AntonM030481 (Migrated from github.com) reviewed 2022-06-03 11:30:21 +00:00

indexer/feature_meta.cpp

					
				@ -77,2 +77,4 @@

				  else if (k == "destination:ref")

				    outType = Metadata::FMD_DESTINATION_REF;

				  else if (k == "junction:ref")

				    outType = Metadata::FMD_JUNCTION_REF;

AntonM030481 (Migrated from github.com) commented

2022-06-03 11:30:21 +00:00

We can do it in the next iteration.

vng commented

2022-06-03 14:10:59 +00:00

(Migrated from github.com)

Hm, you mean that now if we have only highway=motorway_junction point with ref="Exit 55" (no other destination or junction tags in connected links), we don't make turn instruction like "Take exit 55" now?

👍 1

AntonM030481 commented

2022-06-03 14:20:14 +00:00

(Migrated from github.com)

Exactly. All information is taken from link only.

AntonM030481 commented

2022-06-03 14:32:54 +00:00

(Migrated from github.com)

I suppose it should be like this:

Create map of 1st point -> link
Go through all highway=motorway_junction and update link's junction:ref with junction's ref.

Round all coordinates to avoid precision errors in most of cases.

I suppose it should be like this: 1. Create map of 1st point -> link 2. Go through all `highway=motorway_junction` and update link's `junction:ref` with junction's `ref`. Round all coordinates to avoid precision errors in most of cases.

AntonM030481 commented

2022-06-04 07:06:28 +00:00

(Migrated from github.com)

@vng do we need it in this PR?

AntonM030481 commented

2022-06-04 07:56:16 +00:00

(Migrated from github.com)

I don't like RoadNameInfo, since we don't need all this info during turns generation. Name is enough. All additional info is needed later. But I didn't found an elegant alternative to current implementation.
Also we will need mwm info to generate RoadShield properly when in the future will change to icons.

I don't like RoadNameInfo, since we don't need all this info during turns generation. Name is enough. All additional info is needed later. But I didn't found an elegant alternative to current implementation. Also we will need mwm info to generate RoadShield properly when in the future will change to icons.

vng commented

2022-06-04 13:35:10 +00:00

(Migrated from github.com)

This solution looks good to me. Enhancements in generator step can be made later.
At least, destination and destination:ref should be kept, so RoadNameInfo as aggregator of different turn instruction infos is also ok.

This solution looks good to me. Enhancements in generator step can be made later. At least, destination and destination:ref should be kept, so RoadNameInfo as aggregator of different turn instruction infos is also ok.

👍 1

AntonM030481 commented

2022-06-04 19:40:20 +00:00

(Migrated from github.com)

Let's merge?

biodranik (Migrated from github.com) approved these changes 2022-06-05 05:12:09 +00:00

generator/osm2meta.cpp

biodranik (Migrated from github.com) commented

2022-06-05 05:02:50 +00:00

What is normalized here? Is "a;b" replaced by "a; b" ?

routing/car_directions.cpp

biodranik (Migrated from github.com) commented

2022-06-05 05:04:19 +00:00

  /// E.g. Google Maps until you reach the destination will guide you to go to the left or to the right of the first road.

```suggestion /// E.g. Google Maps until you reach the destination will guide you to go to the left or to the right of the first road. ```

routing/car_directions.cpp

					
				@ -102,2 +102,4 @@

				                                             RoutingSettings const & vehicleSettings, TurnItem & turnItem)

				{

				  // This is for jump from initial point to start of the route. No direction is given.

				  /// @todo Sometimes results of GetPossibleTurns are empty, sometimes are invalid.

biodranik (Migrated from github.com) commented

2022-06-05 05:04:32 +00:00

What should be done to fix it?

AntonM030481 (Migrated from github.com) reviewed 2022-06-05 13:46:06 +00:00

generator/osm2meta.cpp

AntonM030481 (Migrated from github.com) commented

2022-06-05 13:46:06 +00:00

Yes. And trim a, b, ... just in case. Comment added. And fixed trimming for 1st item.

AntonM030481 (Migrated from github.com) reviewed 2022-06-05 13:48:41 +00:00

routing/car_directions.cpp

					
				@ -102,2 +102,4 @@

				                                             RoutingSettings const & vehicleSettings, TurnItem & turnItem)

				{

				  // This is for jump from initial point to start of the route. No direction is given.

				  /// @todo Sometimes results of GetPossibleTurns are empty, sometimes are invalid.

AntonM030481 (Migrated from github.com) commented

2022-06-05 13:48:41 +00:00

The best will be to fix GetPossibleTurns(). It should return valid results with proper angles.

AntonM030481 (Migrated from github.com) reviewed 2022-06-05 13:54:54 +00:00

routing/car_directions.cpp

AntonM030481 (Migrated from github.com) commented

2022-06-05 13:54:53 +00:00

OK

AntonM030481 (Migrated from github.com) reviewed 2022-06-05 14:02:27 +00:00

routing/car_directions.cpp

					
				@ -102,2 +102,4 @@

				                                             RoutingSettings const & vehicleSettings, TurnItem & turnItem)

				{

				  // This is for jump from initial point to start of the route. No direction is given.

				  /// @todo Sometimes results of GetPossibleTurns are empty, sometimes are invalid.

AntonM030481 (Migrated from github.com) commented

2022-06-05 14:02:26 +00:00

Comment added.

biodranik (Migrated from github.com) reviewed 2022-06-05 14:08:24 +00:00

generator/osm2meta.cpp

biodranik (Migrated from github.com) commented

2022-06-05 14:08:24 +00:00

Are there many badly formatted values there? Isn't string.replace() enough?

AntonM030481 (Migrated from github.com) reviewed 2022-06-05 16:30:58 +00:00

generator/osm2meta.cpp

AntonM030481 (Migrated from github.com) commented

2022-06-05 16:30:58 +00:00

E.g. "a; b" instead of "a;b" is typical mistake.
I would prefer to keep normalization.
If you think that it will affect generation time, it can be made right before output at routing::GetFullRoadName().
I suppose it will better.

E.g. "a; b" instead of "a;b" is typical mistake. I would prefer to keep normalization. If you think that it will affect generation time, it can be made right before output at routing::GetFullRoadName(). I suppose it will better.

AntonM030481 (Migrated from github.com) reviewed 2022-06-05 20:27:15 +00:00

generator/osm2meta.cpp

AntonM030481 (Migrated from github.com) commented

2022-06-05 20:27:15 +00:00

Moved to routing::GetFullRoadName()

vng (Migrated from github.com) reviewed 2022-06-06 06:27:40 +00:00

generator/osm2meta.cpp

vng (Migrated from github.com) commented

2022-06-06 06:27:40 +00:00

Why move? Initially it was in generator and let stay there.

AntonM030481 (Migrated from github.com) reviewed 2022-06-06 06:58:23 +00:00

generator/osm2meta.cpp

AntonM030481 (Migrated from github.com) commented

2022-06-06 06:58:23 +00:00

I want as much flexibility as possible.
As far as I understand concern of @biodranik potential problem is increased generation time.
Otherwise there is no reason to simplify formatting.
GetFullRoadName() is called is called only once per position update so it should not be a problem there.

I want as much flexibility as possible. As far as I understand concern of @biodranik potential problem is increased generation time. Otherwise there is no reason to simplify formatting. GetFullRoadName() is called is called only once per position update so it should not be a problem there.

vng (Migrated from github.com) reviewed 2022-06-06 07:10:26 +00:00

generator/osm2meta.cpp

vng (Migrated from github.com) commented

2022-06-06 07:10:26 +00:00

I don't know his concern, but definitely not generation time here. If you need to make normalization - do it. And the best place for it is generator.

vng (Migrated from github.com) reviewed 2022-06-06 07:14:08 +00:00

routing/routing_session.cpp

vng (Migrated from github.com) commented

2022-06-06 07:14:08 +00:00

So "New York" destination will be replaced with "New; York" :)

vng (Migrated from github.com) reviewed 2022-06-06 07:20:41 +00:00

routing/routing_session.cpp

vng (Migrated from github.com) commented

2022-06-06 07:20:41 +00:00

Better to leave ";," separators and call strings::Trim(d) inside.

biodranik (Migrated from github.com) reviewed 2022-06-06 08:36:39 +00:00

generator/osm2meta.cpp

biodranik (Migrated from github.com) commented

2022-06-06 08:36:39 +00:00

We do all normalization at the generator, to save device battery.

vng (Migrated from github.com) requested changes 2022-06-07 08:03:49 +00:00

generator/osm2meta.cpp

vng (Migrated from github.com) commented

2022-06-07 08:03:36 +00:00

Please, rebase on fresh master, I changed Trim notation and removed strange returning value.
Should be like this:

strings::Trim(d);
if (d.empty())
  return;
if (!r.empty())
  r += "; ";
r.append(d);

Please, rebase on fresh master, I changed Trim notation and removed strange returning value. Should be like this: ``` strings::Trim(d); if (d.empty()) return; if (!r.empty()) r += "; "; r.append(d); ```

AntonM030481 (Migrated from github.com) reviewed 2022-06-07 10:01:02 +00:00

generator/osm2meta.cpp

AntonM030481 (Migrated from github.com) commented

2022-06-07 10:01:02 +00:00

Thank you, It took me some time to understand why does it work.
Just in case created ValidateAndFormat_destination, and your solution passed all crazy tests :)

Thank you, It took me some time to understand why does it work. Just in case created ValidateAndFormat_destination, and your solution passed all crazy tests :)

AntonM030481 (Migrated from github.com) reviewed 2022-06-07 10:13:36 +00:00

routing/routing_session.cpp

AntonM030481 (Migrated from github.com) commented

2022-06-07 10:13:36 +00:00

OK

vng (Migrated from github.com) approved these changes 2022-06-07 10:19:40 +00:00

zyphlar commented

2022-06-21 04:13:45 +00:00

This is excellent, thank you! Are there any plans to make this appear graphically similar to highway signs, like a larger green rectangle with a larger highway font?

biodranik commented

2022-06-21 05:36:27 +00:00

(Migrated from github.com)

@zyphlar Are highway signs the same in all countries?

zyphlar commented

2022-06-21 07:29:02 +00:00

Obviously not, but highway signs often also don't look like this.

A large, easily readable "sign" that pops up alongside the turn arrow would be an improvement regardless of the color or style. When turn directions are presented as medium sized plain text in a monochrome header, it can be difficult to parse when driving.

In any case I'm not asking project maintainers to debate the nature of road signage, I'm asking this contributor if they intend on further improvements. If not, I might try and dig into contributing myself.

Obviously not, but highway signs often also don't look like this. ![](https://i.imgur.com/qcHHmfI_d.webp?maxwidth=640&shape=thumb&fidelity=medium) A large, easily readable "sign" that pops up alongside the turn arrow would be an improvement regardless of the color or style. When turn directions are presented as medium sized plain text in a monochrome header, it can be difficult to parse when driving. In any case I'm not asking project maintainers to debate the nature of road signage, I'm asking this contributor if they intend on further improvements. If not, I might try and dig into contributing myself.

biodranik commented

2022-06-21 07:41:24 +00:00

(Migrated from github.com)

I would start collecting the most common sign colors for the most popular countries to make it easier for implementers. Ideally a number of screenshots from other navs too. But the best is the "close to reality" color scheme.

AntonM030481 commented

2022-06-21 14:39:28 +00:00

(Migrated from github.com)

@zyphlar for sure I am going to continue improving this.
I agree that most important thing is readability.
The basic thing is font size.
To allow increasing we need to use 2 lines for vertical mode (and it looks reasonable to me).
So we can change
"[exit_number]: destination_name"
to
"[EXIT_NUMBER]:
DESTINATION_NAME".
I suppose font size can be increased x1.5 (and for sure it should be bold).

@zyphlar for sure I am going to continue improving this. I agree that most important thing is readability. The basic thing is font size. To allow increasing we need to use 2 lines for vertical mode (and it looks reasonable to me). So we can change "[exit_number]: destination_name" to "[EXIT_NUMBER]: DESTINATION_NAME". I suppose font size can be increased x1.5 (and for sure it should be bold).

zyphlar commented

2022-06-21 22:15:06 +00:00

Excellent just checking. As you know we have some pretty good examples documented in the parent issue.

biodranik commented

2022-06-22 12:05:50 +00:00

(Migrated from github.com)

What about:

Make the textview label flexible, with unlimited number of lines.
Use one string without newlines, for automatic text placement.
Use plain English like "Take exit XXX to YYY"?

What about: 1. Make the textview label flexible, with unlimited number of lines. 2. Use one string without newlines, for automatic text placement. 3. Use plain English like "Take exit XXX to YYY"?

AntonM030481 commented

2022-06-22 15:42:59 +00:00

(Migrated from github.com)

Not sure about 3. See organicmaps/organicmaps#849 (comment)

Let's start with 1-2.
@biodranik can you do it?

Not sure about 3. See https://git.omaps.dev/organicmaps/organicmaps/issues/849#issuecomment-1163241894 Let's start with 1-2. @biodranik can you do it?

biodranik commented

2022-06-22 21:06:46 +00:00

(Migrated from github.com)

That should be easy, add android:singleLine="false" attribute for the TextView. In iOS it should be also easy.

That should be easy, add `android:singleLine="false"` attribute for the TextView. In iOS it should be also easy.

zyphlar commented

2022-06-22 21:52:27 +00:00

The best way I can imagine would be like I wrote out in markdown in the parent issue, with ref, destination, and maybe also name on separate lines. The arrow suffices for "take exit" and the word "to" is only really spoken it's probably better and more standard to just have them separated by line breaks.

biodranik commented

2022-06-23 05:51:29 +00:00

(Migrated from github.com)

Line breaks will take a lot of space at the top, which may be important to see where actually the turn goes.

👍 1

AntonM030481 commented

2022-06-23 12:03:14 +00:00

(Migrated from github.com)

@biodranik Yesterday I discovered that multi-lined approach is already implemented in iOS and Android:)

I have made screen by screen comparison Waze VS OM.
Waze is much more visible.

Font 1.4 times larger. Let's copycat.
Text color is better. Can we use e.g. color of turn sign background?
Left instead of center text position. Left is better IMHO.

@biodranik Yesterday I discovered that multi-lined approach is already implemented in iOS and Android:) I have made screen by screen comparison Waze VS OM. Waze is much more visible. - Font 1.4 times larger. Let's copycat. - Text color is better. Can we use e.g. color of turn sign background? - Left instead of center text position. Left is better IMHO. ![image](https://user-images.githubusercontent.com/85622715/175292616-737fd97f-da81-4445-97d0-6a7f11a9d47c.png)

AntonM030481 commented

2022-06-24 08:30:32 +00:00

(Migrated from github.com)

And day mode:

And day mode: ![image](https://user-images.githubusercontent.com/85622715/175496259-e7f71d06-5a96-485b-9131-e7f30200c34c.png)

biodranik commented

2022-06-24 12:53:16 +00:00

(Migrated from github.com)

You are not considering:

Landscape mode.
Carplay/Android Auto modes
Next turn after the current one.
Ideally, next after the next turn, it is useful when there are 3+ turns close to each other.
Long street names.
Small distance and text are not visible in the car in many cases (bad eyesight, sunlight).
Distance and direction are more important than the name.

You are not considering: 1. Landscape mode. 2. Carplay/Android Auto modes 3. Next turn after the current one. 4. Ideally, next after the next turn, it is useful when there are 3+ turns close to each other. 5. Long street names. 6. Small distance and text are not visible in the car in many cases (bad eyesight, sunlight). 7. Distance and direction are more important than the name.

AntonM030481 commented

2022-06-24 13:12:01 +00:00

(Migrated from github.com)

Let's not change it until separate floating landscape turn widget will be created.
Let's not change it.
How it's related? We don't taught it.
How it's related? We don't taught it. BTW I don't know any navigator with such functionality.
Long street names will take 2 lines es expected.
It's suggested to make font bigger, not smaller.
Maybe, but we don't taught distance and direction.

Just to clarify.
It's not suggested to change anything in current layout. Only font size/color only for "extended street name"
Waze was selected for comparison since they implement similar approach. Just 1 multiline string with plain text.

1. Let's not change it until separate floating landscape turn widget will be created. 2. Let's not change it. 3. How it's related? We don't taught it. 4. How it's related? We don't taught it. BTW I don't know any navigator with such functionality. 5. Long street names will take 2 lines es expected. 6. It's suggested to make font bigger, not smaller. 7. Maybe, but we don't taught distance and direction. Just to clarify. It's not suggested to change anything in current layout. Only font size/color only for "extended street name" Waze was selected for comparison since they implement similar approach. Just 1 multiline string with plain text.

biodranik commented

2022-06-25 05:37:27 +00:00

(Migrated from github.com)

Increasing the font and making the string 1+ lines of height is a simple change ATM, I agree.

AntonM030481 commented

2022-08-16 10:49:17 +00:00

(Migrated from github.com)

Created #3182

This repo is archived. You cannot comment on pull requests.

No reviewers

biodranik

vng