At the moment I have no idea what should be the main name for the main A1 (PAThE) motorway, because there are other alternative names that users have used, such as the “Aegean Motorway” and the simpler “A1 Motorway”. For the record, I wonder if we can agree on which sections should be called which.

This is because it seems that Aegean Motorway, Nea Odos and Kentriki Odos are operator names so those could be tagged under “operator=*”. Then the rest of the road could be “PAThE motorway” or just “A1 Motorway” (in respective languages and where there is no other name such as Kifisias Avenue in Athens).

Thoughts are welcome on this idea.

I know it is a bit of a challenge given the current situation major changes to Greek road classification but I want to ensure that there is a solid standard so that we do not make mistakes in the future.

Missing Greece a lot,


Just a thought.
Doesn’t A1 means A1 Motorway by itself?
Do we have to give it a ref and a name?

I believe you want to do it without using relations?
How about using the local names=* and/or the operator=* for the company who is responsible for the operation for each part and the same ref=A1 for the whole way.
Leave without name the parts that don’t have one.

A1 will be searchable by its ref and not its name. Also it’s redundant information.

You mean that using name=“A1 motorway” (in respective languages) is just a formality? I know that JayCBR wants most road relations removed.

The OSM website isn’t serving tiles at the time of posting, but I was thinking that the default name should be PAthE, unless there are other common names such as Leoforos Kifisias, and Bridge names. Where there is a different common name then “PAThE motorway” should go to “alt_name=*”.

FYI, Evidence that the PAthE name is alive and well: (Page 7 and various slides onwards)

I just don’t like the idea of using the name of the whole road to fill in the gaps.
In my opinion, when I see on the map something like → Kifisias → PathE → A1 motorway → Aegean → PathE → A1 motorway and so on, it’s confusing.
I would prefer a relation with all the different parts of the way under a common name and data and without using these data on the parts of the road.

Just an opinion.

i think we should name motorways in general like: name = Αυτοκινητόδρομος 1, name:en = Motorway 1, ref = A1
so no confusion with operators

it has come into my attention that osmand prefers refs over names…is there a solution to this?

as for road relations, i would be ok with them if they serve a purpose like rendering or navigation

I am confused by the patchwork of names as well, hence why I need to ask on what is the current situation and how we should solve this.

I am not against using a sequence of default names. I am thinking of:

  • “name=Leoforos Kifisiou” and “alt_name=PAThE Motorway” from the southern end to A6 Attiki Odos.
  • “name=PAThE Motorway” to Lamia
  • “name=Aegean Motorway” and “alt_name=PAThE Motorway” from Lamia to Kleidi
  • “name=Aegean Motorway” and “alt_name=Egnatia Motorway;PAThE Motorway” from Kleidi to Chalastra (the section that A1 and A2 shares)
  • “name=PAThE Motorway” to the border with the Republic of Macedonia.

Of course, we take individual bridge and tunnel names into account, but the transition between the main names should not be too abrupt: in these cases the default name then goes to “alt_name”.

If we follow the rules of road naming to other elements of OSM e.g. a boundary, then each and every element inside the boundary that doesn’t have a name, it should be named with the name of the boundary and the names of the boundaries above that. For example a building without a name it should be named like Greece - Attica Administration - North Athens Regional Unit - xxx and so on.

I know that In the OSM wiki it states that it is preferred for each road to have all the data on the road element than in a relation, but that approach leads to problems like this.
I really flavour the approach of the smaller to the bigger. From the node to the relation.

What I mean is that we should name each road with it’s local data and then create relations for the bigger networks with their own data .
Refs can be an exception as the approach of using multiple ones is working e.g. ref=A1;A2 and I think we can live with that.

As for the OsmAnd support i think it’s irrelevant. And what about other programs or on-line sites?
It’s good that you care how your data are being used but you have to see the whole picture.

Support is always changing and programmers support better well organized data.

EDIT 01: And when a name that is part of the whole route is used as alt_name once then it should be alt_name for the whole route. This back and forth is confusing.
EDIT 02: And what happens when a local road has already the alt_name, old_name etc. already occupied? Don’t think for a solution for A1 or motorways only but for the whole network.

Would that warrant the retention of all road relations instead of deleting them?

How about putting “PAThE Motorway” into a relation, so that the basic structure for the ways is:

  • “name=Leoforos Kifisiou” from the southern end to A6 Attiki Odos.
  • “name=Aegean Motorway” from Lamia to Kleidi
  • “name=Aegean Motorway” and “alt_name=Egnatia Motorway” from Kleidi to Chalastra (the section that A1 and A2 shares)
  • Everything else is left alone.

Again, we take individual bridge and tunnel names into account.

I can’t have an opinion on the specific route.
I’m just saying that relations are a good way to show the whole picture. You can’t mess the local data with the national data and with the international data.
On each part of the road we should use the local data only. That covers the naming of the bridges the tunnels and the other elements.

For example if Egnatia Motorway is part of another relation, don’t use it in the local data as alt_name.
This approach might not be well supported but it solves many problems.

Imagine that you download a route in a spreadsheet.
In the first column you have the object ID. OK no worries here, nothing to check.
Second column is the name. Still nothing to check here.
Next column, the refs. If a ref is missing here there is a problem. For example A1 should be referenced in each cell apart from the other refs there might be there.
You go to the alt_name column. You see many PAThE Motorway names with big portions of the column empty. Don’t you wonder how can this be? You downloaded the same route after all. Why is the alt_name now name and then alt_name again?
And that goes on.

Also in JOSM if you select many ways you expect to have some common data for the same route.

So I believe that this mixing and blending of data creates more problems than it solves (always concerning data structure).

EDIT 01: And I don’t have a problem with leaving parts of the route without a local name. Refs can be enough.
EDIT 02: And why favour one name over the other when you have one road in two routes? For example refs A1 and A2. Which name is the right one?
EDIT 03: And on my spreadsheet example, just to make my self clear, if you fix the data for one route and then you download a second route, the common data will mess with the data of the second route. You can’t have data consistency with any other way except from using relations.
EDIT 04: And yes you can use e.g. name=Aegean Motorway as local name if the road is not interrupted by other roads to continue later on.

If relations are a good way to show the whole picture, then we have a bit of a deadlock because JayCBR wants to route relations removed. Even though we are close to solving the classification issue, I personally recommend that the route number relations stay on OSM because of shared sections like the A1/A2, EO3/EO30 and so on, and from what Kanenas may suggest.

My vote, if it matters, goes to relations.

I just extended this subject with a personal view on the matter. Use more relations and treat them as other elements of the map.

I really don’t understand why the relation type of road was disapproved in the forums. And that was from a programmers point of view, if I remember well.
Now we can’t have a relation to represent a road that might be broken in many pieces and also have other elements on the way, like bridges.
Big highways are broken down in very small pieces every time you try to create a turn restriction, to put a traffic light, to change the speed limit, to create a junction, to put a bus stop etc. And you have to check that every little piece has all it’s data in place.
Attiki odos, Kifisias etc. could be of this kind of relation. Highways with common data with various elements on the way that have a specific start and end point and that are continuous.
Route relations could be used for a collection of highways, road relations, bridges etc.
I would also like to see common data to be represented on the relation and not on the highway parts. Common data should be derived from the relation above.
It’s the only way, with the current tagging scheme, to assign the name or the ref to the route and not on the bridge, tunnel, junction etc.
And the renderer should support this, maybe combine the data. Then we can have clean and structured data for every possible combination of routes, each with its own specific data like name, ref etc.

But this is an old subject that has already been discussed in the forums.
Just a personal opinion/wish and maybe a start of a discussion.

the point i m trying to make is to minimize unnecessary things making maps bigger and slower, my opinion is even e-roads relations are not needed
(really where is int_ref displayed?)

we can find common ground, maybe only motorways relations

Well, bigger and slower. It depends.

If everything has to do with the sum of BYTES, WORDS, CHARS etc. that you put in the database then copy/pasting the same data everywhere creates more load.
If you want programs that won’t have to load relations to just represent data about a specific part of a highway then the other approach is better. But it’s not user friendly.
JOSM on the other hand gives you an instant overview of the relations a specific highway is part of and it seems there is no load there.

I know that there are tags to represent everything but real world is more complicated.
If you find a solution for the ref and the names on the bridges, the tunnels, the junctions that are part of a route then I’m with you.
But please don’t ever think something like “motorways only”. One rule to rule them all :smiley: .

And what about the other routes that have elements inside villages, towns etc.?
What about their local names. And we have common refs for routes that are not of type motorway.
And how can you fetch data of a specific route from the database? Asking what?
Please give me the data of a route with name=xxx OR alt_name=xxx but NOT with ref=xxx and find the bridges along the way that are related with the route AND check for tunnels that are part of the route with different name AND highways inside cities with other names but with ref=xxx…
The other approach is something like → fetch me the data of the route with name=xxx. Or maybe ref=xxx…And so on.

EDIT 01: If you think that you can represent some ways without using relations, do it. But keep in mind that the data should be consistent and not jump from one key to another. And they should be the same for the whole route.

well i dont like josm, and when i edit a road i do exactly this (checking every single way so the result is consistent), some bridges that have specific names i leave them there, with the correct ref, also inside cities etc where roads have names different than National Highways/provincial roads

i noticed links having the same name and ref with the parent road and i feel this is wrong, we should use more destination tags

Θα συμμετάσχω Λακωνικά :slight_smile:

+1 στο μήνυμα #13

It all comes down to WHAT you want to design. HOW comes later.
If you want to put data on the small then think like that. Use what you have available.
If you want to put data for the big then think like that.
Don’t mix both situations as they won’t fit everywhere.

An example:
Someone puts a node in the map. Or maybe a building. He knows the data about that element and he doesn’t care about anything else.
Then someone else comes and designs an amenity e.g. university. He knows the data about it and defines the borders. He doesn’t care about the building and it’s data inside his amenity.
Then someone else comes and designs an administrative border. He knows the data about it, he designs the border he doesn’t care about the amenity and the building inside it.
And that goes on. No one goes on each and every element of the map to change it’s data by adding unnecessary information to represent the whole.

But on the highway scheme we have to put all the data on the highways. In my opinion it’s a design flow and problems like this arise. We have to deal with it.

So, again, the question is WHAT do you want to design.
With no relations you have to live with the small scale and if the bigger doesn’t fit…I don’t know.
On the other hand if you think big and use relations then the data of the relation should not be represented on the highways. Now we have to deal with the renderer.

It’s really a mess but I still favour relations, as they are today, even if the data are redundant.

**EDIT 01: **
@JayCBR → JOSM was just an example of performance.
@aitolos → Thanks.

we better change the title or move to an other post

so you say we should make relations for every road??

and what about broken roads with gaps like EO1 or roads with new and old routes?


You just reminded me of something:

This is not related to the classification issue, but with all due respect, can JayCBR kindly please explain the removal of names at random places such as and This is particularly worrisome, given that no changeset comments were provided, meaning that we have difficulty as to what is going on.

its common practice to leave one of two carriageways without name

so because of consistency i follow this

I will wait for other users in the forum to reply if they are okay with leaving one of two carriageways without name, but it is common practice to tag both sides: I have yet to see a country where it is acceptable practice to tag only one side of the dual carriageway: correct me if I am wrong.