Thanks, Dane.
I tried with a different shapefile (from the link that you gave).
Same issue.
The original shapefile opens fine in QGIS, so somehow the shapefiles
are not being read properly in mapnik. Is it possible to debug this
further? Can we increase the verbosity of the debug messages?
Claire
On Apr 18, 2008, at 2:33 PM, Dane Springmeyer wrote:
> Hi Claire,
>
>> >>> lyr.datasource = Shapefile(file='/Users/mclister/Downloads/
>> world_borders/world_borders')
>> size = 2
>> file=/Users/mclister/Downloads/world_borders/world_borders
>> type=shape
>
> This all looks good.
>
>> Envelope
>> (4.157518931977256e
>> -317,4.15549523909189e
>> -317,4.157455691574588e-317,-1.62334203800658e-118)
>
> This does not. The world borders shapefile from mapping hacks should
> have an envelope more like this:
>
> Envelope(-180,-90,180,83.62359600000001)
>
>> file_length=3332172
>> shape_type=5
>> datasource=0x32a5b0 type=1
>> >>> lyr.styles.append('My Style')
>> >>> m.layers.append(lyr)
>> >>> m.zoom_to_box(lyr.envelope())
>> >>> render_to_file(m,'world.png', 'png')
>
> this looks fine.
>
>> scale=5.41114e-121
>> start map processing
>> bbox
>> =
>> Envelope
>> (-1.62334203800658e
>> -118
>> ,-1.62334203800658e-118,1.62334203800658e-118,4.15549523909189e-317)
>
> This is not going to produce a working map. I'm not sure if this has
> anything to do with hanging python, but it will be problematic
> nonetheless.
>
> Default scale and bbox should be:
> scale=0.6
> start map processing
> bbox=Envelope(-180,-93.18820199999999,180,86.81179800000001)
>
>> scale denominator = 2.1513e-112
>> start layer processing : world
>> datasource = 0x32a5b0
>> ENCODING = utf-8
>> Killed
>>
>
> Looks like mapnik is bailing on the shapefile read step. You should
> get:
>
> total shapes read=3784
> end layer processing
> end map processing
> 1.07 s
>
> I'd first confirm that the unzipping process didn't corrupt the
> shapefile (try opening in another application like QGIS), or try
> another sample dataset like:
> http://thematicmapping.org/downloads/world_borders.php
>
>
> Dane
>
>
>>
>> On Apr 18, 2008, at 11:52 AM, Dane Springmeyer wrote:
>>
>>> If you open up Console.app are there any error messages specific
>>> to the mapnik/python process? Or in the Console/crashreporter logs?
>>>
>>> Did you build with mapnik debug true? If so, what the last set of
>>> text printed to the interpreter before the render_to_file() call?
>>>
>>> Dane
>>>
>>>
>>>
>>> On Apr 18, 2008, at 11:21 AM, Claire McLister wrote:
>>>
>>>> Thanks, that did help. I've made much progress and am able to get
>>>> the
>>>> 'from mapnik import *' to work without errors.
>>>>
>>>> Now, however, when I try the "getting started" map image generation
>>>> for the 'world_borders' shape file, the python process keeps
>>>> churning
>>>> (at about 100% CPU) without any results. After a few minutes I
>>>> had to
>>>> kill the process.
>>>>
>>>> The command was "render_to_file(m,'world.png', 'png')" after all
>>>> the
>>>> other commands as suggested on the wiki page.
>>>>
>>>> On Apr 18, 2008, at 8:22 AM, Justin Bronn wrote:
>>>>
>>>>> I just rebuilt both a debug build and non-debug build using
>>>>> r694. I
>>>>> had
>>>>> no problems running the demo with both builds using Boost 1.34.1.
>>>>> However, I ran into problems with the recently released Boost 1.35
>>>>> and I've created a ticket with a patch that fixes these issues:
>>>>>
>>>>> http://trac.mapnik.org/ticket/90
>>>>>
>>>>> I've found that removing all previous attempted mapnik installs
>>>>> prior to
>>>>> attempting a recompile is essential. Thus, _before_ you
>>>>> instantiate
>>>>> scons, clean up all your previous install attempts. Attached is
>>>>> the
>>>>> shell script I use (modify accordingly).
>>>>>
>>>>> When building Boost in OSX I've found that it is best to use their
>>>>> `bjam` tool rather than their `configure` script. Note that if
>>>>> you
>>>>> have a dual-core system you can add the `-j2` flag to both `bjam`
>>>>> and `scons` to take advantage of both cores:
>>>>>
>>>>> $ tar xjvf boost_1_35_0.tar.bz2
>>>>> $ cd boost_1_35_0
>>>>> $ export BOOST=`pwd`
>>>>> $ cd tools/jam/src
>>>>> $ ./build.sh darwin
>>>>> $ cd bin.macosxx86/
>>>>> $ export PATH=`pwd`:$PATH
>>>>> $ cd $BOOST
>>>>> $ bjam --toolset=darwin \
>>>>> --with-thread --with-filesystem --with-iostreams \
>>>>> --with-regex --with-program_options --with-python \
>>>>> --with-system stage
>>>>> $ sudo bjam --toolset=darwin \
>>>>> --with-thread --with-filesystem --with-iostreams \
>>>>> --with-regex --with-program_options --with-python \
>>>>> --with-system install
>>>>>
>>>>> After applying the patch from ticket #90 (assuming in Mapnik
>>>>> source
>>>>> directory):
>>>>>
>>>>> $ python scons/scons.py PREFIX=/usr/local BOOST_INCLUDES=/usr/
>>>>> local/
>>>>> include/boost-1_35 BOOST_TOOLKIT=1_35
>>>>> $ sudo python scons/scons.py PREFIX=/usr/local BOOST_INCLUDES=/
>>>>> usr/
>>>>> local/include/boost-1_35 BOOST_TOOLKIT=1_35 install
>>>>>
>>>>> -Justin
>>>>> #!/bin/sh
>>>>> PREFIX=/usr/local
>>>>> PYTHON_PREFIX=/Library/Frameworks/Python.framework/Versions/2.5/
>>>>> lib/
>>>>> python2.5/site-packages
>>>>>
>>>>> # Uninstalling Python `mapnik` module.
>>>>> rm -fr $PYTHON_PREFIX/mapnik
>>>>>
>>>>> # Uninstalling mapnik
>>>>> rm -fr $PREFIX/include/mapnik
>>>>> rm -fr $PREFIX/lib/mapnik
>>>>> rm -f $PREFIX/lib/libmapnik.*
>>>>> rm $PREFIX/bin/shapeindex
>>>>> _______________________________________________
>>>>> 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
>>>
>>
>
_______________________________________________
Mapnik-users mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/mapnik-users
