Dane, +init=epsg:2264 works. I had not been putting it in Layer. However, I am still getting the lexical problem. I'm using estimate_extent">false and then defining extent. My xml files is at:
http://www.piedmontgeographic.com/mapdata/wake.xml Could it be a problem with my installation of mapnik? When I configure mapnik I get the following message: However, these optional dependencies were not found: - cairo - cairomm - boost system - pycairo Further up I have: Checking for Boost version >= 1.33... yes Found boost lib version... 1_34_1 Checking for C++ library boost_system-mt... no Could not find optional header or shared library for boost system Checking for C++ library boost_filesystem-mt... yes Checking for C++ library boost_regex-mt... yes Checking for C++ library boost_iostreams-mt... yes Checking for C++ library boost_program_options-mt... yes Checking for C++ library boost_thread-mt... yes I do not have the boost_system-mt library. Could this be the problem? I'm using Fedora Core 9, and according to YUM I have all the boost libraries installed, but this one does not appear to be there. If this is possibly the cause of the problem, I could install new boost libraries in /usr/local Thanks Jim On Fri, Apr 24, 2009 at 8:02 PM, Dane Springmeyer <[email protected]>wrote: > Jim, > On Apr 24, 2009, at 11:53 AM, James McManus wrote: > > Dane, > > My tables do have SRID set in the geometry columns, but I have been having > problems using EPSG codes with mapnik. When I use src=+init=epsg:2264 in my > xml file I get a blank map, so I have been using src=+proj=lcc +datum=NAD83 > instead. > > > you mean 'srs' not 'src' right? > > Also as long as you can do this in an interpreter without error you should > be fine using the Proj4 integer codes: > > >>> from mapnik import * > >>> Projection('+init=epsg:2264') > Projection('+init=epsg:2264') > >>> > > otherwise use the proj literal from: > > http://spatialreference.org/ref/epsg/2264/mapnik/ > > If you are getting a blank map with the right projection then I'd confirm > that the 'srs' is properly set for you layers as well. > > This works, but it looks like it may be the cause of the bad lexical cast > problem. > > > Okay, hard to say. > > Looking at other emails on this list, I see that mapnik has a place to set > epsg codes ( allowedepsgcodes) in ogcserver.conf. Do I have to use this > method, when using epsg codes? > > > Yes, otherwise the OGCServer will throw an exception. > > In my current configureation I'm using mapnik with openlayers (Layer.WMS) > and tilecache (type=MapnikLayer), > > > Okay, although with type=Mapnik TileCache is using Mapnik's python bindings > and I find it is easier to make TMS requests via OpenLayers. > > with eather mod_python (must restart server, after each edit) or just cgi > when editing maps. > > > Okay. > > Is there currently a conventional way to setup mapniks ogcserver to work > with tilecache? > > > Just set up the ogcserver as normal (I prefer WSGI) and use type=wms in > TileCache. > > I currently I have epsg:2264 defined in both tilecache.cfg and in > Openlayers. > > > TileCache ignores the 'srs' parameter when using the type=Mapnik. (i've > been forgetting to submit a patch for this) > > Therefore you need to supply: > > projection=+proj=lcc +lat_1=36.16666666666666 +lat_2=34.33333333333334 > +lat_0=33.75 +lon_0=-79 +x_0=609601.2192024384 +y_0=0 +ellps=GRS80 > +datum=NAD83 +to_meter=0.3048006096012192 +no_defs > > Possibly I could just incorporate ogcserver's wms.py into my tilecache.py > or tilecache.cgi scripts? > > > Why? Sounds tricky :) > > Dane > > > > Thanks > Jim > > On Thu, Apr 23, 2009 at 6:59 PM, Dane Springmeyer <[email protected]>wrote: > >> Hi James, >> >> The lexical cast error is coming from a boost function that is used to >> convert data types being pulled from postgis. Essentially what is happening >> is likely due to problems involved in calculating extents or the table srid, >> where data is not able to be correctly cast to a new type required by the >> PosGIS plugin. >> >> The I've seen this occur when querying an empty table and having >> estimate_extent=True, because its impossible to convert null extents to the >> required types. We should likely insert more friendly error checking, but >> until then I would assume that lexical cast errors indicate a problem in the >> data or parameters used to query postgis. >> >> So, in your example below it looks like you are providing a manual extent, >> so the above does not directly apply. But does your table have an SRID set >> in the geometry columns? Is that extent value correct/valid for your data >> projection? Does your user have privileges to access all the tables >> including the geometry columns table? >> >> Dane >> >> >> On Apr 23, 2009, at 11:25 AM, James McManus wrote: >> >> I'm using mapnik with postgis and tilecache. Everything appears to be >>> working, except I am getting the error message "bad lexical cast: source >>> type value could not be interpreted as target" in my httpd/error_log, even >>> when I have debug set to off. I would like to resolve this, so my error_log >>> does not fill up. Below is part of the error_output from the error_log: >>> >>> [Thu Apr 23 13:57:06 2009] [error] [client 71.120.222.68] >>> datasource=0xbf8420 type=1 >>> [Thu Apr 23 13:57:06 2009] [error] [client 71.120.222.68] size = 7 >>> [Thu Apr 23 13:57:06 2009] [error] [client 71.120.222.68] dbname=wake >>> [Thu Apr 23 13:57:06 2009] [error] [client 71.120.222.68] >>> estimate_extent=false >>> [Thu Apr 23 13:57:06 2009] [error] [client 71.120.222.68] >>> extent=1947126.12, 596061.63, 2258533.48, 891583.72 >>> [Thu Apr 23 13:57:06 2009] [error] [client 71.120.222.68] host=localhost >>> [Thu Apr 23 13:57:06 2009] [error] [client 71.120.222.68] >>> table=wakepublicopenspace0902 >>> [Thu Apr 23 13:57:06 2009] [error] [client 71.120.222.68] type=postgis >>> [Thu Apr 23 13:57:06 2009] [error] [client 71.120.222.68] user=apache >>> [Thu Apr 23 13:57:06 2009] [error] [client 71.120.222.68] bad lexical >>> cast: source type value could not be interpreted as target >>> [Thu Apr 23 13:57:06 2009] [error] [client 71.120.222.68] borrow 0xbbb8f0 >>> [Thu Apr 23 13:57:06 2009] [error] [client 71.120.222.68] unknown >>> type_oid=408585 >>> [Thu Apr 23 13:57:06 2009] [error] [client 71.120.222.68] return 0xbbb8f0 >>> >>> It appears to not like how I'm referenceing user? >>> >>> Jim >>> >>> _______________________________________________ >>> 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
