Right, the NHN import in the area mentioned was done by MBiker. MBiker was a pretty big mapper for the Vancouver area. He started off doing lots of manual edits by biking around and gps'ing, then he got involved in the NRN road import for east GVRD, then he did NHN for the entire watershed area (08X-something?). The problem with his NHN import was that he bit off more than he could chew. He was going around fixing and cleaning the NHN stuff he imported (like a good importer should do), but he suddenly stopped working on OSM in October. I think maybe the size of the import was too daunting for one man?
The process used for importing NHN was different depending on how much was being imported at once. When an entire watershed was done (which is the case here), it was: 1. Download NHN watershed in .osm format from Yan's server. 2. Use one of the bulk upload scripts. 3. Download area from OSM with JOSM and fix any issues. For BC non-coastal watersheds, Canvec is equal to NHN. There was an issue with watersheds abutting against the coast, but I can't remember if this was resolved (and a quick search through my email history turns up nothing). Sam's purpose of the oneway=yes tag was twofold: to get waterflow direction arrows to render, and to show that the flow direction was verified (could have used a "direction_verified=yes" tag). This goes against the standard for OSM tagging of waterways, since the direction of the way itself implies waterflow direction. Mapnik doesn't render flow direction, but that's a matter of the renderer, not the data, just like Richard said. I don't think Sam's (or MBiker's) imports need to be wiped, since that would mean a couple months from now someone will just do the same thing from Canvec. Or if you are anti-import, you can delete the data, put on some bug spray and hiking boots and go map the streams yourself. Now to get back to the original question. I disagree that connectors should be upgraded to stream. On the talk-us list, they gave the example of a river still running through a man-made reservoir, so upgrading to stream would be okay, but in most cases, I don't think it would be appropriate. I think it would be incorrect to think that Chilliwack River flows underneath Chilliwack Lake or Sweltzer River flows through Cultus Lake. In most cases they shouldn't be rendered, since it only makes sense to have the lake rendered. It's not just a rendering issue though, I think connectors are logically different from normal waterways. The purpose of the connector ways (as far as I can think of) is for topological reasons. It's useful to see how different streams and rivers flow through lakes, and how they are connected to each other. We could ask, for example, "can a fish swim from Cultus Lake to Chilliwack Lake", or "if ammonium chloride spills into Slesse Creek, where will it end up?". This is why the connector ways are present. You could potentially make a script that analyzes inflowing and outflowing waterways connected to a lake, and makes the connectors automatically, but having the connectors there already makes it easier and verified. The difference between stream and river is size. Are there cases where waterways large enough to be rivers are tagged as stream in NHN? Be careful when selecting the better data based on imagery. The non-NHN waterways are probably traced from Yahoo, so using Yahoo to see which waterway is more accurate has obvious bias towards the non-NHN way. Try to use a third source (Bing), or look to see if there are obvious reasons to choose one over the other (eg. if Yahoo shows a stream redirected around new housing, then Yahoo is probably more accurate than NHN). Be careful removing source tag. We still need to acknowledge Geobase/NRCan as a source of at least part of the data. Keeping an attribution=Geobase Canada or attribution=Natural Resources Canada should be enough. Adam On Tue, Feb 22, 2011 at 7:43 AM, Paul Norman <[email protected]> wrote: > As an aside, the imports in the lower mainland were not done by Sam, but by > mbiker. I'm not sure on the exact import process used for the NRN data. If I > were to do the imports over again myself I think I'd use CanVec 7.0 which > seems to have the same data but I haven't evaluated it in any detail. > > -----Original Message----- > From: Sam Vekemans [mailto:[email protected]] > Sent: Tuesday, February 22, 2011 6:52 AM > To: Kevin Michael Smith; Talk-CA OpenStreetMap > Subject: Re: [Talk-ca] Proposal: Cleanup of NHN ways in BC > > Cool, if i knew how to edit a stylesheet i would :) So t hat's fine. > > > So perhaps then it can be all changed with a bot? > > > ... or is it better to simply wipe my edits? > > > > The rivers (without oneway=yes tag) is available in another api, so it's no > big deal. > > > cheers, > Sam > > > On 2/22/11, Kevin Michael Smith <[email protected]> wrote: >> On Tue, 2011-02-22 at 06:34 -0800, Sam Vekemans wrote: >>> Great! Were getting somewhere.. >>> >>> >>> Now lets discuss the most appropriate tag that can be used to >>> indicate the rendering of a flow line arrow. >> >> It's not about tagging the rivers to say 'there should be an arrow >> here', it's about putting 'Rivers have arrows' in the style sheet for >> the renderer. 'Having arrows' isn't a property of the river, it's a >> property of how we may or may not want to display it. >> >> -- >> Kevin Michael Smith <[email protected]> >> > > > -- > Twitter: @Acrosscanada > Blogs: http://acrosscanadatrails.posterous.com/ > http://Acrosscanadatrails.blogspot.com > Facebook: http://www.facebook.com/sam.vekemans > Skype: samvekemans > IRC: irc://irc.oftc.net #osm-ca Canadian OSM channel (an open chat room) > @Acrosscanadatrails > > _______________________________________________ > Talk-ca mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/talk-ca > > > _______________________________________________ > Talk-ca mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/talk-ca > _______________________________________________ Talk-ca mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-ca
