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?

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 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

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,

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 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

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