Closed barryrowlingson closed 8 years ago
I've just noticed the geo_str option in the latest version, which should enable one-line geopandas mapping with
map.geo_json(geo_str=gp.to_json(), data=gp, columns=["name", "q"], key_on='feature.properties.name', ...etc)
but that still requires a keying process which is unnecessary when your geometry is in the same object as your data.
@barryrowlingson :+1: I agree it would be useful. Maybe it's not that difficult to write a wrapper around geo_json
to make it work. If somebody can give me a few pointers I might give it a try.
Hmmmm I haven't looked at GeoPandas yet, but it seems like an obvious integration. Will leave this open.
@barryrowlingson the main problem that is the name "geo_json
", that implies a GeoJSON
and not a GeoPandas
object. We could either introduce a new method that is more "duck type friendly." This method could take a GeoPandas
, GeoJSON
, Shapely
, GPX
and other similar objects and files.
We could then convert everything to GeoJSON
and add the layer or we could look into the Leaflet plugins that do that for us and, in same cases, preserve the data format.
Suggestions?
We can easily imagine a plugin doing that. It would look like:
map_osm.add_plugin(GeoPandas(gp))
But maybe we shall think about having a python object for storing geospatial data into folium. Something that would have methods like from_geojson
, from_gpx
, ... and methods like to_geojson
, to_leaflet
, etc. Not reinventing the wheel ; it may inherit from shapely
or geopandas
. What do you think ?
I am inclined towards from_geojson
, from_gpx
, and to_geojson
, to_leaflet
... But we already have geo_json
. Maybe we should break the API in a future version...
Ugh, I hate that I ever wrote the geo_json
method. Terrible API design.
Food for thought: If I Were To Rewrite This Today:
data_overlay
, to follow the image_overlay
convention.data_overlay
s could be GeoJSON, TopoJSON, GeoPandas object, whatever. overlay
is called, a FoliumDataSource
is created. This class would be the translation layer between the various file formats and GeoJSON, which would be used to build the map. No matter what data source is backing your FoliumDataSource
, and API to access GeoJSON from it will be the same. This is the API that data_overlay
will interact with. mark_cnt
, and the user should be able to easily remove overlays from their map. Ugh, I hate that I ever wrote the geo_json method. Terrible API design.
So we just got a license to kill :wink:
:+1: to all that. The _overlay
makes more sense. I have a problem with data_
and image_
though, I prefer vector_overlay
and raster_overlay
.
Yeah, totally agree on vector and raster. That's much better.
One thing you might want to do is leave the geo_json
method with a depreciation warning (see: https://github.com/pydata/pandas/blob/master/pandas/util/decorators.py#L8), and then have it call out to the vector_overlay
method for at least a couple more releases.
method with a depreciation warning
Kill it slowly and make it suffer. Got it!
@wrobstory it sound good, and similar to what I had in mind when putting the hand in the plugins.
If you're okay, a way of moving to this can be to have a plugin FoliumDataSource
, and then to move it to the core.
Yeah, that's fine. Feel free to make major structural changes without my ok- if it feels like the existing structure is holding you back, by all means break it up. Just need to make sure that the test suite is robust enough to catch everything during a major refactor.
Can we close this one ?
Yes. We have some integration with GeoPandas now. any additional functionality deserves a new issue.
Its possible to use Folium to map using data and geometry from a GeoPandas object, but it requires writing the GeoPanda geometry to geojson (using the .to_json method);
something like, for gp being a geopandas obejct:
and then you can map a column 'q' in the GeoPandas object:
It should be possible to remove the steps of writing the json and the keying for a GeoPandas frame. Something like: