ich stolpere immer wieder über Bogenweichen, von denen im bisherigen
Taggingschema nur die symmetrischen Außenbogenweichen berücksichtigt
Ich würde gerne das Tagging dafür durch folgendes erweitern:
1.) railway:switch=wye eigentlich für alle Außenbogenweichen, da der
genaue Radius eh nicht ermittelbar sein wird (und optisch geht es halt
eh beides nach außen)
2.) railway:switch=inner_curved oder curved für Innenbogenweichen, die
bisher bei den einfachen Weichen mit drinstanden.
Natürlich gibt es das Problem, dass eigentlich alle
railway:switch=default überprüft werden müssten, ob sie nicht
Innenbogenweichen sind, aber schadet wohl auch nicht. Die Definition
muss ja nicht sofort geändert werden, es wäre ja lediglich eine genauere
Gibt es da irgendwelche Meinungen oder Bedenken? Sonst würd ich das
(demnächst) mal mit auf die ORM-Tagging-Seite übernehmen.
In the UK we have a number of locations which are permanently wired with overhead line, but the wires are permanently earthed. This is typically done where the OCL is out of use in depots (for safety), to pass OCL through a very low bridge where electrical clearances cannot be provided, or at the limit of an electrified line.
Has this been dealt with before? I would propose the following approach:
One of the issues that we've faced in improving the electrification tagging in the UK is dual electrified tracks. At some locations in the UK - and I believe in most countries - different electrification systems meet and overlap, with an overhead contact system and a ground-level contact system co-existing on a single track for a short distance. We have around 10 of these locations in the UK, some with multiple tracks.
There is currently no guidance given to taggers on how to treat these tracks AFAIK. Has anyone already looked at this? We were thinking to use the standard OSM key=<value1;value2> syntax to identify these tracks. As an example, a single track provided with both 25kV 50Hz AC overhead line and 750V DC third rail would be tagged as follows:
Hello all again.
I have a query about acceptable convention for tagging a proposed railway, i.e. one that is tagged railway=proposed
If the electrification system that this new railway will adopt is known, it is normal/acceptable to add electrification tags? The obvious example here in the UK is HS2, which is going to be 25kV 50Hz AC overhead line as a matter of public record. Should we tag that as electrified=contact_line/voltage=25000/frequency=50?
I'm a railway electrification engineer working in the UK, and a small group of us are planning to produce an electrification-focused map of the UK rail network using OSM data. We are aware of your ongoing project, and it is clear from chat on your github that you have plans to add an electrification view at some point. I wanted to introduce us and let you know that we exist; and to let you know that we are not intending to compete with your much bigger project, but rather produce something fairly quickly to inform the ongoing debate about decarbonisation and further electrification in the UK.
We are also thinking about how we represent a couple of electrification features that we have in the UK that the existing tag scheme does not support, and wondered if we could collaborate on that aspect.
I'm trying to figure out another North American tag interpretation, to keep
us consistent with everyone else.
For most North American railroads, operating sites like junctions, siding
ends, and crossovers (really, all Control Points) are referred to by name
and milepost (and milepost here is most often alphanumeric, example "LP
1.9" for a site named "Colley Avenue"). We've been discussing internally
how to tag these this week, and realized we probably need a better
international interpretation to help us stay consistent.
My initial thought a week ago was that this would probably be
railway:position. However, that tag isn't included by default in the
tagging scheme for these types of operating sites, and based on how it's
used, others have pointed out to me that this is probably a better fit for
railway:ref for these sites. I tend to agree.
For a good, quick typical view of how these are used, see here for a page
out of an employee timetable (which is really the reference book for the
subdivision), page 4 (PDF page 8) where the above example was taken:
So far in North America, railway:ref is only being used for the
three-letter codes for passenger stations, which is a very clear correct
use. Using that tag for the many, many control point operating sites we
have would very much be a different use to what's already done, so I'd want
to verify that it's correct and intended before actually implementing it.
After all, if we stuck with railroad:position for this, it would leave
railroad:ref an "uncluttered" tag for passenger stations, which do
represent its most important use.
What is the sense of the wider community here on how this was meant to work?
A large part of the reason I've been bringing so many of these NA-specific
questions to the list over the past week and a half is that we've been
starting to work up a simplified NA-specific JOSM tagging preset. Anything
I include as an implicit tag interpretation is going to potentially get
repeated over the map quite a bit, so I'm trying to be *really* careful
about making sure my understanding of the tags built into the preset tools
is correct, so they will be correctly applied.
Thanks for your help and input,
We started a discussion this week on the OSM Talk-US list, because we're
looking to create a tag to store the operator's short form designation
(Reporting Marks system in Canada, Mexico, and the US). Most rail maps
generated in the US use the reporting marks for route operator labeling
rather than the operator name, and this reporting mark is also used in the
US federal GIS database as the primary operator designator, so it has
authoritative backing for use.
One of our international readers suggested that rather than using a
NA-specific tag like reporting_mark, we use something more broadly
applicable like operator_identifier. I agree that's a great idea, but
wanted input from the wider OpenRailwayMap community on what that tag
should be before we implement something. Does "operator_identifier" make
clear sense to you as a holder for an official short-form (initials or
alphanumeric) designator for an operator, if such a short form is used for
a particular railroad? Is there something else that might convey the idea
even more clearly? For our part, it's very easy to add a line in the North
American tagging wiki to make clear that whatever name we select for the
tag, it is to be the Reporting Marks for railroads in our part of the world.
---------- Forwarded message ---------
From: Chuck Sanders <nathhad(a)gmail.com>
Date: Fri, Jun 5, 2020 at 12:17 PM
Subject: Re: [Talk-us] Rail tagging in US (and North America): operator=*
Actually, that makes complete sense to me too. It would be very easy to
use "operator_identifier", and simply clarify in the North America tagging
wiki that the appropriate value is the primary reporting mark for Canada,
US, and Mexico lines. I see no reason that wouldn't serve exactly the same
use we were proposing, but be more widely applicable outside NA.
This may be a good topic to foward to the OpenRailwayMap list for input too
- I'll do that now, thanks!
On Fri, Jun 5, 2020 at 12:07 PM Volker Schmidt <voschix(a)gmail.com> wrote:
> so you are saying you use something which is part of of rolling stock
> identifier in a way for which it was not invented, but which is handy.
> From an OSM point of view, I would prefer a neutral tag (something like
> "operator_idenitfier") which in the US corresponds to the first part of the
> reporting mark of the carriages of that operator.
> And say in Germany it would be a different thing, but still a way of
> identifying line operators.
> This would give us a uniform approach.
> (I know that this is in theory irrelevant as OSM keys and values are
> codes, which in most cases are British English terms that make it easier to
> memorise them)
> On Fri, 5 Jun 2020 at 16:56, Chuck Sanders <nathhad(a)gmail.com> wrote:
>> The original use of Reporting Marks in NA is for rolling stock
>> identification, yes. However, it's also the only common, reliable, and
>> consistent short form abbreviation for operators. It's widely used that
>> way in both the railroad industry here and among the industry-connected
>> portions of the public. So, not an official defined use of the mark, but
>> so common in use that it is effectively industry standard here. For
>> example, the FRA, the official US government agency in control of railway
>> regulations, exclusively uses the reporting marks (and not full operator
>> name) for identification of ways and routes in their GIS database (
>> https://fragis.fra.dot.gov/GISFRASafety/ which is OSM-compatible and
>> already being used as a reference in the US). Hence, we have an official
>> and authoritative source for which reporting mark is "primary" for each
>> company, and most appropriate to use - and it's already used as the
>> operator identification in the government map.
>> All larger railroads do own (and often use) multiple different reporting
>> marks for their equipment, but all also have a single, best known,
>> "primary" reporting mark by which it will be commonly known, so this
>> proposal is effective even for lines with multiple registered marks
>> (especially with the help of the FRA map to clarify any inconsistencies).
>> On Fri, Jun 5, 2020 at 9:35 AM Volker Schmidt <voschix(a)gmail.com> wrote:
>>> Question on the term "reporting_mark"
>>> Wikipedia defines "reporting_mark" as "code used to identify owners or
>>> lessees of rolling stock <https://en.wikipedia.org/wiki/Rolling_stock>
>>> and other equipment" and describes such codes alo in other parts of the
>>> In your discussion you seem to refer to railway lines or routes and not
>>> to rolling stock.
>>> What kind objects in OSM will carry the tag reporting_mark=* ?
>>> Talk-us mailing list
Dear ORM community,
As far as I know, the signalling layer renders train protection absence as soon as a way contains railway:pzb=no and railway:lzb=no. I implemented this throughout over 10 European countries. A user from Belgium is now complaining about this. He argues that Belgium doesn't have the PZB nor the LZB system anywhere in the country and that thus these tags should not be in the country. Could you please provide your thoughts on this complaint? You can contribute to the discussion at https://www.openstreetmap.org/changeset/85628039#map=13/50.8173/4.3336 or reply to this email.