hobuinc / greyhound

Greyhound is a point cloud streaming server. It should be considered deprecated for now. Use Entwine and Entwine Point Tile directly if you just want to serve point cloud web services.
https://greyhound.io
Apache License 2.0
131 stars 51 forks source link

Read query returning zero results dependant on formatting of query data #53

Closed Hisol closed 6 years ago

Hisol commented 6 years ago

I am attempting to query data from Greyhound using scaling and offsets and am having some strange results that are not making any sense.

To test URLs I am also using Postman to send the URLs generated by my client to check they are valid and the server responds.

What I have seen is a very strange situation where if there is an equal sign between "bounds" and the value and a scale option in the URL then Greyhound returns 0 points. However if I remove the equal sign then data is returned.

So: This returns data: http://:8080/resource/read?depth=7&bounds[339970,154970,-2460,345030,160030,2600]&scale=0.1

This returns just the number of points as being 0: http://:8080/resource/read?depth=7&bounds=[339970,154970,-2460,345030,160030,2600]&scale=0.1

Removing the scale returns data: http://:8080/resource/read?depth=7&bounds=[339970,154970,-2460,345030,160030,2600]

Comparing this with your examples I see an equals sign is present. Is there some strange bug here or am I doing something wrong?

connormanning commented 6 years ago

The missing = behavior is a red herring here. I'll look into that separately. But the problem with your requests is that when you provide a scale or offset in your query, your bounds are expected to be scaled/offset accordingly. This is a little confusing what you're trying to accomplish (i.e. "fetch these globally-referenced bounds, and scale the output by my specified scale"), and the reason for this is that a renderer can scale/offset the bounds into a local coordinate system one time, and then work completely within that local coordinate system rather than transforming between them. Maybe separate parameters like outScale and outOffset should be introduced for your use-case, which is a reasonable one.

One thing you may find useful is that, instead of using Postman, you can visualize your queries in the browser by using the /static endpoint instead of /read. Here is an example of two queries of the same data with different scales, and notice that the bounds parameter is scaled according to the scale:

http://data.greyhound.io/resource/autzen/static?scale=1&depthEnd=10&offset=[637300,851210,520]&bounds=[0,0,1000,1000] http://data.greyhound.io/resource/autzen/static?scale=0.1&depthEnd=10&offset=[637300,851210,520]&bounds=[0,0,10000,10000]

There is a Javascript object logged to the console of these pages, where mx is the minimum X-value received, xx is the maximum X-value, etc. This may help you navigate your query pattern.

connormanning commented 6 years ago

There's also a brief description of this behavior here.

Hisol commented 6 years ago

Hi, Thanks for the pointers, most useful. I agree the missing = is a red herring, I suspect that this just quietly ignores the attribute and returns the full dataset.

I am not having much joy however. I located a set of co-ordinates within my pointcloud using the co-ords of the camera position in PoTree. When I set these as the offset and the scale factor to 0.0001 with the bounds scaled by the same factor (I went with -1000 to 1000 as the original bounds) I get no data points back.

I have experimented a little and it seems (sensibly) that if I essentially zoom into a void area of the pointcloud that no data is returned (as there is no data! makes sense). However I am putting the origin to be the same co-ords as the camera co-ords within PoTree, which were fairly central to the data. Is the co-ordinate system used by offset different?

One mistake I also noticed seems to be that setting the depth and not endDepth can result in no data (I assume if that depth of the tree doesn't hold data for that scaling factor or some such)

Hisol commented 6 years ago

I have experimented further using the /static link and I am not sure if there is some bug here or not, but it looks like the offset isn't always in the same location or data is being clipped! I have taken screenshots from within the browser so you can see the behaviour. I was unable to go from a scale of 1 to 0.1 as 0.1 yielded no data, but it looks like as the scale changes the offset used drifts.

The coordinates I used I found with PoTree, and at scale of 1, the result seems to be the correct location http://myhost/resource/68x31/static?depthStart=7&depthEnd=20&scale=1&offset=[342220,159579]&bounds=[-1000,-1000,1000,1000] scale1

When I change scale to 0.8 the view looks to shift or clip slightly http://myhost/resource/68x31/static?depthStart=7&depthEnd=20&scale=0.8&offset=[342220,159579]&bounds=[-1250,-1250,1250,1250] scale0 8

And when I set the scale to 0.5 either the offset has moved down significantly (it should be centre as in scale of 1 image), or data is being clipped http://myhost/resource/68x31/static?depthStart=7&depthEnd=20&scale=0.5&offset=[342220,159579]&bounds=[-2000,-2000,2000,2000] scale0 5

connormanning commented 6 years ago

@Hisol can you re-pull your container and try again using nativeBounds in place of bounds. This should be more in line with the behavior you're expecting.

Hisol commented 6 years ago

That returns me nothing at all. I took the query as I have them above, which behave the same. If I change bounds to nativeBounds and try them again I get "no points in query"

(this is after running pull on the image in docker and starting up container with connormanning/greyhound:latest)

connormanning commented 6 years ago

@Hisol, to clarify, are you running your queries from the original posting or from the one just above? With nativeBounds, your query bounds should always be the same and in the native space (for example as selected in Potree). Any query with the same nativeBounds should return the same number of points, regardless of scale/offset. When this parameter is used, any provided scale/offset values are applied on the way out, and should match your expectations from the original posting.

Hisol commented 6 years ago

@connormanning Many thanks for this, I am able to progress with my project now, thanks.