Forum

Zip Code Pack for maps in YF 7.1

I can't get maps to work in YF 7.1. I have a 5 digit zip code field (varchar) which I have matched to the US zip codes pack in my view.

Here is the fields view:

Next, I configured the geo field as shown below:

I then saved the view and it appears that zip code is a geo field. However when I go to build a report using that view, the field is no longer a geo field:

And the geo charts are not active:

Any help would be greatly appreciated!

Hello Scott,

Thank you for posting your issue on our forum and
for including the screenshots.

What build of 7.1 are you using? E.g, Nov?

I've replicated your steps and cannot reproduce
your issue. Clearly your 'Zip Code' field is not being brought
over into the report field with the changes you've made to it.

The only difference in my test is I am editing an existing view
and it looks like you are creating a new view? See the below
screenshot as my edit view has 4 steps whereas your shot
shows only 3.

Step 4 on the view edit is where I activated my view and the
changes.

The final shot is from my report builder showing the Geo Fields
that came through.

Please let me know if there is something I'm missing. In the
interim I will continue to have a look at this for you.

Thank you,

Kyle

Hey Kyle,

thanks for your response. I am using the 11/28 version of 7.1. A few notes per your post:

1) I am doing the step (step 4 above) to save and activate the views. See screenshot below.
2) I have tried to both create a new view as well as edit an old view.
3) a few other troubleshooting steps I have tried are to:
a) re-download and upload / overwrite the geo pack. I did this this morning to no avail
b) start / stop the yellowfin server.

One anomaly that I see: when I click "create report" and then choose my view, the system takes about 3 min or so to open the report builder. This has typically only taken about 5 seconds.

Attached are 1000 records from my data set. I had assumed that perhaps my zip code field is bad, but it seems OK to me. My database is SQL Server 2008 and the field is NVarChar(10).

Here are my views:

Scott,

Thanks for getting back to us. I've imported
your CSV file into my instance and experienced
the same thing that you did.

So, it's possible that your zip code field is bad.

However, before saying that this is indeed the specific
issue, I would like to have another team member
also test this and review.

I'm hoping this can happen today and that we can get
back to you with additional information.

Thank you for your patience.

Kyle

Hi Scott,

Thanks for all the info you have provided and apologies for the troubles you have been facing.

It looks like the CSV file you created is not formatting correctly which is why Kyle is running into issues after exporting.
The CSV itself has many rows that are split like this :

I did manage to import this CSV into SQL Server so the rows are coming through correcly (on 1 line).

I then managed to create the Geo Field without any issues.

I also managed to strip out only 50 rows from the CSV and ensured there were no split lines, and that also worked ok when using the GeoPack.

This means the only thing left to find out is how the data set we have from you differs from the actual data set you are using.
I noticed you have many other columns in your view, and assume a lot more rows of Zip Codes.

Is it possible to get the entire table you are using that has this zip code column?
I can then create this table in my instance of Sql Server.
Alternatively, you can export that entire table to a CSV or TXT file and I can import that.
If this does contain sensitive data, you can email support@Yellowfin.com.au and reference this post with the relevant data.

Sorry again for all the troubles, I think we have ruled out most things so just need to confirm our suspicions.

Hope you had a good Christmas.

Regards,
David

Hello,

I sent the file via email. As a note, I downloaded the Complete ZIP Code Totals File [.8mb zip] from https://www.census.gov/econ/cbp/download/. I then matched up against the database and 1554 out of 1555 zip codes matched (via an access database). So it does appear that most of the zip codes are valid.