Mapnik error (go figure)

[Alex Cruz-3]

So, I got the OSM import issue resolved however now, gpsdrive is complaining
about mapnik:

Cannot init mapnik. Mapnik support DISABLED: Could not create datasource. No
plugin found for type 'shape' (encountered during parsing of layer 'world-1')

In looking thru some previous emails, I'm wondering if there is a version
issue going on here. I am using the latest svn of mapnik due to some errors
while compiling 0.5.1 under Karmic Koala. Thoughts?

-alex
_______________________________________________
GPSdrive mailing list
GPSdrive@...
http://lists.gpsdrivers.org/mailman/listinfo/gpsdrive

[Bruce Johnson-5]

Alex Cruz wrote:

> So, I got the OSM import issue resolved however now, gpsdrive is complaining
> about mapnik:
>
> Cannot init mapnik. Mapnik support DISABLED: Could not create datasource. No
> plugin found for type 'shape' (encountered during parsing of layer 'world-1')
>
> In looking thru some previous emails, I'm wondering if there is a version
> issue going on here. I am using the latest svn of mapnik due to some errors
> while compiling 0.5.1 under Karmic Koala. Thoughts?
>
> -alex
> _______________________________________________
> GPSdrive mailing list
> GPSdrive@...
> http://lists.gpsdrivers.org/mailman/listinfo/gpsdrive
>  

I had the same error and was searching the postgresql calls.  I
suspended the search though I still believe the problem is in that
region.  With 3 database managers, I can't be sure.

Bruce Johnson

_______________________________________________
GPSdrive mailing list
GPSdrive@...
http://lists.gpsdrivers.org/mailman/listinfo/gpsdrive

[Ross Scanlon]

On Tue, 10 Nov 2009 17:29:56 -0800
Bruce Johnson <kingcockup@...> wrote:

> Alex Cruz wrote:
> > So, I got the OSM import issue resolved however now, gpsdrive is complaining
> > about mapnik:
> >
> > Cannot init mapnik. Mapnik support DISABLED: Could not create datasource. No
> > plugin found for type 'shape' (encountered during parsing of layer 'world-1')
> >
> > In looking thru some previous emails, I'm wondering if there is a version
> > issue going on here. I am using the latest svn of mapnik due to some errors
> > while compiling 0.5.1 under Karmic Koala. Thoughts?
> >
> > -alex
> > _______________________________________________
> > GPSdrive mailing list
> > GPSdrive@...
> > http://lists.gpsdrivers.org/mailman/listinfo/gpsdrive
> >  
> I had the same error and was searching the postgresql calls.  I
> suspended the search though I still believe the problem is in that
> region.  With 3 database managers, I can't be sure.
>
> Bruce Johnson

Alex & Bruce

Actually it has to do with the input plugin shape.input for mapnik.

It can be caused by not being able to find the shape.input file or the world_boundaries_m file as below.


With version 0.5 of mapnik it is in

/usr/local/lib/mapnik/0.5/input

what it is looking for is:

/usr/local/share/mapnik/world_boundaries/world_boundaries_m

which is from the osm.xml file in your ~/.gpsdrive directory, this file contains all things to do with how mapnik renders the maps.



--
Ross Scanlon <info@...>
_______________________________________________
GPSdrive mailing list
GPSdrive@...
http://lists.gpsdrivers.org/mailman/listinfo/gpsdrive

[Bruce Johnson-5]

Ross Scanlon wrote:

> On Tue, 10 Nov 2009 17:29:56 -0800
> Bruce Johnson <kingcockup@...> wrote:
>
>  
>> Alex Cruz wrote:
>>    
>>> So, I got the OSM import issue resolved however now, gpsdrive is complaining
>>> about mapnik:
>>>
>>> Cannot init mapnik. Mapnik support DISABLED: Could not create datasource. No
>>> plugin found for type 'shape' (encountered during parsing of layer 'world-1')
>>>
>>> In looking thru some previous emails, I'm wondering if there is a version
>>> issue going on here. I am using the latest svn of mapnik due to some errors
>>> while compiling 0.5.1 under Karmic Koala. Thoughts?
>>>
>>> -alex
>>> _______________________________________________
>>> GPSdrive mailing list
>>> GPSdrive@...
>>> http://lists.gpsdrivers.org/mailman/listinfo/gpsdrive
>>>  
>>>      
>> I had the same error and was searching the postgresql calls.  I
>> suspended the search though I still believe the problem is in that
>> region.  With 3 database managers, I can't be sure.
>>
>> Bruce Johnson
>>    
>
> Alex & Bruce
>
> Actually it has to do with the input plugin shape.input for mapnik.
>
> It can be caused by not being able to find the shape.input file or the world_boundaries_m file as below.
>
>
> With version 0.5 of mapnik it is in
>
> /usr/local/lib/mapnik/0.5/input
>
> what it is looking for is:
>
> /usr/local/share/mapnik/world_boundaries/world_boundaries_m
>
> which is from the osm.xml file in your ~/.gpsdrive directory, this file contains all things to do with how mapnik renders the maps.
>
>
>
>  

Thanks for the information, Ross.  I had just concluded that I had a
biblical moment when I realized I need a "chmod 666 /var/log" in the
rc2.d so postgresql would start at boot.  As I recall, a mask statement
works also.  Which of the scripts execute mysql calls?  Are they still
necessary?

Regards, Bruce Johnson

_______________________________________________
GPSdrive mailing list
GPSdrive@...
http://lists.gpsdrivers.org/mailman/listinfo/gpsdrive

[Bruce Johnson-5]

Ross Scanlon wrote:

> On Tue, 10 Nov 2009 17:29:56 -0800
> Bruce Johnson <kingcockup@...> wrote:
>
>  
>> Alex Cruz wrote:
>>    
>>> So, I got the OSM import issue resolved however now, gpsdrive is complaining
>>> about mapnik:
>>>
>>> Cannot init mapnik. Mapnik support DISABLED: Could not create datasource. No
>>> plugin found for type 'shape' (encountered during parsing of layer 'world-1')
>>>
>>> In looking thru some previous emails, I'm wondering if there is a version
>>> issue going on here. I am using the latest svn of mapnik due to some errors
>>> while compiling 0.5.1 under Karmic Koala. Thoughts?
>>>
>>> -alex
>>> _______________________________________________
>>> GPSdrive mailing list
>>> GPSdrive@...
>>> http://lists.gpsdrivers.org/mailman/listinfo/gpsdrive
>>>  
>>>      
>> I had the same error and was searching the postgresql calls.  I
>> suspended the search though I still believe the problem is in that
>> region.  With 3 database managers, I can't be sure.
>>
>> Bruce Johnson
>>    
>
> Alex & Bruce
>
> Actually it has to do with the input plugin shape.input for mapnik.
>
> It can be caused by not being able to find the shape.input file or the world_boundaries_m file as below.
>
>
> With version 0.5 of mapnik it is in
>
> /usr/local/lib/mapnik/0.5/input
>
> what it is looking for is:
>
> /usr/local/share/mapnik/world_boundaries/world_boundaries_m
>
> which is from the osm.xml file in your ~/.gpsdrive directory, this file contains all things to do with how mapnik renders the maps.
>
>
>
>  

I found world_boundaries_m files with extensions but none with no
extension.  Is the .shp the one mapnik wants?  Should I symlink like "ln
-s world_boundaries_m.shp world_boundaries_m" in the world_boundaries
directory?
_______________________________________________
GPSdrive mailing list
GPSdrive@...
http://lists.gpsdrivers.org/mailman/listinfo/gpsdrive

[Alex Cruz-3]

On Tuesday 10 November 2009, Bruce Johnson wrote:

> Ross Scanlon wrote:
> > On Tue, 10 Nov 2009 17:29:56 -0800
> >
> > Bruce Johnson <kingcockup@...> wrote:
> >> Alex Cruz wrote:
> >>> So, I got the OSM import issue resolved however now, gpsdrive is
> >>> complaining about mapnik:
> >>>
> >>> Cannot init mapnik. Mapnik support DISABLED: Could not create
> >>> datasource. No plugin found for type 'shape' (encountered during
> >>> parsing of layer 'world-1')
> >>>
> >>> In looking thru some previous emails, I'm wondering if there is a
> >>> version issue going on here. I am using the latest svn of mapnik due to
> >>> some errors while compiling 0.5.1 under Karmic Koala. Thoughts?
> >>>
> >>> -alex
> >>> _______________________________________________
> >>> GPSdrive mailing list
> >>> GPSdrive@...
> >>> http://lists.gpsdrivers.org/mailman/listinfo/gpsdrive
> >>
> >> I had the same error and was searching the postgresql calls.  I
> >> suspended the search though I still believe the problem is in that
> >> region.  With 3 database managers, I can't be sure.
> >>
> >> Bruce Johnson
> >
> > Alex & Bruce
> >
> > Actually it has to do with the input plugin shape.input for mapnik.
> >
> > It can be caused by not being able to find the shape.input file or the
> > world_boundaries_m file as below.
> >
> >
> > With version 0.5 of mapnik it is in
> >
> > /usr/local/lib/mapnik/0.5/input
> >
> > what it is looking for is:
> >
> > /usr/local/share/mapnik/world_boundaries/world_boundaries_m
> >
> > which is from the osm.xml file in your ~/.gpsdrive directory, this file
> > contains all things to do with how mapnik renders the maps.
>
> I found world_boundaries_m files with extensions but none with no
> extension.  Is the .shp the one mapnik wants?  Should I symlink like "ln
> -s world_boundaries_m.shp world_boundaries_m" in the world_boundaries
> directory?

 My exact question. How do we fix this since I know that mapnik is working
correctly after running the tests.

-alex
_______________________________________________
GPSdrive mailing list
GPSdrive@...
http://lists.gpsdrivers.org/mailman/listinfo/gpsdrive

[Ross Scanlon]

> > > With version 0.5 of mapnik it is in
> > >
> > > /usr/local/lib/mapnik/0.5/input
> > >
> > > what it is looking for is:
> > >
> > > /usr/local/share/mapnik/world_boundaries/world_boundaries_m
> > >
> > > which is from the osm.xml file in your ~/.gpsdrive directory, this file
> > > contains all things to do with how mapnik renders the maps.
> >
> > I found world_boundaries_m files with extensions but none with no
> > extension.  Is the .shp the one mapnik wants?  Should I symlink like "ln
> > -s world_boundaries_m.shp world_boundaries_m" in the world_boundaries
> > directory?
>
>  My exact question. How do we fix this since I know that mapnik is working
> correctly after running the tests.
>
> -alex

My error it is with .shp

Does the directory

/usr/local/lib/mapnik/world_boundaries

exist?



Try using the following symlink

ln -s /usr/local/lib/mapnik /usr/local/share


If not then try with

ln -s /usr/local/lib/mapnik/* /usr/lib/mapnik/0.5


One of these resolved the issue I had with this. I can't remember which but it's probably the first.


--
Cheers
Ross
_______________________________________________
GPSdrive mailing list
GPSdrive@...
http://lists.gpsdrivers.org/mailman/listinfo/gpsdrive

[Alex Cruz-3]

On Tuesday 10 November 2009, Ross Scanlon wrote:

> > > > With version 0.5 of mapnik it is in
> > > >
> > > > /usr/local/lib/mapnik/0.5/input
> > > >
> > > > what it is looking for is:
> > > >
> > > > /usr/local/share/mapnik/world_boundaries/world_boundaries_m
> > > >
> > > > which is from the osm.xml file in your ~/.gpsdrive directory, this
> > > > file contains all things to do with how mapnik renders the maps.
> > >
> > > I found world_boundaries_m files with extensions but none with no
> > > extension.  Is the .shp the one mapnik wants?  Should I symlink like
> > > "ln -s world_boundaries_m.shp world_boundaries_m" in the
> > > world_boundaries directory?
> >
> >  My exact question. How do we fix this since I know that mapnik is
> > working correctly after running the tests.
> >
> > -alex
>
> My error it is with .shp
>
> Does the directory
>
> /usr/local/lib/mapnik/world_boundaries
>
> exist?
>
>
>
> Try using the following symlink
>
> ln -s /usr/local/lib/mapnik /usr/local/share
>
>
> If not then try with
>
> ln -s /usr/local/lib/mapnik/* /usr/lib/mapnik/0.5
>
>
> One of these resolved the issue I had with this. I can't remember which but
>  it's probably the first.
>

I had to create /usr/lib/mapnik/0.5 and link /usr/local/lib/mapnik/* to it.
That worked and I now have the mapnik option in the Map Control menu. So am I
correct in assuming that gpsdrive is looking for that specific directory?

-alex

_______________________________________________
GPSdrive mailing list
GPSdrive@...
http://lists.gpsdrivers.org/mailman/listinfo/gpsdrive

[Paul Martin-2]

On Tue, Nov 10, 2009 at 06:42:36PM -0800, Bruce Johnson wrote:

> Thanks for the information, Ross.  I had just concluded that I had a
> biblical moment when I realized I need a "chmod 666 /var/log" in the
> rc2.d so postgresql would start at boot.  As I recall, a mask

Are you sure? Directories need the execute bit, too.

On Debian, /var/log is 755 root:root, and /var/log/postgresql is 1775
root:postgres (ie. sticky bit set).

--
Paul Martin <pm@...>
_______________________________________________
GPSdrive mailing list
GPSdrive@...
http://lists.gpsdrivers.org/mailman/listinfo/gpsdrive

[Ross Scanlon]

> >
>
> I had to create /usr/lib/mapnik/0.5 and link /usr/local/lib/mapnik/* to it.
> That worked and I now have the mapnik option in the Map Control menu. So am I
> correct in assuming that gpsdrive is looking for that specific directory?
>
> -alex
>
No, mapnik is looking for that directory.

Once gpsdrive calls mapnik all map generation is done by mapnik.  Unfortunately there are a couple of problems like this with mapnik 0.5, I understand mapnik 0.6 resolved this but gpsdrive does not yet use it.




--
Cheers
Ross
_______________________________________________
GPSdrive mailing list
GPSdrive@...
http://lists.gpsdrivers.org/mailman/listinfo/gpsdrive

[Bruce Johnson-5]

Paul Martin wrote:

> On Tue, Nov 10, 2009 at 06:42:36PM -0800, Bruce Johnson wrote:
>
>  
>> Thanks for the information, Ross.  I had just concluded that I had a
>> biblical moment when I realized I need a "chmod 666 /var/log" in the
>> rc2.d so postgresql would start at boot.  As I recall, a mask
>>    
>
> Are you sure? Directories need the execute bit, too.
>
> On Debian, /var/log is 755 root:root, and /var/log/postgresql is 1775
> root:postgres (ie. sticky bit set).
>
>  

I have Easypeasy 1.5 which is 9.04 or Jaunty Jackalope flavor of
Ubuntu.  /var/log/postgresql is destroyed at shutdown or startup (I
don't know which save that recovery boots have a lot of log files it
cannot find.) so I think I need to set up the rc2.d.  Back in my SCO
Unix days, a mask 644 was necessary to get my application to work.  That
was more than 20 years ago so I may recall poorly.

Bruce Johnson

_______________________________________________
GPSdrive mailing list
GPSdrive@...
http://lists.gpsdrivers.org/mailman/listinfo/gpsdrive

[Paul Martin-2]

On Wed, Nov 11, 2009 at 09:33:56AM -0800, Bruce Johnson wrote:

> Paul Martin wrote:
> >On Tue, Nov 10, 2009 at 06:42:36PM -0800, Bruce Johnson wrote:
> >
> >>Thanks for the information, Ross.  I had just concluded that I had a
> >>biblical moment when I realized I need a "chmod 666 /var/log" in the
> >>rc2.d so postgresql would start at boot.  As I recall, a mask
> >
> >Are you sure? Directories need the execute bit, too.
> >
> >On Debian, /var/log is 755 root:root, and /var/log/postgresql is 1775
> >root:postgres (ie. sticky bit set).
> >
> I have Easypeasy 1.5 which is 9.04 or Jaunty Jackalope flavor of
> Ubuntu.  /var/log/postgresql is destroyed at shutdown or startup (I
> don't know which save that recovery boots have a lot of log files it
> cannot find.) so I think I need to set up the rc2.d.  Back in my SCO
> Unix days, a mask 644 was necessary to get my application to work.
> That was more than 20 years ago so I may recall poorly.

Ubuntu is based on Debian.

I can see no reason for /var/log not to be persistent. There can be much
valuable information in /var/log

I do know that on recent Ubuntus, /var/run is a ramdisk.

SCO Unix is a poor example to bring up. Much was highly non-standard about
it.

Directories should have the executable bit set.

If your Postgresql package isn't correctly setting up /var/log/postgresql,
then that is a bug you must report to the people who packaged your
distribution.

--
Paul Martin <pm@...>
_______________________________________________
GPSdrive mailing list
GPSdrive@...
http://lists.gpsdrivers.org/mailman/listinfo/gpsdrive

[Bruce Johnson-5]

Paul Martin wrote:

On Wed, Nov 11, 2009 at 09:33:56AM -0800, Bruce Johnson wrote:
  

Paul Martin wrote:
    

On Tue, Nov 10, 2009 at 06:42:36PM -0800, Bruce Johnson wrote:

      

Thanks for the information, Ross.  I had just concluded that I had a
biblical moment when I realized I need a "chmod 666 /var/log" in the
rc2.d so postgresql would start at boot.  As I recall, a mask
        

Are you sure? Directories need the execute bit, too.

On Debian, /var/log is 755 root:root, and /var/log/postgresql is 1775
root:postgres (ie. sticky bit set).

      

I have Easypeasy 1.5 which is 9.04 or Jaunty Jackalope flavor of
Ubuntu.  /var/log/postgresql is destroyed at shutdown or startup (I
don't know which save that recovery boots have a lot of log files it
cannot find.) so I think I need to set up the rc2.d.  Back in my SCO
Unix days, a mask 644 was necessary to get my application to work.
That was more than 20 years ago so I may recall poorly.
    

Ubuntu is based on Debian.

I can see no reason for /var/log not to be persistent. There can be much
valuable information in /var/log

I do know that on recent Ubuntus, /var/run is a ramdisk.

SCO Unix is a poor example to bring up. Much was highly non-standard about
it.

Directories should have the executable bit set.

If your Postgresql package isn't correctly setting up /var/log/postgresql,
then that is a bug you must report to the people who packaged your
distribution.

  

I did not know this.  I agree completely.  As far as SCO Unix, it was a pain at times but certainly better than DOS.  I preferred Slackware as soon as I started with it; held onto it long after Red Hat overtook it as the most widely distributed Linux.  I never had AT&T Unix as a frame of reference.  Now that I have revealed my age, the OS I miss most is AEGIS.  I will do as you suggest.

Thanks, Bruce Johnson


_______________________________________________
GPSdrive mailing list
GPSdrive@...
http://lists.gpsdrivers.org/mailman/listinfo/gpsdrive