cartodbirc.log

[12:13] <wboykinm> strk: So I've got a table with a poorly-behaving column
[12:14] <strk> "poorly-behaving" ? how so ?
[12:14] <wboykinm> I'm not precisely sure what's wrong with it, but here's how I narrowed it down:
[12:14] <wboykinm> 1.) downloaded table as .shp
[12:15] <wboykinm> 2.) re-uploaded table as .zip (exactly as downloaded)
[12:15] <wboykinm> 3.) whole swaths of features are missing
[12:15] <strk> uhm
[12:15] <wboykinm> like this: https://www.flickr.com/photos/vtcraghead/14123997052/
[12:15] <wboykinm> But wait, it gets better
[12:15] <wboykinm> So I download as .shp again,
[12:16] <strk> select count(*) gives the correct number ?
[12:16] <wboykinm> then I remove all columns except for my unique key, a string column
[12:16] <wboykinm> compress and re-upload, and it works perfectly - all features visible
[12:16] <wboykinm> last diagnostic:
[12:17] <wboykinm> I download as .shp, remove all columns except for the key column and the name column, and the missing-feature problem returns.
[12:17] <wboykinm> . . . leading me to believe the string "name" column is to blame.
[12:17] <wboykinm> does that make sense?
[12:18] <strk> I'm not very knowledgeable of the import process so can't tell exactly what's going on, but your debugging seems perfect
[12:18] <strk> how about producing a syntetic small version of the case and attaching to a github ticket ?
[12:18] <strk> would seem easy to produce
[12:18] <strk> hopefully the number of features doesn't affect it
[12:19] <wboykinm> will do. WHich repo should I attach it to?
[12:19] <strk> you're basically saying that the presence of a "name" column breaks the import, right ?
[12:19] <wboykinm> right
[12:19] <strk> github.com/cartodb/cartodb
[12:19] <wboykinm> but the encoding seems fine
[12:19] <wboykinm> No characters that cartodb hasn't handled before
[12:19] <strk> and "breaks the import" means "drops some rows", you said (but I'd confirm with SELECT count(*))
[12:20] <wboykinm> okay, doing that now . . .
[12:20] <strk> it's important to distinguish between data and map issues
[12:22] <wboykinm> Yup. rows dropped. Should be 35603, only importing 33004
[12:22] <strk> a-ha!
[12:22] <strk> see if you can produce a much smaller version of the test, like ideally 2 rows (of which 1 only imports)
[12:23] <strk> then the bug would probably become obvious ;)
[12:23] <wboykinm> okay, I'll target those...
[12:24] <strk> or failing to reduce in number of rows, reduce complexity in values, like make all "name" values the same, and see if it still occurs...
[12:24] <strk> I'm off for today, feel free to report on the googlegroup :)