Opened 7 years ago

Last modified 5 years ago

#3292 new enhancement

Query on spatially overlapped features in one vector map

Reported by: hcho Owned by: grass-dev@…
Priority: normal Milestone: 7.6.2
Component: Vector Version: svn-trunk
Keywords: query Cc:
CPU: Unspecified Platform: Unspecified

Description

Currently, v.what and the GUI query tool (based on v.what) can only find one feature that is the nearest from the user-specified location. Most of the time, this is OK, but when there are features overlapping each other, the user cannot query them all. It would be great to be able to find all features at a location, just like v.edit tool=select coor= using Vect_select_lines_by_polygon() instead of Vect_find_line().

I attached a modified version of what.c for v.what and vector.py for GUI. These files query multiple overlapping line features in one vector map, but I wouldn't say that this is a good implementation because I'm not very familiar with the GUI code, which works together with v.what.

Attachments (2)

what.c (18.7 KB ) - added by hcho 7 years ago.
v.what/what.c
vector.py (12.4 KB ) - added by hcho 7 years ago.
lib/python/script/vector.py

Download all attachments as: .zip

Change History (18)

by hcho, 7 years ago

Attachment: what.c added

v.what/what.c

by hcho, 7 years ago

Attachment: vector.py added

lib/python/script/vector.py

comment:1 by hcho, 7 years ago

Possible enhancements to the attached vector.py: Tree view for Features in JSON

comment:2 by annakrat, 7 years ago

Since this can potentially break scripts which rely on the JSON output, it should be used only when requested, so a new flag (-m as 'multiple') would solve this. And I think it makes sense to allow user to choose if they want one or multiple results.

Also the json output must follow the same hierarchy for points, lines and areas. Currently areas behave differently:

{
	"Coordinates": {
		"East": "640122.510114",
		"North": "235832.342168"
	},
	"Maps": [{
		"Map": "bridges",
		"Mapset": "PERMANENT",
		"Features": [{
			"Type": "Point",
			"Id": 3932,
			"Categories": [{
				"Layer": 1,
				"Category": 3932
			}]
		}]
	}]
}
{
	"Coordinates": {
		"East": "640122.510114",
		"North": "235832.342168"
	},
	"Maps": [{
		"Map": "lakes",
		"Mapset": "PERMANENT",
		"Features": [],
		"Type": "Area",
		"Sq_Meters": 373.733,
		"Hectares": 0.037,
		"Acres": 0.092,
		"Sq_Miles": 0.0001,
		"Categories": [{
			"Layer": 1,
			"Category": 3813
		}]
	}]
}

From brief testing, this command creates invalid JSON: v.what -d -j map=bridges@PERMANENT coordinates=641178,235089 distance=100

It would be great if you could update the v.what implementation and I could try to implement the tree for features in the GUI query dialog.

Please upload a diff instead of the entire file.

comment:3 by annakrat, 7 years ago

Component: DefaultVector
Keywords: query added
Milestone: 7.2.17.4.0

comment:4 by hcho, 7 years ago

Check r70700. -m flag should output valid JSON.

v.what -d map=bridges@PERMANENT coordinates=641178,235089 distance=100 -jm

outputs

{
   "Coordinates":{
      "East":"641178",
      "North":"235089"
   },
   "Maps":[
      {
         "Map":"bridges",
         "Mapset":"PERMANENT",
         "Features":[
            {
               "Feature_max_distance":100.000000,
               "Id":3985,
               "Type":"Point",
               "Left":0,
               "Right":0,
               "Categories":[
                  {
                     "Layer":1,
                     "Category":3985
                  }
               ]
            }
         ]
      }
   ]
}

Another example JSON output:

{
   "Coordinates":{
      "East":"3303269.05023",
      "North":"504062.5"
   },
   "Maps":[
      {
         "Map":"lfp",
         "Mapset":"tmp",
         "Features":[
            {
               "Type":"Line",
               "Id":537,
               "Length":55131.571388,
               "Categories":[
                  {
                     "Layer":1,
                     "Category":215646882
                  }
               ]
            },
            {
               "Type":"Line",
               "Id":328,
               "Length":67346.659403,
               "Categories":[
                  {
                     "Layer":1,
                     "Category":124085340
                  }
               ]
            },
            {
               "Type":"Line",
               "Id":536,
               "Length":69806.020152,
               "Categories":[
                  {
                     "Layer":1,
                     "Category":215016485
                  }
               ]
            },
            {
               "Type":"Line",
               "Id":183,
               "Length":97443.201949,
               "Categories":[
                  {
                     "Layer":1,
                     "Category":62974869
                  }
               ]
            },
            {
               "Type":"Line",
               "Id":326,
               "Length":86823.383054,
               "Categories":[
                  {
                     "Layer":1,
                     "Category":122824546
                  }
               ]
            },
            {
               "Type":"Line",
               "Id":535,
               "Length":83302.062710,
               "Categories":[
                  {
                     "Layer":1,
                     "Category":214386088
                  }
               ]
            }
         ]
      }
   ]
}

Now, it would be great if you could implement a new query button for multiple queries.

comment:5 by annakrat, 7 years ago

In 70703:

pythonlib vector_what: add support for finding multiple features implemented in v.what (see #3292)

comment:6 by annakrat, 7 years ago

In 70704:

wxGUI: return multiple features within query distance when querying vector map, see #3292

comment:7 by annakrat, 7 years ago

I implemented it in python scripting library and in GUI query dialog I put it as default. I am not sure if we need to make it optional, it seems like a useful behavior to me.

One more problem I found occurs with areas:

v.what map=lakes coordinates=635886.454183,223255.976096 distance=100 -jm type=area

It's invalid json and there are duplicate records:

{
	"Coordinates": {
		"East": "635886.454183",
		"North": "223255.976096"
	},
	"Maps": [{
		"Map": "lakes",
		"Mapset": "PERMANENT",
		"Features": [{,
			"Type": "Area",
			"Sq_Meters": 596589.425,
			"Hectares": 59.659,
			"Acres": 147.420,
			"Sq_Miles": 0.2303,
			"Categories": [{
				"Layer": 1,
				"Category": 8055
			}]
		}, {,
			"Type": "Area",
			"Sq_Meters": 596589.425,
			"Hectares": 59.659,
			"Acres": 147.420,
			"Sq_Miles": 0.2303,
			"Categories": [{
				"Layer": 1,
				"Category": 8055
			}]
		}, {,
			"Type": "Area",
			"Sq_Meters": 596589.425,
			"Hectares": 59.659,
			"Acres": 147.420,
			"Sq_Miles": 0.2303,
			"Categories": [{
				"Layer": 1,
				"Category": 8055
			}]
		}]
	}]
}

Vect_select_areas_by_polygon documentation says Warning : values in list may be duplicate, but I have no idea why.

comment:8 by hcho, 7 years ago

As for making it default, I agree with you that this behavior is useful especially when the user doesn't know if he has overlapping features. He may never know if there are multiple features until he uses the -m flag.

Selecting duplicate areas is fixed in r70711.

comment:9 by hcho, 7 years ago

I just tried the new query and it's working. Would it be possible to group results by map?

in reply to:  9 ; comment:10 by annakrat, 7 years ago

Replying to hcho:

I just tried the new query and it's working. Would it be possible to group results by map?

Yes, I will look into it later.

in reply to:  10 comment:11 by hcho, 7 years ago

Replying to annakrat:

Replying to hcho:

I just tried the new query and it's working. Would it be possible to group results by map?

Yes, I will look into it later.

Thanks. Keep in mind that v.what still has single query per map by default. No grouping is needed for the default behavior. Still, I'm not sure if it's a good idea to keep both queries in v.what. I believe that -m is more user friendly and I'll use it almost always. Maybe, make it default for the next release and remove the single query?

comment:12 by neteler, 6 years ago

Milestone: 7.4.07.4.1

Ticket retargeted after milestone closed

comment:13 by neteler, 6 years ago

Milestone: 7.4.17.4.2

comment:14 by martinl, 6 years ago

Milestone: 7.4.27.6.0

All enhancement tickets should be assigned to 7.6 milestone.

comment:15 by martinl, 5 years ago

Milestone: 7.6.07.6.1

Ticket retargeted after milestone closed

comment:16 by martinl, 5 years ago

Milestone: 7.6.17.6.2

Ticket retargeted after milestone closed

Note: See TracTickets for help on using tickets.