Thursday, May 28, 2009

Fixing the address search glitch.

So, no sooner had I gotten the newest version of my ISU browser map published than Chance noticed a major flaw in the way that it was setup. It was a flaw I knew about – but I had hoped that he wouldn’t notice it before I had a chance to fix it at least, but of course he did.

In all previous versions of the map that had an address search function, I was pulling the address information for matching with user input from the County’s SITUS database table. The thought behind this is that SITUS is more complete, and sometimes has more addresses than the city does, so in using it I would have a higher probability of matching naive user input.



Because I was using the SITUS database, this had to be linked the existing key value (ACCOUNT NUMBER) somehow – and that somehow ends up being the Kitsap County parcel number (or the RPACCT_ID). And because there are flaws in going through the parcel number (which is much less specific) when very specific user data is already available (specific addresses) the approach is flawed.

What the map was doing was taking the first account it found that shared a parcel with the address that was entered. Now for residential parcels that’s fine – one address one parcel is generally the rule. But, for lots of commercial properties and a few residentials that have multiple addresses on a parcel, selection specificity was being lost, and sometimes the first account that was selected wasn’t the one that we wanted (and wasn’t the address that was enetered – each of our billing accounts have an address of their own too).

The solution was to create a new table that had the addresses (parsed into street number and street name) for each of the locations in the city. This table was something I created many months ago – and I used it here to great advantage, happy for every minute that I spent on that painstaking project. Then I linked that table with a left inner join to only have available in that table (addresses) the rows that shared an account number with the ISU table – that way we know the account we’re getting from the address table is THE right account – rather than the fireline account at the same location. The fireline account wouldn’t be selected now because it wouldn’t appear in the new addresses table because the left join removed all the entries for the fireline account because that account’s account number doesn’t appear in the ISU table (I didn’t assign that account any ISU polygons, essentially). So, now I have this table assigning account numbers to the php script when the address is entered, and as far as I can tell it works perfectly. My original concern – that we would miss addresses by using this table – was not incorrect (we will miss them) but it wasn’t pertinent precisely because if there is an address (and account) that WE don’t have, I wouldn’t have assigned it any ISU polygons, so the fact that I can assign it with SITUS isn’t useful because the accounts that were missed (comparing SITUS vs BILLING ADDRESSES) wouldn’t ever have polygons assigned to them by virtue of the fact that they were missed. Once I figured that out, I felt fine implementing this new address solution, and its working great.

Just in case though, I set the PHP script to first query the new address table, and if that table didn’t have any matches to then search the SITUS table. It didn’t hurt anything, and it might provide functionality at a later date if we do need to link something out of the SITUS table.

Here’s the newest version:

http://gisfbdev.ci.bremerton.wa.us/imagery/kmlmap6.1.SITUS.php

I’d show a screenshot, but these changes were all fixes in the innards of the program – not cosmetic changes so the screen shot wouldn’t look any better than the last time I showed what the program looked like.

You’ll also notice that the hosting address of this page is different. I’ve been developing this on the City’s webserver that has been set up for me for this purpose. It makes some thing a lot harder, but on the other hand, it keeps the peace around here – and it does make more sense for the city to be hosting its own solutions, so I am happy to comply as long as it doesn’t interfere with the development that I need to do.

Plus, I got to learn administration on a LAMP server, which is awesome (I want one!). I might have to set up a computer at home that can serve a new web page for me perhaps.

Peace,

Dom

No comments:

Post a Comment