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

Way to make ogr2ogr available in path? #29

Open
lucasprograms opened this issue Mar 12, 2022 · 3 comments
Open

Way to make ogr2ogr available in path? #29

lucasprograms opened this issue Mar 12, 2022 · 3 comments

Comments

@lucasprograms
Copy link

Hi, and thank you so much for this library!

I am dealing with datasets that I cannot bring into memory all at once, and to my understanding methods like vectorTranslateAsync need the data to be provided as a dataset in memory.

I am wondering if there is a way to leverage this library to expose ogr2ogr in path. I would like to execute some function like

spawn('ogr2ogr', ogrArgs)

is that possible using this library? If not, is there a way to use this library to process data with ogr without bringing the full dataset into memory?

@mmomtchev
Copy link
Owner

Normally everything ogr2ogr does should be matched by vectorTranslateAsync as both use the same C++ code.

Which driver are you using and what is the transformation you are doing?

@lucasprograms
Copy link
Author

lucasprograms commented Mar 12, 2022

Basically it is any variety of common geospatial formats (shp, kmz, gpkg, etc.) to geojson. I haven't tried kmz or gpkg but it looks like gdal.open / gdal.openAsync does that automatically for shapefiles. Is there a way to do that transformation without storing the output in memory?

Also, I am happy to close this and move over to stack overflow or gis stack exchange if you'd rather deal with this sort of question there!

@mmomtchev
Copy link
Owner

GeoJSON has an excessive memory problem usage for sure - that is why GeoJSONSeq exists.

Is there a concrete ogr2ogr command with which you get higher memory usage in gdal-async than GDAL CLI?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants