Open nerik opened 2 years ago
so the thing about an shx is that it's only needed for doing look ups within the shp file, since we're just reading straight through the shp file we don't actually care if it's there or not.
So two issues:
.shp.xml
, and then you could also have a just regular .xml
file in there too.Thanks for reviewing.
Our use case is that we use shapefile-js on the frontend to read feature properties, but the shapefile is then uploaded to a backend service that does its own shapefile parsing, which in our setup needs shp, shx, dbf, as well as prj files. This PR allows us to intercept a shapefile that's not going to work with our backend before uploading.
I guess it's a bit of a convoluted scenario, but I imagined adding some metadata might be useful to someone else. Let me know if you could be interested in merging this, I can easily fix the two remaining issues:
you can find the basename by looking at the basename.shp and then grabbing everything after basename.
@calvinmetcalf I fixed the two issues you reported and added a test.
@calvinmetcalf Hey there, sorry to bother you - do you plan to merge this or should we use my fork? Thanks
sorry was on vacation all last week, I'll take a look this week
Hi, thank you for that very useful lib 👍
We have a backend script that converts shapefiles using a different lib, whose requirement is for a zipped shapefile to contain shp, shx, and dbf components (which seems to be the official recommendation, see https://www.loc.gov/preservation/digital/formats/fdd/fdd000280.shtml).
shpjs has a specific strategy to deal with the absence of a dbf file, and it doesn't seem to require an shx file but can work with an sbx file. Therefore, I can't just throw an error without introducing a breaking change - and without breaking tests.
So I suggest having the output GeoJSON containing an
extensions
meta field (similar asfileName
) to allow users to deal with their own shapefile requirements should they want to.