search

humanitiesplusdesign / palladio

An application that brings humanities research methods to data visualization.
BSD 3-Clause "New" or "Revised" License
172 stars 32 forks source link

Unable to return map tooltip to default value after setting it to another variable #146

Closed mdlincoln closed 8 years ago

mdlincoln commented 8 years ago

Steps to reproduce this bug:

  1. Extend the main table with a new table whose foreign key column has the same name as the primary key column in the main table (sample data: population.csv as main, coordinates.csv as the secondary table)
  2. Go to the map view and add a layer of points. With the data above, the only option for Places should be city. At this point, Tooltip label should be automatically set to city. If you add the layer now, without changing Tooltip label, then everything plots fine, and the label displays as the city name.
  3. However, if you click on the tooltip label menu to pull up the Choose the dimension(s) box, only the variable coordinates will be listed. If you do select coordinates, it's impossible to deselect it and return to the default city value for the tooltip label.

I can only reproduce this when the joining columns on the two data tables have the same name. When they have different names (as they do in the Palladio sample data), then all the possible Tooltip options show up just fine.

esjewett commented 8 years ago

Thanks for the report, and sorry for the delay in responding. That is indeed a bug. I believe the data processing code currently assumes that the dimensions have unique column key names, which is a bad assumption to make especially for multiple tables.

I believe my approach to fixing this is going to be to force the names to be unique internally. Basically:

  1. When a new table is loaded, check each column key against column keys in tables that have already been loaded.
  2. If an identical key is found, change the new column key by appending a '_1'
  3. Return to step 1 but append '_2' if any are still duplicates. Etc.

The drawback of this approach is that if the data is then downloaded from Palladio again as CSV, the column key in the 2nd table will be 'city_1'. We could cover this up, but I'm not sure if that would be worthwhile.

Thoughts?

I'm doing a big refactoring right now but will try to include this fix in the next 1.2.0-beta release.

mdlincoln commented 8 years ago

No worries - and yes, I'd assumed something like that might be going on. I also agree with the tradeoff you suggest. From the use cases I've seen, it'd be more important to have the tooltips working fluidly than it would be to ensure that exported data remain faithful to their original input name.

On Thu, Apr 14, 2016 at 1:28 PM, Ethan Jewett notifications@github.com wrote:

Thanks for the report, and sorry for the delay in responding. That is indeed a bug. I believe the data processing code currently assumes that the dimensions have unique column key names, which is a bad assumption to make especially for multiple tables.

I believe my approach to fixing this is going to be to force the names to be unique internally. Basically:

  1. When a new table is loaded, check each column key against column keys in tables that have already been loaded.
  2. If an identical key is found, change the new column key by appending a '_1'
  3. Return to step 1

The drawback of this approach is that if the data is then downloaded from Palladio again as CSV, the column key in the 2nd table will be 'city_1'. We could cover this up, but I'm not sure if that would be worthwhile.

Thoughts?

I'm doing a big refactoring right now but will try to include this fix in the next 1.2.0-beta release.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/humanitiesplusdesign/palladio/issues/146#issuecomment-210065079

Matthew D. Lincoln Ph.D Candidate Department of Art History & Archaeology http://arthistory.umd.edu University of Maryland College Park, MD 20742

mlincol1@umd.edu matthewlincoln.net

mdlincoln commented 8 years ago

Also, in case someone at H+D is interested in examples of Palladio in use: I only ran in to this bug because of some very enthusiastic participants in a workshop at the Frick Collection who had set to work on some "extra credit" assignments to explore a few datasets on their own! This bug notwithstanding, they were very enthusiastic about showing the tool to other colleagues getting started on data exploration :)

esjewett commented 8 years ago

Sweet, thanks for the tip. We are very interested in understanding where Palladio is being used!

esjewett commented 8 years ago

This should be fixed once 1.2 is released. If you want to test locally, you can clone this repository and the palladio-app repository (https://github.com/humanitiesplusdesign/palladio-app) then follow the instructions in the palladio-app readme for testing palladio-app using the latest palladio framework.