Dear ORM community,
the Dutch rail infrastructure provider ProRail has a lot of data available in the public domain, which makes the Dutch situation quite different than the German one (I heard DB-netz is not very willing to share data). To make use of the data I'm working on quite a large import proposal: named the ProRail import. As described at the wiki-link, it will be done in several slices: one per object category (e.g. platforms, signals, turnouts). I will inform this mailing list about each slice, before proposing it to the imports mailing list.
The first slice is on milestones. The milestone import already has it's own wiki section within the ProRail import wiki. You can read all import details there. The tagging, however, is very important to ORM. This because the milestone placement in the ProRail database is quite in another way than is described in the ORM tagging scheme. Quote: ''They should be entered as nodes on the tracks themselves. If the railway line has more than one track, it should be entered on each track.'' I personally object to such an approach, because it neither encompasses the theoretical nor practical situation. The theoretical situation is placement of milestones directly on the reference ribbon, along the centre of a railway line. The practical situation, however, is placement of signs perpendicular from the reference ribbon (note that this can create other signs intervals than described on the signs).
Railway companies mostly use the reference ribbons in their maps and systems, because those values are more precise. I would propose to make mapping of the theoretical and practical locations of milestones possible, by allowing these systems on the wiki. Importing the Dutch milestones automatically would be impossible without such permission.
Your thoughts on the milestone import and milestone locations are highly appreciated. Thank you in advance.
Best regards, Jeroen
The milestone import already has it's own wiki section within the ProRail import wiki.
Which is here: http://wiki.openstreetmap.org/wiki/ProRail_import
Your thoughts on the milestone import and milestone locations are highly appreciated. Thank you in advance.
Well, you could start with one or 2 railways that are single track anyway, so you could iron out problems that could come up at greater style imports. Since you need to hand-check for already existing data and merge those nodes back into the tracks this will need a lot of steps anyway I guess.
Don't forget to run this on a dedicated account and document everything on the wiki (source of the data, license, whatever). I personally would entirely leave out the "do not touch" or "source" comment and just attach that to the changeset comment.
Those locations should also have a dot as decimal separator, you had a komma in your Excel sheet. It's already with a dot in the wiki.
Eike
The milestone import already has it's own wiki section within the ProRail import wiki. Which is here: http://wiki.openstreetmap.org/wiki/ProRail_import%C2%A0 I used links in my e-mail. It seems they didn't reach you? Well, you could start with one or 2 railways that are single track anyway, so you could iron out problems that could come up at greater style imports. I have checked the data in QGIS, for both irregularities and behaviour at railway hubs. I did not find any problems during that check. That doesn't get rid of all possible errors, but I prefer fixing some leftover errors later, than delaying this and other imports by doing everything in pieces or manually. Moreover, the previous time I did this import (described on the wiki) I didn't encounter any problems (apart from not being aware of the import guidelines). Concluding: doing this import in one single edit makes it really easy to revert, which allows getting rid of errors. Since you need to hand-check for already existing data and merge those nodes back into the tracks this will need a lot of steps anyway I guess. I don't think it's necessary; as described on the wiki, I used http://overpass-turbo.eu/%C2%A0in order to create http://wiki.openstreetmap.org/wiki/File:Milestone_overpass.PNG%C2%A0It shows quite clear that there are only two railway milestones in the entire Netherlands. I will handle those with care. Don't forget to run this on a dedicated account Why would I run this on a dedicated account? and document everything on the wiki (source of the data, license, whatever). Everything is, in my perception, documented on the wiki (as far as possible at this moment). I will update the wiki on any progress. I personally would entirely leave out the "do not touch" or "source" comment and just attach that to the changeset comment. As also described on the wiki and in the mail discussion in the imports mailing list, I abolished the idea of any comments. It's just source=ProRail and source:ProRail=Railmaps / source:ProRail=OpenOV now. Those locations should also have a dot as decimal separator, you had a komma in your Excel sheet. It's already with a dot in the wiki. I had a comma in my Excel sheet because the ProRail data uses commas aswell. The wiki contains the final output (the import) in accordance with tagging schemes. Would you happen to have a suggestion to convert the commas to dots? I tried some commands in QGIS, but didn't find a solution yet.
What would be your opinion on the node placement? Can I just import the nodes on the reference ribbon, or are you in favor of nodes per railway track?
Am Sonntag 12 April 2015, 18:00:36 schrieb JJJ Wegdam:
The milestone import already has it's own wiki section within the ProRail import wiki.
Which is here: http://wiki.openstreetmap.org/wiki/ProRail_import
I used links in my e-mail. It seems they didn't reach you?
No, because your mail program miserably fails producing proper text/plain parts of your HTML mails. It strips the links and the quoting is horrible.
Don't forget to run this on a dedicated account
Why would I run this on a dedicated account?
Because it makes things much easier to be traced. You can set up a description page for that user and it will clearly tell what you are doing automatically and from where. And if you screw up the import your personal account will likely not be the one that get's blocked ;)
What would be your opinion on the node placement? Can I just import the nodes on the reference ribbon, or are you in favor of nodes per railway track?
I tend to follow the "put it on the track" people, but I'm not really a railway man, just someone who sees some easy stuff to map in some areas I'm interested in. So my feedback will more be on "how", less on "what".
Eike
Good evening Eike,
thanks for the information on running a dedicated account. I'll make use of it. Also I'll keep in mind that iCloud apparently doesn't produce emails like I hoped.
Kind regards, Jeroen
Hi guys,
could we please get to a conclusion regarding the milestone import? I answered all your questions, so I'd like to know wether you are convinced by these answers. Thank you in advance for your input.
Kind regards, Jeroen
Hi Jeroen,
On So, 2015-04-26 at 20:34 +0200, JJJ Wegdam wrote:
Hi guys,
could we please get to a conclusion regarding the milestone import? I answered all your questions, so I'd like to know wether you are convinced by these answers. Thank you in advance for your input.
we would prefer to import the milestones as part of the tracks. That is just possible manually, not automatically.
A solution that Michael and I would prefer is to set up a WMS [1], so that mappers can add a background layer into JOSM and trace the data. If you do not know how to do that, we can help you. Just give us the raw data.
Regards Alex
Hi all,
i'd also prefer the import as WMS, and Alex & Michael would support you, so it should be fine.
On the other hand, we discuss about only a milestone import? So it may be an alternative to import the milestones as /new nodes /with /unusual tags/, e.g. import:milestone=*, import:milestone:position?
Regards Christian
Am 28.04.2015 um 01:11 schrieb Alexander Matheisen:
Hi Jeroen,
On So, 2015-04-26 at 20:34 +0200, JJJ Wegdam wrote:
Hi guys,
could we please get to a conclusion regarding the milestone import? I answered all your questions, so I'd like to know wether you are convinced by these answers. Thank you in advance for your input.
we would prefer to import the milestones as part of the tracks. That is just possible manually, not automatically.
A solution that Michael and I would prefer is to set up a WMS [1], so that mappers can add a background layer into JOSM and trace the data. If you do not know how to do that, we can help you. Just give us the raw data.
Regards Alex
[1] https://wiki.openstreetmap.org/wiki/WMS
Openrailwaymap mailing list Openrailwaymap@openrailwaymap.org http://lists.openrailwaymap.org/lists/listinfo/openrailwaymap
On Di, 2015-04-28 at 20:32 +0200, Christian Wendel wrote:
Hi all,
i'd also prefer the import as WMS, and Alex & Michael would support you, so it should be fine.
On the other hand, we discuss about only a milestone import? So it may be an alternative to import the milestones as /new nodes /with /unusual tags/, e.g. import:milestone=*, import:milestone:position?
there is the risk that nobody will correct the imported data. See TIGER data in USA, where most of the data was not fixed even after years.
Regards Alex
Hi Jeroen,
On So, 2015-04-12 at 15:46 +0000, JJJ Wegdam wrote:
The first slice is on milestones. The milestone import already has it's own wiki section within the ProRail import wiki. You can read all import details there. The tagging, however, is very important to ORM. This because the milestone placement in the ProRail database is quite in another way than is described in the ORM tagging scheme. Quote: ''They should be entered as nodes on the tracks themselves. If the railway line has more than one track, it should be entered on each track.'' I personally object to such an approach, because it neither encompasses the theoretical nor practical situation. The theoretical situation is placement of milestones directly on the reference ribbon, along the centre of a railway line. The practical situation, however, is placement of signs perpendicular from the reference ribbon (note that this can create other signs intervals than described on the signs).
Railway companies mostly use the reference ribbons in their maps and systems, because those values are more precise. I would propose to make mapping of the theoretical and practical locations of milestones possible, by allowing these systems on the wiki. Importing the Dutch milestones automatically would be impossible without such permission.
mapping the milestones as nodes that are part of the tracks has some advantages:
* in bigger stations with some parallel railroad lines it would be difficult for mappers to see which milestone belongs to which track; for software it is also nearly impossible to identify which milestone belongs to which track, especially if there is no additional information such as track numbers
* for routing purposes (e.g. generating a speed profile with the positions of speed limit changes), I would prefer to have such data as a part of the tracks; if the milestones would be mapped as separate nodes, preprocessing is necessary to "project" the milestones on the tracks
So I would prefer to import the milestones as part of the tracks. I agree, that this is not possible as an automatically import. But maybe we could map them manually and start a mapping campaign. This topic is easy even for non-railway mappers, so there are many mappers that could help us. People trace thousands of buildings in Haiti within some days, so why not adding thousands of milestones in the Netherlands? ;)
Any other ideas?
Regards Alex
Hi Jeroen,
Am 2015-04-13 um 17:39 schrieb Alexander Matheisen:
So I would prefer to import the milestones as part of the tracks. I agree, that this is not possible as an automatically import. But maybe we could map them manually and start a mapping campaign. This topic is easy even for non-railway mappers, so there are many mappers that could help us. People trace thousands of buildings in Haiti within some days, so why not adding thousands of milestones in the Netherlands? ;)
I agree Alex. Sharing the work will speed up it because this import can only be done manually.
The import has to be done manually because tracks might have an offset at OSM due to a Bing offset and milestones are not mapped on siding, yard and spur tracks.
You should split up the data in smaller pieces or create a WMS which serves it. You already have a shapefile, lots of WMS servers/their database backend have an hapefile import.
Best regards
Michael
Hello Michael,
I agree Alex. Sharing the work will speed up it because this import can only be done manually.
Like I wrote to Alex: can you agree with using the automated import as intermediate phase?
The import has to be done manually because tracks might have an offset at OSM due to a Bing offset and milestones are not mapped on siding, yard and spur tracks.
I checked this at the first try of this import and it didn't cause noticable troubles. The only case I found is a new railway tunnel which was put into service very recently; it replaces the former parallel track on ground level. The reference ribbon is still at the former track at this location. I will handle this section manually and check ProRail's logs for recent geometry changes.
You should split up the data in smaller pieces or create a WMS which serves it. You already have a shapefile, lots of WMS servers/their database backend have an hapefile import.
I'm not familiar with WMS. Do you happen to have a screenshot? Thank you for the suggestion by the way.
Best regards, Jeroen
Hello everyone,
does anyone object the following plan?
1. Import the milestones automatically at their current database location 2. Set up a mapping project/request to re-locate the milestones
The advantage is that we have data available for the entire Netherlands until the milestones are mapped at their final location.
Kind regards, Jeroen
Op 14 apr. 2015 om 02:19 heeft JJJ Wegdam jwegdam@me.com het volgende geschreven:
Hello Michael,
I agree Alex. Sharing the work will speed up it because this import can only be done manually.
Like I wrote to Alex: can you agree with using the automated import as intermediate phase?
The import has to be done manually because tracks might have an offset at OSM due to a Bing offset and milestones are not mapped on siding, yard and spur tracks.
I checked this at the first try of this import and it didn't cause noticable troubles. The only case I found is a new railway tunnel which was put into service very recently; it replaces the former parallel track on ground level. The reference ribbon is still at the former track at this location. I will handle this section manually and check ProRail's logs for recent geometry changes.
You should split up the data in smaller pieces or create a WMS which serves it. You already have a shapefile, lots of WMS servers/their database backend have an hapefile import.
I'm not familiar with WMS. Do you happen to have a screenshot? Thank you for the suggestion by the way.
Best regards, Jeroen _______________________________________________ Openrailwaymap mailing list Openrailwaymap@openrailwaymap.org http://lists.openrailwaymap.org/lists/listinfo/openrailwaymap
Hi Jereon,
2015-04-18 00:25 JJJ Wegdam wrote:
does anyone object the following plan?
- Import the milestones automatically at their current database location
- Set up a mapping project/request to re-locate the milestones
The advantage is that we have data available for the entire Netherlands until the milestones are mapped at their final location.
That looks like an advantage but it is a big disadvantage. It is never a good idea to import data into OSM and let the community fix it. Just have a look at all these TIGER data garbage (stevea as railway mapper could teach you a lesson – he is fixing all these data in California). The TIGER import imported road data of a low quality over the whole US. Up to now about 95 % (rough estimation) has not been fixed. The import took place about 6 to 8 years ago! There are several other imports which did the same – their data has not been fixed yet.
Shortly, if you propose an import at Imports list as you are doing here now, your proposal will definitely fail.
2015-04-14 01:47 JJJ Wegdam wrote:
Milestone systems and signal locations are used for many purposes, like defining and finding maintenance or research locations, but also capacity-calculation. Especially the milestones; I simply know that ProRail employees would greatly appreciate a milestone map that works well at their mobile phone. Railmaps does not and ORM does. I promised them to make this work as soon as I could. This is also why I tried the milestone import before.
If people are interested in having milestons in OSM why don't you ask them to help them tracing from an WMS layer. You can set up a WMS service using a database like PostGIS + a server like Mapserver or Geoserver. I will try to set up such a service (it's not much data, i.e. it does not need a powerful server) at my private server but you might have to wait a few days.
People who add data often stay at OSM as contributors and will keep the data up to date if the reality changes.
Best regards
Michael
PS It makes your mails more readable if you add a empty line between a inline quote and your answer (like this mail). :-)
Good evening Alex,
mapping the milestones as nodes that are part of the tracks has some advantages:
Thank you for explaining the reason for the current tagging scheme.
- in bigger stations with some parallel railroad lines it would be
difficult for mappers to see which milestone belongs to which track;
I disagree; reference ribbons never run parallel (in the Netherlands at least). Therefore even the biggest stations can be mapped without any problems (just by placing a line perpendicular to the ribbon). Also at parting tracks, it is in my opinion very clear what ribbon belongs to a certain track (as shown in the image in my original message).
for software it is also nearly impossible to identify which milestone belongs to which track, especially if there is no additional information such as track numbers
This is indeed true.
- for routing purposes (e.g. generating a speed profile with the
positions of speed limit changes), I would prefer to have such data as a part of the tracks; if the milestones would be mapped as separate nodes, preprocessing is necessary to "project" the milestones on the tracks
I really didn't realize that OSM could be used for generating speed profiles. Of course it's a logic effect of such data, but I didn't think of it. I agree that less preprocessing is better, but I also think that preprocessing is still better than having no data to process at all. I possess the traction curves of Dutch train sets, in case anyone needs those.
So I would prefer to import the milestones as part of the tracks. I agree, that this is not possible as an automatically import.
I would still propose to import the milestones at their respective locations automatically. We could consider that as a intermediate phase before placing the milestones directly on the track. I strongly prefer making use of this opportunity to cover the entire Netherlands in a day. The automatically imported nodes could then serve as reference for mapping the milestones per track. Removing the automatically imported nodes isn't very hard; could even be done automatically with xapi.
But maybe we could map them manually and start a mapping campaign. This topic is easy even for non-railway mappers, so there are many mappers that could help us.
We could indeed try this.
People trace thousands of buildings in Haiti within some days, so why not adding thousands of milestones in the Netherlands? ;)
Do note that mappers only map stuff which they consider important. Mapping Haiti was very important after the disaster there. I consider placement of Dutch railway milestones as something which most mappers will give a low priority.
My arguments may sound a bit less constructive than I intend them to be. If they do: my apologies. I'd state again that I really appreciate the input of you guys. I simply consider milestones and signal locations as very high priority and could therefore sound quite persistent at automatically importing some data as soon as possible. Milestone systems and signal locations are used for many purposes, like defining and finding maintenance or research locations, but also capacity-calculation. Especially the milestones; I simply know that ProRail employees would greatly appreciate a milestone map that works well at their mobile phone. Railmaps does not and ORM does. I promised them to make this work as soon as I could. This is also why I tried the milestone import before.
Best regards, Jeroen
openrailwaymap@openrailwaymap.org