<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Good evening Alex,<div><br></div><div><blockquote type="cite"><div><span>mapping the milestones as nodes that are part of the tracks has some</span><br><span>advantages:</span><br></div></blockquote><div>Thank you for explaining the reason for the current tagging scheme.</div><blockquote type="cite"><div><span></span><span>* in bigger stations with some parallel railroad lines it would be</span><br><span>difficult for mappers to see which milestone belongs to which track; </span></div></blockquote>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).<br><blockquote type="cite"><div><span>for </span><span>software it is also nearly impossible to identify which milestone</span><br><span>belongs to which track, especially if there is no additional information</span><br><span>such as track numbers</span></div></blockquote>This is indeed true.<br><blockquote type="cite"><div><span>* for routing purposes (e.g. generating a speed profile with the</span><br><span>positions of speed limit changes), I would prefer to have such data as a</span><br><span>part of the tracks; if the milestones would be mapped as separate nodes,</span><br><span>preprocessing is necessary to "project" the milestones on the tracks</span><br></div></blockquote>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.<br><blockquote type="cite"><div><span>So I would prefer to import the milestones as part of the tracks. I</span><br><span>agree, that this is not possible as an automatically import. </span></div></blockquote>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.</div><div>I <u>strongly prefer</u> making use of this opportunity to cover the entire Netherlands in a day.</div><div>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.<br><blockquote type="cite"><div><span>But maybe </span><span>we could map them manually and start a mapping campaign. This topic is </span><span>easy even for non-railway mappers, so there are many mappers that could</span><br><span>help us. </span></div></blockquote>We could indeed try this.<br><blockquote type="cite"><div><span>People trace thousands of buildings in Haiti within some days, </span><span>so why not adding thousands of milestones in the Netherlands? ;)</span><br></div></blockquote>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.</div><div><br></div><div>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. </div><div>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.</div><div>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.</div><div><br></div><div>Best regards,</div><div>Jeroen</div></body></html>