koopjs / koop-provider-composite

Combine multiple geoservices into a common, normalized geoservice
Other
4 stars 3 forks source link

Polygons from registered sources not appearing in composite layer #11

Open apfister opened 6 years ago

apfister commented 6 years ago

Using this Initiative Schema, https://gist.github.com/apfister/9040b58445c9593c607229c8ee695002 and adding data from Mexico, https://gist.github.com/apfister/4c5636f2b2f000cba7ffddf19fe3e8f3, the resulting layer appears without complete geometry for the features. The attribute table also shows 0 records. something is wacky

dmfenton commented 6 years ago

can you tell me which version of Winnow you have locally?

dmfenton commented 6 years ago

and can you capture the http responses from your provider?

apfister commented 6 years ago

@dmfenton from the package-lock.json file, it looks like 1.12.1

which requests? just any and all?

apfister commented 6 years ago

Network log after trying to add to AGOL Web Map Viewer is here, https://gist.github.com/apfister/534ffba5bd2a0315628f1ebb820aed1e

The agol proxy is throwing an error but i'm not sure that's the issue: error 400 - invalid url

I think there may be an issue with over-generalizing the geometry. From this screenshot, I would think it would have more vertices than what is coming back in the response. Here are the query params being sent:

f:json
returnGeometry:true
spatialRel:esriSpatialRelIntersects
maxAllowableOffset:39135
geometry:{"xmin":-20037508.342788905,"ymin":0.000004857778549194336,"xmax":-0.000004857778549194336,"ymax":20037508.342788905,"spatialReference":{"wkid":102100,"latestWkid":3857}}
geometryType:esriGeometryEnvelope
inSR:102100
outFields:*
outSR:102100
callback:dojo_request_script_callbacks.dojo_request_script2

query response - over-generalized geometries

apfister commented 6 years ago

@dmfenton after a bit more research, i'm now noticing that my local redis server never shows any active connections. it always says 0 connections. as i test requests in my browser, shouldn't i be seeing that number go up? could this issue be localized to my local use of redis?

dmfenton commented 6 years ago

@apfister have you tested this without using the redis cache? or with ttl = 0?

apfister commented 6 years ago

@dmfenton i have not touched the core codebase after cloning to my machine. how would you suggest i test that out?

dmfenton commented 6 years ago

what do you mean by core? koop-core?

dmfenton commented 6 years ago

can you paste in your server.js ?

apfister commented 6 years ago

i meant to say i haven't touched the code in this GH repo. i only modified the .sh files for my own indicator testing, curl'd them in, and went from there.

server.js

// clean shutdown on `cntrl + c`
process.on('SIGINT', () => process.exit(0))
process.on('SIGTERM', () => process.exit(0))

// Initialize Koop

const Koop = require('koop')
const koop = new Koop()

const cache = require('@koopjs/cache-redis')
koop.register(cache)

// Install the Sample Provider
const provider = require('./')
koop.register(provider)

// Start listening for HTTP traffic
// Set port for configuration or fall back to default
const config = require('config')
const port = config.port || 8080
koop.server.listen(port)

const message = `

Koop Composite Provider listening on ${port}
For more docs visit: https://koopjs.github.io/docs/specs/provider/
To find providers visit: https://www.npmjs.com/search?q=koop+provider

Try it out in your browser: http://localhost:${port}/composite/FeatureServer/0/query
Or on the command line: curl --silent http://localhost:${port}/composite/FeatureServer/0/query?returnCountOnly=true

Press control + c to exit
`
console.log(message)
dmfenton commented 6 years ago

So try this after commenting out those lines about the redis cache

apfister commented 6 years ago

still no dice. i can see it isn't reading the cache anymore because after i restart the server, i need to curl those requests again. so it's reading it in-memory, just not returning the features correctly.

dmfenton commented 6 years ago

let's remove geojson.ttl from the provider itself so we can eliminate that subsystem

apfister commented 6 years ago

i don't see a ttl anywhere in the code. looks like it was removed already https://github.com/koopjs/koop-provider-composite/commit/cf42a8c2e0d9b923fc25fcf65d32f7bbd065c00b

dmfenton commented 6 years ago

ok, so it's not the cache. take a look at logging the geojson right before the callback from getData executes and see if it looks right. from there work backwards to when data is requested from the source if it's wrong.

If the geojson is correct, add it to a gist so I can do some tests w/ Winnow.

apfister commented 6 years ago

can be closed with https://github.com/koopjs/koop-provider-composite/pull/12