Search by revenue village, plot number

[davepaiva]

Is your feature request related to a problem? Please describe.
some areas do not appear in the search dropdown (for example "Panelim" near Old Goa). Also searching by plot nos would be very helpful
Describe the solution you'd like
cover all areas in Goa and search by plot number example ( "candolim 89/1-a")

[davepaiva]

thinking out loud:

Instead of using a DB (which will cost money), how about using JSON-based search index files to store the data?
Given the large number of plots that need to be stored (several MBs I am guessing), we can be smart and create different search indexes for separate talukas and villages. We then lazily load these based on some conditions. To aid to this we can adopt a similar UI to go online land records:

We create indexes for each taluka and their village to populate the dropdowns.
so if the user clicks on and focuses on Taluka we load the taluka JSON file ./taluka_list.json and show the taluka options. next, if user selects a particular taluka say Bardez then we fetch and load the list of villages in Bardez ./bardez_village_list.json and populate the village options . once user clicks in a specific village then we fetch the json file of that village which will contain the list of survey nos for that village and so on... till we have enough info to filter out the polygon that the user needs from the list of polygons for that village

We can combine this with a suitable caching layer and logic

[planemad]

@davepaiva that roughly looks like the way to go. As a starting step let's see how big a search index would be. Will generate a CSV lookup of taluk, village, survey number and lat/lng point coordinates.

[planemad]

The most basic lookup comes to 32 MB in this format

name,village,taluk,y,x
27/28,Cavorem,Quepem,15.15843,74.06284
12/1,Zormen,Sattari,15.57458,74.09417

This is a little heavy but small enough to lazy load as a single file if a user enables plot search.

[ramSeraph]

you can probably create a parquet file sorted by (taluk, village, survey number) and distribute it as part of the frontend( like any js file).. it will let a lazy loading of the data with minimal data tranfer to the frontend. The compression used by parquet might also reduce the data size.

[planemad]

you can probably create a parquet file

Great idea, will try it out

[planemad]

The parquet file is just 10MB 💪 . This looks ideal to load on demand.

Proposed UX workflow:

Introduction

• 
  When inspecting the goa-cadastral layer clicking any feature. This is controlled in map-layer-controls.js
• This will reveal a new button with text 'Search' after 'Export KML'
• Clicking the search button should close the inspect popup and hide the layer panel if visible. Display a search toolbar panel at the bottom of the map with an autocomplete text input. Now the user is in the layer search mode
• The input data for the search is a ./data/plot-search/src/goa_plot_lookup.parquet with the following schema

name,village,taluk,y,x
27/28,Cavorem,Quepem,15.15843,74.06284
12/1,Zormen,Sattari,15.57458,74.09417
..

• Filter the search data to only rows where village= currentVillage; currentVillage is already set from the previously inspected feature
• On the right of the search input add a button with the text of the filtered village value. If clicked, the search data filter is cleared and the search would be for the entire data.
• When the search input is empty, display the first 10 rows of the data. Update the search results as the user types
• The primary string to search in the data is the name. While displaying results, the primary label is name but also show the context of village and taluk
• For each search result drop a marker on the map with the name as the label at the x and y map position
• Dynamically update the markers based on the search result
• When a particular search result or marker is clicked, pan to the marker location at z16. Exit from the layer search mode in 10 seconds by moving it off bottom of the screen if there is no further change in search
• Implement this functionality as a separate js plugin map-search-panel.js

[ramSeraph]

This looks ideal to load on demand.

So, the idea behind the parquet file is that you won't even need to load the whole 10 MB file. You will be pulling in data as required using http range requests. the data itself is arranged into blocks( of configurable size ) with metadata and just reading metadata will allow us to pick which block to fully read.

I am not sure if the code for doing this from the browser already exists. I do see parquet-wasm but I haven't actually seen examples on how to use it.

This is something I have been planning to explore. If you can separate out an interface to query the data, like getAnyNrecords(n), getNRecordsOfVillage(n, vname).. I wouldn't mind having a go at it.