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? 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/ in order to create http://wiki.openstreetmap.org/wiki/File:Milestone_overpass.PNG It 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: 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: 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: 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 -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten ausgenommen) I prefer GPG encryption of emails. (does not apply on mailing lists)

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

Good evening Alex, Thank you for explaining the reason for the current tagging scheme. 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). This is indeed true. 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. 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. We could indeed try this. 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