[OSM-talk] Cycle route improvements

[Bone Killian]

I think you can download the area around your town with JOSM or OSMXAPI 
and load the .OSM file  into postgresql.

Ben Laenen wrote:
> 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
>>     
>
>
>
> _______________________________________________
> talk mailing list
> talk at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>