Expanded spatial fields/search

[knownasilya]

Currently, only points are supported, and pretty basic search based on those points. To be positioned competitively with Elastisearch and other competitors, a broader spectrum of geospatial data types and querying capabilities would be needed.

Additional spatial data types like

• polygons
• multi-polygons
• lines
• Basically anything in the geojson spec

Querying should support

• intersects
• within
• radius
• buffer
• etc.

[jobergum]

Thanks @knownasilya for this detailed feature request!

[bratseth]

Are there any real use cases where this is more than a convenience?
You can always do a query with a radius and do a more fine filtering in code.

Applications with some complexity will add their own component in the stateless layer anyway. In general we're not really attempting to create declarative code for solving every use case, only the ones where computation close to data matters for performance.

[knownasilya]

only the ones where computation close to data matters for performance.

Use cases like find all fire departments in my county. Where the county isn't specified on the fire department data, but the fire department has a location. So you'd need to do a polygon query to see which fire departments intersect the county polygon.

Another example, I'm currently located at lat, long what property am I at? This requires doing an within query on the property polygon data with passed in latlong data.

I have a road, and I need to know which properties are along that road. Do a buffer on the road, and do an intersection of that buffer with all of the properties.

[yngveaasheim]

For the latter you can check out the distanceToPath() ranking feature as documented here:
http://docs.vespa.ai/documentation/geo-search.html
http://docs.vespa.ai/documentation/reference/rank-features.html

[knownasilya]

Thanks, forgot that was thee. Unfortunately, that would only work with documents that have points, not polygon data (or other spatial data types), is that correct?

[bratseth]

Yes, that is correct, Vespa do not provide any feature where a document can have a polygon, but that is not needed for your "on the road" use case, which is the one we know of where radius+post-filtering wouldn't be efficient.

Regarding

Use cases like find all fire departments in my county.

You could do retrieve all documents within a circle encompassing the county, and filter those that are outside. That is probably more efficient, and certainly more flexible.

By the way, in practice this kind of thing is often solved using place names instead of koordinates.

[knownasilya]

You could do retrieve all documents within a circle encompassing the county, and filter those that are outside. That is probably more efficient, and certainly more flexible.

But less accurate, and that is important for any federal, state and local government scenarios.

Regarding the "on the road" example, the same thing applies. For example, one property might be bigger then the rest, and if you use a point (centroid), it would be missed because the point is further from the road then other properties. If you increase the road "width" then you run into finding properties that aren't even on the road. This trades accuracy for speed.

[bratseth]

But less accurate, and that is important for any federal, state and local government scenarios.

With post filtering - in a component running inside the system - it is precisely as accurate.

The road feature should be implemented with the distance to path feature instead of radius. I agree that in that case radius+post filtering is not efficient, which is why we do provide a separate feature for it.