More flexible format in 'Search Features' when searching by element id

[blackboxlogic]

Currently, User can search for a specific feature with a 'Search Features' query like n1234. When I copy an element from JOSM (or other places) I get a string like node 1234. But when I search in iD for this string, I get nothing. When I search for 1234 it offers node 1234 as an option.

I suggest supporting search queries of the form node 1234.

After looking at the code...

iD/modules/ui/feature_list.js

Line 125 in 63aa47f

var idMatch = q.match(/^([nwr])([0-9]+)$/);

it could use the regex
/^(node|way|relation|[nwr]) ?([0-9]+)$/i
and in four places immediately blow, replace idMatch[1] with idMatch[1][0]

But this would only support English. A step further would be to get the user's current language, and support the localized word for each element type.

[manfredbrandl]

It would be great if we could allow more than one translated word for the regex, e.g. „Punkt“ and „Knoten“ for the german translation of node or maybe even „Weg“ and „Fläche“ for way.

[1ec5]

But this would only support English. A step further would be to get the user's current language, and support the localized word for each element type.

I think this would be pretty straightforward. Ideally, iD would expose a translatable string for “node id” in Transifex. With the current locale’s translation in hand, iD could convert that into a regex dynamically.

It would be great if we could allow more than one translated word for the regex, e.g. „Punkt“ and „Knoten“ for the german translation of node or maybe even „Weg“ and „Fläche“ for way.

Or iD could expose two translatable lists of prefixes and suffixes (similar to the presets’ synonym lists), which would allow for variation. Hopefully no language needs both a prefix and suffix at the same time, though.

[boothym]

Would it be possible to update the regex to exclude spaces before or after element ids? As that would solve #7467.

[blackboxlogic]

Ignore whitespace before, after or between:
/^\s*(node|way|relation|[nwr])\s*([0-9]+)\s*$/i

[blackboxlogic]

Consider merging this issue with with #7282. Also, I had indicated I might make a pull request. I'm abandoning that for now.

[blackboxlogic]

These are examples of positive matches:
n158867610
n 158867610
n/158867610
node158867610
node 158867610
node/158867610
https://www.openstreetmap.org/node/158867610
https://www.openstreetmap.org/node/158867610/history
https://www.openstreetmap.org/node/158867610/history#map=19/43.66140/-70.25415
And the same for ways and relations. By requiring tokens before the type and after the id I have minimized false positives.
This also resolves #7282

[blackboxlogic]

To record some unintended consequences of this change:

This seems like a common use-case, and I regret breaking it. Any thoughts on if it is worth addressing?

[kymckay]

I think we could just have locationMatch take priority over idMatch in

iD/modules/ui/feature_list.js

Lines 125 to 149 in 0789b86

	var idMatch = q.match(/(?:^|\W)(node|way|relation|[nwr])\W?0*([1-9]\d*)(?:\W|$)/i);
	if (idMatch) {
	var elemType = idMatch[1].charAt(0);
	var elemId = idMatch[2];
	result.push({
	id: elemType + elemId,
	geometry: elemType === 'n' ? 'point' : elemType === 'w' ? 'line' : 'relation',
	type: elemType === 'n' ? t('inspector.node') : elemType === 'w' ? t('inspector.way') : t('inspector.relation'),
	name: elemId
	});
	}
	var locationMatch = sexagesimal.pair(q.toUpperCase()) || q.match(/^(-?\d+\.?\d*)\s+(-?\d+\.?\d*)$/);
	if (locationMatch) {
	var loc = [parseFloat(locationMatch[0]), parseFloat(locationMatch[1])];
	result.push({
	id: -1,
	geometry: 'point',
	type: t('inspector.location'),
	name: dmsCoordinatePair([loc[1], loc[0]]),
	location: loc
	});
	}

So check location first, don't bother checking id if location is matched. Thoughts?

[quincylvania]

So check location first, don't bother checking id if location is matched. Thoughts?

@SilentSpike Sounds fine, I'd welcome a PR for that.