Hi Jukka,
On Nov 8, 2008, at 3:36 AM, Rahkonen Jukka wrote:
> Hi,
>
> If I run nik2img.py without -l switch I am getting nowadays a fine
> map from the place I want with correct worldfile.
Good.
> If I try to render just one layer by adding, for example, -l "minor-
> roads, coast-poly" the resulting map is not from the same place.
Okay, but that example is two layers, right? (commas should separate
layers, without spaces, and quoting is needed only if the layer names
have spaces)
But yes, you've found a bug, I think. See below...
> I doubt that in this case something goes wrong with setting the
> query window.
>
Don't you mean to say you DO think something is wrong with the query
window when layers are queried?
I can replicate a problem where a roads layer gets shifted north when
it is requested to be shown, as evidenced in the queries sent to
postgres:
1) Bizarre shift:
nik2img.py -m osm.xml -o shift_error.png -l 'roads,world' -v --zoomto
-122,48,10
select asbinary(way) as geom,"highway" from
(select * from planet_osm_roads order by z_order) as roads
where way && setSRID('BOX3D(-13846231.35093522
5898806.581961673,-13315724.40262353 6251413.710313057)'::box3d,900913)
2) Works fine:
nik2img.py -m osm.xml -o works.png -v --zoomto -122,48,1
select asbinary(way) as geom,"highway" from
(select * from planet_osm_roads order by z_order) as roads
where way && setSRID('BOX3D(-13846231.35093522
5930033.35688859,-13315724.40262353 6283704.655763042)'::box3d,900913)
It seems the problem is do to the deletion of non-requested layers, as
commenting out this line fixes the shift:
http://code.google.com/p/mapnik-utils/source/browse/trunk/desktop/nik2img/nik2img.py#773
Can you try updated to the SVH head to see if it fixed your problem?
You can now do this like:
$ sudo easy_install
http://mapnik-utils.googlecode.com/svn/trunk/desktop/nik2img/
> Another question is about calculating scales. I seem to get always
> a map from the same zoom level even if I change the output image size.
Hmm, I don't. Sending different output size radically changes the zoom
level and how the layers are rendered. All nik2img is doing here is
passing your bbox off to mapnik and printing out the scale_denominator
that mapnik reports, no more....
> There may be some problem in calculating the scale denominator, and
> I am not sure if they are calculated in the same units that are used
> in the mapfile. It may also be that I just cannot read the output
> of the nik2img.py script.
Again, nik2img is just printing mapnik's internal scale. It should be
printing the exact same thing as would be printing to STDOUT if you
had built mapnik in debug mode.
> However, here are two examples.
>
> C:\mapnik>c:\python2.5\python nik2imgv2.py -m gosm.xml -o niktest.png
> -e 25.01,60.18,25.06,60.21 -s 1000,1000 --worldfile pgw -v
>
> or the same query with smaller output image:
> -e 25.01,60.18,25.06,60.21 -s 100,100 --worldfile pgw -v
>
>
> Output for 1000 by 1000 pixel image STEP: 23 // --> Scale
> denominator is: -3.57142857143
> Output for 100 by 100 pixel image STEP: 23 // --> Scale denominator
> is: -35.7142857143
>
> This is how zoom levels are defined in the mapfile. In this case
> output is epsg:900913.
>
>
> <Rule>
> <Filter>([highway] = 'motorway' or [highway]='motorway_link')
> and ([bridge] = 'yes' or [bridge]='true') and [layer]='2'</Filter>
> <MaxScaleDenominator>5000</MaxScaleDenominator>
> <MinScaleDenominator>1000</MinScaleDenominator>
>
> -Jukka Rahkonen-
You'll have to send a testcase to convince me, because it sure looks
like the scale is changing as evidenced by the 'STEP 23:' output below.
Dane
> _______________________________________________
> Mapnik-users mailing list
> [email protected]
> https://lists.berlios.de/mailman/listinfo/mapnik-users
_______________________________________________
Mapnik-users mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/mapnik-users
