Hi Dane
Dane Springmeyer wrote:
>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)
Yes, that example was for two layers, but I had tried it with single layer
also. I played a bit with quoting and leading spaces, this is the conclusion:
- quoting makes never any harm
- leading spaces in layer name make harm always
- if layer list is between quotes the layer(s) with leading spaces will not be
rendered but other layers do fine
- if layer list in unqueted then layer with leading space and all layers after
that in the list won't render.
Not a surprising result.
> 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?
Sorry, poor English.
> 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/
Sudo don't help me because I am running on Windows, but because it is Python I
could test it anyway. And yes, it did remove the problem.
>> 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>
> 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.
No need to do that, the scale does change. I was just using in my first trials
scales which were so close to each other that same rendering rules applied.
However, in the examples I sent 1000x1000 and 100x100 sized outputs are using
different rules and the result is OK. Sometimes it would be nice to see the
actual scale that was applied for rendering in the same units that mapfile is
using, that could make mapfile tuning easier.
-Jukka-
_______________________________________________
Mapnik-users mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/mapnik-users
