Comments (7)
The above change does not correspond to the wtk specification correctly as the Dimension is not sufficient to specify the allowed types. For example for points we can have:
- Point
- PointZ
- PointM
- PointZM
Both the Z and M version are dimension 3. Instead I think want there to be 4 fundamental coord types. Basically any use of Option for Z or M should be avoided.
pub struct Coord<T>{
pub x: T,
pub y: T,
}
pub struct CoordZ<T>{
pub x: T,
pub y: T,
pub z: T,
}
pub struct CoordM<T>{
pub x: T,
pub y: T,
pub m: T,
}
pub struct CoordZM<T>{
pub x: T,
pub y: T,
pub z: T,
pub m: T,
}
So a line string would become:
pub enum LineString<CT: CoordType> {
Empty,
Value(Vec<CT>),
}
from wkt.
@grivy Your proposed design looks good to me. What does the CoordType
trait look like?
from wkt.
hmm..
So actually while I do think this library should provide data types as default, ideally I would not want to use them as I do not want to copy my data into these temporary structures and then to WKT.
Like money, coordinates should not be stored in floating points, as we want to be able to compare and we do not want to loose precision. In one project I have lat/lon in i64's (need to divide by (lat_i64 / 8192 / 60 / 60) to get the floating point value. And another project in a local Cartesian reference frame is in mm (y_i32 / 1000) to get float value.
So while I think it is good to provide default structs it should also be possible to use the users' own Coordinate type for direct translation to WKT. So the user would have to implement the CoordZ trait and then implement the x(), y(), z() functions returning floats.
Actually when writing to WKT (unlike WKB) there should not be any need to loss precision due to float representation. For example the y_i32 can be written to a string first, and then have the decimal point inserted later 654356 -> "654356" => "654.356". This would allow the user to prevent any loss in precision.
Or is there a maximum to the number of decimals in the WKT standard?
For this scenario I suppose the user would implement a trait for example CoordM and provide the functions: x_as_string(), y_as_string(), m_as_string() oh and x_from_string(), y_from_string(), m_from_string()
Not sure yet what the implications are on LineString and user provided LineString structs.
Maybe this library can provide some inspiration:
https://docs.rs/postgis/0.4.0/postgis/ewkb/index.html
Note that this is WKB so they have to do i64
from wkt.
What about not having a wkt-specific internal representation and instead having LooksLikeALinestring
, LooksLikeAPoint
traits and a Wkt
trait that provides the wkt(&self) -> String
function implemented for every type that implements such traits. That way the user can represent their types however they want and get a nice WKT without much effort.
And of course impls for every type in geo_types
...
Although I'm not sure how parsing would look like in this scenario
from wkt.
You might also be interested in https://github.com/georust/geozero
Which allows things like:
geojson.to_wkt()
from wkt.
I looked at it when I was trying to find options but by reading the readme I didn't get the idea of how it would help in my case. But you're right, it might be helpful
from wkt.
I'm still kind of getting the hang of GeoZero myself, but I think the idea is that you can implement:
impl GeozeroGeometry for YOURTYPE
or impl GeozeroDatasource for YOURTYPE
and then you can serialize your type to any of the supported output formats (wkt, geojson, gdal, etc.)
from wkt.
Related Issues (20)
- Relax ToWkt impls to work with CoordNum HOT 1
- Support deserializing integer geometries HOT 2
- release 0.11.0 HOT 2
- Add Support For EWKT
- MultiPoint should handle mix of EMPTY and non Empty points
- Should we support LINEARRING type? HOT 13
- Better way to serialize to wkt? HOT 5
- Publish WKT 0.9.0 HOT 4
- `POINT EMPTY` vis-à-vis `geo_types` HOT 2
- WKT Release: proposed minor release 0.9.1 HOT 1
- Wkt parser should parses geometry type as case insensitive HOT 2
- Next release (0.9.2) HOT 1
- Remove ToWkt? HOT 19
- Make geo-types a non-optional dependency HOT 3
- Add MIT license file HOT 1
- How to pass GEOMETRYCOLLECtion from sql HOT 1
- make Wkt<T> display HOT 3
- Use new TZM geo-types instead the custom WKT ones HOT 12
- Avoid intermediate `Wkt` allocation for `ToWkt::wkt_string` for geo-types
- Output `TRIANGLE` type? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from wkt.