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

Would you like to know more?...

Tuesday, May 26, 2009

Creating Infowindow Boxes for Displayed Polygons


So, I wanted to construct an infobox for each of the polygons that come up in my impervious surfaces browser. Originally, the php script that I wrote was using the DOM to create a kml file, but I adapted the code into the following, which creates the HTML for a little text box that I pop up:


PhP:

$pound='#';
$parcelLink1='Kitsap County GIS';
$parcelLink=$parcelLink1.$parcelLink2.$parcelLink3;

$parcelLink11='Kitsap County GIS';
$parcelLink10=$parcelLink11.$parcelLink12.$parcelLink13;

$textbox0="

Surface type: ";
$textbox1=$row['Surface_Ty'];
$textbox2="
Surface Area (sqft): ";
$textbox3=intval($row['Area']);
$textbox3a=" Sqft";
$textbox4="
Impervious Surface Units: ";
$textbox5=((intval($row['ISU']*100))/100);
$textbox6="
Assigned Account: ";
$textbox7=$row['AccountNum'];
$textbox8="
Assigned Address: ";
$textbox9=$row['Address_fr'];
$textbox10="
Total Area for this account: ";
$textbox11=$TotalAreaNew;
$textbox12=" Sqft";
$textbox13="
Total ISUs for this account: ";
$textbox14=$TotalIsuNew;
$textbox15="
Parcel Information: ";
$textbox16=$parcelLink;
$textbox17="
Owner Information: ";
$textbox18=$parcelLink10;
$textbox19="

";

$textbox=$textbox0.$textbox1.$textbox2.$textbox3.$textbox3a.$textbox4.$textbox5.$textbox6.$textbox7.$textbox8.$textbox9.$textbox10.$textbox11.$textbox12.$textbox13.$textbox14.$textbox15.$textbox16.$textbox17.$textbox18.$textbox19;

Then, later, I construct a textbox when I plot the polygon and assign a listener that knows to open the new infowindow when any of the polygons I just drew are clicked on. Assigning the listener was actually the hardest part about making the new infowindow boxes – I was thinking that I needed to assign the listener to create the window on each polygon, when in actuality I just needed to assign the listener to the main window (because you can only have one infowindow at a time) and give the listener some coordinates at which to open the new infowindow (the coordinates, in case you are interested, are the coordinates at the center of each polygon).

So the Php script takes the encoded OGC geometry objects for the polygons that are selected from my user’s query. It parses those polygons out into the corrdinates and reassembles them into a form that is inputtable into new gpolygon() as an array of points. Then it assigns a listener to that polygon which tells the map that if that polygon is clicked on – display all of the information about the polygon (as parsed and created by the script earlier) in a data infowindow that is cenetered on the center coordinates of the polygon.

And it works.

Here’s the newest version:

http://freeforthepicking.com/imagery/kmlmap5.5.SITUS.php

If you want to try it out – enter account number 1101850 as an example or try a street address of 3027 olympus

Dominic

Would you like to know more?...

Friday, May 15, 2009

GPolygon() solves the ggeoxml() innaccuracy issue for house-sized polygons

Well, today I was able to get my real impervious surfaces to show up the way that I wanted.

Originally, I built a PhP utility that created a KML file for a requested property. But, using GgeoXML to display that KML caused the polygons to be simplified – and this simplification was enough (at the scale of buildings that I am working with) to significantly distort the reliability of the data.


So, I had to go back to the drawing board.

I ended up writing a very similar PhP utility that uses the Gpolygon overlay class. So now, each of the polygons I had originally created and stuck in a KML is just displayed directly in the API after I’ve used PhP to correctly format the Glatlong inputs into the Gpolygon() class.

But, the end result is that I have much more polygons being displayed – the polygons are exactly the same ones that I created in the original shp file that I was working with.

Building this map was actually much easier than learning DOM architecture to create the KML-based map that I made first – I can see why folks recommended I go this way originally; on the other hand, I learned a lot: and that’s worth the circuitous route for me: the scenery was more memorable.

Here’s an example polygon loaded from a KML file and displayed using Ggeoxml service class to retrieve the data:

http://freeforthepicking.com/imagery/kmlmap5.A.SITUS.php?q=3101600&Submit=Search&r=&s=



And here’s the same set of polygons using the Gpolygon() overlay class:

http://freeforthepicking.com/imagery/kmlmap5.3.SITUS.php?q=3101600&Submit=Search&r=&s=



As you can see, the true shape of the objects is reflected in the second, but not the first map.

Thanks for everyone’s help: next challenge is getting the info windows working for the polygons – but its always something! I feel empowered to do everything I can think of now, but I wouldn’t be able to do that without the help of the folks in this group, so thank you everyone.

Dr. Dominic Ebacher
Ebacherdom.blogspot.com

Would you like to know more?...

Wednesday, May 6, 2009

To transform Coordinates in a SHP file - use Project Tool in ESRI ArcView


I was having a great deal of trouble with projected coordinate systems. Our workplaces uses data that is created using a stateplane projection, but the google maps API wants data in the form of WGS1983 format. For the longest time I didn’t know how to get over this hurdle. I could convert the shapefiles using shp2mysql.exe but shp2mysql wouldn’t change the projection and the polygons wouldn’t work.



The answer was simple: a tool in ESRI’s ArcView called Project (management). I searched all over looking for transform or coordinates or something similar: but Project is the tool you’d like to use: it allows you transform any source data into another coordinate system or projection including datum and spheroids.

And now the data can fly back and forth every whichway.

Dom

Would you like to know more?...

Saturday, May 2, 2009

Selecting features in a Spatial way using MySQL


There is really no limit to what I can do with HTML, PhP, GIS and MySQL any longer. It was a sharp learning curve, and it remains a very brisk uphill walk against the grade: but it is possible, everything I possible. When I think of a problem now, or something I want to do and give more utility to the operation of the program – I have to spend some time thinking about how I want to approach it, but I CAN approach it.



I don’t know what I thought – but I always thought that programming would be harder than it is. Here I’m referring to PhP, but this could b talking about any kind of programming – I thought it would b monumentally difficult. When I was younger, I wrote program in Visual Basic to help my kid sister learn to multiply numbers together: it was a pretty great program, very simple but it did gie me the chance to learn programming. Somehow along the way I convinced myself that using any other language was going to be an insurmountable task. Well, now that I’m here, and I’m using PhP and the variables are flying and my arrays are being filled and unfilled I have come to the realization that it isn’t any harder than visual basic was: and in a lot of ways it was much, much easier. I don’t just mean that it was easier to learn because I already had that experience with visual basic as a kid either: that is certainly and obviously true as well. What I mean to say is that independent of what I knew before: learning a newer programming language and working with it in a production environment today is easier than it was back with the 8088 and other obsolete equipment I had to use back in the day. On the other hand, without that obsolete equipment, I wouldn’t have been able to do anything at all. I only wish I had tried to learn some other language sooner – I feel like the possibilities of what I can do are so limitless that I’m disappointed I didn’t know about their existence sooner so I could have been pursuing them for longer at this time in my life rather than just getting started with them.

Right now, I’m still adding some features and functionality to the script I wrote for Utility Billing to allow them to pull Imperious Surfaces up. What I am adding for them is the ability to see the parcel boundaries and not just the impervious surfaces in the area they are looking at. In addition, I want to add some functionality so that they can see the impervious surfaces for properties adjacent to the ones they searched for. I plan on having those two changes implemented by the end of this next week. I already have the geometries for all of those features stored in my geodatabase, which is always a fun challenge: now I just have to get them to display appropriately.

The larger challenge, and the more interesting one is that I want the parcel boundaries to display, but not all of them and not all the time. By not all of them, I mean that my users have searched for the imperious surfaces of a particular parcel: and they want to see the parcel boundaries, but they are zoomed in so far that they can’t see many properties: maybe 100 at zoom level 18. So, I need to figure out a functional way to select only those parcel boundaries that are within the present field of view. The reason this is interesting is because I am going to have to find a spatial function of MySQL, and I like figuring out the ways that that RDBMS is equipped to deal with spatial data. I think I should be able to find a way to make it happen, such that when a property shows up, all of the parcel boundaries that are within say ¼ mile are selected and made available to display as well. What I don’t know is how much processor power is going to be eaten up doing that SELECT. Perhaps if it eats up too much processor power, and therefore requires too much time, I’ll have to find another solution. But the cool thing here is that I’m not simply selecting all of the parcels – or even just the one parcel I’m searching for (I’ve done both of those things) but SELECTING a subset of parcels based on their location attributes using MySQL’s spatial engine and all of this Geo-relational magic is happening independent of ArcView or any other ESRI product.

I’ll keep you posted on how it turns out.

Dom

Would you like to know more?...