Geocoding "null" error
Hey I am using the geocoding sample and modifying it to show
more that one location from an imported csv, every other node above
"make point" seems to work but "make point" gives me a "null"
error. Not sure what I am doing wrong. Any help will be highly
appreciated.
Here are the csv and ndbx file
- President_Obama_Visits.ndbx 4.25 KB
- President_Obama_Visits.csv 12.9 KB
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
1 Posted by Rodolfo Oliveir... on 04 Jul, 2014 11:21 PM
... sometimes it works, sometimes it doesn't... I don't get it.
I added a pick module and sampled each 2 and 3... sometimes it worked (image is with n 3)
I only found problems on the "lng" lookup, even adding string modules and everything I could think of, it shows erratic behaviour. none with "lat" lookup.
maybe someone else can have a better idea?
Support Staff 2 Posted by Frederik De Ble... on 05 Jul, 2014 09:23 AM
Hi,
I've tried it and I didn't get any errors. The most probable cause is that the geocoding service is down, or you can't reach it (flaky internet connection?). Your best bet is to try again. You can also increase the refresh time on the http get node to make them cache longer.
Best,
F
3 Posted by Rodolfo Oliveir... on 05 Jul, 2014 02:05 PM
It's not the connection im my case; it retrieves the values (I can see them on a list and they look fine), it's when you try to connect it to the "make point" that the "null" error appears.
"java.lang.IllegalArgumentException at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at nodebox.function.JavaLibrary$StaticMethodFunction.invoke(Unknown Source) at nodebox.node.NodeContext.invokeFunction(Unknown Source) at nodebox.node.NodeContext.invokeNode(Unknown Source) at nodebox.node.NodeContext.invokeNode(Unknown Source) at nodebox.node.NodeContext.renderNode(Unknown Source) at nodebox.node.NodeContext.renderChild(Unknown Source) at nodebox.node.NodeContext.renderNode(Unknown Source) at nodebox.node.NodeContext.renderNode(Unknown Source) at nodebox.client.NodeBoxDocument$3.doInBackground(Unknown Source) at nodebox.client.NodeBoxDocument$3.doInBackground(Unknown Source) at javax.swing.SwingWorker$1.call(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at javax.swing.SwingWorker.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source)"
see attached images
it only happens with the "lng" lookup, despite retrieving results
4 Posted by Ruth Kinyanjui on 05 Jul, 2014 07:59 PM
Hey Frederik & Rodolfo,
I am getting the same error as Rodolfo even after trying with just a few cities.
Rodolfo, would you please provide a full screenshot of the one you got mapped (working) above?
Thanks
Ruth
Support Staff 5 Posted by lucasnijs on 07 Jul, 2014 06:31 AM
Must be a connection error. I put the refresh time up as Frederik suggested and added a slice node to see where it happens. With a small refresh time it happens anywhere between the 40th and the 60th value. Setting refresh higher then 500 I did not get any error anymore.
6 Posted by Ruth Kinyanjui on 07 Jul, 2014 07:27 PM
Hey Lucas, would you attach the ndbx file on here. I tried adding the refresh time and its still giving me the same error.
Thanks
Ruth
Support Staff 7 Posted by lucasnijs on 07 Jul, 2014 08:41 PM
Sure, but it is not the file I think. I just took yours and have been adding two slice nodes and a number node to control the slices. Then by changing the refresh time you can slide the slices until you get the error (or not).
Support Staff 8 Posted by john on 02 Feb, 2017 12:25 AM
This is an old thread, but I believe I may be able to solve this mystery.
This looks exactly like the issue I just reported a few days ago. I was also getting null errors on make point after pulling longitudes (lng lookup) from a geocoding query. As you can see in my other post, I hooked a lookup class node to the longitude and discovered that every now and then Google returns a bigDecimal instead of langDouble for certain locations.
So the real issue is number formats. NodeBox can't handle bigDecimal formatted floating point numbers.
If anyone from this original thread sees this and still has their files, could you confirm this? If you are still getting the error, hook up a lookup with key = class to your longitude node (which is a lookup with key - lng). If you are doing a list of locations you should see a bunch of langDoubles with one or more bigDecimals. You can slice to confirm that the bigDecimal longitudes are the ones causing the null errors when you try to make points out of them.
I still haven't heard back to my bigDecimal post of a few days ago. If the team can come up with a workaround for my problem, it might also work for this problem.
Thanks,
John
Support Staff 9 Posted by john on 02 Feb, 2017 01:42 AM
Update:
I downloaded Ruth's original files and confirmed the problem.
Her query produces latitudes and longitudes for 109 cities. If you hook a lookup with key=class to her longitude node, you can see that all values returned are java.lang.Dobule EXCEPT one, which is java.math.BigDecimal.
The trouble-maker is Deauville France. Every other city works fine, but try querying a longitude for Deauville and NodeBox will generate a null error. This is the same thing that happened to me with Slough in the UK. You can confirm this separately with the example network I attached in my other BigDecimal thread.
Ruth, until the staff comes up with something better, your workaround is to simply remove Deauville from your list of cities before you do your queries. If need be, you could look up the latitude and longitude of Deauville by hand, type them into a make point node, and use a combine to append that location to the output of make point node for the other cities.
By the way, when you run Ruth's original query you sometimes get 109 locations, and sometimes get less. If you get less than 109 the reason is that you have exceeded Google's free query limit for the Geocode API. If you need to get around this you can either wait 24 hours and try again, or obtain an authorization token. This requires a credit card and, for this API, Google will start charging you if you exceed a certain number of queries per day (as I discovered the hard way). This complication may have contributed to the confusion in attempting to debug this problem back in 2014.
Ruth and Rudolfo, please let us know if you saw this post. I hope the staff can find a better work around since mapping is such a powerful use of NodeBox.
John
Support Staff 10 Posted by john on 01 Apr, 2017 08:11 AM
It looks like Ruth and Rudolfo are long gone and I am probably just talking to myself again...
Just to put a final close to this old mystery, I am attaching the fixed version of the NodeBox file and a copy of the map Ruth was never able to produce. As described above, the method is to first remove Deauville before doing Google Map lookups, then add back its coordinates afterwards. (See circled areas in the screenshot for the nodes which remove and restore Deauville.)
If the map in the screenshot does not exactly match the final map attached here, the reason is that every time you do a Google lookup (without paying), Google may or may not return all 109 cities. I made sure all 109 were in the exported version, attached here as a JPEG and included as a PDF in the zip file.
This one simple change solves the problem. Now we can finally see the mysterious map.
Enjoy!
John
P.S. If any staff member happens to read this, please respond to my other post which addresses the NodeBox bug behind all this:
http://support.nodebox.net/discussions/nodebox-2-3/5898-help-how-ca...