Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Bug in shapefile name handling #413

Closed
artemp opened this Issue · 5 comments

1 participant

@artemp
Owner

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.

@artemp
Owner

[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

Shapefile(file='world_borders.merc')
size = 2
file=world_borders.merc
type=shape
datasource=0x343500 type=1

}}}

@artemp
Owner

[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...

@artemp
Owner

[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 :).

@artemp
Owner

[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.

@artemp
Owner

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

@artemp artemp closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.