Special Pick Box Feature Aids in Variable Fees

This past week I converted the City of Fostoria from ZP 32 to ZP SQL. As it turns out they are the first case I have converted that had used the variable fees option for Zoning permits in ZP 32. That feature was dropped in ZP SQL because I reasoned that formula scripts could handle those fees just as well, and as far as the fee calculation that is true. What I didn't account for, however, was the way the old variable fee feature let you pick fee choices from a list of options. I wanted that same ease of use in ZP SQL. The solution I came up with is to add a Special Pick Box feature to ZP SQL. This is a Pick Box screen that can be called from any script. You simply add a line of code to the script that calls the Pick Box and passed it the list to use as choices. It returns the selected item which you can then copy to any available field. I have added a new tutorial to the ZP SQL Documents section of the Tutorial page in our web site that shows how I used this feature in Fostoria's case. The newest version of the ZP SQL demo also uses this option for the "Sewer" Zoning permit type.

Document Section on Tutorials Page

A new "ZP SQL Document" section has been added to the Tutorials page on our web site. The initial posting include several documents that were already in existence. One of the documents goes over the field differences between ZP 32 and ZP SQL to help converting customers move over documents and reports from the old system to the new one. Two of the documents are overviews written for the beta testers of the Contractor Request option and the on-line photo storage option. More will follow, of course.

First Custom Application Ported to ZP SQL

We just recently finished porting the first custom application from ZonePro 32 to ZonePro SQL. Fittingly, it was the Trash Billing custom program which is probably the oldest custom program we wrote. Everything went smoothly. This was a hallmark because the custom applications are the last bits of ZP 32 to be converted. All of the standard modules have made the transition.

Revised Public Pages for Web Interface

This past week we made a few changes to the Public web page component that comes with ZP SQL. Based on customer feedback we eliminated the exposure of the Notes2 field from all databases that have it. For databases like Contractor and Contact File we removed the Notes field. This affords the customer some degree of privacy so there is somewhere in each database that you can enter information that is not automatically exposed to the public. If you have suggestions about other restrictions that should be placed on the Public web page option, please let us know. Non ZP SQL users can demo the Public web pages at www.zpsql.com/public.

Mapping Mania

Okay, one more post about mapping. I've already discussed how the ZP SQL web interface provides a way to include maps as part of the Property page. The really exciting part for me, however, are the mapping options that involve multiple properties. I've implemented a few of these options already. From the opening page you can view a list of recent permit activity or upcoming inspections. Both of these lists also have a mapping option. These maps plot a point for each record in the list. So, if in the last week you had issued five permits, your map would show five flags pinpointing where the activity occurred in your community. (Just like with the Property page, when you call the mapping option it will automatically geocode any properties listed that don't yet have their latitude and longitude defined.) Clicking on the individual markers on the map even displays some brief information about the record it represents. This is very cool stuff. If you have ZP SQL I definitely suggest you go to your web site and try this feature out. If you don't have ZP SQL you can still go to our demo web site and see how it works. In addition to the opening screen the option is implemented for several of the Recent Activity buttons. Just look for the "Show Map" map on any screen.

Adjusting Geocoding

In my last post I mentioned how the ZP SQL web interface will automatically geocode a property prior to showing it on a map. Again this is done by passing a street address to the Google Mapping Server and getting back the latitude and longitude. It turns out that is not a very precise science. In other words, the geographic point that the latitude and longitude represent is not always exactly where you may think it should be when placed on the map. My understanding of this process is that the Mapping Server does not have an address to point database that it uses to return the geocode. Rather there is some estimating that occurs based on the address number and the range of addresses on the street. Of course, there are also issues where you don't have a complete address (a vacant lot perhaps) and therefor can't expect a very precise returned geocode. And of course there is also the issue of coming up with a single point to represent a much larger polygon of some kind. All of this led me to seek out an easy way to allow users to adjust the geocode setting for any given property. This option is now available from the Property page of the ZP SQL web interface. It opens a new page that shows a larger map of the property in satellite view so that you can see buildings and structures. You can then move the marker that represents the property to a new location on the map and then save that point as then new geocode representation for that property.

Automatic Geocoding With Google Maps

When we rewrote the Property Screen for ZP SQL we added a couple of new fields for Latitude and Longitude. Last month we started putting these fields to use. The web-based interface for ZP SQL now has the ability to automatically geocode a property record using Google Maps server. Geocoding is the process of determining the latitude and longitude of a given point or, in our case, address. We've added logic to the web pages that passes the street address of a property to Google Maps and gets the latitude and longitude in return. We then store these values in the database. This happens each time you request a map of a given property. (Did I mention that you can now display maps as part of the Property Screen in the ZP SQL web interface? It's very cool.) This geocoding process happens behind the scenes, automatically. Of course, it only needs to do this for properties that don't yet have geocode values. It is self-populating the database and eventually, your latitude and longitude fields will be completed filled. How cool is that?

Online Photo Storage Beta

One of the trade-offs with the anywhere availability of ZP SQL is that it doesn't always work very well with the Photo Module. The problem is that the Photo Module works by storing the file path to the desired photo or document. But once you are no longer connected to your office network, that file path isn't valid. One solution to this issue is to allow customers to store photos on the internet. These photos would then be accessible through ZP SQL regardless of where the user is. To that end we are beta testing a new service we are calling WebAlbum. This service allows ZP SQL customers to store JPGs and PDFs as part of their ZP SQL internet account. As of now this service is only accessible through a web page interface. You can try this for yourself by going to the Property Screen at the ZP SQL web demo site and clicking on the "Photos & PDFs" button.