MapPro80 Reverse Geocode

[George.Tan]

I am working on a project with mappro80 that involves having to do a lot of reverse geocoding in NYC and San Diego. I am getting the Lat/Lon info from GPS devices and I may have a few dozen such location in each batch.

Before I jump into it feet first, I wonder if the SDK can handle large numbers of such operations and if there are any tricks that I can use to speed the calculations.

[UShadow]

I've used to do that sort of thing in the past and found its performance O.K., though a bit spotty. Now, don't expect it to be lightning fast - geo and reverse geocoding is not what this sdk was devoped for, it's just one more thing it does, fairly well.

I wasn't working in the areas of your interest, I was primarily reverse geocoding in the Chicago and Miami areas and was getting 2-9 reverse geocodes a second.

I had also written a couple of lines of code to test different areas, I'll see if I can dig it out and post it here, in case anyone wants to use it.

[George.Tan]

Well, I already started delving into it and I am having all sorts of problems. I am not sure I understand how this whole paradigm of reverse geocoding works in MapPro80. Can anyone provide a few words of explanation?

[UShadow]

If you provide some detail as to what sort of issues you are having we may be able to help you better. What part of the reverse geocoding are you having a hard time understanding? How well, or not, it works is a different issue, but I think the implementation is fairly straight forward.

Just call the FindClosestStreet and that should return the address corresponding to the Lon/Lat you specify. The number of parameters you need to specify is minimal. Is that what you are having problems with?

[George.Tan]

I am not clear if I am calling the function wrong, or there is some serious problem with the map tool or the data.

Here is how I use it, in general. If you need I can post my exact code.

X=-82.17754
Y=43.88255
Radius=10
Hit=FindClosestStreetFirst(x,y,Radius,1,"",0)
FindClosestStreetClose()

When I run this code the results are unpredictable. Hit sometimes is blank, sometimes it's not even in the right state and sometimes it's correct. That's why I am thinking that either I don't understand how to use the function, or there is something very wrong.

[Charter]

George, I tried many times to get the same type of functionality working with MapPro80, but I gave up each time because, like you, I was getting different results each time I called the function. A shame, really, because on the surface, it looks like it would be a very powerful thing to be able to do.

[LarryWilton]

It doesn't work.

I have been trying to get it to work consistently for a while, but I can't and I'm fairly experienced with mappro80.

I finally contacted undertow's support and asked them, but I haven't heard back, yet. I fear that there is indeed some problem and they are trying to resolve it. Good thing is that they are usually pretty good about fixing problems in a prompt manner. Let's see when they get back to me and what they say.

I'll keep you posted.

[Charter]

Larry, I think in general a lot more documentation for the product would not be a bad thing. Although it's pretty good, a lot of topics are not addressed to the desired depth.

[SamDee]

Carter, +1. The documentation seems to have been prepared by someone who knows the product and the subject matter very well, but presumes that everyone reading it is as familiar with them, and that's simply not true. That, coupled with the fact that some of the functions require weird parameters to be passed to them, sometimes makes for a real struggle to complete even some simple tasks.

[UShadow]

I am not clear if I am calling the function wrong, or there is some serious problem with the map tool or the data.

Here is how I use it, in general. If you need I can post my exact code.

X=-82.17754
Y=43.88255
Radius=10
Hit=FindClosestStreetFirst(x,y,Radius,1,"",0)
FindClosestStreetClose()

When I run this code the results are unpredictable. Hit sometimes is blank, sometimes it's not even in the right state and sometimes it's correct. That's why I am thinking that either I don't understand how to use the function, or there is something very wrong.

George, the code seems pretty simple, but when using the 0-option, as your last parameter, I think the results will be unpredictable and will depend on what is on the map. Did you try using the 1-Option, where the program operates regardless of what is currently on the screen? If not, give it a try and let us know if the results are any better.

[UShadow]

Carter, +1. The documentation seems to have been prepared by someone who knows the product and the subject matter very well, but presumes that everyone reading it is as familiar with them, and that's simply not true. That, coupled with the fact that some of the functions require weird parameters to be passed to them, sometimes makes for a real struggle to complete even some simple tasks.

Samdee, you may be correct, although I find the documentation descent, for what it is, i.e., a reference document. Just for my own understanding, what part/section do you think needs beefing up? Or is it all of it? Simply wondering.

[SamDee]

Ushadow, I think this applies across all the documentation. Any function description you pull up, assumes that you already know what to do and how to do it. If that was the case, why the documentation? For example, the description for the function being discussed says:

FindClosestStreetFirst(X,Y,Radius, Num, Filter, Options):String
Searches the Streets data bases within the specified radius, and finds the street segment that is closest to
the user specified point X,Y (Lon/Lat). The radius (miles) is useful in restricting the search operation
which, if not bound, could take a considerable length of time. The procedure performs an exhaustive
search, and calculates the distances to every street in the grids within "Radius", even if only portion of
such a grid is within that radius. The passed parameters in detail are:

X,Y – Longitude and Latitude of the center of search in degrees
Radius – The radius of search in miles
Num – The maximum number of hits (matches) to be returned
Filter – The CFCC code that should be used for filtering
Options – 0 Search is based on the visibility of the street in the viewport
1 All streets are searched regardless
2 The CFCC filter is used

What grids within "Radius" is the explanation referring to? For Options=0, does it mean if I see it on the map it will be used in the search? If so, what if I am looking at the Southwest, but am making the function call for a point in Seattle, WA? If Options=2, when the CFCC filter is used, is that in combination of the "visible" search, or with the "all" street search?

Do you see my generic problem with the way and the level of detailed information being provided, or is it just me?

[LarryWilton]

I heard back from undertow support and they said pretty much what some other posters stated here, that the problem is the "Options=0" behavior. It apparently has to do with what data is termed "visible" under the current map scale and not what might be visible in the current map windows. I changed the option to 1 and all my problems went away.

So, I guess, the value to use if you don't want any problems is "1". I wonder when someone might need/want to use the 0 option. (I won't even delve into when should one be using the 2 option).

In any case, my searches are now working as I intended them to work, so I'm happy

I also have to say kudos to undertow support who not only answered my question, but emailed me very detailed source code that demonstrates the behavior of the function when using 0 and when using 1. They went the extra step, something you don't see very often these days.

[SamDee]

Larry, could you post the code they sent you? I'd be interested in seeing how they tested it.