On Fri, 2008-10-24 at 00:18 +0100, Jon Burgess wrote:
> On Thu, 2008-10-23 at 15:42 -0700, Dane Springmeyer wrote:
> > Mapnik Users,
> >
> > I've run into a repeatable failure (on both mac 10.5 and Ubuntu 8.04)
> > of the mapnik Filter expression and have a test case.
> >
> >
> > You can download the test case as a zip archive from here:
> >
> > http://mapnik-utils.googlecode.com/svn/trunk/sandbox/mapnik_filter_failure_test_case.zip
> >
> > Inside the zip archive are two shapefiles, two XML mapfiles, and a
> > test script.
> >
> > The run_test.sh script utilizes nik2img to generate a simple graphic
> > using each mapfile.
> >
> > The only difference between the mapfiles is that one points to a
> > 'states.shp' shapefile which mapnik renders fully green highlighting
> > the failure of the <Filter> expression, while the other points to
> > 'states_working.shp' which for me renders with states in shades of
> > green, blue or red, highlighting a working Filter on the [PEOPLE]
> > attribute.
>
> The test script isn't working for me, but doing a simple binary
> comparison between the files shows that only the dbf file are different.
> We can discount the prj file since that is not read by Mapnik.
>
> If I dump the the two dbf files with dbfdump (from shapelib utilities)
> then the results are the same for the two files. The difference must be
> in something very subtle like the padding bytes.
>
> It either needs some extra debug code in the Mapnik shapefile reader to
> compare exactly what is read from the two files. Or if someone is
> familiar with the DBF format might be able to decode the differences
> byte-by-byte.
Looking closer the padding on the numeric fields is definitely different
nul (broken) vs space (working):
0001320 13 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >................<
0001340 0d 20 49 6c 6c 69 6e 6f 69 73 20 20 20 20 20 20 >. Illinois <
0001360 20 20 20 20 20 20 20 20 20 20 20 31 37 45 20 4e > 17E N<
-0001400 20 43 65 6e 49 4c 31 34 33 39 38 36 2e 36 31 30 > CenIL143986.610<
-0001420 30 30 30 30 30 30 00 00 00 31 39 39 33 2e 33 33 >000000...1993.33<
-0001440 35 30 30 30 30 30 30 00 00 00 00 00 31 31 34 33 >5000000.....1143<
-0001460 30 36 30 32 2e 30 30 30 30 30 30 30 30 30 00 32 >0602.000000000.2<
-0001500 39 32 34 38 38 30 2e 30 30 30 30 30 30 30 30 30 >924880.000000000<
-0001520 00 00 34 32 30 32 32 34 30 2e 30 30 30 30 30 30 >..4202240.000000<
-0001540 30 30 30 00 00 35 35 35 32 32 33 33 2e 30 30 30 >000..5552233.000<
...
+0001400 20 43 65 6e 49 4c 20 20 20 31 34 33 39 38 36 2e > CenIL 143986.<
+0001420 36 31 30 30 30 30 30 30 30 20 20 20 20 20 31 39 >610000000 19<
+0001440 39 33 2e 33 33 35 30 30 30 30 30 30 20 31 31 34 >93.335000000 114<
+0001460 33 30 36 30 32 2e 30 30 30 30 30 30 30 30 30 20 >30602.000000000 <
+0001500 20 32 39 32 34 38 38 30 2e 30 30 30 30 30 30 30 > 2924880.0000000<
+0001520 30 30 20 20 34 32 30 32 32 34 30 2e 30 30 30 30 >00 4202240.0000<
+0001540 30 30 30 30 30 20 20 35 35 35 32 32 33 33 2e 30 >00000 5552233.0<
+0001560 30 30 30 30 30 30 30 30 20 20 35 38 37 38 33 36 >00000000 587836<
Not sure why this should confuse Mapnik though.
Jon
_______________________________________________
Mapnik-users mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/mapnik-users
