Salut Daniel, Yes, I'm still alive :) but unfortunately I can't find much time to follow what is going on in Canada. (The import of Dutch landuse data is partially to blame ;) ) As you might expect, I've looked a bit at the 021L14 data (Quebec City area). Here are some comments, and hopefully I'm not touching something again which was discussed in the past.
* Some ways are duplicated. They are all hydrological features (landuse=basin, landuse=reservoir, natural=water). This is even true for the St. Lawrence river. * I think it would be a good idea to split up each file in 3 files, namely one for roads (what one would typically find in the NRN), one for hydrological features (as in the NHN), and the rest. The reason is that in many areas roads and or hydro features have already been imported (be it originally created or Canvec/Geobase based), but this is not true for the other features. --> A consequence of this is that the same node could be found in different files. I think that this should be taken care of during the import process. As Sam mentions, it is not just 'plopping' the data in OSM, but this kind of processing (and also properly connect features over tile boundaries, etc.) is also part of it. * Can you get rid of the turning circles at the end of the roads? I bet they are more often non-existing than actually existing. * Bridges have no layer tags. Probably the actual layer can't be determined correctly, but usually it will be layer=1, so that is a good default. --> Regarding bridges: I actually don't like the fact that when a bridge crosses a road below it, they both share the same node. This does not occur physically. However, if you leave duplicate nodes in there (which would throw a wrench in the dedup process), then this might be incorrectly be seen as a duplicate node. A workaround could be to give one of the nodes a small offset. * How are you going to deal with the issue I raised in the past about huge forest areas? In the sample areas you didn't split up the forests into multiple shapes (or multipolygons). OTOH, I don't like to have to split up, with the sole purpose to make JOSM more responsive. It might be possible that JOSM has improved in this regard as well. (I'm yet clueless as to how Potlatch would deal with it.) * There is an area overlap between several features, like natural=wood and natural=wetland. This must come from the source data. I think that in this particular case it is justified, namely a wooded marsh/swamp. Anyways, keep up the good work :) Thanks, Frank On 10-06-17 07:00 PM, Bégin, Daniel wrote: > Bonjour! > Before the Canvec.osm production starts, I have produced complete NTS > datasets for samples previously offered - actually I have expanded the > samples to cover the entire NTS tile and add 092G06. > Each NTS dataset have been tiled using a quadtree algorithm - a nice > example of the result is 092G06 ! The .osm subtiles are zipped all > together. We are still using WinZip but we might eventually move to > gzip or bzip. > Have a look! > And, by the way, can you make sure everything is still OK with the data? > Cheers, > Daniel > > ------------------------------------------------------------------------ > *From:* talk-ca-boun...@openstreetmap.org > [mailto:talk-ca-boun...@openstreetmap.org] *On Behalf Of *Bégin, Daniel > *Sent:* 15 juin 2010 15:10 > *To:* talk-ca@openstreetmap.org > *Subject:* [Talk-ca] Canvec.osm Product almost... > > Bonjour à tous, > We are still on schedule for Canvec.osm product. We should be able to > start the production later next week. Each NTS will be tiled using a > quadtree algorithm. A tile splits when there is more than 25K nodes in it. > Each tile is named after the dataset name + tiling subtree. Subtree > naming convention is 0=SW, 1=NW, 2=NE, 3=SE. Each subtree level is > separates with a "." - like in 021E05.3.2.1 > Example: > http://wiki.openstreetmap.org/wiki/CanVec#Canvec_Product_-_Osm_format > Regarding splitting threshold, 50K nodes is Osm xapi maximum. With > 25K nodes I make sure you can add all the stuff you have/that is > already available over the area before uploading it. > Cheers, > Daniel > > > _______________________________________________ > 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