Bug in shapefile name handling #413

Closed
artemp opened this Issue Oct 11, 2011 · 5 comments

Comments

Projects
None yet
1 participant
Owner

artemp commented Oct 11, 2011

I think this might be related to ticket:199 - I had a shapefile named "phys_contours.merc.shp", and I refer to it in the datasource as "phys_contours.merc". This does not work, but if I rename them to "phys_contours-merc.shp" and "phys_contours-merc", it does. Is the ".merc" at the end being misinterpreted as a filename extension? I'm running Mapnik from trunk, I believe it's been approx. 1 month since I updated and recompiled. This stylesheet has worked in the past, btw - it's only since my last recompile that the buggy behavior has surfaced.

Owner

artemp commented Oct 11, 2011

[springmeyer] Ruh row.

Yes, your guess is the same as mine that mine changes caused a regression because of mishandling of the extension.

However it would be a problem in the current behavior which was actually changed further than #199 in r1170 and a fix made to that for boost < 1_36 in r1172.

I wonder if you are using boost <1_36, because I am using 1_39 and I don't immediately see the issue you describe:

{{{
$ ogr2ogr world_borders.merc.shp world_borders.shp

springmeyer:data spring$ python
Python 2.5.1 (r251:54863, Feb 6 2009, 19:02:12)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

from mapnik import Shapefile
registered datasource : gdal
registered datasource : kismet
registered datasource : ogr
registered datasource : osm
registered datasource : postgis
registered datasource : raster
registered datasource : shape
registered datasource : sqlite
Shapefile(file='world_borders.merc.shp')
size = 2
file=world_borders.merc.shp
type=shape
datasource=0x341ac0 type=1
<mapnik.Datasource object at 0x23ed30>
Shapefile(file='world_borders.merc')
size = 2
file=world_borders.merc
type=shape
datasource=0x343500 type=1
<mapnik.Datasource object at 0x23ed70>
}}}

Owner

artemp commented Oct 11, 2011

[springmeyer] ack, nm, bad test because it was finding the original shapefile.

Okay, i can reproduce now. This surely looks like boost::filesystem::path.replace_extension() is interpreting the extension as .merc if the .shp is left off since it must look for the last '.' and trim the rest and it is working on the path string not the actual file.

As such this should work:
{{{
phys_contours.merc.shp
}}}

I think in general that is a fine approach, but agree that since this changes behavior where previously there was no exception, this is not ideal.

Hmmm...

Owner

artemp commented Oct 11, 2011

[springmeyer] looks like the easiest solution would be to rollback to the behavior in r1046. I introduced this newer code to snip off not only the .shp extension but the others twoo because that was more akin to how ogr handles datasources with multiple extensions, and because I figured that using boost path and extension handling would be more robust - in this case perhaps too robust :).

Owner

artemp commented Oct 11, 2011

[migurski] Makes sense - I like that it's possible to omit the .shp since a shapefile is really a collection of files, but I'm going to play it safe and leave on the .shp in the future.

Owner

artemp commented Oct 11, 2011

[springmeyer] fixed in r1294 but restoring behavior added in r1046 and later changed in r1170.

artemp closed this Oct 11, 2011

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment