Add GeoJSON display class #10253

Merged
merged 1 commit into from Feb 7, 2017

Conversation

Projects
None yet
4 participants
@gnestor
Contributor

gnestor commented Feb 7, 2017

@rgbkrk

rgbkrk approved these changes Feb 7, 2017

@rgbkrk

rgbkrk approved these changes Feb 7, 2017

@rgbkrk

This comment has been minimized.

Show comment
Hide comment
@rgbkrk

rgbkrk Feb 7, 2017

Member

Oops, I approved twice. It must be really good, since I also approved of it in the JupyterLab extension. 😉

Member

rgbkrk commented Feb 7, 2017

Oops, I approved twice. It must be really good, since I also approved of it in the JupyterLab extension. 😉

@gnestor

This comment has been minimized.

Show comment
Hide comment
@gnestor

gnestor Feb 7, 2017

Contributor

I tested locally and it's working:

from IPython.display import GeoJSON

GeoJSON({
    "type": "Feature",
    "geometry": {
        "type": "Point",
        "coordinates": [-118.4563712, 34.0163116]
    },
    "properties": {
        "name": "Clover Park"
    }
})
Contributor

gnestor commented Feb 7, 2017

I tested locally and it's working:

from IPython.display import GeoJSON

GeoJSON({
    "type": "Feature",
    "geometry": {
        "type": "Point",
        "coordinates": [-118.4563712, 34.0163116]
    },
    "properties": {
        "name": "Clover Park"
    }
})
@rgbkrk

This comment has been minimized.

Show comment
Hide comment
@rgbkrk

rgbkrk Feb 7, 2017

Member

Do we have tests for the HTML or other display functions that we could use here as well to make sure this gets covered?

Member

rgbkrk commented Feb 7, 2017

Do we have tests for the HTML or other display functions that we could use here as well to make sure this gets covered?

@gnestor

This comment has been minimized.

Show comment
Hide comment
@gnestor

gnestor Feb 7, 2017

Contributor

Good call. There is a test_json that I could use for reference: https://github.com/ipython/ipython/blob/master/IPython/core/tests/test_display.py#L137-L164

Contributor

gnestor commented Feb 7, 2017

Good call. There is a test_json that I could use for reference: https://github.com/ipython/ipython/blob/master/IPython/core/tests/test_display.py#L137-L164

@Carreau Carreau added this to the 6.0 milestone Feb 7, 2017

@Carreau Carreau merged commit 3ce26ed into ipython:master Feb 7, 2017

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@ellisonbg

This comment has been minimized.

Show comment
Hide comment
@ellisonbg

ellisonbg Feb 7, 2017

Member
Member

ellisonbg commented Feb 7, 2017

@Carreau

This comment has been minimized.

Show comment
Hide comment
@Carreau

Carreau Feb 7, 2017

Member

We might want to add that in the what's new. We can refine in subsequent PR.
ALso at some point we should try to register things with entry-points not to block on IPython releases.

Member

Carreau commented Feb 7, 2017

We might want to add that in the what's new. We can refine in subsequent PR.
ALso at some point we should try to register things with entry-points not to block on IPython releases.

@gnestor

This comment has been minimized.

Show comment
Hide comment
@gnestor

gnestor Feb 7, 2017

Contributor

ALso at some point we should try to register things with entry-points not to block on IPython releases.

@Carreau Can you clarify?

We might want to add that in the what's new.

I'm happy to do this. I assume a new release section will be added to version5.rst?

Contributor

gnestor commented Feb 7, 2017

ALso at some point we should try to register things with entry-points not to block on IPython releases.

@Carreau Can you clarify?

We might want to add that in the what's new.

I'm happy to do this. I assume a new release section will be added to version5.rst?

@rgbkrk

This comment has been minimized.

Show comment
Hide comment
@rgbkrk

rgbkrk Feb 7, 2017

Member

I'm so looking forward to the next IPython release now that we have updating displays and GeoJSON built-in. 🦅

Member

rgbkrk commented Feb 7, 2017

I'm so looking forward to the next IPython release now that we have updating displays and GeoJSON built-in. 🦅

@ellisonbg

This comment has been minimized.

Show comment
Hide comment
@ellisonbg

ellisonbg Feb 7, 2017

Member
Member

ellisonbg commented Feb 7, 2017

@gnestor

This comment has been minimized.

Show comment
Hide comment
@gnestor

gnestor Feb 7, 2017

Contributor

@rgbkrk So I haven't been able to get display updates to work in notebook or lab. It's implemented in both, isn't it? I'm running them and ipython from master...

Contributor

gnestor commented Feb 7, 2017

@rgbkrk So I haven't been able to get display updates to work in notebook or lab. It's implemented in both, isn't it? I'm running them and ipython from master...

@rgbkrk

This comment has been minimized.

Show comment
Hide comment
@rgbkrk

rgbkrk Feb 7, 2017

Member

Should be in notebook, we certainly merged it. Has to be master of ipython, ipykernel, and notebook.

Member

rgbkrk commented Feb 7, 2017

Should be in notebook, we certainly merged it. Has to be master of ipython, ipykernel, and notebook.

@ellisonbg

This comment has been minimized.

Show comment
Hide comment
@ellisonbg

ellisonbg Feb 7, 2017

Member
Member

ellisonbg commented Feb 7, 2017

@Carreau

This comment has been minimized.

Show comment
Hide comment
@Carreau

Carreau Feb 7, 2017

Member

@Carreau Can you clarify?

Basically any update to the display mechanism need update to IPython itself that can take a year or so to get released. It would be better to provide a mechanism for other packages to provide this. In Python that would be entry-points.

Then you can "just" update/publish an ipython-geosjon, ipython-vegalite, ipython-mp3 , ipython-pdf , ipython-midi ... and have IPython auto discover these.

Then in case of updates needed, a new release of IPython is not necessary.

Member

Carreau commented Feb 7, 2017

@Carreau Can you clarify?

Basically any update to the display mechanism need update to IPython itself that can take a year or so to get released. It would be better to provide a mechanism for other packages to provide this. In Python that would be entry-points.

Then you can "just" update/publish an ipython-geosjon, ipython-vegalite, ipython-mp3 , ipython-pdf , ipython-midi ... and have IPython auto discover these.

Then in case of updates needed, a new release of IPython is not necessary.

@ellisonbg

This comment has been minimized.

Show comment
Hide comment
@ellisonbg

ellisonbg Feb 7, 2017

Member
Member

ellisonbg commented Feb 7, 2017

@Carreau

This comment has been minimized.

Show comment
Hide comment
@Carreau

Carreau Feb 7, 2017

Member

One other reason is that this is targeted as IPython 6.0, so only Python 3 users will have access to it.

Member

Carreau commented Feb 7, 2017

One other reason is that this is targeted as IPython 6.0, so only Python 3 users will have access to it.

@ellisonbg

This comment has been minimized.

Show comment
Hide comment
@ellisonbg

ellisonbg Feb 7, 2017

Member
Member

ellisonbg commented Feb 7, 2017

@Carreau

This comment has been minimized.

Show comment
Hide comment
@Carreau

Carreau Feb 7, 2017

Member

Hmmm...good point. Overall, I don't mind if we have nice things in 6.0 that
aren't going to be available for users in python2. That is the carrot part
of moving people to python 3...

So maybe in this case I am ok with that.

I agree but, as someone have to play devil advocate this will put some extra weight on implementers of libraries if they want to be Py2 and Py3.

And to disagree with myself, anyway if py2/py3 is not a lot more complicated than checking IPython version, so I'm unsure it really matters.

Member

Carreau commented Feb 7, 2017

Hmmm...good point. Overall, I don't mind if we have nice things in 6.0 that
aren't going to be available for users in python2. That is the carrot part
of moving people to python 3...

So maybe in this case I am ok with that.

I agree but, as someone have to play devil advocate this will put some extra weight on implementers of libraries if they want to be Py2 and Py3.

And to disagree with myself, anyway if py2/py3 is not a lot more complicated than checking IPython version, so I'm unsure it really matters.

@rgbkrk

This comment has been minimized.

Show comment
Hide comment
@rgbkrk

rgbkrk Feb 7, 2017

Member

A long time ago I remember voting in favor of Python3 only for the server, it's been annoying that we're not doing ipykernel and ipython fixes across 2 and 3. However, I haven't been putting maintainership cycles into ipython (except for some small things), so I feel I don't have much sway on this.

Member

rgbkrk commented Feb 7, 2017

A long time ago I remember voting in favor of Python3 only for the server, it's been annoying that we're not doing ipykernel and ipython fixes across 2 and 3. However, I haven't been putting maintainership cycles into ipython (except for some small things), so I feel I don't have much sway on this.

@gnestor

This comment has been minimized.

Show comment
Hide comment
@gnestor

gnestor Feb 7, 2017

Contributor

To come back around to the GeoJSON display class, currently the tile layer options are hard-coded in the renderer but perhaps they should be configurable from the GeoJSON class? E.g.

GeoJSON(data, tileUrlTemplate, tileLayerOptions)
Contributor

gnestor commented Feb 7, 2017

To come back around to the GeoJSON display class, currently the tile layer options are hard-coded in the renderer but perhaps they should be configurable from the GeoJSON class? E.g.

GeoJSON(data, tileUrlTemplate, tileLayerOptions)
@rgbkrk

This comment has been minimized.

Show comment
Hide comment
@rgbkrk

rgbkrk Feb 7, 2017

Member

To add on, we're thinking tileUrlTemplate: string and tileLayerOptions: dict because of the Leaflet options.

Member

rgbkrk commented Feb 7, 2017

To add on, we're thinking tileUrlTemplate: string and tileLayerOptions: dict because of the Leaflet options.

@gnestor gnestor referenced this pull request in jupyter-attic/jupyterlab_geojson Feb 8, 2017

Closed

[WIP] Move GeoJSON display class to IPython.display #26

@gnestor

This comment has been minimized.

Show comment
Hide comment
@gnestor

gnestor Feb 9, 2017

Contributor

@ellisonbg Are you aware of a way to access the metadata property of an output from a mimerender extension? I updated the GeoJSON display class to accept additional options (url_template and layer_options) so it's in the metadata, I just don't know how to access on render... 🤔

Contributor

gnestor commented Feb 9, 2017

@ellisonbg Are you aware of a way to access the metadata property of an output from a mimerender extension? I updated the GeoJSON display class to accept additional options (url_template and layer_options) so it's in the metadata, I just don't know how to access on render... 🤔

@gnestor gnestor referenced this pull request in jupyter-attic/jupyterlab_geojson Feb 10, 2017

Closed

Expansion to planetary bodies? #27

@gnestor gnestor deleted the gnestor:geojson branch Feb 23, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment