Dumb query

[stlim0730]

Even though we need to find a good way to smoothly join the three data tables on-the-fly, the basic query features should work.

This issue includes debugging query feature for survey data (currently broken) and finding a reasonable way to present query results without join operations.

I'm assigning myself to this issue.

[stlim0730]

@calo1, I think I solved the SQL join issue. More updates to come, but it seems that I found a way to do joins.

Minor issues and details related to it:

• I'm constructing the map layers from the scratch. The app won't simply import vizjson from CartoDB, but it will rely more on the code I'll write and more configuration data on admin panel. The settings on CartoDB should go to the admin panel. This requires a little chores that we should copy the cartocss for all the layers on CartoDB and paste it on the admin panel.
• For the same reason, my local copy of the app doesn't have interactivity including infowindow and so on. I should build those features using the app data mentioned above. One advantage of this is that we can improve the infowindow (e.g., display human readable values, etc).
• I'm trying to remove polygonaspoints layer in doing this process. I understand what you want from it, so I'm going to have data_polygon layer satisfies the requirement.
• Existing bugs on query UIs are gone.

[stlim0730]

Currently, parcel-only queries and survey-only queries are working like a charm with join operations across the layers.

A semantic issue, I believe not technical, is that queries that involve both parcel and survey data (queries where all the three tables are involved) will hardly display results due to sparseness of the dataset; the more filters applied, the less results displayed. Do we want to somehow apply "union" for this type of queries, in order to increase the chance that we see some results (this might also help development and debugging process)? If we do, how?

I'm still working on this type of queries, but I want to make sure how we want to deal with it.

@calo1, what do you think?

[stlim0730]

I pushed my updates and deployed the latest version to the production sever. Good to see the app with the fully functioning query feature.

I'll keep this issue open for a few days so that @calo1 can test it. Any comments are welcomed.

[stlim0730]

Just note that the map lost interactivity of infowindow becuase the app doesn't import vizjson data from Carto. I'll create another issue on getting back the basic on-map interactivity.

[calo1]

@stlim0730 Query works well, I tested it sufficiently. That is a big milestone! But I'm a little worried about how to manage changes in map styling and data ... If I make new layers or new CartoDB visualizations ... How will the application reflect the changes? The vizjson was the Adam-proof way of getting those styling in the app.

I have CartoCSS files for each layer. Should I drop them here?

[stlim0730]

@calo1, good point. The settings are hard-coded in the source for now. The settings can be (and must be) modeled and configured on the admin panel later. This will be everyone-proof way. I think you should copy and paste some settings and code snippets from Carto (there's no CartoDB now!) to the admin panel, at most. Or, if I can come up with good enough design within the code, the copy and paste might not be even needed. We'll found out what we want to configure or not.

Showing a warning message is a good idea that also addresses other general needs, such as Carto errors. I'll work on it with low-to-med priority on on-map-interaction branch.

Did you notice the basemap changed? Take a look at Mapbox (https://www.mapbox.com) and let me know your preferred map tile. Map tile configuration will be also part of the admin configuration later.

Map interactivity:
I don't think you should. I'll build the feature from the scratch by pulling the data from Carto. I'll let you know when I need further information on your Carto account and settings.

One minor error I found was that the app fails to query the unique no_land_available datapoint in data_point table. The reason is that the geoprocessing code has a typo; no_land_availalble. I hope @sohyeonlee can fix it on her branch that will be eventually merged into master.

[calo1]

@stlim0730 Also: A general goal is that Farmview can be a suit of tools to replicate in other agricultural counties. Severing the link to 'carto' means that technical expertise will be needed as more visualizations are changed or added.

[stlim0730]

@calo1, I understand your concern. Let me try to find the optimal way that doesn't really compromise the accessibility through Carto.

Improving Django admin panel's usability might be an option.

[calo1]

@stlim0730 small note: The legend is also defined with html via Carto

[stlim0730]

Now query works fine, so I'm closing this issue.
I'll create a new issue to address the concern raised in conversation on this thread.