Closed mlthlschr closed 3 years ago
Okay, I think I found the error. I should have used geom_path
instead of geom_line
. Is there any possibility to improve the docs a little? :-)
Yes, you absolutely should be using geom_path
in this case. Our docs most certainly need improvements. Meanwhile, when in doubt, I would recommend checking ggplot2 documentation. Lets-plot-kotlin is conceptually a ggplot2 derivative.
I'm curious which libraries are you using for geospatial? As far as I know there are no Kontlin counterparts for the Python's Geopandas or Shapely.
PlotSvgExport.buildSvgImageFromRawSpecs(plotSpecRaw)
If you are saving to a file there is suitable ggsave function.
Yes, you absolutely should be using
geom_path
in this case. Our docs most certainly need improvements. Meanwhile, when in doubt, I would recommend checking ggplot2 documentation. Lets-plot-kotlin is conceptually a ggplot2 derivative.
Looks like that's a good plan
I'm curious which libraries are you using for geospatial? As far as I know there are no Kontlin counterparts for the Python's Geopandas or Shapely.
Unfortunately there are not kotlin alternatives. I am using geotools, to display them I am mapping the GIS-features to the lets-plot format
Interesting. In a matter of fact Let's-Plot internally has quite robust support for geospatial data visualization, but these capabilities are not yet exposed in the Kotlin API. At the moment only Lets-plot Python API supports geospatial data types (geodataframe) and visualization (see geopandas support and the example notebooks).
We are planning to add similar features to the Kotlin API: map
, map_join
parameters in layers and some data structure which would play the role of geodataframe. This data structure could be as simple as just a container of a standard hashmap with a mandatory entry: "geometry" -> string , where the string is a WKT representation of a geometry like: "MULTIPOLYGON (((180.00000 -16.06713, 180.00000..."
Then geotools would work with lets-plot rather smoothly, I think, providing there is an adapter/converter between FeatureCollection
(?) and the data structure above.
Interesting. In a matter of fact Let's-Plot internally has quite robust support for geospatial data visualization, but these capabilities are not yet exposed in the Kotlin API. At the moment only Lets-plot Python API supports geospatial data types (geodataframe) and visualization (see geopandas support and the example notebooks).
Just checked geom_polygon and found the todo.
We are planning to add similar features to the Kotlin API:
map
,map_join
parameters in layers and some data structure which would play the role of geodataframe. This data structure could be as simple as just a container of a standard hashmap with a mandatory entry: "geometry" -> string , where the string is a WKT representation of a geometry like: "MULTIPOLYGON (((180.00000 -16.06713, 180.00000..."
yeah, I guess that would be awesome. In that case "only" a WKT-parser would be needed and not only geotools could be supported, but also other tools which at least have WKT-export. Geotools certainly supports WKT, at least on Feature
-level.
Then geotools would work with lets-plot rather smoothly, I think, providing there is an adapter/converter between
FeatureCollection
(?) and the data structure above.
When working with single Features
based on the jts Geometry
-type not even a adapter would be needed, as they support wkt export. If I understood the geotools docs correctly, currently, the jts-Geometries are the only ones used.
The FeatureCollection
indeed needs an adapter, but I guess that could be handled as well (maybe with some kind of extension function generating GEOMETRYCOLLECTION
, MULTIPOLYGON
or so).
In any case, if I can help implementing this somehow, I would be glad to do so.
Thank you! I think a good first milestone would be the reproductions of the natural earth Python Jupyter notebook with Kotlin kernel.
We need to figure out how to rewrite input cells 1, 2, 3. Could you try to work it out?
Of course. However, I doubt that it is possible for me to reimplement geopandas, which is basically the only thing done in cells 1-3. Or do you mean by using geotools and any arbitrary geo-dataset I can find?
Yes, I meant using geotools of course. Would be nice to have a piece of code in Kotlin/Java producing the result similar to the table shown in Out[3]
. In particular: columns "continent" and "geometry".
To achieve this goal the code should:
This will also tell us what minimal geotools
dependencies are required for this kind of tasks.
I have 0 experience in geotools
and this would help a lot.
Okay, that sounds like a plan! I am going to have a look the next days.
Yes, I meant using geotools of course. Would be nice to have a piece of code in Kotlin/Java producing the result similar to the table shown in
Out[3]
. In particular: columns "continent" and "geometry".To achieve this goal the code should:
* read continental boundaries from a shapefile or other geospatial format * transform coordinates to decimal degrees (WGS84) if necessary * convert geometries from internal format to WKT strings
See example ex1 here. Quite ugly code, but should be sufficient to prove the point.
Thanx, this is exactly what needed! Is there a way in geotools to explicitly convert the "the_geom" feature attribute to WKT form?
yes. the printed string is the WKT format given by the Geometrie's toText() method, shortened to 50 letters. I updated the example to show it.
Hi, I've added 'SpatialDataset' type which consists of one 'geometry' column and optional 'data' columns. I've also added a converter method (as a Kotlin extension method for SimpleFeatureCollection) for transforming geotools feature collection to SpatialDataset.
SpatialDataset can be passed to a plot layer via the 'data' or 'map' parameter as it the following use cases:
I was able to almost entirely reproduce the GeoPandas notebook in Kotlin notebook: https://nbviewer.jupyter.org/github/JetBrains/lets-plot-kotlin/blob/master/docs/examples/jupyter-notebooks-dev/geotools_naturalearth.ipynb
The only part I skipped was the 'South America' part where we need to filter 'worldFeatures' - drop everything which is not continent == "South America". Do you know how such filter is done in GeoTools?
Of course, this issue https://github.com/Kotlin/kotlin-jupyter/issues/107 is still a showstopper.
There are also simple JVM demos in the project: https://github.com/JetBrains/lets-plot-kotlin/tree/master/demo/geotools-batik/src/main/kotlin/naturalEarth
Thanx, the filtering worked like a charm - I've updated the naturalearth example.
@mlthlschr Hi, there is a public Kotlin Kernel release available (kotlin-jupyter-kernel 0.8.3.1) which fixes the issue https://github.com/Kotlin/kotlin-jupyter/issues/107.
Last week we released Lets-PLot Kotlin API v1.1.0 that includes the support for GeoTools's SimpleFeatureCollection, ReferencedEnvelope and Geometry objects - please, check out this updated demo: https://nbviewer.jupyter.org/github/JetBrains/lets-plot-kotlin/blob/master/docs/examples/jupyter-notebooks/geotools_naturalearth.ipynb
I think this exhausts all the issues discussed in this thread and I'm closing it now. )
@mlthlschr Make sure you include the %useLatestDescriptors
jupyter line magic because kotlin-jupyter-kernel 0.8.3.1 still doesn't have the latest Lets-Plot package bundled with it.
Currently, I am working with geospatial data. I have a problem if I want to plot the contour lines. The dataset might not be sorted by the x-axis, as the lines might contain curves going back or might even be circles.
When I create a single
Feature
from a map containing all coordinates of the line viageom_line(map)
the plot viaPlotSvgExport.buildSvgImageFromRawSpecs(plotSpecRaw)
is looking quite strange.If I inspect the resulting
.svg
, I can see that the plotted parts are sorted by x-axis, even though they are not sorted in the lists stored in the mapIn case I plot every single line on it's own, the file gets so huge that I can not see anything anymore.
Is there any way to force the svg export not to sort the given
Features
by x-axis? What can I do instead?