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 <[EMAIL PROTECTED]> 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 > [email protected] > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > _______________________________________________ talk mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
