We have a preliminary release of a part of the Land Management System being developed for Neufreistadt and future sims in our confederation. You are encouraged to inspect it here:
http://land.neufreistadt.info/index.php
The project was proposed by me last spring following the very interesting work that Sky Honey did providing an updated map of our sim. It's now been taken on by Eloise Pasteur as a city contract. She and I are working closely on it.... the input and assistance of others is heartedly welcomed.
The core of the new system is the collection, display and manipulation of the land ownership data contained in each of the elements of land in the sim. The smallest size unit of divisible land in SL is a parcel 4m by 4m, what we have come to call a quad. Since each sim is 256m x 256m, there are 4096 quads whose metadata contains significant land information. The major input end of the Land Management System is a periodic scan, initiated in different forms for different needs, of the data contained in the quads. This is stored in a database, stamped with date, and used for a large variety of outputs. This demo shows a small part of the potential functionality.
Ultimately, this data will support the following primary areas of sim administration:
1) Easily accessible map data for visitors, citizens and administrators.
2) The deeding process by which the "ownership" of parcels is transferred from one avatar or group to another. Preview of new purchases, output of deeding materials, and facilitation of the deed notarization process. Complete and accurate information on every deed currently registered with the sim.
3) Resident "account" management. Since all the data concerning ownership of each citizen is contained here, residents will ultimately have the ability to management their own land account with this app, including payments, advance payments on account, etc.
4) Undoubtedly many other functions yet to be determined.
Please explore the demo app linked above. The scan data IS NOT current. On the maps, please try clicking both on the map itself, on different parcels, and, where present, the names listed. To access the Admin section, please use the UN "Sudane" and the PW "landnut".
For the purpose of completeness, I have attached below the original "Operations" proposal and the original "Programming" proposal, upon which this project is based. Since these were preliminary descriptions, some of the thinking and development has modified the content of these somewhat. Please read them with that in mind.
Comments, questions and criticism are indeed welcome.
===============================================
April 25, 2006
[size=150:20l6iq4a]City of Neualtenburg
Land Transaction process[/size:20l6iq4a]-----------------------------------------------
The foundation concept of this proposal is that the citizen purchasing land contracts to occupy a "set" of what I call "quads", 4m x 4m land elements, the minimum divisible land element. Each of those quads is assigned to a "zone", which determines its tax. The identity of this set of quads is determinable by an LSL scripted object. The land is of course marked out in parcels, for the purpose of prim management and the maintenance of the citizen's land rights. But the "set" of "quads" is what sets the relationship to the City. Data can be automatically generated and stored in City databases. Citizen accounts can be built upon this database.
To buy land:
1. Prospect indicates desire to buy requested land... need not correspond to arbitrary parcels.
2. Officer deeds land request to trial group.
3. Scanner is run... seeking only the trial group (and possiblity an existing group already owned)
5. Scanner output: how many m2 are in each tax zone covered by this transaction.
6. Report looks up/calculates: tax rates based on m2 in each zone.
7. Officer assigns person name and group name to scan data.
8. Program generates deed based on scan output and manually input data.
8. If citizen accepts deed, Officer deeds land to group, deed is notarized.
9. Land Transaction Scan / Part Two is run which records the data of the pro-forma deed into the Land Data.
10. Using related tables, program regens map data, ownership/availability chart, and fee chart for resident tax payments.
11. Any date map can be accessed thru DB3 (raw land data) archives.
12. Project established set of related tables which include all land-holding information. Writing extension code to set-up citizen "accounts" can easily hook to this data.
Notes:
------------------
1. Revise display to include numbers with the colors, and multi-layers.
2. Definition: quad id# i.e. quad 0001, quad 0002, quad 0144, quad 4096: an assigned sequential id# for each of the 4m x 4m (16m2) land parcels which is the minimum divisible land module.
4. Land owned by the City (non-available) will be re-assigned to one group, and, land owned by the City but available for purchase will be re-assigned to another group. This makes it easy to see available land.
5. Pre-defined parcels become arbitrary and used for convenience only. Citizen financial obligations are defined by total number of m2 in each tax zone.
6. Programming proposal listed in a separate document.
===============================================
[i:20l6iq4a]
(REMINDER: IN MANY RESPECTS, THIS IS NOT THE FORM THIS APPLICATION WILL TAKE. IT WAS MY ATTEMPT IN APRIL TO DESCRIBE THE CONCEPT OF THE MECHANISM.)[/i:20l6iq4a]
April 25, 2006
[size=150:20l6iq4a]City of Neualtenburg
Programming the Proposed Land Management System[/size:20l6iq4a]
Database Structure
-------------------------------
DB1 citizen# | personname | groupname | groupkey index on citizen# and groupkey
DB2 citizen# | zone# | m2 output database for reports
DB3 quad# | citizen# index on quad#
DB4 quad# | zone# index on quad#
DB5 zone# | tax$rate | city_sale_rate$ index on zone# (if needed)
SCANNER
Assumption: The scanner proceeds sequentially from side to side across the sim, starting in one corner and ending in the diagonally opposite corner, in the fashion of television scan lines. Since this scan path is the same each time, it is practical to assign a sequential id# to each scanner reading, so that each numbered reading observes the data for the identical spot of land.
Further assumption: Since the minimum land module is 4x4 meters, it is assumed that the scanner reads only once for each 4x4 module (a quad), and that therefore there are 4096 readings in each complete scan of the sim.
Scanner to perform in different modes.
Scan One: Utility scan. Runs as needed (probably manual initiation). Basically the same scan as we have now, except that discrete info is collected.
Copies current DB3 to archive DB3_date
Data collected is in the form quad# | groupkey.
Conveyed by whatever process to external database.
Database app looks up citizen# for each data item in DB1 and adds a record in DB3.
Using look-ups in DB1, DB4 and DB5 the following output can be generated:
Map as now with possibility of number-coded colors. Perhaps a way to make much larger with all data on one image?/ selectable image layers, like the SL big map?
Output: possible output format (see below) Land holdings for each citizen listed by #m2 in each zone ( times $rate/zone equals total monthly charges)
Scan Two: Land transaction scan. Runs by command as part of process of defining and deeding parcel.
Officer "Edits Land" to create a new parcel. Deeds that parcel to special "Transfer Group".
Scan is run testing each quad only to find groupkey of Transfer Group.
"Found" quads are conveyed to external database.
Stored in numbered temporary holding DB, with single field in each record, quad#
the reason for "temporary numbered holding DB" is that more than one may be open at once.... there may be more than one person considering a deed at a given point in time
Input: manual input of personname and groupname, discover groupkey
Output: Using look-ups in DB4 and DB5, pro-forma deed can be generated.
Purchaser is then presented a Purchase/No Purchase decision
Decision Outcome:
1. Transaction Declined.
Database app deletes temporary holding DB.
2. Transaction accepted.
Officer deeds parcel to citizen
Application proceeds.....
If groupkey is not found in DB1, generate new citizen#
insert citizen# into current DB3 for each quad# appearing in numbered temporary holding DB
delete temporary holding DB
re-run reports listed in Scan One.
Note: This scan results in the same output as Scan One. Scan One should be technically un-necessary, but functions as a "cleanup scan", error-correcting if deeded land does not correspond to land in "Transfer group". It also serves the purpose of "baking" an archive.
Scan Three: Zoning Scan. This scan is for the purpose of defining or re-defining different zoning areas. There are two procedures, only one of which requires an actual scan.
1. Officer marks a parcel and deeds the land to a transfer group.
Manually inputs zone number.
Scan runs as in Scan Two, seeking only the groupkey for the transfer group.
Using temporary holding DB, update DB4.
Delete temporary holding DB.
Officer deeds back the land affected.
2. Officer designates a record in DB1(citizen#) which is to be re-catagorized with new zone number.
Manually inputs zone number.
Using look-up in DB3, app updates DB4,
3. There may be other "zone assignment" techniques.
FRAMEWORK
Obviously, this application spans both in-world and out-of-world. There is no absolute requirement (at the moment) that any particular function be located in any other but its easiest location. Here are some notes.
1. Obviously, the Scanner is an LSL app in-world. So, initiating one of the several Scan processes, along with passing certain manually input parameters, would most easily happen in-world.
2. Obviously, Scanner output will have to travel over, I presume via either email or XML/RPC.
3. At this point, ANY data input thats more convenient out-of world can happen there. If there's a transaction that requires both in and out world component interaction, the operator can easily access web via llLoadURL.
4. The only necessary "report" which will need to be "notecard-friendly" will be the deed report resulting from Scan Two: Part One, since this deed report will comprise the pro-forma deed which will then get authenticated by the Notary process which we've already set up in NBurg. I can create this "notecard-friendly" (obviously, basically an elemental TXT file) deed form, and your data app can feed fields into it.
Running through the various processes described, these are the input and output components I see.
Inputs.
1. Run Utility Scan. no parameters
2. Run Land Transaction Scan.
more or less permanent input of Transfer Group key
Form for inputting Person name, Group name, and some little tool for grabbing Group Key
Initiate second part of Scan depending on decision outcome
3. Zoning Scan.
First version Again, more or less permanent input of Transfer Group key
Form for inputting Zone #
Second Ver Form to select Citizen# and input Zone#
Outputs.
1. Utility Scan. The "Map". As mentioned above. Be nice to do as multiple layers, like the SL main map. Turn components on and off. One layer should be a manually drawn "parcels" layer, since this is one element of data we cannot derive from the Scanner.
DB2... Using DB2 and DB5, generate a variety of reports on demand. Example, the current "Land Fees" http://neufreistadt.info/id33.html , and "Land" http://neufreistadt.info/id11.html , could both be generated this way.
2. Land Transaction Scan.
The purpose of this scan is to do a transaction. So a Pro-forma deed, as described above (the "notecard compatible" form) is the main output. We could also do a report which is the same thing without the Person name info for basic utility purposes... this goes to the point of the Zoning Scan.
3. Zoning Scan.
The purpose of this scan is to populate DB4. We could output as well maybe a form listing all zones and their m2's. Check to make sure that everything adds up to 65,536.
