Map API
Nutiteq Maps Lib SDK enables developing advanced mobile mapping applications.Platforms: Android, RIM BlackBerry, Java ME (J2ME)
Download maps API SDK »
Query string encoding in GeocodingService
Hi,
It seems that GeocodingService doesn't properly encode query string when sending it from nutiteq server to cloudmade one.
I use lang="ru" and 'query' is a cyrillic text - it finds something different than that I specified (looks like it assumed a wrong encoding on server side). I tried to call cloudmade's geocoding API directly (in Chrome) - it worked OK for cyrillic chars in URL.
If I search for ascii text (ie 'moscow') - it works OK.
Could you please have a look at the problem?
Also it looks like that the description field (in KmlPlace class) is constructed regardless 'lang' parameter - I would prefer to construct that myself from the data returned by cloudmade but I'm not sure KmlPlace has them (country name for example).
Probably I'll have to go with a direct call to cloudmade API for now.
Thanks,
Mike
| Attachment | Size |
|---|---|
| CloudMadeGeocodingService.java | 4.66 KB |
| JsonKmlReader.java | 5.06 KB |
It should be fixed now. However, in the roadmap we plan not to use serverside proxy, and have direct JSON requests. There are free tools for parsing in json.org available. So f you'll can implement nice direct access which is compatible with the library, then we'd might be interested.
Btw, you can get the extra parameters as extendeddata, which is attached to KmlPlaces what you get as geocode result. Something like following. Depending on OSM data you will get different parameters there.
ExtendedDataMap xdata = kmlPlaces[i].getExtendedData();
Log.d(TAG,"type:"+xdata.getValue("type"));
Log.d(TAG,"is_in:"+xdata.getValue("is_in"));
Log.d(TAG,"county:"+xdata.getValue("county"));
Log.d(TAG,"city:"+xdata.getValue("city"));
Log.d(TAG,"country:"+xdata.getValue("country"));
Log.d(TAG,"road:"+xdata.getValue("road"));
Ok, now there is new service which makes direct requests. Check out the latest beta from nutiteq.com/beta/lib and let me know if it works for you. API is basically same, just service name is different:
final CloudMadeGeocodingService service = new CloudMadeGeocodingService(this, CloudMadeGeocodingService.SERVICE_URL_BASE,
"et", center, "Moscow", "q", null, 10, false);
It provides also extendeddata for more fields given by service, but there could be quite different sets for different objects, as OSM has quite "weak" structure there.
Seems that CloudMadeGeocodingService is broken in maps_lib-1.1.0a.jar - missing loudMadeGeocodingService.SERVICE_URL_BASE and no constructor at all. I guess wrong obfuscation options were used, please check.
Is it possible to publish CloudMadeGeocodingService sources somewhere in sources download area, may be as a standalone file?
Regards,
Mike
Right, this constant was obfuscated. I attached sources of relevant files to this article, and will fix the build.
Actually you should use own value here, so there is your own CloudMade ID. It should be "http://geocoding.cloudmade.com/YOUR-CLOUDMADE-KEY/geocoding/v2/find.js"
Hi Jaak, thanks a lot - now it works indeed!
I'll try ExtendedDataMap - I thought about it but didn't have any idea what I can find there.
About direct access to cloadmade's geocoding - I thought proxing is better approach, from strategy point of view. Could you elaborate why you think it's better to serve on client side - just to reduce server's workload or there are some other reasons?
TIA
Mike
Right, there are pros and cons:
a) why proxy is better
- if server API changes and is not backward-compatible, then changes in proxy could enough and no client update is required
- proxy could do combined queries: e.g. several queries to different backend API-s. Actually this was original reason why we used this, as in the first CloudMade API we needed to make several requests to get all address data what client needed
- you can compress data, use compact binary format
b) why direct access is better
- faster responses
- one possible point of failure less
- no commercial or technical dependence on 3rd party between server and client. Nutiteq does not charge for the proxy, and we try to keep it running, but currently it is not really part of the SDK and it works on "as is" basis.
- more flexibility for client: if server adds new parameters in response, then client can take these into use without waiting until server is updated. This works if you choose to customize geocoding service (parser) yourself, using (latest) source of it.
So basically we offer both options now: you can still define own base URL for service and use own (or Nutiteq) proxy instead of direct access, just API (parameters and response) should be the same; or you can do direct requsts.
Cloudmade's JSON format doesn't appear good enough for parsing on client side, so I decided to wait for the fix on Nutiteq server ;)
Please let me know if you think that this is a problem on Nutiteq server side indeed, and if so, when a fix may be available? Thanks.