Address naming convention for map searches

[Pertti Lehtinen]

Hi there!

I have a question about OSMand's object naming convention when searching for certain objects!

For example, if I search for "Helsinki railway station", all objects get the upper-level address "...Klaukkala, Helsinki......".

What is the reason for this naming convention?
Is this perhaps a larger area whose map technical name is "Klaukkala" or what is the issue?

I have attached two screenshots that clarify my question.
Thank you if any of you can answer this question.

BR Pepe

[Dmytro Prodchenko]

Hi! Thank you for the feedback. We are working on improving search results as part of adding addresses to the results. However, as you pointed out that there is something wrong with the address, I have created an issue for our team: [https://github.com/osmandapp/OsmAnd-Issues/issues/3135](https://github.com/osmandapp/OsmAnd-Issues/issues/3135)

[Greg Troxel]

Dmytro Prodchenko <dmpr...@gmail.com> writes:

> Hi! Thank you for the feedback. We are working on improving search results
> as part of adding addresses to the results. However, as you pointed out
> that there is something wrong with the address, I have created an issue for
> our team:
> [https://github.com/osmandapp/OsmAnd-Issues/issues/3135](https://github.com/osmandapp/OsmAnd-Issues/issues/3135)

Perhaps related:

When I search for an address in the US, and do "find city", I am given
a list of city/towns. In my area, that really should mean admin level
8 entities, and the list seems reasonable.

When I am presented with the list, it is not annotated with the admin
level 2 (state) name. This is a problem because here in New England
town names are very often taken from England, so that e.g. both
Massachusetts and New Hampshire have a Concord, and most such town
names are used in more than one state.


So this is sort of a bug/feature request to show admin level 2 for
identification when displaying city/town in address search.

Perhaps more generally, for all admin levels < 8, if the admin level of
the searched entity is different from the admin level of the search
start point, display it. I'd certainly want to know if a town is in
Canada vs US/Vermont, were I close enough for those hits to appear.

[Martin Trautmann]

On 28.11.25 14:03, Dmytro Prodchenko wrote:

Hi! Thank you for the feedback. We are working on improving search results as part of adding addresses to the results. However, as you pointed out that there is something wrong with the address, I have created an issue for our team: [https://github.com/osmandapp/OsmAnd-Issues/issues/3135](https://github.com/osmandapp/OsmAnd-Issues/issues/3135)

In Germany we many times have a town like XYZ and other towns or villages, naming roads as XYZstraße (street). The recent osmand versions now show XYZstr first,

The usual address scheme here is road + house number, then postal area code (PLZ) + town. 

For a quick address search it was better to search for town first, then refine by the road. But because of the new (?) address search behaviour, the town XYZ is shown far below all other XYZstreets - probably because those are closer to my current position?

Unfortunately, this does not help. Please show XYZ first - especially if this name is entered with XYZ + space (as it is entered from the spell checker as a suggestion)

[Harry van der Wolf]

Op vr 28 nov 2025 om 19:51 schreef 'Martin Trautmann' via OsmAnd <osm...@googlegroups.com>:

In Germany we many times have a town like XYZ and other towns or villages, naming roads as XYZstraße (street). The recent osmand versions now show XYZstr first,

The usual address scheme here is road + house number, then postal area code (PLZ) + town. 

Same for the Netherlands.

Many years ago we also had issues that when you searched for an address in a small town that belongs to a big(ger) town, it would show: <big(ger) town> <address>, instead of <small town><address>.

That was also terribly confusing.

Please go back to the previous scheme and please do not fall back to that old scheme.

Harry

[*Hobbit*]

It should really behave like google-maps, searching for matches that make
sense given the LOCAL context of where we've zoomed to. OSM tries to start
at the 60,000 foot view without regard for our viewport, which is stupid.

_H*