This mailing list has been migrated to Mailman 3. This archive will no longer be updated. Messages after 1 February 2020 are missing. Please use the new archive instead.
Diese Mailingliste wurde auf Mailman 3 umgestellt. Dieses Archiv wird nicht mehr länger aktualisiert. Nachrichten nach dem 1. Februar 2020 fehlen. Bitte benutze das neue Archiv.
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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openrailwaymap.org/archives/openrailwaymap/attachments/20150414/80d9a9d8/attachment.html>