The first rule of imports is: **If you have to ask - don't do it.** Seriously, imports are difficult for a number of reasons. Firstly, not every import makes sense; for example, if it is third-party data which is well and actively maintained then importing the data into OSM will create a reduced-quality clone (because the data will not be updated when the original source updates). Or if the data is of a kind that cannot be sensibly improved by the community, like official boundaries or airspaces or building floor plans - that's also something that has very little reason to be in OSM. It is important to remember that OSM is a community mapping platform; data not meant for editing should not be in OSM. Secondly, even if the data is good and suitable, imports can discourage people from getting engaged (because the map looks complete). This is a problem we're seeing in some areas where imports have boosted the data but not the community. Andy Allan has an excellent parable about imports, [The Pottery Club][1], and Matt Amos has run an interesting [simulation][2] that aims to illustrate the effect of imports on community growth. Thirdly, doing imports properly requires a lot of knowledge. You have to select the right tagging, you have to make sure your data does not collide with anything that is already there, you have to make sure that adjacent polygons don't unnecessarily duplicate nodes, and so on. Some of these challenges can be solved by good importing software, some cannot. The second rule of imports is: Even if you find a program that seemingly does what you want, never try to run an import if you don't know exactly what the program does, and if you don't know exactly how to undo your import if something should go wrong. Any import needs to be well planned, needs to be discussed with the community, and professionally executed. The usual credo of "something is better than nothing", which we often use when surveying, does not apply to imports. There is a high risk of imports actually damaging the project rather than being of use. There is a piece of software that seems to read dxf files and create osm files, but it is seldom used and I have no idea whether or not this would work for your data set: [http://github.com/h4ck3rm1k3/TwoNickels][3] Be sure to discuss your plans on the ["imports" mailing list][4] before you do anything. [1]: http://www.gravitystorm.co.uk/shine/page/2/ http://www.gravitystorm.co.uk/shine/archives/2009/11/10/the-pottery-club/ [2]: http://www.asklater.com/matt/wordpress/2009/09/imports-and-the-community/ [3]: http://github.com/h4ck3rm1k3/TwoNickels [4]: http://lists.openstreetmap.org/listinfo/imports

The first rule of imports is: If **If you have to ask - don't do it. it.** Seriously, imports are difficult for a number of reasons. Firstly, not every import makes sense; for example, if it is third-party data which is well and actively maintained then importing the data into OSM will create a reduced-quality clone (because the data will not be updated when the original source updates). Or if the data is of a kind that cannot be sensibly improved by the community, like official boundaries or airspaces or building floor plans - that's also something that has very little reason to be in OSM. It is important to remember that OSM is a community mapping platform; data not meant for editing should not be in OSM. Secondly, even if the data is good and suitable, imports can discourage people from getting engaged (because the map looks complete). This is a problem we're seeing in some areas where imports have boosted the data but not the community. community. Andy Allan has an excellent parable about imports, [The Pottery Club][1], and Matt Amos has run an interesting [simulation][2] that aims to illustrate the effect of imports on community growth. Thirdly, doing imports properly requires a lot of knowledge. You have to select the right tagging, you have to make sure your data does not collide with anything that is already there, you have to make sure that adjacent polygons don't unnecessarily duplicate nodes, and so on. Some of these challenges can be solved by good importing software, some cannot. The second rule of imports is: Even if you find a program that seemingly does what you want, never try to run an import if you don't know exactly what the program does, and if you don't know exactly how to undo your import if something should go wrong. Any import needs to be well planned, needs to be discussed with the community, and professionally executed. The usual credo of "something is better than nothing", which we often use when surveying, does not apply to imports. There is a high risk of imports actually damaging the project rather than being of use. There is a piece of software that seems to read dxf files and create osm files, but it is seldom used and I have no idea whether or not this would work for your data set: http://github.com/h4ck3rm1k3/TwoNickels [http://github.com/h4ck3rm1k3/TwoNickels][3] Be sure to discuss your plans on the ["imports" mailing list][1] list][4] before you do anything. [1]: http://www.gravitystorm.co.uk/shine/page/2/ [2]: http://www.asklater.com/matt/wordpress/2009/09/imports-and-the-community/ [3]: http://github.com/h4ck3rm1k3/TwoNickels [4]: http://lists.openstreetmap.org/listinfo/imports

The first rule of imports is: If you have to ask - don't do it. Seriously, imports are difficult for a number of reasons. Firstly, not every import makes sense; for example, if it is third-party data which is well and actively maintained then importing the data into OSM will create a reduced-quality clone (because the data will not be updated when the original source updates). Or if the data is of a kind that cannot be sensibly improved by the community, like official boundaries or airspaces or building floor plans - that's also something that has very little reason to be in OSM. It is important to remember that OSM is a community mapping platform; data not meant for editing should not be in OSM. Secondly, even if the data is good and suitable, imports can discourage people from getting engaged (because the map looks complete). This is a problem we're seeing in some areas where imports have boosted the data but not the community. Thirdly, doing imports properly requires a lot of knowledge. You have to select the right tagging, you have to make sure your data does not collide with anything that is already there, you have to make sure that adjacent polygons don't unnecessarily duplicate nodes, and so on. Some of these challenges can be solved by good importing software, some cannot. The second rule of imports is: Even if you find a program that seemingly does what you want, never try to run an import if you don't know exactly what the program does, and if you don't know exactly how to undo your import if something should go wrong. Any import needs to be well planned, needs to be discussed with the community, and professionally executed. The usual credo of "something is better than nothing", which we often use when surveying, does not apply to imports. There is a high risk of imports actually damaging the project rather than being of use. There is a piece of software that seems to read dxf files and create osm files, but it is seldom used and I have no idea whether or not this would work for your data set: http://github.com/h4ck3rm1k3/TwoNickels Be sure to discuss your plans on the ["imports" mailing list][1] before you do anything. [1]: http://lists.openstreetmap.org/listinfo/imports