Importers, Based on feedback from people on this list, I've changed my process for the US Wilderness data set from using ogr2ogr for the SHP->OSM conversion to using poly2shp. I had to heavily modify poly2shp to handle the type of multipolygons in the wilderness.net data set, but it is now working, and a sample (one wilderness polygon) has been uploaded to the OSM database.
Following the Importing Guidelines Wiki page, I've created the following objects: "USWilderness" OSM user, which will own all the data: http://www.openstreetmap.org/user/USWilderness Wilderness.net data import description page: http://wiki.openstreetmap.org/wiki/Wilderness.net Added the above page to the import catalog: http://wiki.openstreetmap.org/wiki/Import/Catalogue For group discussion/approval, I followed the process to upload the "Mojave Wilderness" areas to OSM, as seen here: http://www.openstreetmap.org/browse/changeset/5436275 Each of these wilderness areas is a single legal entity, so I created them each as "outer" members of a relation that shares all of the same tags as the individual areas. Please let me know what you think, if I should change my process at all, change the tagging scheme, etc. There are 753 unique wilderness areas, many of which are multipolygons as above. I expect to process and upload each wilderness area individually, ensuring no conflict/duplicate/etc of existing data. -Erik > I'm sure you all saw my posts to the Talk mailing list on this subject, > but I'm working my way through the "Import Guidelines" wiki page, which > requests a post to this list: > > The "Designated Wilderness Areas" in the USA are of great interest to > people like me, who like to explore the less populated places in the US. > The "Wilderness Act" (1964) specifies that: > > "...lands designated for preservation and protection in their natural > condition..." Section 2(a) (Wilderness.net) > > "...shall be devoted to the public purposes of recreation, scenic, > scientific, educational, conservation and historic use." Section 4(b) > (Wilderness.net) > > These areas are made publicly available through several US government > agencies, including the US Forest Service, Bureau of Land Management, > National Park Service, etc. The "National Atlas" site makes all of the > Wilderness Areas available for download as a single shapefile: > > http://www.nationalatlas.gov/mld/wildrnp.html > > (There is also a ton of other great information available for download at > this site.) > > > Many of these areas are already imported into the OSM database, as part of > USFS imports, and many of the areas are already defined as other types of > objects, such as parks and preserves. However, most of the Designated > Wilderness areas are not in the OSM database. > > I'd like to work to import these areas. There has already been some > discussion on the "talk" mailing list about the details, especially the > need to be careful not to duplicate data already in the database. > > I think there will need to be a substantial amount of manual work done to > ensure no data duplication occurs, and some cleanup of enclosing boundary > areas, so the process I'm planning on using is fairly manual: > > 1. Convert the National Atlas shapefile into KML using ogr2ogr.* > *The intermediate step through KML format is necessary because gpsbabel > below needs 3-D coordinates on input, but this shapefile is 2-D. The KML > file allows for manual (perl script) addition of a zero-value > z-coordinate. > > 2. Convert the KML file into OSM format using gpsbabel. > > 3. Use JOSM to add each area to the OSM database manually by copying areas > from the shapefile-derived layer to the downloaded OSM layer for that > region. > > Some metadata is lost in this process, such as the area state, state FIPS > code, managing agency, unique ID and URL to wilderness.net. In order to > restore this data, I plan to either create a patch for gpsbabel to tunnel > this metadata through, or create a perl script to copy this data from the > KML file to the OSM file. > > There are > 1300 total designated wilderness areas, so the manual nature > of this process means the import will take some time. Fortunately, many of > the areas are in very remote regions, with little other data nearby, so > can be added with little work correcting conflicts. > > Your comments, suggestions and assistance are greatly appreciated. > > -Erik Burrows > _______________________________________________ Imports mailing list [email protected] http://lists.openstreetmap.org/listinfo/imports
