Suggest street names in quest

[rmikke]

There really should be suggestions for street names in street name quests.
The list could be taken from adjacent streets (with common nodes) or by searching highway names and add:street nearby.

Without it users will be entering similar, but not identical names for street parts that are missing name=* tag. You may bet on it - we will end up with a few similar street names for the same street if users can't just select the name if it's already entered for other part of the street.

[westnordost]

This is more complex to implement than you might think because the app would need to persistently store all the street names and clean them up as well when they are not needed anymore.

[rmikke]

On the other hand it's really important that StreetComplete doesn't generate wrong entries in the map. I even think the user's first choice should be picking a name from the list and typing the name manually should be an option.

It doesn't have to store all the street names persistently.

If it is the app that generates tasks on the fly, then one additional query for a street names in a small bounding box should not make a big difference.

If the quests are generated by some server, then a street name task should have a list of nearby streets associated and the data would be removed when the task is solved. This way only the names needed for creating the lists are stored and they are automatically removed when not needed.

[westnordost]

Imagine you are in, say, Kenia and you are the first person to ever walk this street since the street was added via satellite imagery. You wouldn't want a list of nearby streets to select, you will want to add the street name.
Really a adding new street names is what the quest was designed for, not for all these small annoying "this is a link between two streets" cases which are a necessary side product when searching for streets with no name. Naturally, you won't find many "real" streets with no names in Warsaw.

Anyway, this issue is a valid request. The implementation should look like that you have a free input text, but a small down-arrow on the right from which you can select streets which share a node with this street.

[rmikke]

Yes, I understand your intention.

What I say is: most common use of this quest will not comply with your intention and it will create many more errors on these links, than add really new street names in Kenya.

How about trying to create a list from a small bounding box and adjacent (i.e. sharing node with way in question) ways and if the list is empty - present a box for entering a name. But if the list is not empty - present a list of names as the first option. This way you have both targets covered - it's easy to enter a new name where the vicinity is void of street names, and at the same time we are protected against entering similar, but not exact same names for the same street.

EDIT: if the bounding box is a little bit greater than a box just containing the way in question, adding adjacent ways will be redundant. So, getting the street names from a small bounding box ("a bit bigger than only big enough to contain the way") will be enough.

EDIT: Actually, if the user is presented with a list of names but still chooses to add new name, I would even suggest setting additional tag to allow finding such entries and prevent vandalism. The tag could be:

streetcomplete:newname=New name created, please check. When the name is correct, remove this tag.

[HolgerJeromin]

streetcomplete:newname=New name created, please check. When the name is correct, remove this tag.

We have enough FIXME like special tags which no one is checking. For example USA was filled with tiger:checked=no tags. This just does not worked.

[zxmon21]

A suggestion: JOSM avoids this problem by using auto complete based on the letters entered already. Then the interface would look the same, but if there is King Street and King Lane nearby, you could either pick one of them or insist to create King Square

[rmikke]

We have enough FIXME like special tags which no one is checking. For example USA was filled with tiger:checked=no tags. This just does not worked.

That's true. But consider:

1. I wouldn't know what to do with tiger:checked=no if I found it accidentally. That's why I propose more descriptive value.
2. SC knows, when it has proposed a list of street names, but the user has chosen to enter a new name, and THERE IS NO WAY to find it out later, if it's not marked down with a tag.
3. The tag will not flood the database, because most users will just choose a value from the list.

Actually, the amount of objects with streetcomplete:newname tag can be even much more smaller, because SC could also remove this tag. This is how:

• when creating a list of names, for every name we keep a boolean marker that we set if the name has been taken from an object with streetcomplete:newname tag.
• when a user chooses such a name from the list, we may assume that there really exists a street with such name, so we remove the streetcomplete:newname from original object.
• the above should also work offline - then all this should happen in SC and streetcomplete:newname tag would not even be sent to OSM.

It is important, that list of names should be taken from and used for every object that contains street name i.e. name=* on highways and addr:street=* on buildings. And every such object should be marked with streetcomplete:newname tag if the user gets the list of nearby street names, but chooses to add a new name.

A suggestion: JOSM avoids this problem by using auto complete based on the letters entered already. Then the interface would look the same, but if there is King Street and King Lane nearby, you could either pick one of them or insist to create King Square

That's a good idea, provided that autocomplete suggests every name that contains the typed string, not only the names that begin with it. Otherwise the users will tend to create "Patton Street" even when they should choose "General Patton Street" from the list.

[rugk]

Really a adding new street names is what the quest was designed for, not for all these small annoying "this is a link between two streets" cases which are a necessary side product when searching for streets with no name.

Actually from my own experience I'd say most quests of this type are only small links between some streets missing a name – so the contrary of what you intended. Of course, I'm not in Kenia, but both input methods should be possible.
I think there were already enough suggestions for the input design, and I'm sure, @westnordost, you'll find a good way to do it. 😃

[westnordost]

Thought a bit about how to implement it properly. This is quite complex if it should be proper.

Requirements:

• in the UI, only these street names should be shown in the suggestion list which are directly neighbouring (i.e. share a node) with the current "street with no name"
• names are stored persistently just like the quests
• it must be possible to select names by language (multilingual names)
• when quests are solved, this meta data also needs to be cleared from local database, but of course only the data that is not needed by other quests anymore (<- hard)
• when quests are solved, the data the user entered must find it's way into the local database, so that he can select the name he just entered for the next street section without downloading quests completely anew (<- hard)

Solution would involve:

• Street name quest must query via Overpass not only streets without a name but all streets. Must create the quests out of the ones without a name and create a graph of streets out of all queried streets
• during graph creation, the ways need to be split at every node which is shared by two or more ways so that the ways can be persisted in the following format:
• the graph is persisted in a DB table with the following columns or similar: endpoint1 (node id), endpoint2 (node id), names (blob which contains a list of names+language code). If names is null, it means that this way has no name(s) yet but this can change through user solving quests
• pitfall: this'd mean the ways with no name need to be split as well in the graph
• any newly fetched data must be merged with the data in the table
• when the quest is shown, the names data can then be queried by querying the table for each of the two endpoints of the street without a name and when the quest is solved, the user's answer can be put into the table the same way
• on solving the quest, it should be possible to remove the unreferenced (by street name quests) sections of the graph from the DB somehow
• probably it is necessary to refactor the OsmQuestUpload a bit, so that a QuestType is being notified when a quest of its type has been uploaded so that the quest type can do some custom cleanup work
• UI wise, it should simply be a little down-arrow on the right side of the input field that looks and behaves like a dropdown that is only shown while the user did not enter any text yet. What is being shown in the dropdown is dependent on the language the user selected for the input field
• UI wise (cont.): After he selected an item in any language, the complete street name sign should be prefilled with all the languages with which the other street was tagged

Given the complexity of this, this is not exactly a low hanging fruit. So I will not work on this anytime soon

[westnordost]

By the way, @rmikke, there is no server. StreetComplete (the app) generates all quests from analyzing OSM data queried through Overpass.

[rmikke]

Disclaimer: While I am a programmer and know quite a lot about databases and user interaction, I have never programmed even the simplest web or mobile app, so please be patient if I write something stupid ;)

I think you overcomplicate a little bit.

Getting data

First of all, limiting list of names to the names of neighbouring ways seems too strict:

1. See this street.
2. The street name may be also already entered in addr:street of a nearby house.
   So why not just get all the street names in bounding box (both from name=* and addr:street=*) with positions of all nodes and present a user list of all street names that have nodes within, say, 30 meters from any node of unnamed street in question?

For example, street named Somestreet1 has three nodes, so we get to local database three entries for it in form (more or less):

Somestreet1, Lat1, Lon1
Somestreet1, Lat2, Lon2
Somestreet1, Lat3, Lon3

and then, some unnamed street has any node within 30 meters of any of those nodes, the name Somestreet1 appears on the list of proposed names.

On choosing or entering a name we add way's nodes to the above list.
The list could be cleared and recreated when bbox moves (which, I believe is done for all the quests anyway).

This way there would be no graph building, no Overpass querying for every single way.

Multilingual names

How is this problem solved now? Without list of suggestions the street may also have two names in two languages - how does the user enter these two names?

If it's not solved yet then I agree that this should be dealt with prior to working on suggestion lists.

UI

Here I insist that the user should be presented with a list of suggestions (if there exist any) first and have to deliberately choose some "Enter new street name" option to enter a new name. Otherwise quite a big part of users will start typing before they even think there may be some list and all the idea of avoiding entering multiple versions of the same street name is lost and we may not bother as well.

Also, I think the same suggestions list should be used when the user enters addr:street for a building.

[westnordost]

overcomplicate

Yes, could be. Your suggestion looks quite simple, I like that. I assume you mean there should be two tables, one street id, lat, lon and the other street id, names blob.
Though, this has a few problems:

1. How to query for streets that are ~30m away from DB? Remember, the street is a (potentially very long) way, not a single lat lon
2. How to detect which data is not needed anymore and clear it?

The overpass querying (once), by the way, needs to be done either way. But it can be done in the same query that is used to create the quests, so it is no problem.

How is this problem solved now? Without list of suggestions the street may also have two names in two languages - how does the user enter these two names?

They can enter them soon. The feature has been developed in a branch and is about to be merged to master.

[rmikke]

I assume you mean there should be two tables, one street id, lat, lon and the other street id, names blob.

I suggest to prepare list of nodes when overpass returns data in table with:
node id, lat, lon, name id and name id, names blob
containing nodes both from streets with names and buildings with addr:street.
I mean, take names from all name=* on highways and addr:street=* on buildings and build the above two tables with name id that you assign to names. If you build them paralelly in one loop, you don't need any object id (street id and building id) in these tables. This way, when you want to present a list of suggestions, you get names from the nodes within 30m from DB (what does this acronym stand for?).

How to query for streets that are ~30m away from DB? Remember, the street is a (potentially very long) way, not a single lat lon

There are two questions here.

When retrieving data from overpass there is no problem really, around can return objects within range from a set. And AFAIK it's easier to get objects that are within range from street even if they are totally out of bbox, than restrict the result set to objects in bbox, which is good, because if the user is on one end of long unnamed street and there is an object with correct name on the other end of this street, then we want that name. See this query - it returns objects with street names around streets with no names (some tweaking required ;) ).

Now, when SC builds suggestions list, I think it will be enough to loop through the way's nodes and for each node find all nodes from the table node id, lat, lon, name id within 30m.

How to detect which data is not needed anymore and clear it?

Don't :)
Just clear the data and rebuild it when requiryng Overpass, I think.

[westnordost]

Okay, I am not sure if you can make reasonable suggestions from your point of view because you don't know how the the quest creation and persistence process works. I'll try sum it up:

First, you need to know that the download process is decoupled from displaying and solving the quests. The app is not a web app, it downloads the quests once and then keeps them and all other information that is necessary to solve the quests stored in a local DB persistently. Importantly, the app does not make any http queries after the quests were downloaded and before the changes are uploaded.

The process is as follows. Download:

1. Each quest type fires one (or several) overpass queries to gather the data
2. The response is processed by each quest type respectively and quests are created out of the data which are stored in this DB table along with their geometry for displaying them on the map and along with their respective OSM element (node, way, relation)

Display & Solving quests:

1. For displaying the quests on the map, data is queried from the quests table and the geometry table (so, not from the internet!).
2. Solved quests are updated to the database (not uploaded yet)

Uploading quests is done by a separate process:

1. For upload, the OSM element the quest is associated with is pulled from local DB and the changes that have been stored in the quest table are applied to this local copy of the OSM element
2. This modified OSM element is added to a changeset and uploaded to OSM. Only if OSM reports a conflict, the app will download the new version of the associated element and again try to apply the changes to it, then try again.
3. After this has been done, the quest is deleted and both the element geometry database table and the osm element database tables are cleaned: All rows are cleared that do not have an associated quest anymore

[westnordost]

How to detect which data is not needed anymore and clear it?

Don't :)
Just clear the data and rebuild it when requiryng Overpass, I think.

Users can download quests at different locations. You can scan for quests in Krakow, then scan for quests in Prague. Your suggestion would mean that the Krakow name suggestion data is cleared on that second scan.

[rmikke]

Okay, I am not sure if you can make reasonable suggestions from your point of view because you don't know how the the quest creation and persistence process works. I'll try sum it up:

Thanks, it's more clear for me now. And it seems that in such an arrangement clearing data is not a hard task. But before I make more suggestions, one question is important:

The response is processed by each quest type respectively and quests are created out of the data which are stored in this DB table along with their geometry for displaying them on the map and along with their respective OSM element (node, way, relation)

Does that mean, that data stored in DB for a quest is associated somehow with each quest (specific building or bus stop for example) by some quest id, or is it just stored in separate tables for each quest type and shared by all quests of this type? If the latter, how do you decide which data is not needed anymore?

Well, that were two questions ;)

[westnordost]

See the links in the last comment for how the tables look.

[westnordost]

How I decide. I.e. like this: https://github.com/westnordost/StreetComplete/blob/master/app/src/main/java/de/westnordost/streetcomplete/data/osm/persist/ElementGeometryDao.java#L146

Same for OSM element table

[rmikke]

Okay then, this structure tells me that so far there was no need to store any data about objects other then quest subjects.

Now let me get my wife from the airport and think how to evolve this without revolution, I will come up with something.

[westnordost]

Correct.
As said, it is already possible for any quest type to do any other kind of stuff, including creating db tables, adding data to it etc. This has to be done anyway also with the approach I laid down earlier.

[rmikke]

Ooookay.

First, from now on everywhere I talk about name, it is a name to suggest, taken either from highway's name or building's addr:street.

So I think we need two new tables:

First:

NamesAroundTable
  NAMED_NODE_ID int PRIMARY KEY
  LATITUDE double NOT NULL
  LONGITUDE double NOT NULL
  NAME varchar(255)

This is a simplified version of your NodeTable. We don't need version as we won't update these nodes, we don't need all the tags, and we don't want to use the NodeTable because it contains nodes that are parts of quest subjects and we want to store quite a different set of nodes.

Second:

QuestToNamesTable
  QUERY_ID int NOT NULL --foreign key to OsmQuestTable
  NAMED_NODE_ID int NOT NULL --foreign key to NamesAroundTable
PRIMARY KEY on both columns

This is to maintain many-to-many relation between quests and names.

There will be a third table to temporarily store ways, description below.

How to fill tables

Filling NamesAroundTable

First we fill NamesAroundTable from query similar to this one (I've added relations for complex buildings, still some tweaking required, like adding more highway types, also it should be modified if we want to use it also to suggest street names for addr:street).

We want to "propagate" street names from relations and ways to nodes and put those nodes with names into NamesAroundTable. This will require temporary table

WaysAroundTable 
  ID int PRIMARY KEY
  NAME varchar(255)
  NODES blob

to store all ways until we have NamesAroundTable filled.

Now, we go through query results, it contains nodes first, then ways, then relations.

1. For every node, we store id, lat, lon, NULL in NamesAroundTable.

2. For every way with name (in "name" or "addr:street" field), we store id, name, nodes in WaysAroundTable.

3. For every unnamed way we store id, NULL, nodes in WaysAroundTable.

4. For every relation we lookup it's members:

   1. If the member is of type "way" we lookup this way in WaysAroundTable and update NAME. If the way belongs to more than one relation - no problem, we overwrite previous value regardless. See below for reason why.
   2. In the rare occasion where a member is of type "node", we lookup this node in NamesAroundTable and update NAME.

Then we go through WaysAroundTable and for each way we lookup it's nodes in NamesAroundTable and update NAME.

Then we purge the WaysAroundTable, it's no longer needed.

Why we don't care about overwriting names

First, because they will usually will be overwritten with the same value. Second, because even if not, we will have the overwritten value in another way/node, that does not belong to relation/way with the new value for name, so we will get the name anyway.

Filling QuestToNamesTable

For every unnamed way (a quest) we loop through it's nodes (I can see they are stored in a blob in WayTable) and for every node we loop through nodes in NamesAroundTable and compare latitudes and longitudes of the nodes (node in quest and node from NamesAroundTable). If latitudes difference is less than half a radius (i.e.15m, half of 30m) and longitude difference is less then half a radius, we insert QUEST_ID, NAMED_NODE_ID into QuestToNamesTable.

This will cover slightly bigger area, than covered by overpass query, but I can't see a problem here. And just comparing latitudes and longitudes will be faster than trying to select named nodes in circular area around quest's nodes.

NOTE: If we use the same algorithm to suggest street names for building's addresses, we have to take into consideration, that quest may be a single node, or a relation, not a way.

Creating the list of suggestion

We simply

SELECT DISTINCT NamesAroundTable.NAME
FROM   QuestToNamesTable, NamesAroundTable
WHERE  QuestToNamesTable.NAMED_NODE_ID=NamesAroundTable.NAMED_NODE_ID
  AND  QuestToNamesTable.QUERY_ID=<our query ID>

When the user selects or types a street name for the quest

We add the quest's nodes to NamesAroundTable in a loop. For every node we look up all the quests that may require suggestion and if any node of such a quest is within range from a node, we add QUEST_ID, NAMED_NODE_ID to QuestToNameTable. If for this node we don"t add anything to QuestToNameTable, we delete the node from NamesAroundTable.

I is also possible to hold the node and check quests' nodes for proximity and only if we find one, we add the node to NamesAroundTable and then add an entry to QuestToNamesTable (in that sequence, because of foreign key constraint on NAMED_NODE_ID in QuestToNamesTable).

Cleaning unnecessary data

It has to be done in this sequence:

From QuestToNamesTable

We delete all rows having QUEST_ID that can't be found in OsmQuestTable, analogically to your current cleanup procedure.

From NamesAroundTable

We delete all rows having NAMED_NODE_ID that can't be found in QuestToNamesTable.

[westnordost]

Hm your suggestion doesn't sound exactly easier than my original proposal, just different. The problem with discussion the implementation in such a detail is that at some point it does not help the implementer anymore since he will be expected to read through all this here (again) when he finally implements it. That "he" will most likely be me anyway, so I will have to write a short summary later on anyway as I did already a few days ago.

Anyway, a few comments regarding your deliberations:

• It is unusual in Android development to create temporary tables. That's what programming languages are for. It is easier to loop through results and insert it into the final table immediately than to insert and then later query that from a temporary table
• you did not consider multilingual names. The name should be a blob (dictionary from locale -> name)
• you did not consider that with your approach, one node may have several names (for nodes that are crossroads) never mind. Though: There are indeed roads that only consist of two nodes - in planned checkerboard-style cities, mostly.
• You suggest to do the work to fill the QuestToNamesTable at download time. I think this (and thus this the existance of that table) is not necessary, it should be deferred to when actually displaying the quest / solving the quest. Reasons:
  • you did not consider that the names information need to be updated on solving a quest by entering a new name. This will be more complicated with a QuestToNamesTable to be updated
  • there will always be less or equal quests actually displayed and solved than downloaded

Based on your ideas/suggestions, I will write a final note for implementer(s) later today that contains the requirements and how it should be implemented. I will accept a PR that follows this recipe. This is also meant as an invitation for you to contribute, since you already looked into the subject. I will not leave you (or anyone else who will have a go at this) hanging if he is stuck. Also, if there is a PR, I can shift my priorities and implement the UI side completely within that PR.

[rmikke]

It is unusual in Android development to create temporary tables. That's what programming languages are for. It is easier to loop through results and insert it into the final table immediately than to insert and then later query that from a temporary table

If you can reverse the order (nodes, ways, relations) of data returned by overpass, then you don't need temporary table, because you will have names before nodes. Or you don't mind going through this data mutiple times, then the order of data doesn't matter.

you did not consider multilingual names. The name should be a blob (dictionary from locale -> name)

You are right. This also means that you need to generate this blob from tags in such a way, that when you compare two name blobs created for the same set of name:xx=* tags, the blobs will be the same.

Hmm, is it possible at all to compare blobs?

There are indeed roads that only consist of two nodes - in planned checkerboard-style cities, mostly.

Well, it MAY happen that such a street will also not have any buildings with addr:street with it's name and we would lose the name completely. So... To avoid this we have to change:

NamesAroundTable
  NAMED_NODE_ID int PRIMARY KEY --SC assigns it's own ID here
  NODE_ID int NOT NULL --this is node ID from OSM
  LATITUDE double NOT NULL
  LONGITUDE double NOT NULL
  NAME blob 

and then we can store the same node multiple times for multiple names. This will also complicate filling the table a little bit, because we have to:

• find a node by NODE_ID
• if NAME is NULL, then update it
• else if NAME is different then what we have from query then insert a new row
  OTOH if you want to avoid temporary table, the filling process may by quite different...

You suggest to do the work to fill the QuestToNamesTable at download time. I think this (and thus this the existance of that table) is not necessary, it should be deferred to when actually displaying the quest / solving the quest.

That's because I imagine that doing it at display time will be to slow for the user. I may be wrong. But UI-wise, the user should not wait for generating suggestions list.

you did not consider that the names information need to be updated on solving a quest by entering a new name. This will be more complicated with a QuestToNamesTable to be updated

But I did. The section When the user selects or types a street name for the quest works well regardless whether the user chooses existing name or types in a new one.

there will always be less or equal quests actually displayed and solved than downloaded

That's of course true, I just thought that doing it at display time may be too slow for the enduser. Again, I may be wrong.

This is also meant as an invitation for you to contribute, since you already looked into the subject. I will not leave you (or anyone else who will have a go at this) hanging if he is stuck. Also, if there is a PR, I can shift my priorities and implement the UI side completely within that PR.

But you remember that I have close to null knowledge of coding a mobile app? Understanding the DB structure from unknown language (especially if the code is quite clear, as in this case, and uses well known SQL to create tables) and coding in this same language are different things :)

I think I could add the code to create tables, but filling them from overpass query is beyond me.
EDIT: Cleanup code also seems to be no problem, as all the logic is in SQL ;)

[westnordost]

Rather than writing down the stuff here I put that in code as discussed. Of course, it's only the tables for now, nothing else.

[rmikke]

Now it seems that I have overcomplicated this a bit :D

The schema you defined should do the trick.
I understand that your intention is to link quest to way, instead of node that I proposed, and decide which roads link to which quest by means of RoadNodesPositionsTable. If it displays the suggestions list fast enough, it's good and you avoid names propagation to nodes.

One remark: How do you intend to fill in names from relations?
Because if you get them after ways' names, you may have to remove NOT NULL constraint
from RoadNamesTable.names column.

Otherwise, the schema seems to be able to cover all the tasks (getting data, linking to quests, adding solved quests to data and cleaning unnecessary data). So far so good.

Oh, and I still hope you will get also street names from addr:street in buildings and use the same mechanism to suggest street names for addr:place when asking for building's address. Beacuse it's the same set of names after all.

[westnordost]

I will just disregard relations. street names are usually found on ways only.

Can you help me with the SQL expression that selects all road_names.names given a quest_id? I always mix up the different methods of merging / joining tables.

[westnordost]

SELECT names FROM road_names INNER JOIN road_names_quest_suggestions USING way_id WHERE road_names_quest_suggestions.quest_id = X?

[althio]

I will just disregard relations. street names are usually found on ways only.

But street names are sometimes found on relations also. Relation:associatedStreet can also take the name of the street.

In practice, street name will be on way and relation in most cases of Relation:associatedStreet, so it does not hurt to search only ways and disregard relations, I guess.

[rmikke]

I will just disregard relations. street names are usually found on ways only.

Buildings with addr:street=*, on the other hand, are quite often multipolygons.
And the reason for this issue is to avoid introducing inconsistencies.

SELECT names FROM road_names INNER JOIN road_names_quest_suggestions USING way_id WHERE road_names_quest_suggestions.quest_id = X?

This, or

SELECT road_names.names
FROM   road_names_quest_suggestions, road_names
WHERE  road_names_quest_suggestions.way_id=road_names.way_id
  AND  road_names_quest_suggestions.quest_id=X

You might also try SELECT DISTINCT, but most probably it can't be used on a blob, so you will have to deal with repeating names in java.

[westnordost]

#420

[rmikke]

Hi again.

There is a new tool for mismatched names (in Poland and should be treated as alpha version for now), so I've got a showcase now.

See how many cases of street names typed differently it shows. It is a real problem. Could we return to the concept of mutual matching street names in name=* and addr:street=* ? By mutual matching I mean taking both fields into consideration when suggesting a value for name=* for highways and addr:street=* for buldings.

I can open a new issue, if it's convenient for you.

[matkoniecz]

It is a real problem.

Have you analyzed how many wrong names were added using recent StreetComplete versions that include name suggestions?

[rmikke]

Have you analyzed how many wrong names were added using recent StreetComplete versions that include name suggestions?

Probably not possible:

1. the tool for inconsistent names works only for Poland now,
2. It does not catch typos {except for missing diacritics),
3. I can't see a way to check how many of them are made with StreetComplete other than analysing each case individually. And there are more than 750 cases now. Only for Poland and not including typos.

On the other hand:

1. StreetComplete has suggestions for street names in name=* for highways already,
2. adding support for addr:street seems to be much easier task than creating suggestion list itself,
3. I think making it hard to introduce inconsistent street names BEFORE people really do it is a good idea ;)

If I get the Overpass query that creates suggestion list now, I can modify it to include street names from addr:street as well.