[OSM-talk] Cycle route improvements

[Ben Laenen]

I'd like to experiment with Mapnik a bit to test out my ideas. Since I 
never tried to do anything like that: is it possible to use it without 
needing to download the entire planet file? I don't really feel like 
downloading 3.6GB while I just need a tiny bit near my home town... And 
I can't find any info about that on the wiki.

And if it's possible, can the rendering rules for the cycle map be 
downloaded somewhere to use as a starting point?

Greetings
Ben


On Tuesday 05 February 2008, you wrote:
> On Feb 5, 2008 4:43 PM, Ben Laenen <benlaenen at gmail.com> wrote:
> > All the better if there's an existing tag already, but how does
> > that work with current tagging, I thought it
> > was "type=route", "route=bicycle", "network=ncn", and will this be
> > another tag "ncn=yes|proposed|etc"? Isn't the "ncn=yes" redundant
> > information then?
>
> Sorry, see Dave's translation to relations-speak, which uses slightly
> different tags. This would be state= on the cycle route relation -
> state=proposed on a relation gets handled the same as ncn=proposed on
> a way.
>
> > I see this:
> > http://www.gravitystorm.co.uk/osm/?zoom=12&lat=6652000.91116&lon=49
> >6400.42424&layers=B00
> >
> > It looks random to me, but it could be "deterministic chaos" of
> > course :-)
>
> (/me adds a few more zoom levels to Antwerpen)
>
> It looks rubbish either way. As do the the nodenet numbers, but
> that's on my todo list too.
>
> > > My preference would be to draw the lines side-by-side, but that's
> > > what I'll call the "tube map problem" since mapnik can't do that.
> >
> > That could work as well of course, though it looks much harder to
> > implement compared to the wider vs thinner lines... But it could be
> > a problem when there are lots of routes running in parallel (like
> > the opposite sides of a canal or a dual carriageway even).
> >
> > > It's common for routes to be distinguished on signs by colour as
> > > much as name or reference. I think they should be mapped with
> > > signed_colour = yellow, since that makes it clear. Renderers can
> > > then know that the colour is important, but still choose to
> > > ignore it if they wish (or map the colours to a chosen palette,
> > > or keep all the local routes in blue and put little coloured
> > > borders on them or similar). Using "signed_colour" clarifies what
> > > we mean.
> >
> > I see, I was trying to avoid real colour names, but I guess we
> > could further extend this colour tag to things like bus routes. I
> > don't like signed_colour though, as that suggests that it's the
> > colour of the signs, and I could well see someone adding
> > "signed_colour=green" for all ncn, rcn and some lcn routes, since
> > all those signs are green.
>
> yeah, I get your point. How do we make clear that we mean "the Green
> route and the Yellow route"
>
> > I just use "name=X" for that currently (since it's the relation
> > that has this name tag, not the road, but don't ask me how to put
> > that name on a starting point, could the starting point be a member
> > of the route relation as well?)...
>
> Again, just name= works fine when using relations, ncn_name= would be
> needed for ways.
>
> As for the nodes, theoretically you could have a node in the
> relation, but the importing process for osm2pgsql would ignore it
> (even our route-relations-aware version that Dave developed). That's
> why nodenets currently have a separate node. Unless Dave corrects me
> on this.
>
> Cheers,
> Andy