Throw error for invalid coordinates

[elizawe]

When given correctly formatted but invalid coordinates, Palladio tries to graph the data–placing it on the edge of the map–but will not zoom to fit them or notify the user that they are invalid.

[esjewett]

This is great. Do you have a Palladio save file with one of these sorts of coordinates that you can attach here? Thanks!

[elizawe]

You can take the SF Civic Art sample data from Breve and load it into Palladio as an example.

[esjewett]

@elizawe Thanks - will do!

[esjewett]

I'm adding a validation to the data loading function. It will flag if a dimension is set to be a Coordinates dimension but has latitude values < -90 or > 90.

[esjewett]

I think we should also add an indicator somewhere for "number of records not displayed". Not sure if that should be in the map view itself, or as a separate dimension. Thoughts?

[cncoleman]

Definitely. How would this work as a separate dimension?

[esjewett]

@cncoleman I've been planning to make a generated dimension for "non-mappable coordinate" that would have value "Not mapped" or some equivalent for coordinates that are blank or are invalid. Then this dimension could be used in a facet filter or as the grouping on the timeline in order to give the same sort of "Stacked bar chart of mapped vs non-mapped values" you had in the MRofL project.

[esjewett]

@cncoleman Alternative, we could just display a count indicator in the map legend or something like that.

[cncoleman]

Let's go with the generated dimension. It solves the problem in an elegant way that is consistent with the application logic (as you pointed out!).

[cncoleman]

But for this issue that Eliza brings up, it seems that we might want to add another consideration: swapping the order of coordinates. I know we have discussed in the past being more flexible about assigning coordinates. We've talked about assigning latitude and longitude separately (2 dimensions). Here are the options:

1. Require LatLon (as we do). Recognize coordinate format. Also check that the first value is not greater than 90_. That gives a bit of error checking, but forces a single data format.
2. Give greater flexibility in applying data formats: A. Lat and lon can be in one column as either latlon or lonlat. We guess based on the 90_ rule for lat. If we cannot tell, we force the user to specify; B. We let the user apply lat and lon to separate dimensions as data format.
3. We require latlon, throw an error if lat is out of range, and allow reversing of values in the column.