Bounding box coming from koop returning odd coordinates

[sirws]

http://50.18.49.187/koop/socrata/wa/9ubz-5r4b/FeatureServer/0 (at least for xmin). It seems to be missing a decimal point. I am guessing should be -121.0 or something along those lines.

extent: {
  xmin: -1210,
  ymin: 45.5876,
  xmax: -117.079,
  ymax: 48.9989,
  spatialReference: {
    wkid: 4326,
    latestWkid: 4326
  }
},

[sirws]

Is this a known issue?

[chelm]

@sirws I was pretty shocked about this and so I looked at the data. Feature ID 407 has coordinate of -1210 so its not a koop bug IMO. :)

http://50.18.49.187/koop/socrata/wa/9ubz-5r4b -> search for "-1210"

[sirws]

Oh hahaha! Perhaps we should filter them out somehow? -1210 definitely isn't within the -180 to 180 domain! :)

[chelm]

@sirws true, and actually I think the latest socrata provider has code to do that. Maybe make sure you're on the latest?

https://github.com/koopjs/koop-socrata/blob/master/models/Socrata.js#L211

[chelm]

@sirws However looks like koop is now having trouble parsing something from: https://data.wa.gov/resource/9ubz-5r4b.json?$order=:id&$limit=1000

[chelm]

Ahh I think I broke it of course...

[sirws]

What do you mean? This seems to be working? http://50.18.49.187/koop/socrata/wa/9ubz-5r4b/FeatureServer/0/query?where=1=1

Also, what is the best way to install the latest socrata provider on top of an existing koop-sample-app install? I am a n00b to a lot of this stuff so bear with me.

[jgravois]

i can help with that... blow away that koop-socrata folder inside 'node_modules' and call npm install again after updating the tagged version in your package.json

you can even point at specific commit hashes in feature branches to test things out...

[chelm]

@sirws I think in the sample koop app we need to upgrade the socrata provider version to the ^0.1.0 in order for it to get pulled down.

So many repos, so much fixing to do

[jgravois]

i can PR that update @chelm

[chelm]

Thanks @jgravois Hold off until I get a PR to koop-socrata in to fix this issue I'm seeing

[chelm]

This issue will be fixed via https://github.com/koopjs/koop-socrata/pull/18

[chelm]

@sirws this issue is resolved in the koop-socrata and @jgravois bumped the version in the sample app to reflect the new koop-socrata version.

[sirws]

So, I brought the latest code down and I am still seeing the -1210 in the extent:

http://50.18.49.187/koop/socrata/wa/9ubz-5r4b/FeatureServer/0

[chelm]

@sirws The data are cached, so you need to drop the data first...

fixed: http://50.18.49.187/koop/socrata/wa/9ubz-5r4b/FeatureServer/0

[sirws]

Thanks @chelm ! What's the command to tell it to drop the data out of the cache? I really appreciate all of your help on this!

[chelm]

@sirws adding "/drop" on the base url http://50.18.49.187/koop/socrata/wa/9ubz-5r4b/ + 'drop'...

Your instance seems to crash on drop (maybe koop ckan crashes on drop?) but the drop seemed to work.

[sirws]

@chelm How would you recommend troubleshooting the fact that it crashes on /drop? Also, how do you drop all indexes? I tried http://50.18.49.187/koop/socrata/wa/drop and it doesn't seem to drop them all.

[chelm]

@sirws There is not a way to drop all on the socrata provider yet. Could be built.

What error do you get on "drop" when it crashes?

[sirws]

Error: spawn rm ENOENT, Error: spawn rm ENOENT, Error: spawn rm ENOENT

[chelm]

@sirws Let's make an issue in koop-socrata. It's a bug.

[sirws]

OK, will do.