-
Notifications
You must be signed in to change notification settings - Fork 293
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
Postgis 3 #1303
Postgis 3 #1303
Conversation
because rgdal is not available from bionic apparently
configure.ac creates a LF warning and this makes the check fail
This is the order in which srid is synchronised: - search for srid match - search for wkt match - create a new srid in the database (using the wkt)
Apologies for off-topic comment by a quick look at this suggests you solved a problem I was having with GH Actions: r-lib/usethis#1005 great work 🎉 Do you plan to create a placeholder repo that demonstrates these actions, e.g. called |
I still see this:
could you address this? Will submit to CRAN today or tomorrow. |
@Robinlovelace, good to hear. It's on a separate branch, so I could certainly create a repo out of the github actions. @edzer, I'm on it. The PR is still in draft mode though, but I'll try to resolve as much checks as I can before the end of the day. I saw you made some commits, I'll have a look too. |
Great! I resolved the conflicts and the warnings; I also tried to get postgis on travis to work, which doesn't look like it's going to work (requiring GEOS >= 3.6, apparently not avail on travis), but now see that you got postgis tests going on this new workflows thing, right? |
Yes, I also tried to have the tests work with travis, but in the end it was much simpler to make them work on github actions/workflow, and adding more databases will be also relatively simple. We could transition the whole tests suite to github. It also allows tests on mac and windows (which I suspended since they don't support postgres services for now). |
@edzer, found this note. Lines 325 to 330 in 051b204
Do you plan to fix EWKB for R |
@etiennebr, that would be great. Writing the SRID of EWKB happens and has always happened here: Lines 609 to 610 in 051b204
The section you point to is the R code which is only used when calling |
R/db.R
Outdated
} | ||
|
||
#' Find srid in a database by using the srid |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So you're writing documentation for a function that is not exported, right? If so, why? I'd suggest to leave out the #'
, maybe use only #
, so that no documentation objects are created.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it feels awkward to write a .Rd, but I still felt like minimal documentation would be useful. I'll use #
, then.
This allows to use a remote srid (e.g. from a database)
Thanks for the pointer. I modified the All checks pass locally on my side (after re-building |
Can't we pass the (new) srid through the input field of the Maybe you are right, I just want to understand what the implication is of working with a postgis db; any srid that you're writing in the EWKB has to be valid (as of: present) in the context of the database you're writing to, right? |
Thanks for looking at this. I tried to pass it through the srid attribute as it was, but when the srid is written to the EWKB, it goes through Postgis maintains a The table can also be edited by the user to add custom projections, or be of a different version than the local list of projections An R user could also use a WKT unavailable in the list of local projections (so no local srid, but still has a valid WKT). |
I don't like to extend
or do I overlook something? |
I must say I currently have an awkward work schedule with the pandemic, so it's very likely I'm not coming with the best solutions :). I think your logic would work in most cases (in fact I don't think using custom projection is common, so we're talking about small edge cases). The improbable scenario where two identical srids refer to different WKT would still be incorrect. I don't know if this could happen with different proj/postgis versions, but it could happen when using custom projections. I'm thinking that maybe |
I agree that asking GDAL to get it is maybe not the good thing here. OK, I'll write it such that it tries to read the SRID from the |
Excellent, I think it should work. |
This is the draft PR to adapt sf to postgis 3 and proj 6.
st_write
's new arguments logic. Also, if you're ok with it, I'd like to deprecatedelete_layer
in favor ofoverwrite
.There are many commits, if you prefer I could reorganize the commits while I rebase to make it easier to review.
I still need to provide a fix to override missing local srids (#1234 (comment)).