Moderator: SC Moderators
This is the simplest RL system used to establish who owns what. Since the estate owner owns the sim, it's good to have a system for recording land transactions.
Here are some details: http://en.wikipedia.org/wiki/Torrens_title
Maybe we can modify something like this for SL.
4-39 Use of the Torrens or Cadastre Systems
The Austrialian Torrens system is proposed in order to record Neualtenburg deeds and land transactions. The Torrens system is the simplest method of clearly recording title and minimizing land disputes. The Estate Manager is repsonsible for maintaining deeds and recording land transactions. The Guild will oversee the estate manager to ensure that deeds and the land transaction log are in order. Optionally, the French cadastre system could be used in lieu of the Torrens system at the discretion of the Guildmaster.
The Torrens system appears to involve the numbered registration of "parcels" of land as the sole recording of the ownership of that land, in order to avoid problems of certification of actual title of the seller.
It certainly appears to be an interesting, and very simple, system, and could probably be implemented with LSL. However, because it addresses RL issues, and takes no account of SL issues, I have suggested another system. Which may, btw, be implemented in parallel with this.
I have previously published (I think) this proposal for an expansion of the Land Mapping system set up by Sky Honey. The purpose of the expansion was to use the scanning and mapping tool and extend it to the generation of deeds and the formation of citizen land accounts. All the details of this system spring from the unique qualities of land on a private sim in SL.
Here's the "Operational" part of the proposal. It was not drafted as a bill, so please excuse the vagueness in certain areas. It was meant as one half of a project proposal, the other half being specifically devoted to programming.
-----------------------------------
City of Neualtenburg
Land Transaction process
-----------------------------------------------
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.
-------------------------------------------
end of existing proposal
-------------------------------------------
A full description of the concepts are not included here... I had intended this to get evolved as the project was implemented. I'd be happy to discuss this with folks, and, given interest and time, develop a thorough description.
Sudane
My goals were:
-A simple system for verifying ownership and reducing the possibility of disputes.
-A mechanism for recording land transactions in order to be able to view a history of ownership of a given parcel.
-The ability for the above system to handle apartment living, subdivisions and mortgages.
It appears that Sudane's proposal meets all these criteria, and so I withdraw my bill. If we feel her proposal needs a bill, I'd be happy to assist in drafting it, otherwise we could just view the choice of land mangement system as the perogative of the GM.
My goals were:
-A simple system for verifying ownership and reducing the possibility of disputes.
-A mechanism for recording land transactions in order to be able to view a history of ownership of a given parcel.
-The ability for the above system to handle apartment living, subdivisions and mortgages.
It appears that Sudane's proposal meets all these criteria, and so I withdraw my bill. If we feel her proposal needs a bill, I'd be happy to assist in drafting it, otherwise we could just view the choice of land mangement system as the perogative of the GM.
[quote:2uuu4paq]-The ability for the above system to handle apartment living, subdivisions and mortgages. [/quote:2uuu4paq]
Well, as conceived, it doesn't explicitly handle these... rather I think lays a framework, in database form, for features which could get built on the data.
In its absolutely most basic concept, the system would track the ownership of each "quad" in the sim (4mX4m), Ownership in its literal, technical sense... the name of the group which name appears in the "Owner Field of that "quad". Using data organization routines and lookup methods, this data becomes the underpining of the land management.
Since the fundamental molecule of the system is the owner groupname retrieved via LSL from the land itself, concepts like apartment living would not be as well suited to this system, since that would imply multiple sharing ownership over one groupname. In fact, at the point such a system as this might be implemented, it will be important that every citizen, possessing no matter how small a lot, have their own group.
You might be a citizen by virtue of your identity as a representation of a RL human being, but your land ownership title will be established via the name of your group (until such time as land management tools are improved by LL).
Sudane
[quote="Sudane Erato":1qgt2p2n]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.[/quote:1qgt2p2n]
I wonder whether it would be beneficial to count like this instead: quad 0101, quad 0102, quad 0102, ..., quad 0163, quad 0164, quad 0201, quad 0202, ..., quad 6463, quad 6464.
That way, the quad number directly represents the grid layout and is similar to map co-ordinates.