This is one of the pending functionalities from Editor. Basically the user could export the map viewport to an image. There will be several options to be chosen like:
- The size (width and height) by typing the pixel size.
- Drag handles of the export bounding box to manually resize the image.
- Image extension.
- ~Show legends~ -> not for the moment.
- ~Show widgets~ -> not for the moment.
Of course the creation of the map image will need some time, that's the reason why we need a loading modal window. Similar to the export map functionality.
Some tips
- Map controls should not be present in the image or in the preview.
- Map attribution should appear YES or YES in the right bottom corner (check design).
- We should not remove anything from the map in the preview (like legend, widgets, map controls,...), we could "hide" (tricky way) those and when user finishes with image-export, display again those elements.
- Take care of image exports when a torque style (animated or pixel) is applied, would it work?.
Design: https://github.com/CartoDB/design/issues/340
PR: https://github.com/CartoDB/cartodb/pull/11789
urbanphes
All 39 comments
Note that the strict requirement is to export to PNG. If adding JPG is hard, we should wait to see if it makes sense to prioritise or not.
jorgesancha
on 2 Mar 2017
It is already implemented in the Maps API, so no difficulty added.
xavijam
on 2 Mar 2017
Also, https://carto.com/docs/carto-editor/maps#export-image.
xavijam
on 2 Mar 2017
One question regarding this ticket. Technically, for maps that use Google Maps basemaps we can generate an image that shows the geometries, but not the basemap below… should we want to inform users about this somehow in the UI?
javierarce
on 8 Mar 2017
cc @noguerol @saleiva @asimcox ^^^
xavijam
on 8 Mar 2017
javisantana
on 8 Mar 2017
but, for that case google maps has a static maps api so we could reach that api and merge frontend side
javisantana
on 8 Mar 2017
Bad news.
Yesterday I talked with @javierarce and @xavijam about how to solve this using existing static images from named maps (as we do for the dashboard previews). The named maps static images can use zoom, longitude, and latitude params.
However, that doesn't consider applied filters to the map and will export images with no filters applied, so we cannot rely on that functionality for exporting the images. We will need to use the current map instance to retrieve the adequate version (with filters applied) of the map in sight.
rochoa
on 9 Mar 2017
Ok, we'll need to use cdb.Image, but it seems it was removed some time ago (because it didn't work with cartodb.js v4?): https://github.com/CartoDB/cartodb.js/commit/2834c95959a09b1ad57500b6c0f4eff75ab6b1e3
cc: @alonsogarciapablo
javierarce
on 10 Mar 2017
After talking with @rochoa, @alonsogarciapablo & @xavijam last week, we decided to reenable, in the current v4 version of cartodb.js, the static image generation functionality that we previously had.
Initially, we won't be supporting the exact same API that cdb.Image had, just enough methods to generate an image from a visualization providing: a center (lat & lng) or a bounding box, a width and a height and the zoom level.
We also decided not to support static maps with basemaps with google maps at this moment, so the static maps in that particular case will only show geometries. @urbanphes and @noguerol: we should see if in that particular case we should show a message to our users.
javierarce
on 13 Mar 2017
So, considering the last comment, we probably have a problem regarding the current Google + image export use case we should attend, right @javisantana?
In other words, we need Google Maps support.
noguerol
on 14 Mar 2017
@alonsogarciapablo tells me that in the case of a private dataset, we'll need to use the API key. I imagine that we won't want to expose it in the UI (a user could accidentally pick the URL and paste it in a website).
What should we do in that case, @noguerol? Should we hide the URL when the map is private and only allow to download the image?
javierarce
on 14 Mar 2017
Also, we should take into account that the image URL will "expire" (i.e: not work) after some time. IMHO, we shouldn't expose it in the UI.
alonsogarciapablo
on 14 Mar 2017
I agree, although don't know if the use case is to have a URL, download the image or both, @noguerol.
If it's just having an image, we could use the same solution as in the previous version of this feature: the URL that appeared was linked to the image object (see bottom of the page), so in the regular case it wasn't possible to grab the URL (only when using the advanced mode was possible to get it)
javierarce
on 14 Mar 2017
We should not expose the API key. We can enforce the image download via html, right?
noguerol
on 14 Mar 2017
@alonsogarciapablo will those temporal urls work without being logged in? Because in that case this could be a liability and we should think about a way to obscure the url.
noguerol
on 14 Mar 2017
We can enforce the image download via html, right?
Yes, see the attached picture in my previous comment.
@alonsogarciapablo will those temporal urls work without being logged in? Because in that case this could be a liability and we should think about a way to obscure the url.
Since we can't show the complete URL purely because of its size, we can truncate it and just show the first part that won't contain the API KEY. Or we could just use a text for the link instead of the URL.
javierarce
on 14 Mar 2017
@alonsogarciapablo will those temporal urls work without being logged in?
Yes, they are "public" URLs.
alonsogarciapablo
on 15 Mar 2017
Here's a summary of the things we've talked offline between us:
- We'll implement the integration with the Static Google Maps in the frontend/builder side and not cartodb.js.
- The implementation will be tracked on its own issue.
- We'll add a feature a flag for this feature and release it without the Static GMap integration, to speed up the release of the feature.
Suggested feature flag: static-maps.
javierarce
on 15 Mar 2017
Problem to the url issue is we can not have users sharing images with third parties with an exposed api key. I propose we get rid of the final download modal window and we directly trigger download from the "export" button in the export pane.
cc @urbanphes
noguerol
on 15 Mar 2017
Ok, another change we've discussed offline with @noguerol & @urbanphes:
- Since we can't expose the URLs, that makes the modal unnecessary… we are going to get rid of it and download the image when users click on the export button (while the image is being generated, we'll disable the Export button)
- @urbanphes will create a ticket to design a button with a loader (but we won't be using it in the first iteration of this feature)
javierarce
on 15 Mar 2017
We have a button loading that we can use for this case.
When you update the map, this button has a loading icon inside the button.
cc/ @javierarce @noguerol
urbanphes
on 16 Mar 2017
Oh, that's true, good catch 💋
xavijam
on 16 Mar 2017
Oh nice @javierarce what do you think
noguerol
on 16 Mar 2017
I think is time to implement it ;) I'll update the form with that kind of button.
javierarce
on 16 Mar 2017
:*
saleiva
on 16 Mar 2017
Chavales, this is looking good. Some things:
- We are including our logo in the images, as @xavijam suggested, but this goes to another ticket
- Out of bounding box image crop should be provided, specially because our low resolution users will probably be the ones using more this feature. We should show an "out of viewport" notification with a reset button next to the size input, as @xavijam suggested cc @urbanphes
- Maps with custom color basemaps only export geometries cc @alonsogarciapablo
noguerol
on 17 Mar 2017
About point 2. that was second version if I don't recall wrong
saleiva
on 17 Mar 2017
- Maps with custom color basemaps only export geometries cc @alonsogarciapablo
@javierarce is going to update CartoDB.js cause it was a bit behind. Let's try again with latest changes.
alonsogarciapablo
on 17 Mar 2017
@saleiva true, but we had to give support to that in order to support crop selection free movement, which is required, but this opens a UI conflict with crop areas out of the viewport bounds.
noguerol
on 17 Mar 2017
I don't get the dependency @noguerol. I'd just force the crop selection area to be inside the viewport.
saleiva
on 21 Mar 2017
Well, then I'm happy we have already developed it out of the scope, even if it was by accident, as it will be much of a need for corporate low res scenarios.
noguerol
on 21 Mar 2017
It is blocked until we don't have https://github.com/CartoDB/cartodb.js/pull/1598 merged in CARTO.js.
xavijam
on 27 Mar 2017
@noguerol apart from you, @urbanphes should also pass acceptance here :)
saleiva
on 27 Mar 2017
Ok, I didn't know but we have three dependencies:
- [x] [CartoDB.js problem](https://github.com/CartoDB/cartodb.js/issues/1606).
- [x] https://github.com/CartoDB/Windshaft-cartodb/issues/653.
- [x] ~CARTO.js PR with new export image functionality~ -> Merged!.
xavijam
on 28 Mar 2017
Deploying frontend changes, but ticket will keep opened until we have all pieces in production 🤗 .
xavijam
on 29 Mar 2017
CARTO.js problem fixed and in production, thanks @alonsogarciapablo 💋 .
xavijam
on 30 Mar 2017
Maps API changes have been promoted to production 🎉 .
rochoa
on 3 Apr 2017
MÁQUINAS!
xavijam
on 3 Apr 2017
Related issues
jesusbotella
·
4Comments
rochoa
·
3Comments
xavijam
·
3Comments
makella
·
3Comments
arianaescobar
·
5Comments