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

Improve renderSpeciesPhenophases() handling of radius #19

Open
dhornbein opened this issue Apr 14, 2014 · 1 comment
Open

Improve renderSpeciesPhenophases() handling of radius #19

dhornbein opened this issue Apr 14, 2014 · 1 comment

Comments

@dhornbein
Copy link
Owner

The initial phenophases can appear too close to the center of the pClock. Currently the phenophase's index is multiplied by the initial radius.

js/pclock.renderer.js:96

for( var phenophase in phenophases ) {
      var start = phenophases[phenophase].start,
        end = phenophases[phenophase].end;
      if( start && end ){
        var phenophaseElement = this.paper.path().attr({
          "stroke": "#" + sp.color,
          "stroke-linecap": "round",
          "stroke-width": Math.max( this.options.strokeWidth * ( zoom * 0.075 * speciesIndex ), 3 )
        }).attr({
          arc: [ center.x, center.y, r * speciesIndex, start, end ]
        });
        phenophaseElement.node.setAttribute("class", slug );
        sp.registerPhenophaseElement( phenophaseElement );
      }
    }

There needs to be some way to set the radius "dead zone" in the middle and raise the increment between each phenophase by the stroke width rather than initial radius.

@thiagodemellobueno
Copy link
Collaborator

Remember that the amount of data on the chart, and current zoom level can fix all this... if the center gets crammed, but we can see more data when zoomed out, whats the harm?
It's not about looking good in a certain spot, as much as allowing access to the data in a variety of unpredictable circumstances.

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

No branches or pull requests

2 participants