-
Notifications
You must be signed in to change notification settings - Fork 288
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
st_write arguments #53
Comments
I now give the default value
writes layer
writes a real |
Right now it works well for shapefiles, but if you try to use it for different formats - you always get shapefile as a result:
|
I see your point - sth like
Who's willing to wite a |
Do you think about something like:
|
I'd suggest using |
Rather than
A simple |
@mpadge that's a good idea, but do you know any source of table with short names and extensions of vector formats? |
Prototype of
Of course, using this implementation there is a need for storing extensions data.frame somewhere. Moreover, this data.frame should also use What do you think? |
You should only need to specify the exceptions and leave the rest to
This is also non-tibbled to minimise dependencies as noted by Edzer here. The lists of
from 190 entries, or one quarter of all drivers. |
I'm not sure if
|
I agree; we also don't know in advance which drivers might be present. I think this is a good proposal. |
Here is the exhaustive list of all OGR vector drivers with write support (ordered according to appearance in the OGR table). These driver support writing to files, with this list ignoring a number of database drivers which first require connections to be established, so anyone using them may be presumed to know what they want anyway.
Using my previous Notes:
TODO prior to implementing |
Attempt to write to driver without write support:
That seems an entirely informative error message, so no risks there. Regarding But wouldnt' |
This is bikeshedding. With a fixed table (or two vectors), we see, and fix what we do. We can then deselect those not present or without write support, using |
Note that checking for write capability needs to be done dynamically, as different GDAL installs will have different external dependencies and versions of those dependencies. I don't feel that guessing file extensions is smart at all, users should state the driver the want to use explicitly, then they will not be caught out. |
This version of
The function could then be implemented by modifying
|
And actually I'd suggest that appropriate drivers should be 'guessed' even when they are specified because:
The final line above thus might be better as
and then passing |
It's not that I don't like PRs, but I think my fix does the right thing. Please comment, or add by (PR) extension/driver combinations. @mpadge : your
|
@edzer what's the purpose of adding |
@Nowosad Error is more informative that way:
|
Signed-off-by: Edzer Pebesma <edzer.pebesma@uni-muenster.de>
@Nowosad I removed this; it was just to remind myself to write tests for drivers that don't write. Anyway, there's little you can test here, with drivers evolving and all platforms supporting sth different. |
Similar to #39, but about
st_write()
.Now,
st_read()
accepts filename, but to write a file usingst_write
there is a need to specify layer argument:Is it possible to add this new functionality also for
st_write()
?The text was updated successfully, but these errors were encountered: