Hi @abhinav9414, happy to see the interest! As mentioned in the project idea, part of the work should be a diagnosis of the current state and community needs, based on which we should be able to point at specific changes. A good place to start are issues labelled as "plotting" which should cover the most pressing issues. We don't have a list of changes that need to be made (yet), we hope that the initial stage of the GSoC will produce one. A project proposal template might also help with drafting.
5 replies
Hi Geopandas, I am interested contributing to dask-geopandas through the Google Summer of Code this year. There are a few goals listed on the wiki page and I was wondering whether there was a priority on any one of these?
Hi @tastatham,
dask-geopandas is in an early stage of development so there is a lot to do. I would say that the ideal roadmap now would be 1) spatial partitioning, 2) spatial indexing, 3) overlapping computation, based on my own experience and needs (which may be biased). Maybe IO... You can check the issues https://github.com/geopandas/dask-geopandas/issues for a discussion on some of these. If you have some needs yourself, feel free to embed them in the proposal. Also note that we have submitted a workshop proposal around dask-geopandas to Dask Summit, so there may be a chance to have a good discussion on priorities during that with a wider range of people.
thanks @martinfleis, that's really helpful. Ok, I'll consider in the proposal aspects that are important to my work too (which will probably be useful to others) but the geopandas/dask-geopandas#40 could be really useful!
@tastatham check also the initial implementation by Matt Rocklin https://github.com/mrocklin/dask-geopandas and
spatialpandas, which implements some aspects of geospatial parallelization using dask - https://github.com/holoviz/spatialpandas.
@tastatham cool to see interest in dask-geopandas! ;)
One general comment in addition to what Martin already said: it's indeed in an early stage of development, which also means that we have almost no documentation or examples, not much test coverage, etc. That are of course not "big" topics to focus on, but something that will be useful to give some time along the way.
One general comment in addition to what Martin already said: it's indeed in an early stage of development, which also means that we have almost no documentation or examples, not much test coverage, etc. That are of course not "big" topics to focus on, but something that will be useful to give some time along the way.
And related to that, what I think will be useful at some point: take an (advanced) use case (which can be something from your own work / interest, or a general one like the "NYC taxi data"), implement a full workflow with using dask-geopandas, and see all the issues that you run into / areas that can be optimized.
Since not a lot of people already did this with their workflow (and we don't have example case studies), I think in general we will still run into quite some issues in the beginning.
Since not a lot of people already did this with their workflow (and we don't have example case studies), I think in general we will still run into quite some issues in the beginning.
thanks @jorisvandenbossche for pointers, the NYC taxi dataset is a good one and there are a number of others listed on datashader that would be worth exploring too and my own work of course
@abhinav9414 You mean the "Approach" section in the template? It depends. I guess that for plotting project it is fairly straightforward python code based existing matplotlib functionality. In the gpkg IO, there may be some SQL, regarding technology. But it all depends on the rest of the proposal. You haven't shared the draft via GSoC so it is hard to advise. If you need some PRs in related packages it should be there etc.
@martinfleis and @jorisvandenbossche, I have also completed my draft in Google Docs and would also appreciate some suggestions. Apologies for submitting this so close to the deadline.
Just FYI, I will be (mostly) off for the rest of the day and won't be able to check any further drafts or changes before the deadline.
Hi @arredond, Looking at it the list of issues, it is clear that we should do some spring cleaning. The best would be to check issues labelled
bug and find some you're comfortable fixing. They require various level of expertise and some will be easier than other so you should be able to find some you're comfortable with. If you want to work on documentation, #1896 is a nice one to start with.
Hello all, the github contact section pointed me here. I'd like to open a feature request to build oriented minimum bounding boxes from polygons, like you can do in QGIS. Having trouble implementing it on my own. This this an appropriate issue to open?
Still got some testing to do, but I ended up using https://github.com/dbworth/minimum-area-bounding-rectangle/blob/master/python/min_bounding_rect.py to make follow on operations easier.
It looks like geom.minimum_rotated_rectangle doesn't guarantee right angles? They might be trying to accomplish different things.
Short answer everything works as intended - thank you again. FWIW the github link to min_bounding_rect.py returns identical return as geom.minimum_rotated_rectangle.
Long answer is that the KML writer enforces geographic coordinates, which I did not know. So QGIS' project on the fly visually was not showing a true rectangle versus the underlying (in my case) local UTM. I had done quick tests with min_bounding_rect.py at large scales only, and tests with minimum_rotated_rectangle at small scale only. Obviously at large scale the difference in the projection were not as noticeable so the two calls appeared to have different results. Using the same projections for minimum rectangle and the underlying in a non-KML format works as intended.
Hello everyone :) As a completely freshman to pygeos, I just have simple question on data input format when constructing a geometry in pygeos: is there other input data format possible other than string?
I want to construct polygon, whose boundary points are returned from a list of numbers....it's quite cumbersome to convert it in the desired string format.
I want to construct polygon, whose boundary points are returned from a list of numbers....it's quite cumbersome to convert it in the desired string format.
@Aniwax you can pass arrays of coordinates, see the docs here https://pygeos.readthedocs.io/en/latest/creation.html (for linearrings and polygons)
Hey folks, working on a project and ran into a bunch of "illegalArgumentException: Geometry must be a Point or LineString" when exporting a dataframe to json (or passing it into rasterstats). Any idea what could cause this? The geometry seems valid and plots fine. I'm using Shapely 1.8a1 but unable to reproduce with sample data. This data is a large set of isochrones created using the Mapbox API.
Happy to create a ticket but didn't want to clutter things up if there's something I should try first
The project is analyzing internet connectivity in Kazakhstan for Unicef GIGA