On Sun, 15 Feb 2009, Frank Steggink wrote: > Hi, > > > I've tried to digest the wiki pages and e-mails, but it's quite a lot of > information. It is especially hard to identify what information is still > current > and what is obsolete. Hopefully you can help me getting started by answering a > couple of questions. I understand that the NRN data has the highest priority, > so > I'll focus on that.
Yes the wiki needs a cleanup, I've been hoping someone else would do it since that doesn't seem to be happening I will try to find sometime soon to delete all obsolete information from the wiki pages. > 1. Is there an agreed set of tags which need to be imported? There > Geobase_NRN_-_OSM_Map_Feature page on the wiki lists a huge list of tags. > Should > they all be converted? I assume we would like to keep the imported data > consistent, although there will be differences between different provinces, > and > existing data will also be different. > a. What is the final resolution about NID's? Do they need to be kept? Yes please try to keep nids for data that actually comes from geobase. Not importing could limit us in the future. > b. How can we guarantee that the final import will be consistent? (See > also > my first question.) Depends what you mean by consitent. 1. Using consistent tags for things, the best way to ensure this is to look at what others are doing and share your scripts. 2. data consistency, ie roads line up and are joined between different imports or between the existing and geobase data. Right now we have no automated consistency tools, we are depending on people to manually line up/connect ways post import. > > 2. Do I have to use existing software / processes, like RoadMatcher, or can I > develop a way to import data in a way that will suit me the most? > a. For software it makes most sense to reuse what is already available, > and > adjust it when necessary. > b. I'm actually missing a best practice page. It is not evident what the > most efficient process is, but that's also likely subject to personal taste / > skills. You are free to use your own processes and software. I don't think any two people are doing the exact same thing for importing. This is the process I follow You don't need to use roadmatcher, you just need to have some method of avoiding hundreds of duplicate roads. For comparision purposes what I've done with the larger areas in Alberta: 1. Populate a postgis database with the NRN shapefile 2. Populate a postgis database with the OSM data using osm2pgsql 3. Generate a NRN and OSM shapefile for the area that I'm interested in using pgsql2shp and some SQL queries. I handle reprojection during this process as well (lately I've been reprojecting into meters) 4. Import both shapefiles into jump and automatch with roadmatcher 5. Export my results 6. Run geobase2osm on the NRN GML file(yes I had to download the NRN data twice) and produce a standalone file 7. Review the standalone file in JOSM 8. Upload the standalone file with bulk_upload.pl 9. Manual fixup in JOSM. > 3. Is there an existing tool to cut the NRN data files in tiles? Or does > someone > host the NRN data which are already cut into tiles? Or is it preferred to use > the Ibycus topo maps (and convert them to OSM)? > a. Do the Ibycus maps contain all attributes? I don't think so, since > they're created specifically to be used by GPSs. > Do not use any of the Ibycus stuff the import the licenses are not compatible. Do not use ibycus in the geobase import. Someone should have removed these references from the wiki a long time ago. I will try to do it soon. The geobase2osm.py script accepts a -b parameter which is a file containing containing a bounding area (it doesn't need to be square), POLYGON((-120 54.9999961853027,-120 56,-118 56,-118 54.9999961853027,-120 54.9999961853027)) I use conditions on my postgis WHERE clause to cut the data down in the shapefiles I generate for roadmatcher. > 4. Since it seems there are several different individual import / > experimentation processes going on, many imports will have to be rolled back. > (I'll create a new OSM user, so my changes will be easily detectable.) Is > there > a test server available? > I just viewed/posted my initial .osm files in JOSM and when people where happy with them I did an import to a small isolated area. Using a seperate userid is a good idea. You can get the latest version of geobase2osm.py here, a number of people have used this as the basis for their custom procedures. http://svn.openstreetmap.org/applications/utils/import/geobase2osm/geobase2osm.py Steve > [Not in the mail to Michel:] > Based on the gathered information I've developed a workflow based on PostGIS. > I > still need to test it, but if this workflow is useful, I'll share it with you. > It will involve a certain degree of manual checks, but my experience is that > data imports always need close attention. It is very easy to mess up things. > We > also need to take things like relationships into account. > > That's about it for now. As a test area I'll probably use an area in the > Beauce. > Sheet 021L07 seems to be a good candidate. I've mapped most of the existing > OSM > roads, and there are some larger residential areas, but not too much. > > Regards and thanks in advance, > > Frank > > _______________________________________________ > Talk-ca mailing list > Talk-ca@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-ca > _______________________________________________ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
