[Talk-ca] Proposal: Cleanup of NHN ways in BC
Adam Dunn
dunnadam at gmail.com
Tue Feb 22 17:37:30 GMT 2011
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 <penorman at mac.com> 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:acrosscanadatrails at gmail.com]
> 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 <smithkm at draconic.ca> 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 <smithkm at draconic.ca>
>>
>
>
> --
> 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
> Talk-ca at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-ca
>
>
> _______________________________________________
> Talk-ca mailing list
> Talk-ca at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-ca
>
More information about the Talk-ca
mailing list