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 Michael, 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. personally, I regard this differently; why would we only accept a final form of data, while we are currently not having any Dutch milestone data at all? To illustrate this: OSM is actually based on importing data which was afterwards improved. As an example: in the Netherlands all meadows and residential areas for example have been imported by AND. These were welcomed as a country-wide basis because there wasn't any data on this subject at all by then. Nowadays, we are still improving and detailling that data through Bing and other sources. Imagine the other method: not accepting any meadow imports for example and ask all mappers to map meadows according to Bing. That would take years, while still having blank spots. A nice example of such a contradiction can be found at the border of the Netherlands with Nordrhein-Westfalen: http://www.openstreetmap.org/#map=11/52.2635/7.1727. 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. A nice example of a big bad import indeed. I think it is not justified to compare such a poor and large import with my current proposal though: A few weeks ago, I attended a guest lecture on mapping ProRail's infrastructure. Fugro explained how they did it with a standard deviation of 15 mm's. That very data is the source for my import proposal, which makes my import data somewhat 500 times more precise than the TIGER import data. When comparing with the current OSM data, this means a deviation of max. 2 metres with the current OSM data, which I consider as very acceptable. If you wish, please consider the attached lecture nodes at page 21 and the attached JOSM screenshots (blue dots are ProRail data and grey is OSM rail). TIGER consists of many seperate changesets. When I first attempted the milestone import, it was possible with just one single changeset. This makes it very easy to revert if ever considered necessary. Another safety measure is the tag combination that I'll add to it, which makes it easy to remove parts of the dataset by using XAPI. This enables mappers that are adding more precise data, to remove old data parallel to theirs with some simple mouseclicks. TIGER consists of a heterogeneous network of ways with even some weird drawing styles for seperated lanes. My proposal is very simple and contains just nodes with homogeneous properties (all nodes the same tags). Like described above, the import will not intervene in existing data, because there is literally just two milestones in the entire country (like shown in the attached overpass). Shortly, if you propose an import at Imports list as you are doing here now, your proposal will definitely fail. Since I already tried this before, I am well aware of the standards of the Imports mailing list. Thank you for your concerns though; it's members are (with reason) very strict. 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. Because all interested people that I am aware of are working in the rail sector. Because of competition between the companies, they are all interested in either improving their own services or welcoming open source services made by others. 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. I'm unaware of what WMS precisely is and how it works, but it sounds nice. I could provide you with the shapefiles and accompanying QGIS renders? Kind regards, Jeroen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openrailwaymap.org/archives/openrailwaymap/attachments/20150418/65f4ffdd/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: Milestone precision 1.PNG Type: image/png Size: 18621 bytes Desc: not available URL: <http://lists.openrailwaymap.org/archives/openrailwaymap/attachments/20150418/65f4ffdd/attachment.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: Milestone precision 2.PNG Type: image/png Size: 29492 bytes Desc: not available URL: <http://lists.openrailwaymap.org/archives/openrailwaymap/attachments/20150418/65f4ffdd/attachment-0001.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: milestone overpass.PNG Type: image/png Size: 244814 bytes Desc: not available URL: <http://lists.openrailwaymap.org/archives/openrailwaymap/attachments/20150418/65f4ffdd/attachment-0002.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: Acquisition_on_solid_ground.pdf Type: application/pdf Size: 3606922 bytes Desc: not available URL: <http://lists.openrailwaymap.org/archives/openrailwaymap/attachments/20150418/65f4ffdd/attachment.pdf>