![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
symbioidljSo, while thinking about OpenAssess.WI (as I would call the system, if I ever actually made it), I thought sqlite may be the solution, as it's small, portable, and is more like Access than an SQL server. That is, to set it up would be damn easy to do. Just bundle the dll with the app, and it's all there. It appears, from what I recall, that all it does is store the data in a text file. I like that. Simple and small.
However, according to the mono site, all the data typing is removed. Apparently sqlite only stores the data as a string. TBH, I'm not sure what that means in terms of dealing with the data. Do other databases store data-type info along with the string of data? I'd assume that as long as YOU know what you're dealing with in each field it doesn't matter, but it may be a bit more work as a developer to work with SQLite in this regards than, say, MySQL.
Thinking about the system, there's a lot of components that would be required to be dealt with (especially if one is to make it as feature filled as the competition):
1) Interface: Ideally, I'd like to have an extensible UI that allows a person to customize it. I'm thinking, in this regards, the ability to have a config file that would allow a person to "skin" the interface in a way that mimics "the competition". That is, if they are familiar with the other software, they can quickly translate over to OpenAssess. For an example, in one program we use, I manually type in the codes defined by the state: AB1 or AD2 (a flat barn or dairy barn), AP1 (a pole shed), RG1 (residential detached garage). Another program I use actually uses all numerical codes: 12-1 (in fact, two fields, 12 is in the first field denoting the AB part, and 1 is the 1), 17-1, 30-1 and 1-1 (and yes, I have a majority of these codes memorized) While on the one hand, the numerical system is more a pain in the sense it requires more memorization (and the fact that these codes don't always match up with what the state defines ... grrr), it's much faster to type 3 digits on a keypad than it is to lift up to the keyboard and switch between numbers and letters. However, different people probably feel differently. Hence, IMO, it would be nice for this "skinning" feature. The default system would of course, be the preferred/supported system, but if someone adds on and wants to share/support it, they should be free to do so.
2) Modular/Extensible: Of course, the above goes along with this. The reason I want this to be as modular as possible is because, one driving factor of open source is it's userbase. What I mean is that, of course, anything can be open source, but to get as much traction with a project, it requires a wide userbase. This large userbase would (in theory) draw more devs than a small userbase. Being that assessment is a narrow base, in order to widen it, it's best to allow a modular system that would allow for various regions to expand the system to their local needs. (Hence the ".WI" in the name -- each state (AFAIK, assessment is dictated by a state's Depts of Revenue, along with practices put forth by assessor bodies, such as the IAAO and WAAO (wow, WAAO could use a much better site, ewww...)) In this respect, the formulae/tables used to derive costs are unique to each locale. I'm also assuming that different locales have different types of representing data. For example there's many kinds of barns. Each barn has a code dictated by the Wisconsin Assessment Manual (Volume 2). AB1, AB2, AB3, etc... These each have a different cost model associated with it. That's only one subset of barns, there's others as well. Then pole-sheds, silos, grainaries, etc... Now, I'd guess that Missouri has a different way of defining these buildings, and hence, different codes. Making a modular system with these codes/tables means different places can have their own needs met. It also works with the skinning of the UI concept as if you have a skinnable UI, you can skin it not just for preferences within a locale, but between locales.
3) Plugins: This goes with the modularity. However, instead of modularizing the interface/tables, you're working with sub-components. For example, the primary system we use has plugins that you can order. Unfortunately, a lot of these plugins are proprietary and require a separate license and cost. I don't even know, for sure, how many of these plugins have open-source alternatives, but I'm sure a few do.
4) Cost Tables : Currently, the Manual 2 has simple tables that define costs. However, there are places where there is no clear definition. Our current provider did a Multiple Regression Analysis of the cost tables in order to figure out a good model for sizes that are out of bounds. They've added the ability to modify the tables as someone sees fit. Anyways, building the cost table seems to be a massive undertaking by itself. The manual 2 is pretty large and contains a LOT of data. This is only for Residential and Farm Buildings, not even counting Commercial buildings which is a whole other game (Wisconsin uses "Marshall & Swift" in order to cost Commercial properties, which alas, is a proprietary system :( )
So those are some of the hurdles I'd have to overcome in order to design this. Jesus fuck... And that's not even a fun project! I mean, of course, completing each feature is fun (for me at least) But I would have no clue where to even begin designing such a thing. Well, the database/cost-tables are good place to start, but that requires learning SQL and figuring out the cost system. Man.
One other thing I hate is the lack of standardized specification across Wisconsin for parcel numbers. The state has a "recommended" format, something like : 9999-888-7777-6... Some places use it, others have their own system : zzzz.aaaa, or zzzz-aaaa. Some have leading 0s, some don't The worst offender is Walworth county (just look at Whitewater on our site (http://www.gardinerappraisal.com) -things like
However, according to the mono site, all the data typing is removed. Apparently sqlite only stores the data as a string. TBH, I'm not sure what that means in terms of dealing with the data. Do other databases store data-type info along with the string of data? I'd assume that as long as YOU know what you're dealing with in each field it doesn't matter, but it may be a bit more work as a developer to work with SQLite in this regards than, say, MySQL.
Thinking about the system, there's a lot of components that would be required to be dealt with (especially if one is to make it as feature filled as the competition):
1) Interface: Ideally, I'd like to have an extensible UI that allows a person to customize it. I'm thinking, in this regards, the ability to have a config file that would allow a person to "skin" the interface in a way that mimics "the competition". That is, if they are familiar with the other software, they can quickly translate over to OpenAssess. For an example, in one program we use, I manually type in the codes defined by the state: AB1 or AD2 (a flat barn or dairy barn), AP1 (a pole shed), RG1 (residential detached garage). Another program I use actually uses all numerical codes: 12-1 (in fact, two fields, 12 is in the first field denoting the AB part, and 1 is the 1), 17-1, 30-1 and 1-1 (and yes, I have a majority of these codes memorized) While on the one hand, the numerical system is more a pain in the sense it requires more memorization (and the fact that these codes don't always match up with what the state defines ... grrr), it's much faster to type 3 digits on a keypad than it is to lift up to the keyboard and switch between numbers and letters. However, different people probably feel differently. Hence, IMO, it would be nice for this "skinning" feature. The default system would of course, be the preferred/supported system, but if someone adds on and wants to share/support it, they should be free to do so.
2) Modular/Extensible: Of course, the above goes along with this. The reason I want this to be as modular as possible is because, one driving factor of open source is it's userbase. What I mean is that, of course, anything can be open source, but to get as much traction with a project, it requires a wide userbase. This large userbase would (in theory) draw more devs than a small userbase. Being that assessment is a narrow base, in order to widen it, it's best to allow a modular system that would allow for various regions to expand the system to their local needs. (Hence the ".WI" in the name -- each state (AFAIK, assessment is dictated by a state's Depts of Revenue, along with practices put forth by assessor bodies, such as the IAAO and WAAO (wow, WAAO could use a much better site, ewww...)) In this respect, the formulae/tables used to derive costs are unique to each locale. I'm also assuming that different locales have different types of representing data. For example there's many kinds of barns. Each barn has a code dictated by the Wisconsin Assessment Manual (Volume 2). AB1, AB2, AB3, etc... These each have a different cost model associated with it. That's only one subset of barns, there's others as well. Then pole-sheds, silos, grainaries, etc... Now, I'd guess that Missouri has a different way of defining these buildings, and hence, different codes. Making a modular system with these codes/tables means different places can have their own needs met. It also works with the skinning of the UI concept as if you have a skinnable UI, you can skin it not just for preferences within a locale, but between locales.
3) Plugins: This goes with the modularity. However, instead of modularizing the interface/tables, you're working with sub-components. For example, the primary system we use has plugins that you can order. Unfortunately, a lot of these plugins are proprietary and require a separate license and cost. I don't even know, for sure, how many of these plugins have open-source alternatives, but I'm sure a few do.
- GIS : This is really important. A lot of municipalities want a solid GIS system to see not just the buildings, but a view of the lots. If you can incorporate the orthophotography as well (which most counties provide), even better. If you have an OpenGIS system, this makes the need for paying a license to the big guys (ESRI, I'm lookin' at you!) less necessary. I know there's some work on an open source GIS system, but not sure how advanced they are.
- Printing : One of the features used in our current package is Crystal Reports. If you have that software you can create reports that aren't built into the program. While it's a nice feature, Crystal Reports costs money, and it requires time and effort to learn. Time that I don't have. And I'm sure money my boss doesn't care to spend, especially as we don't have a *huge* need to get this, since we'd only have a few reports to generate, it's not cost effective. An open source alternative (of which there are a few) would be nice, and especially allowing individuals to use options they're comfortable with.
- Exporting/Importing : A solid ability to export and import in a variety of formats (especially since each county has their own format). A tool to build specs for this is necessary.
- Database format : The proprietary system we use has MS Access as a default with MS SQL as an alternative. I want to see a thousand flowers bloom. Of course, I'd have a default, but the ability to plug in a different database for people would be nice. This is especially handy if someone has a MySQL server on their site, an export function would be damn easy.
4) Cost Tables : Currently, the Manual 2 has simple tables that define costs. However, there are places where there is no clear definition. Our current provider did a Multiple Regression Analysis of the cost tables in order to figure out a good model for sizes that are out of bounds. They've added the ability to modify the tables as someone sees fit. Anyways, building the cost table seems to be a massive undertaking by itself. The manual 2 is pretty large and contains a LOT of data. This is only for Residential and Farm Buildings, not even counting Commercial buildings which is a whole other game (Wisconsin uses "Marshall & Swift" in order to cost Commercial properties, which alas, is a proprietary system :( )
So those are some of the hurdles I'd have to overcome in order to design this. Jesus fuck... And that's not even a fun project! I mean, of course, completing each feature is fun (for me at least) But I would have no clue where to even begin designing such a thing. Well, the database/cost-tables are good place to start, but that requires learning SQL and figuring out the cost system. Man.
One other thing I hate is the lack of standardized specification across Wisconsin for parcel numbers. The state has a "recommended" format, something like : 9999-888-7777-6... Some places use it, others have their own system : zzzz.aaaa, or zzzz-aaaa. Some have leading 0s, some don't The worst offender is Walworth county (just look at Whitewater on our site (http://www.gardinerappraisal.com) -things like
E W 8000001vs
E W 80000001- quick! How many spaces? how many 0s? Yeah, deal with that shit, and you'll wish for a nice standard format like the state recommendation (and the state one actually means something). Instead of a recommendation, Wisconsin needs to mandate that and enforce it. This would also make it easier to have state-wide systems that work with one another. Ugh!
Tags:
