Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SMOKES] Dynamic VS Vector decision + Vector Infowindows / Tooltips #1624

Merged
merged 80 commits into from
Jun 5, 2017

Conversation

pabletecodes
Copy link
Contributor

@pabletecodes pabletecodes commented Apr 17, 2017

This PR implements 3 things:

  1. VisView (and MapView) is now rendered after the map is first reloaded.
  2. CARTO.js now decides whether to use vector or raster. DEPENDS ON Include stats in the response to map instantiation requests Windshaft-cartodb#664.
  3. Infowindows & Tooltips for vector rendering.

We'll be running some SMOKE tests for these changes.

Fixes: CartoDB/cartodb#11783

@pabletecodes pabletecodes requested a review from donflopez April 18, 2017 11:30
Copy link
Contributor

@donflopez donflopez left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🇪🇸

@donflopez donflopez self-assigned this Apr 19, 2017
@donflopez
Copy link
Contributor

I did the acceptance steps and it works perfectly.

One thing, vector will not work because it needs some changes that are under dynamic-raster-vs-vector-decision-2 and a new release of tangram.cartodb

@pabletecodes
Copy link
Contributor Author

True fact @donflopez! Should we cherry-pick those changes so that we can release this?

@donflopez
Copy link
Contributor

Yes, sure!

@donflopez
Copy link
Contributor

I already did this! We should try it in staging.

@donflopez
Copy link
Contributor

It is working on ded02, if you want to try @alonsogarciapablo, I think we're ready to merge :)

@donflopez
Copy link
Contributor

Well, I just tried with a torque map and it fails with the next error:

vis-view.js:104 Uncaught TypeError: Cannot read property 'invalidateSize' of undefined

At the API level, this optional setting/option is still called `vector`.
It can be set to `true` to enforce vector rendering or `false` to
enforce raster rendering. Any other value or not passing this option at
all, will enable the auto render mode, and the library will try to
use vector rendering by default.
@donflopez donflopez force-pushed the render-view-after-first-reload branch from 32e2fb7 to 9db7d49 Compare April 20, 2017 11:02
@donflopez
Copy link
Contributor

donflopez commented Apr 20, 2017

Torque is now working, it needs this changes on deep-insights.js

@donflopez
Copy link
Contributor

I've noticed that the time series widget is not being animated like the map content.

@pabletecodes
Copy link
Contributor Author

retest this please

@donflopez
Copy link
Contributor

donflopez commented May 19, 2017

Important reminder!

Some properties set by default are not supported by Tangram and the decision always goes for raster.

We have to think which solution is the best for this cases:

1.- Support those properties.

This can be a pain where most hurt. It is gonna take time and collaboration with Mapzen.

2.- Remove those properties from default ccss.

This has some inconveniences that @makella can explain better than me, some of them are that raster needs some of them to make the visualisations smoother and we have raster in Builder.

3.- Ignore those properties in Tangram.

IMO, this is the best option because we don't affect to the Builder visualisation and we can get rid of those properties that doesn't affect pretty much in visualisations terms in vector.

cc/ @javisantana, @jorgesancha, @rochoa, @makella

@makella
Copy link

makella commented May 19, 2017

The one property that we have by default that isn't supported by Tangram is the polygon-gamma as @donflopez mentioned, this smooths out polygonal data and makes a big difference with things like choropleth maps.

On the other hand, the only place that we have this default is when polygons are first added. As soon as the user modifies any styling property, polygon-gamma and any other custom styling properties are lost so in reality, it isn't a big deal.

Paco and I did some testing and it seemed that the Tangram rendering did an ok job with the rendering so I'd agree with him that if we can ignore these properties and still get the map to vector rendering that would be preferable instead of something like polygon-gamma being something that stops people from getting vector maps.

@donflopez
Copy link
Contributor

donflopez commented May 19, 2017

I'd like to add some other properties that aren't fully supported like line-comp-op: soft-light we only support multiply, add and overlay at this moment.

Thank you @makella! 🙂

@makella
Copy link

makella commented May 19, 2017

@donflopez oh yes, that's another default cartocss property for polygons :)

@pabletecodes
Copy link
Contributor Author

pabletecodes commented May 22, 2017

@makella thanks for your input! ❤️

So the idea is to ignore all of the default properties that are not supported by tangram? Should we make a list of these properties or they are just the ones you guys already mentioned (polygon-gamma and line-comp-op: soft-light)? Not sure if other types of geometries have some unsupported props. Here's the default CartoCSS:

#layer['mapnik::geometry_type'=1] {
  marker-width: 7;
  marker-fill: #FFB927;
  marker-fill-opacity: 0.9;
  marker-line-color: #FFF;
  marker-line-width: 1;
  marker-line-opacity: 1;
  marker-placement: point;
  marker-type: ellipse;
  marker-allow-overlap: true;
}
#layer['mapnik::geometry_type'=2] {
  line-color: #3EBCAE;
  line-width: 1.5;
  line-opacity: 1;
}
#layer['mapnik::geometry_type'=3] {
  polygon-fill: #374C70;
  polygon-opacity: 0.9;
  polygon-gamma: 0.5;
  line-color: #FFF;
  line-width: 1;
  line-opacity: 0.5;
  line-comp-op: soft-light;
}

Also, not sure if auto-styling might set some props that won't work with Tangram.

@makella you're the boss here! Thanks!

cc: @jorgesancha

@javisantana
Copy link
Contributor

If outostyle set a not suported property we should remove it if it's not that important or add support for it.

For example, in case of line-comp-op: soft-light we should remove it from autostyle or default style.

I understand the visual quality is not the same but we should take into account we can't do everything and we need to cut scope at some point

@pabletecodes
Copy link
Contributor Author

We are going to release this internally as is and we can then continue with this discussion and tune things a bit more.

@pabletecodes
Copy link
Contributor Author

Retest this please!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants