Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug in shapefile name handling #413

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

Bug in shapefile name handling #413

artemp opened this issue Oct 11, 2011 · 5 comments

Comments

@artemp
Copy link
Member

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.

@artemp
Copy link
Member Author

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>
}}}

@artemp
Copy link
Member Author

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

@artemp
Copy link
Member Author

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

@artemp
Copy link
Member Author

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.

@artemp
Copy link
Member Author

artemp commented Oct 11, 2011

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

@artemp artemp closed this as completed Oct 11, 2011
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant