Talk:WikiProject Europe/E-road network

warning: revert affecting e-roads

i'm not sure this should be publicised in the main page of this project, so i'm adding it here. recent revert regarding lithuania problems also affected several e-roads, probably the ones crossing lithuania. for example, see http://www.openstreetmap.org/browse/relation/32939/history - large parts of the quite long e-road are gone now, including large chunks of edits outside lithuania. might be worth a headsup to recreate lost data.

Relations are not Collections

I've moved the two paragraphs below out of the main page because of two reasons: 1) such discussions don't belong in the main page, and 2) Relations/Relations are not Categories --Mdeen 07:35, 20 February 2009 (UTC)

All ways that belong to an E-road should be grouped together in a single relation. The int_ref=* tag should not be used anymore. (There are different opinions about that, see discussion)

All e-roads are collected in an extra relation (http://www.openstreetmap.org/browse/relation/20645) (which was deleted by accident (anybody who can undo this?) on 2008-10-18).

• it's been a while since this relation has disappeared, should the issue be escalated ? --Richlv 21:27, 28 November 2008 (UTC)

Tags

I think the E-road relation are tagged in the wrong way. Instead of type=route route=road it should be type=road. Route relations make it look like walking or cycling routes (and in Belgium we have many touristic routes for cars). I really don't like seeing E-roads and these touristic routes in the same category. type=road has also been mentioned several times for pushing road data (like names and references) into relations. --Eimai 13:18, 21 July 2008 (UTC)

"Route relations make it look like walking or cycling routes" - They are like walking or cycling routes - just for cars. The "E 30" is the same for car drivers as the "D 12" (Germany) is for cyclists. A route describes a way from A to B. Using different vehicle doesn't make any difference. -- Eckhart 17:29, 21 July 2008 (UTC)

I disagree here. The E-number is the "name" of the motorway (okay, this may be a different perception in countries that use the national numbers instead, but all road signs over here only have the E-numbers and almost no-one knows their national A-numbers). The E-number will never be seen here as a route here. --Eimai 19:44, 21 July 2008 (UTC)

Route relations are also be used to collect the segments of rail routes, national roads, cycleways, motorways and so on. So the "category" of the relation type "route" is a grouping functionality not restricted to only a specific type. If you want a map with special interest features like hiking trails or cycle routes, why not render them by yourself? There's no reason to restrict the OSM features to "your" interests. --HeikoE 22:03, 21 July 2008 (UTC)

I think you miss my point. I'm not saying I want to restrict route relations to bicycle or walking routes. I'm merely pointing out the semantic difference between the route relations that are in use now for buses, cyclists etc, and the route relations as used on this page. There's plenty of evidence for routes for cars, but these are touristic routes which should use the route relations. But these will eventually give conflicts in the rendering, where we have a international highway tagged with something like "ref=E20", and the touristic route as "ref=CR". I don't want to see these touristic routes rendered on the base maps, that's pointless, but I want to see the E20 on the map, yet the tags would be entirely the same.

So, either find a way to distinguish all your E-road relations from national and local road numbers, and as well from touristic routes which may also appear in local/regional/national/international routes like bicycle or walking routes in some countries. Or use the type=road kind of relations like you would for road names (in which case you would just use int_ref so no ambiguities occur with national road numbers). --Eimai 13:11, 22 July 2008 (UTC)

If you insist on doing the former, then I propose a "network=e-road" tag so it can appear in the proper white on green colours on the map. --Eimai 13:22, 22 July 2008 (UTC)

There is already a not-yet-standardized-upon solution - a relation of type "network", see 20645 20645 -- Eckhart 14:55, 22 July 2008 (UTC)

I think we should use both variants. --TEL0000 17:26, 15 August 2008 (UTC)

Space between E and number

How would one solve the issue of a space in the reference? Over here we don't use spaces like "E19" instead of "E 19". I know it's a small issue, but nevertheless important for not having inconsistencies on the map (so we don't get "E 19" and "A1" next to each other). --Eimai 19:31, 21 July 2008 (UTC)

In the official contract they're listed with spaces. Also on the road signs they're appearing with spaces, so which reason exists not to map the facts? --HeikoE 21:56, 21 July 2008 (UTC)

Well, mostly the fact that there are no spaces on our signs over here, see for example [1], [2] or [3]. So mapping the facts over here would be no spaces in the numbers... --Eimai 12:50, 22 July 2008 (UTC)

don't mix up the layout in signs with it's official name/reference of the route. In Germany for example our motorways als called e.g. "A 8" (longform "BAB 8"), but the sign is layouted without any letter --> --Cbm 15:10, 22 July 2008 (UTC)

Sure, but our government always uses the reference without space in its documents as well, as do all media. I think I can tell that the official usage is without space here in Belgium if all government documents write it like that... --Eimai 15:17, 22 July 2008 (UTC)

I would suggest using the sort of writing which is used in the defining document - and if it is possible (later?) to have a specific national rendering - as far as I see it, in spain the e-roads are written with a dash (i'm not sure) -- Schusch 11:59, 23 July 2008 (UTC)

We should use the official writing with a space for tagging. For rendering of local maps it will be easy to delete the space by a script. --TEL0000 17:31, 15 August 2008 (UTC)

I agree that spaces shouldn't be used. The only country where refs use spaces is Germany, while in all other countries the space is not used. Using a space would lead to inconsistencies in map data and is probably better this way since the space doesn't add any supplemental information and wastes space in all places the map data is stored. Second, I don't think anyone would confuse "Enn" with something else. Also in Romania the tags in the field don't have a space (but sometimes the "E" is a little bit bigger than the number following it), and recently the team decided not to use spaces between the letter and the numbers for all road refs. EddyP 13:01, 30 March 2009 (EET)

Finnish signs use a space in the E-road refs, too, even though people usually write them without the space in other texts. A trailing zero is never used, i.e. the road signs read E 8 and not E 08. One could make a list of the countries or use the int_ref=* the way the local signs do, and leave the relations as they are. Alv 10:18, 30 March 2009 (UTC)

I don't mind the relations, the problem is that this proposal drives people to change the 'int_ref' to contain a space, or worse, remove the existent data in the ref field (local reference) and add the european route number with a space. This proposal must be clarified and modified to be usable and consistent with the present state of facts and data. EddyP 13:31 30 March 2009 (EET)

It was consistent but should now be better with the clarification. Alv 10:44, 30 March 2009 (UTC)

ref and int_ref

I suggest as long as the "ref" and "int_ref" tags are still in use, to have the "int_ref"-tag for the e-roads; otherwise there are conflicts with national references, which are normally tagged as "ref" (Eckhart changed this, I don't want to change it back without some more feedback); when most of the work is done (and the renderer supports this way of tagging), we can delete the int_ref-tags, i think ... -- Schusch 11:59, 23 July 2008 (UTC)

Well, from my POV there's no need to use int_ref at all. Current renderers don't render those relations, future renderers will (hopefully) render them correctly. Unless there's the unlikely case of a render using the relation ref in the wrong way for some time, nobody will ever notice. And the only way the renderer will probably do it wrong is when we don't provide data that exposes the wrong behaviour. -- Eckhart 13:44, 24 July 2008 (UTC)

Who cares if current renders don't render the relations or the int_ref tag? Did we start tagging for renders lately? Keep "Enn" in its designated int_ref tag and leave ref alone. Keeping the ref tag reserved for the local reference is consistent with the name tag usage. Has everyone forgot that int_ref is short for "International reference"? Because of this proposal some "mappers" started to remove the ref information from roads in Romania. Please stop this nonsense! EddyP 13:24 30 March 2009 EET

well ok - my point is more a "historical" point; when i work in osm i (sometimes) find roads tagged "ref=E 40", "reg_ref=L 329" coming across - i usually change this in "int_ref=E 40", "ref=L 329" ... i don't want to start tagging every road that is wrong with the relation which is needed to be correct. Otherwise i would never finish what i wanted to do originally. So for "historical" means it should be mentioned, that up to the time we started using relations the "int_ref" tag was used to tag e-roads. I of course agree that the better solution is using a relation. -- Schusch 15:55, 25 July 2008 (UTC)

I agree that the ref must not be dedicated to the international reference, but it should be reserved for the local reference and int_ref should keep the reference of the European route; the reasoning is that, since in most countries people refer to the roads with their local names, E60, E80 doesn't tell them anything. Second, European routes are simply that - routes - thus some virtual paths, while the national road network designates actual roads. European routes are so long that they offer no practical benefit in most practical cases as opposed to national routes which allow fine grained localization in most cases. EddyP 13:24 30 March 2009 EET

True for the tags on the ways. When tagged on a way, use int_ref=E## and ref=#local number. Come to think of it, would it make sense to use in the relation:

• Some countries use the space: ref=E ## in the relation
• Other countries don't have the space; ref=E## + int_ref=E ## in the relation.
• Where one E-road crosses countries that have different signs (E## or E ##), they are in separate relations. Relations will have a limit on the member count with API 0.6 and the longer E-roads easily max out that limit, anyway.

Otherwise any single E-road is one "entity" and has only one reference... Alv 11:06, 30 March 2009 (UTC)

In Belgium we now have the insane case that ref=E40 has no space (since we use the E-numbers for motorways if they have one, almost no-one knows the national numbers of those roads anymore, so we store the national number as nat_ref=A8), and someone changed all int_refs so they have a space now, like int_ref=E 40, to be consistent with the E-road relation. This is really insane and completely inconsistent.

Furthermore, there really is no UNECE convention to write it with a space, since such a convention isn't documented anywhere. The reference document with the routes for all E-roads surely has them, but that's hardly evidence of a convention. It just shows that in that specific document the writer chose to use a space, for whatever reason (readability in the list?).

Thirdly, I'm not even sure the relation should have an "E" in its reference number, because it's "European road 40" and not "European road E40". --Eimai 12:03, 30 March 2009 (UTC)

On the way ref=* what is and as is on the ground/sign, I don't think there's any disagreement on that... I personally don't see the need for the relations, except where E-roads overlap on some physical road, but they do seem to group together the varyingly (per country) signposted int_refs together - if there is any particular use for that. Alv 13:04, 30 March 2009 (UTC)

I would like to remove int_ref=* from the E-roads in Norway. It is identical to ref=* in this country (no local ref's), so it is a redundant tag.--NKA (talk) 15:52, 22 May 2021 (UTC)

---

This section was moved from the article page:

All ways that belong to an E-road should be grouped together in a single relation. The int_ref=* tag should not be used anymore.

• Should existing int_ref tags be removed from E-roads ? --Richlv 10:29, 17 September 2008 (UTC)
  • Absolutely not, also i think it should NOT be a replacement for the int_ref tag. --Skywave 18:49, 26 October 2008 (UTC)
    • Why not? --TEL0000 23:53, 30 November 2008 (UTC)

Sometimes relations are damaged or deleted. Currently the available tools doesn't provide a convenient method to restore a relation (like Potlatch does with standard objects). Therefore, to prevent loss of information, it may be useful to have redundancy. Also there are no conflicts with other tags, so the usage of int_ref=* doesn't hurt. --HeikoE 12:46, 12 December 2008 (UTC)

IMO, the correct way to tag these are to use int_ref on the way (if there is a concurrency, reference routes should be preferred to primary routes, and primary to secondary), and add the way to a relation for all E-roads that it carries. Exceptions would be where the reference shown on the signs is an E-road (as is the case in Belgium and Sweden), where it goes in the ref field. Chriscf 12:54, 12 December 2008 (UTC)

E 70 deleted, how to get it back?

the relation for the E 70 was deleted [4] see, how to get it back? The history seems not to be viewable [5] (at least for me) -- Schusch 10:59, 27 October 2008 (UTC)

I have been contacted by a couple of you asking why I deleted the E70 relation.

That was the first time I heard of it: I did not delete that: I am not at ease with relations and I try to be very cautious not to delete or modify any existing one. I cannot view its history [6], so I can think about something malfunctioning, but I really don't know.

Of course I may have done something wrong, totally unconsciously: if that was the case (but it seems strange to me) I apologize with all those who spent time and efforts in creating that relation.

Anyway, I will gladly help to restore it, if somebody knows and tells me how.

that was Feder 12:23, 27 October 2008

Hi - mistakes happen, that shouldn't be a problem ... I asked just in case if there was a reason; I also don't know how to restore the relation ... so let's hope somebody repairs it -- Schusch 19:44, 27 October 2008 (UTC)

I asked Frederik Ramm, and he restored it. Thanks for that! --TEL0000 05:03, 18 November 2008 (UTC)

e-road relation deleted, why?

mikes deleted the International E-road network relation [[7]] in which all E-roads were collected. Any reason? I can't find one. Isn't this relation usefull for example to download all E-roads from the server? -- Schusch 10:42, 27 October 2008 (UTC)

I did not intentionally delete this relation.

At the same time the E-road relation was deleted I was also listed to have the E45 relation deleted. As a third relation E70 seems to be deleted unintentionally, too, s.o. with a better understanding of the relations, the db and the API should have a closer look at.

Regarding the E45 I asked Frederik Ramm from Geofabrik to restore the relation and he did it.

mikes 17:32, 27 October 2008 (UTC)

whatever happened (mistakes shouldn't be a problem in a wiki) ... let's hope somebody repairs it -- Schusch 19:44, 27 October 2008 (UTC)

This releation is not useful. If you want to download all E-Roads from the server then you can use something like OSMXAPI to download all roads that have certain tags, and/or lie in a certain area. It is not necessary to think about each and every query that someone might one day have ("all churches in Germany beginning with the letter A") and then create relation for that. PLEASE don't. Relations are there to create a (close and usually local) connection between obejcts. Relations are not buckets into which you collect whatever you think belongs remotely together. --Frederik Ramm 22:41, 14 November 2008 (UTC)

I did realise a similar relation like that for the german motorways ... it seemed to be useful for me, but if one can get the information without another relation then it's ok, i don't insist on the relation; greetings -- Schusch 23:27, 21 November 2008 (UTC)

The relation is useful because you must know to which network this road belongs. If there is no such relation, how can anyone get all e-road-relations? If we really must not use the network-relation, then we must use a network tag in each relation. (network=e-road) --TEL0000 00:54, 1 December 2008 (UTC)

One useful point of this relation is to be able to have some settings which are valid for all E-roads: the name of the network in different languages, how to create a correct sign for the roads and probably there are more things. What's the difference between a network of special european roads and the different lines of a subway in a city? I think relations describe the relation between several objects, no matter what objects they are. --MasterMG 20:39, 1 December 2008 (UTC)

Exactly! --TEL0000 17:26, 8 December 2008 (UTC)

A relevant point to this discussion is here: Relations/Relations are not Categories Chriscf 12:58, 12 December 2008 (UTC)

country column

what about adding another column to these tables that would list countries the particular e road crosses ?

it would be quite useful, for example, if somebody would like to quickly skim over e roads crossing ones country that might not be completed in that area.

while it would somewhat clutter the tables, i think there's some usefulness to be extracted. --Richlv 20:01, 29 December 2008 (UTC)

Does the E 32 exist?

As per the comments at wikipedia, does E 32 exist? It's completely within the UK, and therefore no signs will exist for it.

If it does exist, then it follows the A120 from the A12 to Harwich. (unsigned: 14:34, 9 February 2009 User:EdLoach)

If it's in the definitive document, then we should probably conclude that it at least exists on paper. I have no specific opinion either way as to whether or not we map it, as there are convincing arguments on both sides (we know it's there vs. it's not on the ground). Chriscf 19:13, 11 February 2009 (UTC)

Does the E 02 exist?

On wikipedia there is a mention of E 02 running Galway - Middleton-in-Teesdale - Oxford - Cambridge - Harwich - Oostende - Zoersel - Hoek van Holland - Bergen op Zoom - Nice, or alternatively Galway - Middleton-in-Teesdale - Oxford - Dover - Calais - Paris - Lyon - Nice. There is no mention of E 02 in the UNECE document. I have never noticed the E 02 signs that would be on the Dutch A16/A17 (the very few times I've been there) and I also see no mention of the E 02 on maps.

Does it exist?

No. It's one of the "European long-distance walking routes". Chriscf 15:50, 13 February 2009 (UTC)

I see the wiki page has been editted too. Glad to get this mixup out the world. --Mdeen 07:34, 16 February 2009 (UTC)

The E 15 relation got deleted

The relation 48044 E15 has been deleted by user Skywave Sat Mar 14 16:14:15 +0000 2009. Can some one restore the old data? Thanks --Thomas1950 07:04, 15 March 2009 (UTC)

The E 45 relation got deleted

The relation 20773 E45 has been deleted by user polderrunner Tue Apr 28 18:23:51 UTC 2009 2009. Can some one restore the old data? Thanks --Thomas1950 23:04, 15 May 2009 (UTC) The relation 20773 E45 has been restored by polderrunner Many Thanks --Thomas1950 18:28, 22 May 2009 (UTC)

stamväg tag used in relations

for example, e22 has a tag : stamväg = yes

why is such a tag added, is that appropriate ? looks like a recipe for tag count explosion...

int_ref and not relation

I noticed that many ways have appropriate int_ref key but they are not added to appropriate relation. Would it be possible to add automatically ways with int_ref and without relation to relation ? --Jkjk 03:41, 22 January 2010 (UTC)

You can use a xapi query: http://www.informationfreeway.org/api/0.6/*%5bint_ref=E%2010%5d (currently seems to be down) --NE2 21:51, 8 March 2010 (UTC)

order of the members

Every entry in the E-road list has a link to OSM Relation Analyzer. This tool shows lots of gaps especially in places where separate carriageways joins single carriageway. Talk:Relation:route#Order_of_members even suggest to have two relations--one forward, another backwards. Therefore question--what is correct order for E-road members? Monas 06:03, 25 July 2010 (UTC)

I can't offer more than general guidance, being an American, but order makes no difference to any applications such as the analyzer. I don't know of any analyzers that will deal with forward/backward roles (there's one that will handle the east/west and north/south roles that US road relations use, but that doesn't help). --NE2 08:11, 25 July 2010 (UTC)

size of relations

May I modestly link to Relation:route#Size where I wrote down common mapping practice.
I started to work on splitting up E 80 into pieces one can work with. Loading the complete relation E 80 (5.1k members remaining) lasts atm around one hour or more. I encourage to split up the other relations as well -- malenki 21:44, 30 January 2012 (UTC)

Is it good to split a route (one for both way)?

I was wondering how to tag a route with different path depending of the direction you go. For instance E87 is not clear to me, so I am having a look. I was wondering if it's correct or suitable to split it into a "E87 northbound" and "E87 southbound". For instance here Fabyen11:39, 9 May 2013 (UTC)

E 73 duplicated?

I think the E 73 relation has been duplicated. Original: http://www.openstreetmap.org/relation/38373 Duplicated one: http://www.openstreetmap.org/relation/3163863 AndreasTUHU

No leading 0 in single digit routes

Please stop using the leading 0 in singel digit routes. There is no such thing. They are signed without it. Some maps list both ref and int_ref and causing a hot mess in contries where ref = int_ref. --Gazer75 (talk) 17:32, 12 September 2020 (UTC)

I agree. It causes some app's to to display both E6 and E06 on the same road (for example MagicEarth).--NKA (talk) 15:54, 22 May 2021 (UTC)

Delete E relations in Norway

I would like to delete the E-road relations in Norway. They are broken beyond repair and have not served any purpose for the past few years. It is very easy to extract all the E-roads in Norway through Overpass by using the ref tag (all E-roads in the country have E ref's, no local ref's).--NKA (talk) 15:58, 22 May 2021 (UTC)

General Relation deleted

Why has the Relation has been deleted that includes all the Sub Relations of the E-road network?? 7884303. On the Wikidata there has even been set an end date to the OSM relation: https://www.wikidata.org/wiki/Q106123