calvinmetcalf / shapefile-js

Convert a Shapefile to GeoJSON. Not many caveats.
http://calvinmetcalf.github.io/shapefile-js/
714 stars 228 forks source link

adds extensions meta in geojson output #181

Open nerik opened 2 years ago

nerik commented 2 years ago

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 as fileName) to allow users to deal with their own shapefile requirements should they want to.

calvinmetcalf commented 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:

  1. I don't totally get why you'd need this?
  2. some of the file extensions actually have two dots in them notably .shp.xml, and then you could also have a just regular .xml file in there too.
  3. what you've written makes a list of all the extentions of all the files in the zipfile and then puts them on everyfile, so if you have two shapefiles each with .shp, .dbf and .shx files in one zip, you'd have an array on each with .shp, .dbf, .shx , .shp, .dbf and .shx in it.
nerik commented 2 years ago

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:

  1. just report whatever comes after the first dot?
  2. yep, good catch, I was distracted 🙄
calvinmetcalf commented 2 years ago

you can find the basename by looking at the basename.shp and then grabbing everything after basename.

nerik commented 2 years ago

@calvinmetcalf I fixed the two issues you reported and added a test.

nerik commented 2 years ago

@calvinmetcalf Hey there, sorry to bother you - do you plan to merge this or should we use my fork? Thanks

calvinmetcalf commented 1 year ago

sorry was on vacation all last week, I'll take a look this week