-
Notifications
You must be signed in to change notification settings - Fork 37
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
Adds Ewkt dialect #155
Adds Ewkt dialect #155
Conversation
TBH, I am not too happy about changing all of the APIs to force the user to always be WKT dialect aware. I would much rather keep the existing API, plus perhaps add a new constructor, e.g. keep the |
Sure, I changed the signature of the constructor for the sake of consistency with |
oh, i didn't realize we already did it that way with WkbWriter... I'm a bit on a fence on this one then - ideally I would want Wkb to also be done the same way - |
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.
I'm fine with changing the WktWriter
-API. The ToWkt
trait API should be kept compatible if possible, which is the case here.
Comments:
- We should use the opportunity to drop the lifetime in
ẀktWriter
, like in RFC: Drop lifetime parameter of GeoJsonReader #147 - Run
cargo fmt
Thanks for the review, I ran |
@Oreilles thx! Do you need help merging main branch into your PRs? |
I just rebased onto |
After discussing the PR with @nyurik, I'm also for keeping the |
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.
I made a few suggestions in code. I think we shouldn't be removing the lifetime in the same PR - lets just figure out the dialects first, as it is not certain?
geozero/src/wkt/mod.rs
Outdated
/// Convert to WKT String with dimensions. | ||
fn to_wkt_ndim(&self, dims: CoordDimensions) -> Result<String>; | ||
/// Convert to WKT String with srid, dimensions and dialect. | ||
fn to_wkt_dialect( |
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.
Technically this is more of a to_wkt_with_options
or to_wkt_extended
method, not just dialect
... Naming is hard, we may want to bikeshed this one.... (note that I am still kinda uneasy about the new
constructor now requiring an additional dialect param even though most of the users probably won't ever care about it, and plus it doesn't allow us to have a default
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.
Actually maybe we don't want a to_wkt_with_options
? Then to_ewkt
would leave you no choice over the output dimensions, e.g. taking all those available. I hardly think of a use case where you'd want an EWKT output with less information. Maybe we can just remove to_wkt_dialect
, and just leave to_wkt
, to_wkt_ndim
and to_ewkt
.
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.
I just hope the number of dialects don't explode :) to_ewkt
and to_ewkt_ndim
sounds fine.
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.
Oh, but since there is now three to_wkt
flavour, that would imply a lot of code duplicate to remove to_wkt_dialect
. So we might as well just find an appropriate name for it as you suggested. About the number of Wkt dialect... I discovered while working on this that Spatialite rejects POINT(1 2 3 4)
as valid Wkt and will only accept POINTZM(1 2 3 4)
so maybe a next PR to come ? 😅
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.
sigh :) I think we may as well just use to_wkt_with_opts
, and provide all those detalis. We may even want to get rid of the to_wkt_ndims
to reduce the api surface (TBD)
I just really don't like the to_wkt_dialect
because it actually has many more params than just the dialect one, making it confusing
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.
I agree, not sure what the best solution is here so I'll that one up to you..!
That's understandable, I'll do the modification 👍
Even though it's not a standard, thanks to PostGIS success it's still quite common and (AFAIAA) is the only human-friendly geometry format that allows SRID declaration. It will be used as a user input format in a product I'm working on. |
Co-authored-by: Yuri Astrakhan <yuriastrakhan@gmail.com>
This reverts commit c670618.
geozero/src/wkt/mod.rs
Outdated
/// Convert to WKT String with dimensions. | ||
fn to_wkt_ndim(&self, dims: CoordDimensions) -> Result<String>; | ||
/// Convert to WKT String with srid, dimensions and dialect. | ||
fn to_wkt_dialect( |
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.
I just hope the number of dialects don't explode :) to_ewkt
and to_ewkt_ndim
sounds fine.
let mut out: Vec<u8> = Vec::new(); | ||
let mut writer = WktWriter::with_dialect(&mut out, WktDialect::Ewkt); | ||
writer.dims = CoordDimensions::xyzm(); | ||
crate::wkb::process_wkb_type_geom(rdr, &mut writer, dialect)?; |
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.
not sure if actionable, just checking if this is correct: both the writer and the processor need a dialect? And when reading, the processor cannot auto-detect the dialect, or can it?
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 an Ewkt
string can be parsed from several Wkb
dialects, which is why we need to pass it as a parameter. In the current implementation, no detection of the Wkb
dialect is implemented; I guess it would be pretty tricky to do so, as they all have their own quirks.
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.
seems like this one is ready to go once we settle on the to_wkt_X
name... I think to_wkt_with_opts
is the cleanest?
geozero/src/wkt/mod.rs
Outdated
/// Convert to WKT String with dimensions. | ||
fn to_wkt_ndim(&self, dims: CoordDimensions) -> Result<String>; | ||
/// Convert to WKT String with srid, dimensions and dialect. | ||
fn to_wkt_dialect( |
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.
sigh :) I think we may as well just use to_wkt_with_opts
, and provide all those detalis. We may even want to get rid of the to_wkt_ndims
to reduce the api surface (TBD)
I just really don't like the to_wkt_dialect
because it actually has many more params than just the dialect one, making it confusing
I made a few more suggestions for this PR in Oreilles#2
|
* rename `to_wkt_dialect` -> to_wkt_with_opts` * make `WktWriter` content private! It's ridiculous to have write access to a writer from outside * introduce `WktWriter::with_dims` to allow creation of a writer with the needed params
ewkt PR - a few suggestions
This PR adds:
enum WktDialect
with optionsWktDialect::Wkt
andWktDialect::Ewkt
towkt
modulestruct EwktString(pub String)
fn to_ewkt(&self, srid: Option<i32>) -> Result<String>
to traitToWkt
fn to_wkt_dialect(&self, dialect: WktDialect, dims: CoordDimensions, srid: Option<i32>) -> Result<String>
to traitToWkt
The trait
FromWkb
is implemented forEwktString
so that the srid is inferred from the Wkb stream if available. The later is made possible by implementingGeomProcessor::srid
forWktWriter
and callingprocessor.srid(info.srid)
inprocess_wkb_geom
.Side notes:
wkt
crate.ProcessToCsv::to_csv_ewkt
and/orProcessToCsv::to_csv_dialect
?