RELATED APPLICATIONS
-
This disclosure claims priority to U.S. App. No. 62/965,104 filed 23 Jan. 2021 (entitled “Parcel Aggregation Facilitation Systems and Methods”), which is incorporated by reference herein in its entirety for all purposes.
BRIEF DESCRIPTION OF THE DRAWINGS
-
FIG. 1 illustrates land parcels and potential parcel assemblages according to one or more improved technologies.
-
FIG. 2 illustrates a displayable model comprising a development of several virtual shelters or other building models in which one or more improved technologies may be incorporated.
-
FIG. 3 depicts a transpacific implementation featuring special-purpose transistor-based circuitry in which one or more improved technologies may be incorporated.
-
FIG. 4 depicts a distributed ledger in which one or more improved technologies may be incorporated.
-
FIG. 5 depicts data-handling media containing particular information items in which one or more improved technologies may be incorporated.
-
FIG. 6 illustrates a displayable top-view model comprising a development of a virtual building model that spans several parcels in which one or more improved technologies may be incorporated.
-
FIG. 7 illustrates an augmented display of a perspective-view model comprising the virtual building model of FIG. 6 in which one or more improved technologies may be incorporated.
-
FIG. 8 depicts a network-connected mobile device in which particular information items reside in data-handling media in which one or more improved technologies may be incorporated.
-
FIG. 9 depicts a client device in which one or more improved technologies may be incorporated.
-
FIG. 10 depicts a server in which one or more improved technologies may be incorporated.
-
FIG. 11 depicts a particular scenario and progressive data flow in which client devices interact with one or more servers according to one or more improved technologies.
-
FIG. 12 depicts another particular scenario and progressive data flow in which client devices interact with one or more servers according to one or more improved technologies.
-
FIG. 13 depicts an offer-descriptive message generated according to one or more improved technologies.
-
FIG. 14 depicts an operational flow in which one or more improved technologies may be incorporated.
-
FIG. 15 depicts another operational flow in which one or more improved technologies may be incorporated.
-
FIG. 16 depicts yet another operational flow in which one or more improved technologies may be incorporated.
DETAILED DESCRIPTION
-
The detailed description that follows is represented largely in terms of processes and symbolic representations of operations by conventional computer components, including a processor, memory storage devices for the processor, connected display devices and input devices. Furthermore, some of these processes and operations may utilize conventional computer components in a heterogeneous distributed computing environment, including remote file servers, computer servers and memory storage devices.
-
It is intended that the terminology used in the description presented below be interpreted in its broadest reasonable manner, even though it is being used in conjunction with a detailed description of certain example embodiments. Although certain terms may be emphasized below, any terminology intended to be interpreted in any restricted manner will be overtly and specifically defined as such.
-
The phrases “in one embodiment,” “in various embodiments,” “in some embodiments,” and the like are used repeatedly. Such phrases do not necessarily refer to the same embodiment. The terms “comprising,” “having,” and “including” are synonymous, unless the context dictates otherwise.
-
“Above,” “accelerating,” “achieved,” “aggregate,” “any,” “application-type,” “application-specific,” “assembled,” “augmented,” “automatic,” “availability,” “based on,” “because,” “complete,” “comprising,” “conditional,” “configured,” “correlated,” “current,” “decelerating,” “decreasing,” “digital,” “directly,” “displayable,” “distributed,” “executed,” “first,” “given,” “higher,” “hybrid,” “implemented,” “in combination with,” “inalterable,” “included,” “indicated,” “inferred,” “integrated,” “malicious,” “matching,” “monotonic,” “more,” “mutually,” “multiple,” “negatively,” “of,” “otherwise,” “particular,” “partly,” “positively,” “prior,” “private,” “public,” “received,” “remote,” “requester-specified,” “responsive,” “scoring,” “second,” “seeding,” “sequencing,” “shorter,” “signaling,” “simultaneous,” “single,” “smart,” “so as,” “special-purpose,” “specific,” “stepwise,” “suitability,” “techniques,” “temporal,” “third,” “through,” “transistor-based,” “undue,” “updated,” “upon,” “utility,” “version-controlled,” “via,” “without,” or other such descriptors herein are used in their normal yes-or-no sense, not merely as terms of degree, unless context dictates otherwise. As used herein “inventory-type” instruction sets are those that primarily implement asset transfers or verifications thereof, moving quantities among accounts rather than changing them. As used herein “data transformative” instruction sets are those that primarily implement other kinds of computations. Although one of these types of instruction sets may invoke the other as a subroutine, only very rarely is a single code component of instructions a true hybrid.
-
In light of the present disclosure those skilled in the art will understand from context what is meant by “remote” and by other such positional descriptors used herein. Likewise they will understand what is meant by “partly based” or other such descriptions of dependent computational variables/signals. “On-chain” refers to (permanent) inclusion in a blockchain, whether or not such content is public or transparent. “On-list” encompasses not only on-chain but also other content linked and effectively rendered immutable using cryptography (e.g. in a consensus-based data verification). In an implementation that includes “on-list” content (e.g. a blockchain or tangle) as described below, “off-list” refers to content elements (e.g. an in-app account ledger) that have yet to be included “on-list.” A set of items is “numerous” if at least two dozen items are included. A “batch” data distribution (broadcast) is one in which data is directed to numerous recipients (i.e. dozens or more) within a limited time (e.g. less than 24 hours) after a triggering event (e.g. an administrator action or weekly trigger time). Terms like “processor,” “center,” “unit,” “computer,” or other such descriptors herein are used in their normal sense, in reference to an inanimate structure. Such terms do not include any people, irrespective of their location or employment or other association with the thing described, unless context dictates otherwise. “For” is not used to articulate a mere intended purpose in phrases like “circuitry for” or “instruction for,” moreover, but is used normally, in descriptively identifying special purpose software or structures.
-
Reference is now made in detail to the description of the embodiments as illustrated in the drawings. While embodiments are described in connection with the drawings and related descriptions, there is no intent to limit the scope to the embodiments disclosed herein. On the contrary, the intent is to cover all alternatives, modifications, and equivalents. In alternate embodiments, additional devices, or combinations of illustrated devices, may be added to, or combined, without limiting the scope to the embodiments disclosed herein.
-
FIG. 1 illustrates what is meant by “parcel assemblage” herein. Shown is a top view of a geographic region 111A in which a reference parcel 161 may be combined with a first adjacent parcel 161 to form a first parcel assemblage 121, with a second adjacent parcel 162 (and perhaps a third parcel 163) to form a second parcel assemblage 122, or with both to form other parcel assemblages such as a largest superset parcel assemblage 123 that includes the first and second parcel assemblages 161-162. Notably, in some contexts parcel assemblage 123 is recognizable by one or more machine learning modules described herein as unsuitable for further expansion (e.g. by virtue of no additional adjacent parcels being available to add according to available parcel description records).
-
FIG. 2 shows a displayable model of another potential construction site 211 in which a virtual development comprising several virtual building models 202A are shown. They are an example of a species 201A, one of many hypothetical but well-defined developments that might be erected upon an assemblage of parcels.
-
FIG. 3 shows a system 300 by which a user in one region 111B of Asia may interact with many parcels in a city or neighborhood of interest or other particular region 111C of North America. Whichever of these regions 100 contains the parcels being analyzed corresponds to one or more local site maps 360 (e.g. with one or more coordinates or dimensions 362), one or more municipal or other regional zone types 370 (e.g. defined by one or more parcel use constraint codes 371 or other regulatory definitions 372), one or more valuations 380 (e.g. affected by an ownership history 381 or property transaction comparables 382), or other such information as described herein.
-
FIG. 3 also depicts special-purpose transistor-based circuitry 330—optionally implemented as an application specific integrated circuit (ASIC) or in a user interface (UI) governance server, for example—in which some or all of the functional modules described herein may be implemented. Transistor-based circuitry 330 includes one or more instances of various modules 331-338 as further described below. Assemblage modules 331, for example, each including an electrical node set 341 upon which informational data is represented digitally as a corresponding voltage configuration 351. Alternatively or additionally, transistor-based circuitry 330 may likewise include instances of invocation modules 332 (e.g. configured to invoke one or more other modules 334-338) each including an electrical node set 342 upon which informational data is represented digitally as a corresponding voltage configuration 352. Transistor-based circuitry 330 may likewise include instances of speciation modules 333 each including an electrical node set 343 upon which informational data is represented digitally as a corresponding voltage configuration 353. Transistor-based circuitry 330 may likewise include instances of evaluation modules 334 each including an electrical node set 344 upon which informational data is represented digitally as a corresponding voltage configuration 354. Transistor-based circuitry 330 may likewise include instances of indexing modules 335 each including an electrical node set 345 upon which informational data is represented digitally as a corresponding voltage configuration 355. Transistor-based circuitry 330 may likewise include instances of response modules 336 each including an electrical node set 346 upon which informational data is represented digitally as a corresponding voltage configuration 356. Transistor-based circuitry 330 may likewise include instances of configuration modules 337 each including an electrical node set 347 upon which informational data is represented digitally as a corresponding voltage configuration 357. And transistor-based circuitry 330 may likewise include instances of transmission modules 338 each including an electrical node set 348 upon which informational data is represented digitally as a corresponding voltage configuration 358. In some variants, as described below, such modules implement such functionality jointly (e.g. in conjunction with other modules or processors described herein). Alternatively or additionally, in some variants such modules (or components thereof) may be geographically distributed across one or more networks 350.
-
FIG. 4 schematically illustrates a system 400 in which respective (institutional or other) entities 410A-B interact with one another and with participating mining rigs (as blockchain node device 490K or similar distributed node devices 490A-J many of which are, at various times, able to implement a crypto asset transfer or other transaction 441 or to confirm such occurrences as described below (e.g. by one or more confirmations 442). In some variants a private entity 410A comprises one or more node management servers 1000A that interact with one or more client devices 400A thereof (e.g. via respective instances of linkage 444A). Likewise a public or collective entity 410B comprises one or more node management servers 1000B that interact with one or more client devices 400B thereof (e.g. via respective instances of linkage 444B). In some instances (e.g. in response to interactions via linkages 444C-D) the entities 410A-B may cooperate so that updates (e.g. indicia of dispensations, distributed ledger recordations, or other events) to values maintained at (one or more instances of) server 1000B are received and so that adequately timely confirmations to those updates can occur in a decentralized fashion. In an instance where a node is distributed across multiple servers 1000B in a proof-of-work architecture, for example, numerous proof-of-work blockchain node devices 490A, 490C, 490D, 490E, 490G, 490H, 490K (e.g. each implementing a mining rig) may validate changes thereof (e.g. by correctly identifying which block was added last) so as to maintain or rebuild consensus on one or more blockchains 455. Alternatively or additionally, such consensus may be maintained or rebuilt using numerous (proof-of-stake or other) secure blockchain node devices 490B, 490F, 490I, 490J not configured as a mining rig may validate changes to a particular node in other blockchain proof architectures currently in public use.
-
As used herein, a plain reference numeral (e.g. like 490) may refer generally to a member of a class of items (e.g. like computing devices) exemplified with a hybrid numeral (e.g. like 490A) and it will be understood that every item identified with a hybrid numeral is also an exemplar of the class. Moreover although a reference numeral shared between figures refers to the same item, most figures depict respective embodiments.
-
FIG. 5 shows one or more data-handling media 500. Operational data 505 thereon may include one or more instances of parcel-specific data 506, of parcel assemblage data 507, of investor data 510, or of acquisition data 530. For example, such parcel-specific data 506 may include one or more instances of postal codes 541 of identifiers of a district 543, of identifiers of a region 544, of identifiers of a city 544, of reference lot identifiers 547, of lot identifiers 548 pertaining to lots 161, 162 adjacent to a corresponding reference lot 160 of coordinates (e.g. pertaining to a lot boundary), or of other such geographic data 540. Alternatively or additionally such parcel-specific data 506 may include one or more instances of owner names 551, of corresponding physical or other addresses 553, of dates 555 (e.g. of a recorded retrieval or transmitted offer as described herein), of explicitly selected or other apparent preferences 556, or of other such owner data 550. Alternatively or additionally such parcel-specific data 506 may include one or more instances of public or other third-party records 558.
-
Likewise such parcel assemblage-specific data 507 may include one or more instances of parcel assemblage identifiers 571, of parcel lists 573 for each respective parcel assemblage, of (protocols for) seeding 575 that define how seeding is/was done for a given species or specimen, of identifiers of speciation protocols 576 that define how speciation is/was done for a given species or specimen, of reference lot identifiers 577, of adjacent lot identifiers 578, or of other specimen-descriptive data 570 referenced herein. Alternatively or additionally such parcel assemblage-specific data 507 may include one or more instances of specimen-specific objective machine-learning-based scores 581, of determination dates 583 or similar evaluation data provenance, of scores reflecting subjective specimen compatibilities 584 (e.g. partly based on objective indicia and partly based on a preference model 514 of a potential buyer as described herein), of evaluation identifiers 586 that designate what each rank or other score herein signifies, of cycle counts 587 that designate how many recursions or other iterations of a protocol 576 were used in repeatably generating a given species 201 from its corresponding seeding 575, of current ranks 588 of each species hold relative to other generated species 201 of the same type, or other such augmented evaluation 580.
-
In some variants such operational data 505 may likewise include one or more instances of session or other user interaction dates 513 (e.g. signaling when an entity requested information); of preference models 514 (e.g. designating points or ranges of ideal parcel assemblage size, estimated price, or profit margin in a given investor's project or campaign); of search, presentation duration, or other action histories 515 by which such preference models may be derived; or of other such investor data 510.
-
In some variants such operational data 505 may likewise include one or more instances of historical or proposed prices 531; of option exercise or other fulfillment deadlines 532; of lists 534; of messages 535, of default values 537 (e.g. a designated value as described herein initially set by the system but available to change); of estimated returns on investment 538 or other figures of merit; of tracked module invocations 539 (whereby a task described herein is performed by a remote instance of one or more of the above-described modules 331-338 in response to a locally transmitted request); or of other acquisition data 530 pertaining to a potential or actual parcel availability described herein.
-
As used herein a “parcel assemblage” is a (nominally) contiguous set of real property parcels not all commonly owned. Two parcels are “contiguous” if they share a property line or if their respective boundaries are sufficiently proximate that the two parcels are adjacent. Two parcels can be “adjacent” across a public street only if they are suitable to be linked by a bridge, tunnel, or other artificial structure. As used herein an “instantaneous” response to a triggering event is one that is completed in less than one second after the triggering event. As used herein an operation is “deterministic” only if current temporal indicia and iteration-specific randomness do not affect its outcome. As used herein a protocol or other process is “deterministically repeatable” if seeding information, protocol identification, versions, and other operational data 505 is preserved (e.g. on a public blockchain 455) with sufficient fidelity and lasting accessibility that a mutation or other digital speciation thereof that was generated before may be perfectly and systematically re-created. A collection of geographic assemblages is referred to as “geographically dispersed” herein if more than half of the assemblages of the collection are each separated from all of the other assemblages in the collection by more than 100 meters. As used herein a parcel assemblage is “identified” by obtaining street addresses, boundary coordinates 361 or other legal definitions 372 that provide shape and position information, alphanumeric lot identifiers 548, or other such parcel-specific data 506 describing (serially or otherwise) adjacent parcels thereof.
-
Terms like “feature-augmentation-type” refer herein not only to feature augmentation per se but also to other technologies in which seeding or speciation are used for gleaning viable and detailed recommendation data (e.g. scores 581, ranks 588, merit-based default values, or other “better” configurations 872 initially presented in lieu of other available counterparts) derived from one or more profile tags or other heuristics. In light of teachings herein, for example, such seeding or speciation (or both) can be gleaned from a crowdsourced or other action history 515 so as to augment the features of the identified species without any undue experimentation.
-
FIG. 6 shows a displayable top view of another model 600 of a potential construction site in which a single virtual building model 202B spanning multiple parcels is shown. It is another example of a species 201B derived as a highest-scoring one of many hypothetical but well-defined developments that might be erected on this city block if mutually agreeable transactions and suitable supporting investment can be resolved.
-
FIG. 7 shows a displayable perspective rendering 700 of the model 600 FIG. 6. This can occur, for example, in a context in which a parcel assemblage-specific estimated total acquisition price 531, model-specific areal apportionments (e.g. simultaneously presenting respective square footages of two or more categories displayed with suitable labels for each), model-specific total development costs, expected return on investment 538, or other such quantifications 739 of particular merit are presented overlapping or otherwise adjacent a perspective rendering and in which an automatically generated and ranked alternative (parcel assemblage 121-123 or other) species 201 encompassing a reference parcel 160 can be indexed through with a single user action that also triggers an update of the quantification(s) 739 to correspond with the shown species. In some variants, moreover, the duration of a presentation to a user is used to update the preference model 514 of the user, as further described below.
-
Referring now to FIG. 8, there is shown a system 800 in which one or more client devices 900 interact with (servers or other resources in) one or more networks 850. A device user or other human entity 10 interacts with one or more such networks 350, 850 via a touchscreen or other display screen 812 of a client device 900 (see FIG. 9). Aboard such a device as shown is one or more data-handling media 804 on which there may reside one or more instances of responses 825; of phone numbers 857, degrees 859 of service, or other access information 860; of resources 891; of periods 892, of gestures or other user actions 894 such as activations of a button or other control 895; or of displayed images 896. In some contexts, for example, such responses 825 may include one or more user-specific maps 360, data types 370, asset valuations 380, recommendations 821, or (indications of) process status 822. Alternatively or additionally, such media 804 may contain one or more instances of searches 861, of shapes 864, of configurations 872, of applications 877, of comparisons 879, of inquiries 883, of selected or other options 884, of smart contracts 885 resident on one or more blockchains 455, of levels 887 (of a multi-story building generated by artificial intelligence as described herein), or of terms 890 to which these relate as described below.
-
With regard to data distillation as described herein, the selective inclusion of suitable parcel assemblages and viable structures depicted thereon are described herein as “pattern matching.” In the context of artificial intelligence, pattern matching is a branch of machine learning in which token sequences are searched for occurrences of (data corresponding to) a pattern. In light of technologies described herein, advanced machine learning may allow one or more servers described herein to overcome a computational barrier that previously made effective pattern matching in regard to structures that could be built on a regional assortment of parcel assemblages computationally prohibitive. As described herein, various technologies allow artificial intelligence to generate, sift, and selectively present vetted hypothetical structures automatically. Terms like “pattern-matching-type” refer herein not only to pattern matching per se but also to prioritization and other technologies in which one or more sequences of tokens are searched for occurrences of suitable adjacent land parcels for assemblage analysis, ranking, or recommendation (e.g. in an image 896 presented to a display screen 812). In a virtual or augmented reality implementation, for example, such assemblages and virtual structures thereon may come into view as a device 900 approaches and enters a corresponding physical location.
-
Referring now to FIG. 9, there is shown a client device 900 in which one or more technologies may be implemented. Device 900 may include one or more instances of processors 902, of memory 904, of user inputs 908, and of display screens 912 all interconnected along with the network interface 906 via a bus 916. One or more network interfaces 906 allow device 900 to connect via the Internet or other networks to or within corporate or other human entities 10. Memory 904 generally comprises a random-access memory (“RAM”), a read only memory (“ROM”), and a permanent mass storage device, such as a disk drive.
-
Memory 904 may contain one or more instances of operating systems 910, web browsers 914, and local apps 924. These and other software components may be loaded from a non-transitory computer readable storage medium 918 into memory 904 of the client device 900 using a drive mechanism (not shown) associated with a non-transitory computer readable storage medium 918, such as a floppy disc, tape, DVD/CD-ROM drive, flash card, memory card, or the like. In some embodiments, software components may also be loaded via the network interface 906, rather than via a computer readable storage medium 918. Special-purpose circuitry 922 may, in some variants, include some or all of the event-sequencing logic described herein as transistor-based circuitry 354 (e.g. in a peer-to-peer implementation) and one or more security features 960 (e.g. a fob or similar security apparatus).
-
In some contexts security feature 960 may implement or otherwise interact with a removable or other digital wallet 966. Such wallets may (optionally) each include one or more instances of private keys of utility tokens, of crypto currency, of provenance data, or of device-executable code snippets (e.g. smart contracts) configured to perform one or more functions as described below. In some embodiments client device 900 may include many more components than those shown in FIG. 9, but it is not necessary that all conventional components be shown in order to disclose an illustrative embodiment.
-
Referring now to FIG. 10, there is shown an exemplary server 1000 one or more of which may likewise be configured to perform functions as described below. Server 1000 may include one or more instances of processors 1002, of memory 1004, of user inputs 1008, and of display screens 1012 all interconnected along with the network interface 1006 via a bus 1016. One or more network interfaces 1006 allow server 1000 to connect via the Internet or other networks to or within entities as described below). Memory 1004 generally comprises a random-access memory (“RAM”), a read only memory (“ROM”), and a permanent mass storage device, such as a disk drive.
-
Memory 1004 may contain one or more instances of operating systems 1010, hosted websites 1020, and aggregation modules 1026. These and other software components may be loaded from a non-transitory computer readable storage medium 1018 into memory 1004 of the server 1000 using a drive mechanism (not shown) associated with a non-transitory computer readable storage medium 1018, such as a floppy disc, tape, DVD/CD-ROM drive, flash card, memory card, or the like. In some embodiments, software components may also be loaded via the network interface 1006, rather than via a computer readable storage medium 1018. Special-purpose circuitry 1022 may, in some variants, include some or all of the event-sequencing logic described with reference to FIG. 3 (e.g. in a peer-to-peer implementation) and one or more security features (e.g. a firewall), not shown. In some embodiments server 1000 may include many more components than those shown in FIG. 10, but it is not necessary that all conventional components be shown in order to disclose an illustrative embodiment.
-
FIG. 11 depicts a particular scenario and progressive data flow 1100 in which client devices 900 respectively used by several human entities 10A-C interact with one or more servers 1000A-D in regard to a potential transfer of a reference parcel 160 in facilitating development of a multi-parcel assemblage. A species development server 1000C receives parcel descriptions 1115 and other reference data 1120 such as site maps 360, zone types 370, valuations 380, or other operational data 505. Thousands of diverse stock species 1140A are developed in numerous urban and suburban regions across multiple price ranges and zoning-compatible land uses. Many such species posit a largest superset parcel assemblage 123 (nominally) incompatible with an inclusion of additional adjacent land. Many others are based upon price-appropriate subset thereof that are consistent with interior area sizes or other aspects of a particular investor's preference model. Meanwhile several investor entities 10C undergo registration, which may provide overt expressions of preference to presentation server 1000D that may inform a most promising inventory 1150A. For example property search development criteria 1140 may provide operating parameters 1145 to development server to enhance the available inventory 1150A through further speciation, as well as to support an immediate service 1155 of rendering candidate parcel assemblages and building model configurations 872.
-
After an implementation delay 1149 of several additional hours or days, such focused search parameters 1145 may have been used by the development server(s) 1000C to develop additional parcel assemblages (and species thereof) of likely interest (as manifested by a compatibility 584, rank 588, or other score 581 thereof) in an enhanced inventory 1150B. Moreover prior offers or other available owner data 550, contractual restriction status may be useful to update 1160 to facilitate real-time parcel selection refinement 1170, offer customization 1185, and the resulting firm offers or other offer-descriptive content 1190 being distributed to owners of parcels of confirmed interest.
-
The following table illustrates a root genetic algorithm suitable for use (e.g. by one or more development servers 1000C) in one or more variants described herein:
-
TABLE 1 |
|
Algorithm 1 root genetic algorithm |
|
|
1: |
generation0 = for M species: |
2: |
for N specimens: |
3: |
generate random specimen (according to strategy) |
4: |
generationn+1 = map for each species in generationn: |
5: |
map for each specimen in species: |
6: |
if (random probability 70%): |
7: |
// do crossover |
8: |
if (random probability 1%): |
9: |
get random other specimen from random other species |
10: |
else: |
11: |
get random other specimen from this species |
12: |
specimen = crossover(specimen, other specimen) |
13: |
if (random probability 25%): |
14: |
specimen = mutate(specimen) |
15: |
if (random probability 0.5%): |
16: |
specimen = smooth(specimen) |
17: |
specimen = normalize(specimen) |
18: |
specimen.fitness = evaluate(specimen) |
19: |
return specimen |
20: |
fitness change rate = 1000 |
21: |
best specimen ever = specimen having max |
(fitness from specimens in generation0) |
22: |
recurse through generations: |
23: |
// keep track of the best specimen we’ve ever seen |
24: |
best specimen = specimen having max |
(fitness from specimens in generation) |
25: |
if best specimen.fitness > best specimen ever.fitness: |
26: |
best specimen ever = best specimen |
27: |
// moving average to see how quickly we’re improving |
28: |
fitness delta = best specimen.fitness − best specimen ever.fitness |
29: |
fitness change rate = (92% * fitness change rate) + |
30: |
if (fitness change rate < min change rate or |
generation number >= 1500): |
31: |
abort |
32: |
return best specimen ever |
|
-
The following table illustrates an arena sizing algorithm suitable for use (e.g. by one or more development servers 1000C) in some variants described herein:
-
TABLE 2 |
|
Algorithm 2 arena sizing algorithm |
|
|
1: |
// The arena is the local grid of cells in which specimens |
can be generated. A parcel’s lot area is mapped onto a grid of fixed-size |
cells with the following algorithm: |
2: |
parcel street line = the street line with the same name as the |
3: |
parcel orientation = angle from parcel centroid to parcel street line |
4: |
// This is used to transform points from global coordinates to |
5: |
accurate local coordinate system for the parcel based on the |
6: |
tolocal(centroid {x, y}, point {x, y}) = |
7: |
radius of earth = 6,371,009 m |
8: |
centroid radians = centroid * (π/180) |
9: |
point radians = point * (π/180) |
10: |
// cos(centroid radians.y) accounts for convergence of longitude |
11: |
return { |
12: |
x = radius of earth * (point radians.x − centroid radians.x) * |
13: |
y = radius of earth * (point radians.y − centroid radians.y) |
14: |
} |
15: |
// Project the polygon to our local coordinate system in metres |
16: |
local poly = map tolocal(parcel centroid, point) for each point in |
parcel polygon // lot lines |
17: |
// Rotate the parcel to its orientation |
18: |
local poly = rotate(local poly, parcel orientation) |
19: |
|
20: |
// Place the grid around the center of the rotated polygon. |
21: |
the defining shape of our arena |
22: |
bounding box = make bounding box for local poly: { |
23: |
MinX = min(x) from local poly |
24: |
MinY = min(y) from local poly |
25: |
MaxX = max(x) from local poly |
26: |
MaxY = max(y) from local poly |
27: |
} |
28: |
// Size each cell inside the bounding rectangle - |
these are the discrete units that can be filled with different data |
29: |
// ln = natural logarithm |
30: |
smaller side = smaller of (MaxX − MinX) or (MaxY − MinY) |
31: |
cell size = ln(l + smaller side / 10) / 1.5 |
32: |
|
33: |
// Create a mask of cells within the bounding box that aren’t |
actually within the parcel polygon |
34: |
for each discrete cell {x, y} from {0, 0} in bounding box / |
35: |
cell point = minimum point from bounding box + |
36: |
cell rectangle = {cell point, cell point + cell size} |
37: |
if (cell rectangle is fully inside local poly): |
38: |
mask[x, y] = true |
39: |
else: |
40: |
mask[x, y] = false |
41: |
// Defined for convenience: |
42: |
arena width = floor(bounding box.(MaxX − MinX) / cell size) |
43: |
arena height = floor(bounding box.(MaxY − MinY) / cell size) |
44: |
|
45: |
// The arena is defined as: |
46: |
arena = { |
47: |
world poly, // the original polygon in world coordinates |
48: |
parcel orientation, |
49: |
centroid, |
50: |
local poly, |
51: |
bounding box, |
52: |
cell size, |
53: |
arena width, |
54: |
arena height, |
55: |
mask |
56: |
} |
57: |
// All array shapes and coordinates within strategies will typically |
-
The following table illustrates a single-shelter algorithm suitable for use in some speciation described herein:
-
TABLE 3 |
|
Algorithm 3 single-shelter algorithm |
|
|
1: |
// data structures |
2: |
params := { |
3: |
// We define multiple levels for a given configuration at which |
4: |
levels = array [N] { |
5: |
height, |
6: |
// Areas where building is not permitted measured from the lot line |
7: |
setbacks { left, right, back, front } |
8: |
}, |
9: |
// Parking parameters |
10: |
assumed unit size for parking, |
11: |
parking per dwelling unit, |
12: |
surface parking space area, |
13: |
underground parking space area, |
14: |
underground parking permitted = boolean, |
15: |
} |
16: |
specimen := { |
17: |
params, |
18: |
// A particular cell can be in one of the following states: |
19: |
shape array [X] [Y] arena cells: |
20: |
values for: |
21: |
parking, |
22: |
empty, |
23: |
level1, |
24: |
level2, |
25: |
..., |
26: |
leveln |
27: |
} |
28: |
// genetic algorithm operations |
29: |
random specimen = |
30: |
for each cell {x, y}: |
31: |
if mask[cell] = true: |
32: |
shape[cell] = random either empty or level1 |
33: |
else: |
34: |
shape[cell] = empty |
35: |
normalize(specimen) = |
36: |
set all cells where mask is false to empty |
37: |
crossover(specimen1, specimen2) = |
38: |
axis = randomly choose either X or Y |
39: |
split = randomly choose any coordinate within arena on axis |
40: |
return new specimen { |
41: |
shape = cells from specimen1 where coordinate |
42: |
cells from specimen2 where coordinate on axis >= split |
43: |
} |
44: |
// Smooth out the specimen, somewhat averaging each cell across |
45: |
smooth(specimen) = |
46: |
map for each cell {x, y} in specimen: |
47: |
// Whichever distinct value has the highest sum score |
48: |
// For example, if there are three instances of level2 in the |
49: |
// and others are empty, level2 has a score of 6 and empty has a |
50: |
// we would choose level2 |
51: |
new value = value with highest score where: |
52: |
score 1 for value at {x, y} |
53: |
// neighbors |
54: |
score 2 for value at {x − 1, y − 1} |
55: |
score 2 for value at {x + 1, y − 1} |
56: |
score 2 for value at {x − 1, y + 1} |
57: |
score 2 for value at {x + 1, y + 1} |
58: |
mutate(specimen) = |
59: |
origin = randomly choose point where mask[point] = true |
60: |
level = n if shape[point] is leveln otherwise 0 |
61: |
// either raise or lower structure |
62: |
new level = (if (random) level + 1 else level − 1) clip between 0 |
63: |
// Expand the largest contiguous rectangle that fits fully within |
64: |
// the mask |
65: |
states = [ |
66: |
X minus, |
67: |
X plus, |
68: |
Y minus, |
69: |
Y plus |
70: |
] |
71: |
done = [false, false, false, false] |
72: |
rectangle = {origin, origin} |
73: |
loop through states as state: |
74: |
if not done[state]: |
75: |
// Ensure we can continue to expand |
76: |
if all points in expanded rectangle have mask[point] = true: |
77: |
expand rectangle in the direction of state |
78: |
else: |
79: |
// We can’t expand more in this direction |
80: |
done[state] = true |
81: |
else: |
82: |
if all elements of done are true: |
83: |
break loop |
84: |
randomly choose an action from: |
85: |
Set: |
86: |
set all cells within rectangle to new level // where 0 |
87: |
Set Parking: |
88: |
set all cells within rectangle to parking |
89: |
Shear: |
90: |
set all cells outside of rectangle to empty |
91: |
Flip X: |
92: |
mirror cells within rectangle along X axis |
93: |
Flip Y: |
94: |
mirror cells within rectangle along Y axis |
95: |
fitness(specimen) = |
96: |
// Compute all of the input parameters |
97: |
with lengths(specimen, level) for each level |
98: |
with lengths(specimen, parking) |
99: |
with heights(specimen, lengths) |
100: |
total storeys = max(heights) |
101: |
for each level: |
102: |
storeys = heights[level] |
103: |
limits = conditional limits for(storeys, total storeys) |
104: |
with length suboptimality(specimen, limits, lengths[level]) |
105: |
with setback interference(specimen, limits, lengths[level]) |
106: |
with coverage(specimen, limits, level) |
107: |
with length suboptimality(specimen, {min gap = 50 ft, |
min run = 18 ft}, lengths[parking]) |
108: |
with area stats(specimen, heights) |
109: |
with parking stats(specimen, area stats) |
110: |
with connectedness(specimen) |
111: |
with count walls(specimen, axis) for axes X and Y |
112: |
return sum: |
113: |
40 * (5 + (area stats.spread / total # cells in arena)) + |
114: |
(if params.max FAR is set: |
115: |
if area stats.FAR < params.max FAR: |
116: |
−1 * (1 + 80 * (max FAR − area stats.FAR))3 |
117: |
else if area stats.FAR > params.max FAR: |
118: |
// being over the max FAR is worse |
119: |
−10 * (l + 80 * (area stats.FAR − max FAR))3 |
120: |
else: |
121: |
0 |
122: |
else: |
123: |
2 * (area stats.area)1.3 |
124: |
) + |
125: |
1 * (1 + count walls.cells per wall)2 + // long walls |
126: |
−10 * (count walls.walls)3 + // many walls |
127: |
2 * connectedness.connected + |
128: |
−2000 * (connectedness.alone)2 + |
129: |
1 * (area stats.centrality)2 + |
130: |
−5 * (1 + sum ( |
131: |
(10 * under gap)2 + |
132: |
(10 * under run)2 + |
133: |
(0.3 * one side)2 + |
134: |
(10 * inner hole)2 + |
135: |
(10 * good points)2 + |
136: |
(good)0.6 + |
137: |
if this is the first level and there is more than one level: |
138: |
(20 * gap)3 |
139: |
else 0 |
140: |
) for each length suboptimality) + |
141: |
−5000 * (sum of setback interference for each |
142: |
−5 * (sum of coverage.excess for each level)2 + |
143: |
−10000 * (only if greater than 0: |
144: |
(parking stats.underground parking + |
parking stats.surface parking) − |
145: |
parking stats.required parking) + |
146: |
(if parking stats.underground parking area > 0: |
147: |
// disincentivize underground parking vs. surface parking |
148: |
−1000 * (1 + parking stats.underground parking area / |
149: |
// Measure lengths of either under or on/over level accessible |
150: |
// Result is an array for each axis where each cell maps to a |
151: |
// - Outside: cell is masked, outside the parcel |
152: |
// - Gap(length): this cell is part of a gap of “length” cells below |
153: |
// - OutsideGap(length): same as above but gap is on the outside |
154: |
// - Run(length): this cell is part of a run of “length” cells on or |
155: |
lengths(specimen, level) = |
156: |
for each row for each axis: |
157: |
for cells in row: |
158: |
if mask[cell] = false: |
159: |
lengths[cell] = Outside |
160: |
else if shape[cell] >= level: |
161: |
gather cells on this row while shape[cell] >= level |
162: |
length = count cells |
163: |
lengths[cells] = Run(length) |
164: |
else: |
165: |
gather cells on this row while shape[cell] < level |
166: |
length = count cells |
167: |
if cells are on outside edge of row: |
168: |
lengths[cells] = OutsideGap(length) |
169: |
else: |
170: |
lengths[cells] = Gap(length) |
171: |
// Calculate supported heights for each level based on some concept |
172: |
// These heights will be treated as the actual heights for the |
173: |
// using the heights in the params as a maximum. |
174: |
heights(specimen, lengths) = |
175: |
stability = 5.0 |
176: |
last computed = 0 |
177: |
max supported = array of numbers for each level |
178: |
computed = array of numbers for each level |
179: |
for each level: |
180: |
average length x = calculate mean dimension of |
181: |
all Run(length) in lengths for X axis |
182: |
average length y = calculate mean dimension of |
183: |
all Run(length) in lengths for Y axis |
184: |
min mean length = the lowest of either average length x |
185: |
|
186: |
// The theoretically max supported height at this level. |
187: |
max supported[level] = last computed + |
188: |
then min mean length * cell size * stability else 0) |
189: |
|
190: |
min support = min(max supported for all levels up to and |
191: |
// The actual computed height for this level. |
192: |
computed[level] = the lowest of either |
params.levels[level].height or |
193: |
floor(min support) |
194: |
return {max supported, computed} |
195: |
// “lengths” here is for a particular level or parking, not all of them |
196: |
length suboptimality(specimen, limits, lengths) = |
197: |
gap run x = gap run(limits, lengths, X) |
198: |
gap run y = gap run(limits, lengths, Y) |
199: |
one side = 0 |
200: |
inner hole = 0 |
201: |
for each cell {x, y}: |
202: |
if lengths[x, y] for either axis is Run(length): |
203: |
if length on either axis > limits.max one side: |
204: |
one side += 1 |
205: |
if lengths[x, y] for both axes is Gap: // NOT OutsideGap |
206: |
inner hole += 1 |
207: |
return { |
208: |
sum everything from gap run x and gap run y, |
209: |
one side, |
210: |
inner hole |
211: |
} |
212: |
// “lengths” here is for a particular level or parking, not all of them |
213: |
// Evaluate statistics for the lengths matrix for the axis |
214: |
gap run(limits, lengths, axis) = |
215: |
min run = limits.min run as cells |
216: |
min gap = limits.min gap as cells |
217: |
output = { |
218: |
gap = 0 |
219: |
run = 0 |
220: |
under gap = 0 |
221: |
under run = 0 |
222: |
good = 0 |
223: |
} |
224: |
for each row on axis: |
225: |
start = the index of the first OutsideGap in lengths |
226: |
end = the index of the last OutsideGap in lengths |
227: |
for each column between start and end: |
228: |
match lengths[axis, row, column]: |
229: |
case Gap(length) or OutsideGap(length): |
230: |
if this is not the first or last col and length < min gap: |
231: |
output.under gap += (min gap − length) |
232: |
else: |
233: |
output.good += 1 |
234: |
if this is not OutsideGap: |
235: |
out.gap += 1 |
236: |
skip ahead by length |
237: |
case Run(length): |
238: |
if length < min run: |
239: |
output.under run += (min run − length) |
240: |
else: |
241: |
output.good += 1 |
242: |
output.run += 1 |
243: |
skip ahead by length |
244: |
case Outside: |
245: |
continue |
246: |
return output |
247: |
setback interference(specimen, limits, lengths) = |
248: |
interference = {left = 0, right = 0, back = 0, front = 0} |
249: |
for each direction {Forward, Reverse} of each axis {X, Y}: |
250: |
side if (Forward, X) = left |
251: |
side if (Reverse, X) = right |
252: |
side if (Forward, Y) = back |
253: |
side if (Reverse, Y) = front |
254: |
for each row: |
255: |
initial gap = find first OutsideGap or Gap on axis by direction |
256: |
if row contains any Run: |
257: |
setback = limits.setbacks[side] |
258: |
if initial gap.length < setback: |
259: |
interference[side] += (1 + setback − initial gap.length)2 |
260: |
return interference |
261: |
coverage(specimen, limits, level) = |
262: |
max coverage = limits.max coverage or 100% |
263: |
count = count cells in specimen.shape where value |
264: |
area in one cell = (cell size)2 |
265: |
coverage = (count * area in one cell) / lot area |
266: |
excess = if coverage > max coverage then coverage − |
267: |
return {max coverage, coverage, excess} |
268: |
area stats(specimen, heights) = |
269: |
area in one cell = (cell size)2 |
270: |
area = 0 |
271: |
spread = 0 |
272: |
centrality sum = 0 |
273: |
centrality weights = 0 |
274: |
for each cell {x,y}: |
275: |
if specimen, shape[x, y] is level: |
276: |
area here = area in one cell * |
(heights.computed[level] in storeys) |
277: |
area += area here |
278: |
spread += 1 |
279: |
centrality weight = 1 / (1 + (abs(x − width/2) + |
280: |
centrality sum += area here * centrality weight |
281: |
centrality weights += centrality weight |
282: |
centrality = centrality sum / centrality weights |
283: |
FAR = area / lot area |
284: |
return {area, FAR, spread, centrality} |
285: |
parking stats(specimen, area stats) = |
286: |
area in one cell = (cell size)2 |
287: |
units for parking = area stats.area / |
params.assumed unit size for parking |
288: |
required parking = ceil(units for parking * params.parking |
289: |
surface parking area = (count cells that are parking) * |
290: |
surface parking = floor(surface parking area / params.surface |
291: |
underground parking = |
292: |
if params.underground parking permitted: |
293: |
required parking - surface parking or at least 0 |
294: |
else: |
295: |
0 |
296: |
underground parking area = |
297: |
underground parking * params.underground parking space area |
298: |
return { |
299: |
required parking, |
300: |
surface parking, |
301: |
surface parking area, |
302: |
underground parking, |
303: |
underground parking area |
304: |
} |
305: |
connectedness(specimen) = |
306: |
connected = 0 |
307: |
alone = 0 |
308: |
for each cell {x, y}: |
309: |
if specimen.shape[x, y] is not empty: |
310: |
neighbors = values of specimen.shape for following |
311: |
(x − 1, y − 1), |
312: |
(x − 1, y + 1), |
313: |
(x + 1, y − 1), |
314: |
(x + 1, y + 1) |
315: |
connected here = count neighbors where value is same |
316: |
if connected here > 0: |
317: |
connected += connected here |
318: |
else: |
319: |
alone += 1 |
320: |
|
321: |
return {connected, alone} |
322: |
count walls(specimen, axis) = |
323: |
walls = 0 |
324: |
wall cells = 0 |
325: |
for each row on axis: |
326: |
// Edge-detect array - true where the cell is beside a |
327: |
opposites = array [width] of boolean |
328: |
for each col on axis: // opposite coordinate of row |
329: |
value here = specimen.shape[axis, row, col] |
330: |
next value = specimen.shape[axis, row, col + 1] or empty |
331: |
opposites[col] = value here is not equal to next value |
332: |
last opposites = opposites from the previous row or array of |
333: |
for each (new edge, old edge) in (opposites, last opposites): |
334: |
if old edge = false and new edge = true: |
335: |
// The value has changed on this row |
336: |
// while it didn’t in the previous row. This is the start of a wall. |
337: |
walls += 1 |
338: |
if new edge = true: |
339: |
// Any time the value changed, this is part of a wall |
340: |
wall cells += 1 |
341: |
return {walls, wall cells} |
|
-
The following table illustrates a multi-building algorithm suitable for use in other speciation described herein:
-
TABLE 4 |
|
Algorithm 4 multi-building algorithm |
|
|
1: |
building definition := { |
2: |
width, // x |
3: |
length, // y |
4: |
height, // z |
5: |
floor area, |
6: |
units, // dwelling units contained within the building |
7: |
margins {left, right, back, front}, |
8: |
required padding, // additional unspecified area that must be |
added around the building |
9: |
weight // relative weight for choosing this building |
10: |
} |
11: |
params := { |
12: |
max height, |
13: |
max area ratio, // FAR |
14: |
max units, |
15: |
min lot per unit, // minimum lot area per unit |
16: |
min lot width, |
17: |
path size, |
18: |
conditional limits, |
19: |
bake setbacks, // whether to put the setbacks on the arena rather |
20: |
measure outer setbacks, // whether to measure setbacks |
21: |
one lot only, // whether to only generate a single building |
22: |
access directions, // directions from which access |
is available (street/alley on that side) |
23: |
directions, // directions buildings can face |
24: |
no obstructions, // buildings must not be obstructed by other |
buildings to access the street |
25: |
bias to edge, // prefer buildings toward the edge |
26: |
building definitions |
27: |
} |
28: |
building instance := { |
29: |
building definition, |
30: |
origin {x, y}, |
31: |
rotation: 0 | 90 | 180 | 270 degrees, |
32: |
padding {left, right, back, front} |
33: |
} |
34: |
path instance := { |
35: |
origin {x, y}, |
36: |
size {w, 1}, |
37: |
rotation: 0 | 90 | 180 | 270 degrees, |
38: |
} |
39: |
entity := building instance | path instance |
40: |
specimen := { |
41: |
params, |
42: |
entities array of entity |
43: |
} |
44: |
min change rate = 0.001 // for genetic algorithm |
45: |
rectangle(entity) = |
46: |
case entity.rotation of: |
47: |
0 or 180: w = entity.size.w; 1 = entity.size.1 |
48: |
90 or 270: w = entity.size.1; 1 = entity.size.w // flipped |
49: |
{entity.origin, {w, 1}} |
50: |
|
51: |
// This is defined by the parameters of the building definition |
52: |
building instance.size = |
53: |
{margins.left + width + margins.right, margins.front + |
54: |
random specimen = |
55: |
insert random pattern(empty specimen) |
56: |
normalize(specimen) = |
57: |
if params.one lot only: |
58: |
keep only first entity in entities |
59: |
remove entity from entities where entity.direction is not in |
60: |
remove entity from entities where rectangle(entity) intersects |
61: |
if params.measure outer setbacks: |
62: |
remove entity from entities where rectangle(entity) |
63: |
for each entity in entities: |
64: |
// No overlapping entities. |
65: |
if rectangle(entity) intersects the rectangle of any prior entity |
66: |
remove entity |
67: |
crossover(specimen1, specimen2) = |
68: |
axis = random axis of either X or Y |
69: |
range = range along axis |
70: |
split = random point within range |
71: |
new specimen1 = specimen with entities from ( |
72: |
entities from specimen1 where origin < split along axis + |
73: |
entities from specimen2 where origin >= split along axis |
74: |
) |
75: |
new specimen2 = specimen with entities from ( |
76: |
entities from specimen2 where origin < split along axis + |
77: |
entities from specimen1 where origin >= split along axis |
78: |
) |
79: |
return (normalize(new specimen1), normalize(new specimen2)) |
80: |
mutate(specimen) = |
81: |
// Try again if we fail to insert anything |
82: |
up to 5 times try: |
83: |
insert random pattern(specimen) |
84: |
if params.one lot only: |
85: |
entity = choose random entity from entities |
86: |
remove all from entities except entity // keep a random entity |
87: |
// weighted random |
88: |
random definition(params) = |
89: |
weights sum = sum of weight from params.definitions |
90: |
for each definition in params.definitions: |
91: |
let definition.max number = sum of weight from |
params.definitions prior to and including this definition |
92: |
number = random number between 0 and weights sum |
93: |
for each definition in params.definitions: |
94: |
if number < definition.max number: |
95: |
return definition |
96: |
insert random pattern(specimen) = |
97: |
rectangle = generate random rectangle within arena |
98: |
remove entities from specimen where rectangle(entity) |
99: |
definition = random definition(params) |
100: |
rotation = randomly choose {0, 90, 180, 270} |
101: |
movement axis = case rotation of: |
102: |
0 or 180: Y |
103: |
90 or 270: X |
104: |
movement direction = case rotation of: |
105: |
0 or 90: Positive |
106: |
180 or 270: Negative |
107: |
// each row is the length of two buildings and a path |
108: |
for each row along movement axis in movement direction |
109: |
for each column opposite movement axis |
110: |
in movement direction within rectangle: |
111: |
for every 7th column: |
112: |
insert path instance covering entire column |
113: |
else: |
114: |
// buildings are facing the path |
115: |
insert building instance with opposite(rotation) |
116: |
insert path instance |
117: |
insert building instance with rotation |
118: |
fitness(specimen) = |
119: |
floor area = sum of building definition.floor area for each |
120: |
FAR = floor area / lot area |
121: |
units count = sum of building definition.units for each |
122: |
variations = count distinct building definition for each |
123: |
max units = |
124: |
if params.min lot per unit: |
125: |
density based limit = floor(lot area / |
126: |
lesser of density based limit or params.max units |
127: |
else: |
128: |
params.max units |
129: |
excess units = |
130: |
if max units is set and units count > max units: |
131: |
units count − max units |
132: |
else: |
133: |
0 |
134: |
with edge bias(specimen) |
135: |
with facing preference(specimen) |
136: |
with reachability(specimen) |
137: |
return sum: |
138: |
(if params.max FAR is set: |
139: |
if FAR < params.max FAR: |
140: |
−1 * (1 + 60 * (max FAR − area stats.FAR))2 |
141: |
else if FAR > params.max FAR: |
142: |
// being over the max FAR is worse |
143: |
−1 * (1 + 120 * (FAR − max FAR))2 |
144: |
else: |
145: |
0 |
146: |
else: |
147: |
2 * (floor area)1.4 |
148: |
) + |
149: |
1000 * (units count) + |
150: |
20 * (facing preference)1.2 + |
151: |
−50 * (4 * (variations − l))2 + |
152: |
−1 * (100000 * excess units)2 + |
153: |
50 * (4 * reachability.touching paths)2 + |
154: |
−200 * (4 * reachability.not connected)2 + |
155: |
25 * (4 * reachability.extra path touches)1.2 + |
156: |
−100 * (reachability.path edges)2 + |
157: |
(if params.bias to edge: |
158: |
100 * edge bias |
159: |
else: |
160: |
0) |
161: |
facing preference(specimen) = |
162: |
sum for each building instance: |
163: |
case rotation of: |
164: |
0: 10 * building definition.units // front |
165: |
90 or 270: 3 * building definition.units // right or left |
166: |
180: 1 * building definition.units // back |
167: |
reachability(specimen) = |
168: |
touching paths = 0 |
169: |
not connected = 0 |
170: |
extra path touches = 0 |
171: |
path edges = 0 |
172: |
clear to edge = 0 |
173: |
is covered by path(x0, y0, x1, y1) = |
174: |
for each box-wise (x, y) between (x0, y0) and (x1, y1): |
175: |
if entity intersecting (x, y) is path instance: |
176: |
return true |
177: |
otherwise false |
178: |
// Boxes covering the given edge of the given box to the edge |
179: |
edge sweep(left, x0, y0, x1, y1) = (0, y0, x0 − 1, y1) |
180: |
edge sweep(right, x0, y0, x1, y1) = (x1, y0, arena.width, y1) |
181: |
edge sweep(back, x0, y0, x1, y1) = (x0, 0, x1, y0 − 1) |
182: |
edge sweep(front, x0, y0, x1, y1) = (x0, y1, x1, arena.height) |
183: |
// check edge of box is not obstructed |
184: |
box clear to(direction, x0, y0, x1, y1) = |
185: |
if x0 > x1 then swap x0 with x1 |
186: |
if y0 > y1 then swap y0 with y1 |
187: |
(cx0, cy0, cx1, cy1) = edge sweep(direction, x0, y0, x1, y1) |
188: |
for each box-wise (x, y) between (x0, y0) and (x1, y1): |
189: |
if entity exists intersecting (x, y): |
190: |
return false |
191: |
otherwise true |
192: |
for each building instance entity: |
193: |
(x, y, w, 1) = rectangle(entity) |
194: |
units = building definition.units |
195: |
// each side |
196: |
path touches = count where true: |
197: |
is covered by path(x, y − 1, x + w, y), |
198: |
is covered by path(x, y + 1, x + w, y + 1 + 1), |
199: |
is covered by path(x − 1, y, x, y + 1), |
200: |
is covered by path(x + w, y, x + w + 1, y + 1) |
201: |
if path touches > 0: |
202: |
touching paths += units |
203: |
extra path touches += (path touches − 1) * units |
204: |
else: |
205: |
direction = entity.rotation as direction |
206: |
accessible = params.access directions contains direction |
207: |
if accessible and box clear to(direction, x, y, x + w, y + 1): |
208: |
clear to edge += units |
209: |
else: |
210: |
not connected += units |
211: |
for each path instance entity: |
212: |
(x, y, w, 1) = rectangle(entity) |
213: |
path edges += count where false: |
214: |
is covered by path(x, y − 1, x + w, y), |
215: |
is covered by path(x, y + 1, x + w, y + 1 + 1), |
216: |
is covered by path(x − 1, y, x, y + 1), |
217: |
is covered by path(x + w, y, x + w + 1, y + 1) |
218: |
return {touching paths, not connected, extra path touches, |
path edges, clear to edge} |
219: |
edge bias(specimen) = |
220: |
search(left) = (X, forward) |
221: |
search(right) = (X, reverse) |
222: |
search(back) = (Y, forward) |
223: |
search(front) = (Y, reverse) |
224: |
average score = none for each side |
225: |
min score = none for each side |
226: |
max score = none for each side |
227: |
for each side: |
228: |
(axis, pattern) = search(side) |
229: |
gaps = empty list |
230: |
for each row in arena on axis: |
231: |
entity = none |
232: |
counting = false |
233: |
initial gap = 0 |
234: |
for each column on the opposite axis via pattern: |
235: |
if there is a building instance entity here at axis(row, |
236: |
entity = entity here |
237: |
break loop |
238: |
else: |
239: |
// Count how much of a gap we have before any |
240: |
// building instances at the beginning of the |
241: |
// the lot line |
242: |
if arena.mask[x, y] is true: |
243: |
counting = true |
244: |
initial gap += 1 |
245: |
else: |
246: |
if counting then initial gap += 1 |
247: |
if entity is set and entity is facing side: |
248: |
push(gaps, cells to metres(initial gap)) |
249: |
average score[side] = 1 / (0.1 + (sum gaps / count gaps)/100) |
250: |
min score[side] = 1 / (0.1 + (minimum value in gaps)/100) |
251: |
max score[side] = 1 / (0.1 + (maximum value in gaps)/100) |
252: |
average score mean = average of average score for each side |
253: |
min score mean = average of min score for each side |
254: |
max score mean = average of max score for each side |
255: |
return (average score mean + min score mean + |
-
FIG. 13 illustrates a storage or other data-handling medium 1304 (e.g. a display 812 presenting an image 896) containing an offer-descriptive message 1335 of the general type described herein. Message 1335 comprising a sender identifier 1326, a recipient identifier 1327, and a series of natural-language clauses 1377A-E. As shown clause 1377A includes a subject line that comprises a scalar expression of parcel-specific premium price 1938 (e.g. “Want to sell for $195,000 today?”).
-
Clause 1377B includes a background statement identifying (at least) a published information source 1346 (e.g. “tax records”), a street address 1347, and a corresponding published valuation 380 (e.g. “According to Zillow, your property at 1623 Main Street is worth $176,475”). Clause 1377B also presents an offer-descriptive statement featuring a proposed payment amount 1345 identified by a natural-language description 1316 (e.g. “earnest money” or “option purchase price”), and a payment mode identifier 1317 (e.g. “wire transfer” or “cashier's check”) intended to entice the owner (e.g. “We want to give you a $1000 down payment immediately, directly via Venmo today.”)
-
Clause 1377C includes additional transaction terms 890 including a proposed duration 1328 and a request for a phone number or other requested contact information 1346 to facilitate the inchoate transaction (e.g. “It may take 18 months for us to decide whether to complete the purchase, but either way you keep the $1000. Does that sound fair? If so, please reply with your phone number.”). Clause 1377D includes additional transaction terms 890 (e.g. “Please note that if you accept the $1000, you will have entered a legally binding contract. Also please note that another seller might accept this $1000 on a similar property if you do not reply quickly. This is a ‘first come, first serve’ opportunity.”). Clause 1377E includes a reference to further transaction terms (e.g. “Detailed terms for this contract are provided below.”). Following the salutation and signature, the prospective buying entity may self-identify with a place name 1367 local to the reference parcel or an area code 1368 local to the reference parcel.
-
FIG. 14 illustrates an operational flow 1400 suitable for use with at least one embodiment, such as may be performed (in some variants) on one or more servers 1000 or using special- purpose circuitry 922, 1022. As will be recognized by those having ordinary skill in the art, not all events of information management are illustrated in FIG. 14. Rather, for clarity, only those steps reasonably relevant to describing the distributed ledger interaction aspects of flow 1400 are shown and described. Those having ordinary skill in the art will also recognize the present embodiment is merely one exemplary embodiment and that variations on the present embodiment may be made without departing from the scope of the broader inventive concept set forth in the clauses and claims below.
-
Operation 1415 describes obtaining an identification of first and second assemblages both containing a reference parcel, wherein the first assemblage includes a first parcel adjacent the reference parcel in combination with the reference parcel, wherein the second assemblage includes a second parcel adjacent the reference parcel in combination with the reference parcel, and wherein a reference recordation signals that the reference parcel is not commonly owned with the first or second parcels (e.g. one or more assemblage modules 331 receiving or generating an identification of component parcels in respective first and second parcel assemblages 121, 122 both containing a reference parcel 160, wherein the first parcel assemblage 121 includes a first parcel 161 adjacent the reference parcel 160 in combination with the reference parcel 160, wherein the second parcel assemblage 122 includes a second parcel 162 adjacent the reference parcel 160 in combination with the reference parcel 160, and wherein one or more public records 558 signal that the reference parcel 160 is not commonly owned with the first parcel 161 or with the second parcel 162). This can occur, for example, in a context in which each assemblage module 331 manifests lot identifiers 547-548, boundary coordinates 361, and other such information about the parcels as respective (instances of) voltage configurations 351 thereof.
-
Operation 1430 describes recursively or otherwise obtaining first and second building models of the first assemblage each based on a respective application of first and second deterministically repeatable speciation protocols to a first multi-parcel-assemblage-specific seeding configuration associated with the first assemblage (e.g. an instance of a speciation module 333 obtaining first and second deterministically identified instances of species 201 including one or more simulated building models 202 depicted upon the first parcel assemblage 121 wherein each such species 201 is based on a respective application 877 of at least first and second speciation protocols 576 to a first multi-parcel-assemblage-specific seeding configuration associated with the first parcel assemblage 121). This can occur, for example, in a context in which the first speciation protocol 576 comprises a single-shelter algorithm like that of Table 3 herein; in which the second (instance of a) speciation protocol 576 comprises a multi-building model algorithm like that of Table 4 herein; and in which seeding 575 for such algorithms comprises a reference lot identifier 547, street address 1347, coordinates 361, or other repeatable designation of the reference lot 160 together with a repeatable designation of other parcels of the first parcel assemblage 121 as respective voltage configurations 353.
-
Operation 1440 describes recursively obtaining first and second building models of the second assemblage each based on a respective application of first and second deterministically repeatable speciation protocols to a first multi-parcel-assemblage-specific seeding configuration associated with the second parcel assemblage (e.g. a second instance of a speciation module 333 obtaining first and second deterministic instances of species 201 including one or more simulated building models 202 depicted at least partly upon the second parcel assemblage 122, wherein each such species 201 is based on an application 877 of respective speciation protocols 576 to a multi-parcel-assemblage-specific seeding 575 associated with the second parcel assemblage 122). This can occur, for example, in a context in which the “first” speciation protocol 576 is a multi-building model algorithm like that of Table 4 herein; in which the “second” speciation protocol 576 is a single-shelter algorithm like that of Table 3 herein; and in which seeding 575 for such algorithms comprises a reference lot identifier 547 or other repeatable designation of the reference lot 160 together with a repeatable designation of other parcels of the second parcel assemblage 122 as respective voltage configurations 353.
-
Operation 1450 describes causing the first building model of the first assemblage to be prioritized over the second building model of the first assemblage and to be presented to a user of a visual display in lieu of the second building model based on a machine-learning-based scoring protocol (e.g. a first instance of an evaluation module 334 causing a first species 201 of the first parcel assemblage 121 to be ranked above a second instance of an alternative species of the first parcel assemblage 121 and to be presented to an entity 10C using one or more display screens 912 in lieu of the alternative species based on a machine-learning-based score 581, rank 588, or other evaluation). This can occur, for example, in a context in which such evaluation data 580 comprises explicit preferences from the entity 10C; a preference model 514 derived from search, presentation duration, or other user action history 515; or no preference data at all. Alternatively or additionally, such preference data relating to one or more entities 10 may be obtained or used (or both) as a component of a supervised-learning-type protocol 576.
-
Terms like “supervised-learning-type” refer herein not only to supervised learning per se but also to other technologies in which input data is mapped to output data based on training data that pairs numerous vector-valued input objects (e.g. defining assemblages, speciations, or other such operational data 505) each to a corresponding desired output value (e.g. a valuation 380, score 581, selection, rank 588, authorization, or other user-provided preference indication) using one or more user-provided inductive biases (e.g. observed user actions 894). In light of teachings herein, for example, such machine learning implementations can be gleaned from search terms 890 or other user inputs 908 from such entities 10 without any undue experimentation.
-
Operation 1465 describes causing the first building model of the second assemblage to be prioritized over the second building model of the second assemblage, to displace the first building model of the first assemblage, and to be presented via the visual display in lieu of the second building model of the second assemblage all partly based on the machine-learning-based scoring protocol and partly based on one or more preference-indicative actions of the user of the visual display (e.g. a second instance of an evaluation module 334 and one or more indexing modules 335 jointly causing the first species 201 of the second parcel assemblage 122 to be deemed preferable over the second species of the second parcel assemblage 122; to replace or partly occlude a rendering of the first species 201 of the first parcel assemblage 121; and to be presented to the user in lieu of the second species of the second parcel assemblage 122 partly based on the machine-learning-based scoring protocol and partly based on one or more preference-indicative actions of the user). This can occur, for example, in a context in which an evaluation module 334 manifests an identifier of the first parcel assemblage as a voltage configuration 354 thereof; in which the rendering of the first species 201 of the first parcel assemblage 121 is thereby initially presented to the user; in which an indexing module 335 manifests a touchscreen activation or other preference-indicative user action as a voltage configuration 355 to index to a next-most-preferable option; in which the visual display presents (the first species 201 of) the second parcel assemblage 122 in response 825; and in which multiple visual display devices would otherwise be required to allow the automatically created message draft to be tailored by the user before transmission.
-
Operation 1480 describes causing a draft offer-descriptive message containing a parcel identifier, a parcel valuation, and a premium valuation to be presented simultaneously via the visual display as a real-time response to a request associated with the reference parcel following a presentation of one or more such building models via the visual display (e.g. one or more configuration modules 337 causing a draft offer-descriptive message 1335 containing a street address 1347 or other lot identifier 247; a public-records or independent-party-provided parcel valuation 380; and premium valuation 1338 10-50% higher than the prior parcel valuation 380 to be presented simultaneously via the one or more display screens 912 as a real-time response 825 to a request associated with the reference parcel 160 following a presentation of one or more such building models 202 corresponding to the message 1335). This can occur, for example, in a context in which the configuration module(s) 137 manifest the draft message 1335 in a memory (e.g. as a voltage configuration 357 on electrical nodes 347 thereof) and in which parcel adjacency would not otherwise get appropriately proactive consideration when undertaking to acquire real property parcels from multiple respective sellers.
-
Operation 1490 describes causing numerous additional pairings of a subject parcel identifier with a corresponding valuation to be presented together after a corresponding building model all within a one-hour period (e.g. one or more response modules 336 serially or otherwise causing dozens of additional pairings of a street address 1347 of a subject parcel 160 each with a corresponding published or other conventional valuation 380 of that parcel to be presented together after a corresponding species 201 of a preferable parcel assemblage 121 of that parcel all within a one-hour period). This can occur, for example, in a context in which the user has reviewed parcel assemblages 121-122 and corresponding species 201 as a semi-automatic protocol for validating parcel suitability; in which the response module(s) 336 manifest such pairings in a proposed offer batch of more than half of the parcels in those validated parcel assemblages; in which the user has reviewed a draft (version of a) message 1335 for at least one such parcel on a prior occasion; in which such validations are manifested as a voltage configuration 356 on electrical nodes 346 thereof); in which a transmission module 338 may thereafter send such offer-descriptive content 1190 to email or other addresses 553 associated with each owner name 551 thereof; and in which a strategically adequate number (i.e. more than 12) of contemporaneous parallel offers (i.e. all within the one-hour period) all based on the same machine-learning-based scoring protocol would otherwise remain unattainable. Alternatively or additionally, the “corresponding” valuations may include premium valuations 1338 each at least partly based on a conventional valuation 380 of the subject parcel (derived as a markup percentage designated by the user, e.g.).
-
In light of teachings herein, numerous existing techniques may be applied for configuring special-purpose circuitry or other structures effective for obtaining real property data and presenting key aspects of potential developments thereon as described herein without undue experimentation. See, e.g., U.S. Pat. No. 10,528,652 (“Generating predictive models for authoring short messages”); U.S. Pat. No. 10,521,943 (“Lot planning”); U.S. Pat. No. 10,521,865 (“Structural characteristic extraction and insurance quote generation using 3D images”); U.S. Pat. No. 10,510,087 (“Method and apparatus for conducting an information brokering service”); U.S. Pat. No. 10,459,981 (“Computerized system and method for automatically generating and providing interactive query suggestions within an electronic mail system”); U.S. Pat. No. 10,496,927 (“Systems for time-series predictive data analytics, and related methods and apparatus”); U.S. Pat. No. 10,467,353 (“Building model with capture of as built features and experiential data”); U.S. Pat. No. 10,387,414 (“High performance big data computing system and platform”); U.S. Pat. No. 10,382,383 (“Social media post facilitation systems and methods”); U.S. Pat. No. 10,198,735 (“Automatically determining market rental rate index for properties”); U.S. Pat. No. 10,192,275 (“Automated real estate valuation system”); U.S. Pat. No. 10,190,791 (“Three-dimensional building management system visualization”); U.S. Pub. No. 20170109668 (“Model for Linking Between Nonconsecutively Performed Steps in a Business Process; and U.S. Pub. No. 20170109638 (“Ensemble-Based Identification of Executions of a Business Process”).
-
In light of teachings herein, numerous existing techniques may be applied for configuring special-purpose circuitry or other structures effective for applying machine learning, blockchain, and other land-related data distillation as described herein without undue experimentation. See, e.g., U.S. Pat. No. 10,897,650 (“Vehicle content recommendation using cognitive states”); U.S. Pat. No. 10,889,925 (“Augmented reality system for stitching along a predetermined path”); U.S. Pat. No. 10,861,187 (“Method of processing object detection data”); U.S. Pat. No. 10,853,398 (“Generating three-dimensional digital content from natural language requests”); U.S. Pat. No. 10,846,873 (“Methods and apparatus for autonomous robotic control”); U.S. Pat. No. 10,839,431 (“Systems, methods and computer program products for cross-marketing related products and services based on machine learning algorithms involving field identifier level adjacencies”); U.S. Pat. No. 10,839,297 (“System and method for configuration of an ensemble solver”); U.S. Pat. No. 10,657,375 (“Augmented reality system for facilitating currency conversion”); U.S. Pat. No. 10,565,329 (“System and method for modelling system behaviour”); U.S. Pat. No. 10,521,508 (“Natural language processing for extracting conveyance graphs”); U.S. Pat. No. 10,373,073 (“Creating deep learning models using feature augmentation”); U.S. Pat. No. 10,297,129 (“Fire/security service system with augmented reality”); U.S. Pat. No. 10,204,362 (“Marketplace listing analysis systems and methods”); U.S. Pat. No. 9,770,189 (“Systematic distillation of status data relating to regimen compliance”); U.S. Pat. No. 9,746,913 (“Secured mobile maintenance and operator system including wearable augmented reality interface, voice command interface, and visual recognition systems and related methods”); U.S. Pat. No. 9,576,083 (“Automatic driver modeling for integration of human-controlled vehicles into an autonomous vehicle network”); and U.S. Pat. No. 9,245,229 (“Occupancy pattern detection, estimation and prediction”).
-
FIG. 15 illustrates an operational flow 1500 suitable for use with at least one embodiment, such as may be performed (in some variants) on one or more servers 1000 using special-purpose circuitry 1022. Operation 1515 describes obtaining an identification of first and second assemblages both containing a reference parcel, wherein the first assemblage includes a first parcel adjacent the reference parcel in combination with the reference parcel, wherein the second assemblage includes a second parcel adjacent the reference parcel in combination with the reference parcel, and wherein a reference recordation signals that the reference parcel is not commonly owned with the other parcels (e.g. one or more assemblage modules 331 generally configured and invoked as described above).
-
Operation 1535 describes obtaining multiple building models of each of the assemblages each based on a respective application of multiple deterministically repeatable speciation protocols to a respective multi-parcel-assemblage-specific seeding configuration (e.g. one or more speciation modules 333 generally configured and invoked as described above).
-
Operation 1550 describes causing a first building model of a first assemblage thereof to be prioritized over a second building model of the first assemblage and to be presented via a visual display based on a given scoring protocol (e.g. one or more evaluation module 334 generally configured and invoked as described above). This can occur, for example, in a context in which such diverse, selective, and controllable presentations allow a developer to see and act upon vetted search results that could not have been visualized via a single display screen 812 and in which such complex arrangements of property transfers would otherwise be too diffuse to allow any such multi-parcel-assemblage-specific development to occur without government compulsion or significant duress.
-
FIG. 16 illustrates an operational flow 1600 suitable for use with at least one embodiment, such as may be performed (in some variants) on one or more servers 1000 using special-purpose circuitry 1022. Operation 1665 describes causing a first building model of a given assemblage to be prioritized over a second building model of the assemblage, to displace a third building model of another assemblage, and to be presented via a visual display all as a conditional response 825 partly based on a machine-learning-based scoring protocol and partly based on one or more preference-indicative actions signaling a reference parcel of the assemblages (e.g. one or more evaluation module 334 generally configured and invoked as described above via the visual display).
-
Operation 1680 describes causing a subsequent presentation of a parcel identifier simultaneously with a corresponding premium valuation at least partly based on a prior valuation thereof (e.g. one or more response, configuration, and transmission modules 356-358 generally configured and cooperatively invoked as described above).
-
Although various operational flows are presented in a sequence(s), it should be understood that the various operations may be performed in other orders than those which are illustrated or may be performed concurrently. Examples of such alternate orderings may include overlapping, interleaved, interrupted, reordered, incremental, preparatory, supplemental, simultaneous, reverse, or other variant orderings, unless context dictates otherwise. Furthermore, terms like “responsive to,” “related to,” or other past-tense adjectives are generally not intended to exclude such variants, unless context dictates otherwise.
-
While various system, method, article of manufacture, or other embodiments or aspects have been disclosed above, also, other combinations of embodiments or aspects will be apparent to those skilled in the art in view of the above disclosure. The various embodiments and aspects disclosed above are for purposes of illustration and are not intended to be limiting, with the true scope and spirit being indicated in the final claim set that follows.
-
In the numbered clauses below, first combinations of aspects and embodiments are articulated in a shorthand form such that (1) according to respective embodiments, for each instance in which a “component” or other such identifiers appear to be introduced (e.g., with “a” or “an,”) more than once in a given chain of clauses, such designations may either identify the same entity or distinct entities; and (2) what might be called “dependent” clauses below may or may not incorporate, in respective embodiments, the features of “independent” clauses to which they refer or other features described above.
CLAUSES
-
1. A machine learning method for facilitating multi-parcel development (e.g., comprising one or more data flows 1100, 1200 or operational flows 1400, 1500, 1600 described above) comprising:
-
invoking transistor-based circuitry (e.g. one or more instances of assemblage modules 331) configured to obtain (at least) an identification of first and second assemblages 121, 122 wherein the first assemblage 121 includes a first parcel 161 adjacent the particular parcel 160 in combination with the particular parcel 160 and wherein the second assemblage 122 likewise includes a second parcel 162 adjacent the particular parcel 160 in combination with the particular parcel 160;
-
invoking transistor-based circuitry (e.g. one or more instances of speciation modules 333) configured to obtain first and second building models 202 of the first assemblage 121 each based on a respective application 877 of first and second speciation protocols 576 to a first multi-parcel-assemblage-specific seeding configuration 872 associated with the first assemblage 121; and
-
invoking transistor-based circuitry (e.g. another one or more instances of speciation modules 333) configured to obtain first and second building models 202 of the second assemblage 122 each based on a respective application 877 of first and second speciation protocols 576 to a first multi-parcel-assemblage-specific seeding configuration 872 associated (at least) with the second assemblage 122.
-
2. The machine learning method of any of the above Clauses wherein the first speciation protocol 576 comprises a multi-building model algorithm like that of Table 4 herein.
-
3. The machine learning method of any of the above Clauses wherein the second speciation protocol 576 comprises a single-shelter algorithm like that of Table 3 herein.
-
4. The machine learning method of any of the above Clauses wherein the first and second speciation protocols 576 each comprise a multi-building model algorithm or single-shelter algorithm and wherein seeding 575 for such algorithms comprises a (set of coordinates 361, dimensions 362, or other) repeatable designation of the reference lot 160 together with a repeatable designation of the other parcel(s) thereof.
-
5. The machine learning method of any of the above Clauses comprising:
-
triggering a supervised-learning-type protocol 576 that includes pairing numerous vector-valued input objects (e.g. as operational data 505) each to a corresponding output value using one or more user-provided inductive biases (e.g. observed user actions 894).
-
6. The machine learning method of any of the above Clauses comprising:
-
triggering a supervised learning protocol 576 that includes pairing first input data that includes the first assemblage 121 with a corresponding indication of user preference (e.g. activating a control 895 depicted in an image 896 of the first assemblage 121).
-
7. The machine learning method of any of the above Clauses comprising:
-
triggering a supervised learning protocol 576 that includes pairing numerous vector-valued input objects each to a corresponding desired output value (e.g. a valuation 380, score 581, selection, rank 588, authorization, or other user-provided preference indication) using one or more user-provided inductive biases.
-
8. The machine learning method of any of the above Clauses comprising:
-
triggering a supervised learning protocol 576 that includes pairing numerous vector-valued input objects each to a corresponding desired output value (e.g. a valuation 380, score 581, selection, rank 588, authorization, or other user-provided preference indication) using one or more user-provided inductive biases.
-
9. The machine learning method of any of the above Clauses comprising:
-
triggering a feature augmentation protocol 576 that includes an application 877 of the first and second speciation protocols to the first multi-parcel-assemblage-specific seeding configuration 872 associated with the first assemblage 121.
-
10. The machine learning method of any of the above Clauses comprising:
-
extracting one or more pattern definition terms 890 for use in a pattern matching protocol 576 as user input.
-
11. The machine learning method of any of the above Clauses comprising:
-
triggering a pattern-matching-type protocol 576 that determines a selective first inclusion of the first assemblage in a geographical map 360.
-
12. The machine learning method of any of the above Clauses comprising:
-
triggering a pattern matching protocol 576 that determines a selective first inclusion of the first assemblage in a geographical map 360 of a development site 211, neighborhood, city 546, or other region 111 (e.g. as an inventory 1150 of matching models 202 or assemblages that excludes some others in the region 111 that were not matching).
-
13. The machine learning method of any of the above Clauses comprising:
-
triggering a pattern matching protocol 576 that determines a selective first inclusion of the first assemblage and a selective exclusion of one or more other assemblages within 5 kilometers of the first assemblage 121 both (at least partly) based on the application 877 of the first and second speciation protocol to the first multi-parcel-assemblage-specific seeding configuration 872 associated with the first assemblage 121.
-
14. The machine learning method of any of the above Clauses comprising:
-
triggering a pattern matching protocol 576 that determines a selective first inclusion of the first assemblage and a selective exclusion of one or more other assemblages within 5 kilometers of the first assemblage 121 both partly based on the application 877 of the first and second speciation protocol to the first multi-parcel-assemblage-specific seeding configuration 872 associated with the first assemblage 121 and an application 877 of the first and second speciation protocol to the first multi-parcel-assemblage-specific seeding configuration 872 associated with the one or more other assemblages.
-
15. The machine learning method of any of the above Clauses comprising:
-
triggering a feature-augmentation-type protocol 576 that includes obtaining an other building model by gleaning a user-provided inductive bias manifesting a first inferred preference for (a result of) a first speciation protocol, generating the other building model using the first speciation protocol in lieu of the second speciation protocol, and displaying the other building model simultaneously with the first building model 202.
-
16. The machine learning method of any of the above Clauses comprising:
-
triggering a feature augmentation protocol 576 that includes obtaining an other (instance of a) building model by gleaning a user-provided inductive bias manifesting a first inferred (apparent user) preference for a first speciation protocol, generating the other building model using the first speciation protocol in lieu of the second speciation protocol, and displaying the other building model simultaneously with the first building model 202 (e.g. by showing both in a map 360 of a city that includes both assemblages thereof).
-
17. The machine learning method of any of the above Clauses wherein the method combines a supervised learning protocol 576 with a pattern matching protocol 576.
-
18. The machine learning method of any of the above Clauses wherein the method combines a pattern matching protocol 576 with a feature augmentation protocol 576.
-
19. The machine learning method of any of the above Clauses wherein the method combines a feature augmentation protocol 576 with a supervised learning protocol 576.
-
20. The machine learning method of any of the above Clauses wherein a comparison 879 among one or more records 558 signals that the particular parcel 160 is not commonly owned with the first parcel 161 or with the second parcel 162 (or with both).
-
21. The machine learning method of any of the above Clauses comprising:
-
invoking transistor-based circuitry (e.g. one or more instances of evaluation modules 334) configured to cause the first building model 202 of the first assemblage 121 to be prioritized over the second building model 202 of the first assemblage 121 and to be presented to a user of a visual display 812 (e.g. an entity 10C using one or more display screens 912) in lieu of the second building model 202 based on a programmatic scoring protocol 576 (e.g. a machine-learning-based score 581, rank 588, or other valuation 380);
-
22. The machine learning method of any of the above Clauses comprising:
-
causing numerous additional assemblages 121 to be depicted all via a single display screen 912 all within a one-hour period 892 wherein each of the additional assemblages 121 links a corresponding parcel 160 to at least one corresponding adjacent parcel 161 with which the corresponding parcel 160 is adjacent and wherein the corresponding parcels 160 include the particular parcel 160.
-
23. The machine learning method of any of the above Clauses comprising:
-
causing a collection of numerous additional assemblages 121 to be depicted all via a single display screen 912 all within a ten-minute period 892 wherein each of the additional assemblages 121 links a corresponding parcel 160 to at least one corresponding adjacent parcel 161 with which the corresponding parcel 160 is adjacent and wherein the corresponding parcels 160 include the particular parcel 160.
-
24. The machine learning method of any of the above Clauses comprising:
-
causing a geographically dispersed collection of numerous additional assemblages 121 to be depicted all via a single display screen 912 all within a ten-minute period 892 wherein each of the additional assemblages 121 links a corresponding parcel 160 to at least one corresponding adjacent parcel 161 with which the corresponding parcel 160 is adjacent, wherein more than half of the numerous additional assemblages 121 are separated from the other additional assemblages 121 by more than 100 meters, and wherein the corresponding parcels 160 include the particular parcel 160.
-
25. The machine learning method of any of the above Clauses comprising:
-
causing a first digital resource 891 to be offered (in overlapping time periods 892 or otherwise) simultaneously for many of the additional assemblages 121 via one or more smart contracts 885 on a first-come first-served basis so that one or more options 884 presented in regard to some of the additional assemblages 121 are (nominally) withdrawn via the one or more smart contracts 885 as an automatic and conditional response 825 to the first digital resource 891 being claimed in association with the particular parcel 160.
-
26. The machine learning method of any of the above Clauses comprising:
-
causing a first digital resource 891 to be offered simultaneously for many of the additional assemblages 121 on a first-come first-served basis so that one or more options 884 presented in regard to some of the additional assemblages 121 are withdrawn as an automatic and conditional response 825 to the first digital resource 891 being claimed in association with the particular parcel 160.
-
27. The machine learning method of any of the above Clauses comprising:
-
transmitting one or more messages 535 signaling the first digital resource 891 being claimed in association with the particular parcel 160 after transmitting (at least) the first digital resource 891 via one or more smart contracts 885 as an automatic and conditional instantaneous response 825 to the first digital resource 891 being claimed in association with the particular parcel 160.
-
28. The machine learning method of any of the above Clauses comprising:
-
transmitting one or more messages 535 signaling the first digital resource 891 being claimed in association with the particular parcel 160.
-
29. The machine learning method of any of the above Clauses comprising:
-
transmitting (at least) the first digital resource 891 as an automatic and conditional response 825 to the first digital resource 891 being claimed in association with the particular parcel 160.
-
30. The machine learning method of any of the above Clauses comprising:
-
causing a first digital resource 891 to be offered simultaneously for many of the additional assemblages 121 on a first-come first-served basis so that one or more options 884 presented to entities 10 that own a majority of the additional assemblages 121.
-
31. The machine learning method of any of the above Clauses comprising:
-
causing a first digital resource 891 to be offered simultaneously for many of the additional assemblages 121 on a first-come first-served basis so that one or more options 884 presented in regard to some of the additional assemblages 121 are (nominally) withdrawn as an automatic and conditional response 825 to the first digital resource 891 being claimed in association with the particular parcel 160.
-
32. The machine learning method of any of the above Clauses comprising:
-
transmitting one or more messages 535 via a visual display 812, 912 signaling the first digital resource 891 being claimed in association with the particular parcel 160 and transmitting (at least) the first digital resource 891 both as an automatic and conditional response 825 to the first digital resource 891 being claimed in association with the particular parcel 160.
-
33. The machine learning method of any of the above Clauses comprising:
-
invoking transistor-based circuitry (e.g. another one or more instances of speciation modules 333) configured to obtain first and second building models 202 of a third assemblage 123 based on an application 877 of the one or more other speciation protocols 576 to a first multi-parcel-assemblage-specific seeding configuration 872 associated with the third assemblage 123; and
-
invoking transistor-based circuitry (e.g. one or more instances of evaluation modules 334) configured to cause the first building model 202 of the third assemblage 123 to be prioritized over the one or more building models 202 of the first and second assemblages 121, 122 and to be signaled to the user 10 of the visual display 812 (at least partly) based on a programmatic scoring protocol 576.
-
34. The machine learning method of any of the above Clauses comprising:
-
invoking transistor-based circuitry (e.g. another one or more instances of speciation modules 333) configured to obtain first and second building models 202 of a third assemblage 123 based on an application 877 of the one or more other speciation protocols 576 to a first multi-parcel-assemblage-specific seeding configuration 872 associated with the third assemblage 123; and
-
invoking transistor-based circuitry (e.g. one or more instances of evaluation modules 334) configured to cause the first building model 202 of the third assemblage 123 to be prioritized over the one or more building models 202 of the first and second assemblages 121, 122 and to be signaled to the user 10 of the visual display 812 at least partly based on a programmatic scoring protocol 576 and partly based on another digital resource 891 having been claimed in association with one or more parcels of the third assemblage 123.
-
35. The machine learning method of any of the above Clauses wherein the one or more records 558 signal that the particular parcel 160 is not commonly owned with the first parcel 161 and wherein the one or more records 558 signal that the particular parcel 160 is not commonly owned with the second parcel 162.
-
36. The machine learning method of any of the above Clauses wherein the one or more records 558 signal that the particular parcel 160 is not commonly owned with the first parcel 161 and wherein the one or more records 558 signal that the particular parcel 160 is not commonly owned with the second parcel 162 and wherein the first and second assemblages 121, 122 are automatically included in an inventory 1150 as a conditional response 825 to information 860 in the one or more records 558 indicating that at least the first and second parcels 161, 162 are not commonly owned with one another.
-
37. The machine learning method of any of the above Clauses comprising:
-
causing the first building model of the second assemblage 122 to be presented via the visual display 812, 912 in lieu of the second building model of the second assemblage 122 partly based on the programmatic scoring protocol and partly based on one or more preference-indicative actions 894 of the user of the visual display 812, 912 (e.g. as a contemporaneous direct or other response 825 to an action of the user signaling interest in the particular parcel).
-
38. The machine learning method of any of the above Clauses comprising:
-
invoking transistor-based circuitry (e.g. one or more instances of evaluation modules 334) configured to cause the first building model 202 of an other assemblage to be prioritized over (at least) the first and second assemblages 121, 122 and to displace the first or second assemblage 121, 122 partly based on the programmatic scoring protocol 576 and partly based on a first preference-indicative action 894 of the user of the visual display 812, 912 (e.g. as a contemporaneous direct or other response 825 to the first preference-indicative action 894 of the user signaling interest in the particular parcel).
-
39. The machine learning method of any of the above Clauses comprising:
-
invoking transistor-based circuitry (e.g. one or more instances of evaluation modules 334) configured to cause the first building model 202 of the first assemblage 121 to be prioritized over the second building model 202 of the first assemblage 121 and to be presented to a user of a visual display (e.g. an entity 10C using one or more display screens 912) in lieu of the second building model 202 based on a programmatic scoring protocol 576.
-
40. The machine learning method of any of the above Clauses comprising:
-
applying one or more deterministically repeatable speciation protocols 576 as the applications 877 of the first and second speciation protocols 576 respectively to the first multi-parcel-assemblage-specific seeding configuration 872 associated with the first and second assemblages 121, 122.
-
41. The machine learning method of any of the above Clauses comprising:
-
applying one or more deterministically repeatable speciation protocols 576 as the applications 877 of the first and second speciation protocols 576 respectively to the first multi-parcel-assemblage-specific seeding configuration 872 associated with the first and second assemblages 121, 122 by causing a recordation of one or more parameters (as operational data 505) thereof on a public blockchain 455.
-
42. The machine learning method of any of the above Clauses comprising:
-
implementing the programmatic scoring protocol 576 to include a determination of one or more machine-learning-based assemblage valuations 380 as components of the programmatic scoring protocol 576.
-
43. The machine learning method of any of the above Clauses comprising:
-
implementing the programmatic scoring protocol 576 to include a determination of one or more machine-learning-based scores 581 as components of the programmatic scoring protocol 576.
-
44. The machine learning method of any of the above Clauses comprising:
-
implementing the programmatic scoring protocol 576 to include a determination of one or more machine-learning-based ranks 588 as components of the programmatic scoring protocol 576.
-
45. A machine learning system configured to perform any of the above-described methods.
-
46. A machine learning system 300, 400, 800 for facilitating multi-parcel development, the system comprising:
-
transistor-based circuitry (e.g. one or more instances of assemblage modules 331) configured to obtain an identification of (at least) first and second assemblages 121, 122 wherein the first assemblage 121 includes a first parcel 161 adjacent the particular parcel 160 in combination with the particular parcel 160, wherein the second assemblage 122 likewise includes a second parcel 162 adjacent the particular parcel 160 in combination with the particular parcel 160, and wherein one or more records 558 signal that the particular parcel 160 is not commonly owned with the first parcel 161 or with the second parcel 162 (or with both);
-
transistor-based circuitry (e.g. one or more instances of speciation modules 333) configured to obtain first and second building models 202 of the first assemblage 121 each based on (at least) a respective application 877 of first and second speciation protocols 576 to a first multi-parcel-assemblage-specific seeding configuration 872 associated with the first assemblage 121; and
-
transistor-based circuitry (e.g. another one or more instances of speciation modules 333) configured to obtain first and second building models 202 of the second assemblage 122 each based on a respective application 877 of first and second speciation protocols 576 (at least) to a first multi-parcel-assemblage-specific seeding configuration 872 associated with the second assemblage 122.
-
47. The machine learning system of Clause 45 wherein (at least two of) the mentioned instances of transistor-based circuitry are geographically remote from one another (i.e. more than 1 kilometer apart).
-
48. The machine learning system of Clause 45 wherein all of the mentioned instances of transistor-based circuitry reside within a single device (e.g. an ASIC).
-
49. The machine learning system of any of the above systems (e.g. Clause 45 et seq.) including a first indexing module 335 that comprises:
-
transistor-based circuitry 330 configured to manifest an activation of a control 895 as a voltage configuration 355 to index to a next-most-preferable option, wherein such indexing modifies a user selection.
-
50. The machine learning system of any of the above systems including a first response module 336 that comprises:
-
transistor-based circuitry 330 configured to generate a conditional response 825 in which numerous parcels 160 in a region 111 each undergoes one or more augmentations, disqualifications, or other such distillations (see FIG. 14).
-
51. The machine learning system of any of the above systems including a first configuration module 337 that comprises:
-
transistor-based circuitry 330 configured to produce a natural-language message 1335 or other signal identifying one or more subject parcels or other components of an assemblage for which one or more building models 202 have been presented.
-
52. The machine learning system of any of the above systems including a first transmission module 338 that comprises:
-
transistor-based circuitry 330 configured to transmit one or more inquiries 883 or related resources 891, optionally including a component thereof sent to a cryptographically secured digital wallet 966 that receives or provides the one or more resources 891.
-
53. The machine learning system of any of the above systems including a first transmission module 338 that comprises:
-
transistor-based circuitry 330 configured to transmit one or more inquiries 883 or related resources 891, optionally including a component thereof sent to one or more mining rigs that comprise proof-of-work blockchain node devices 490A, 490C.
-
54. The machine learning system of any of the above systems including a first transmission module 338 that comprises:
-
transistor-based circuitry 330 configured to transmit one or more inquiries 883 or related resources 891, optionally including a component thereof sent to one or more stake authority nodes that comprise proof-of-stake blockchain node devices 490B, 490F.
-
55. The machine learning system of any of the above systems including a first invocation module 332 that comprises:
-
transistor-based circuitry 330 configured to perform an instance of one or more other modules by delegation (e.g. by triggering one or more functions thereof to be performed abroad or in one or more cloud servers 1000.
-
With respect to the numbered claims expressed below, those skilled in the art will appreciate that recited operations therein may generally be performed in any order. Also, although various operational flows are presented in sequence(s), it should be understood that the various operations may be performed in other orders than those which are illustrated or may be performed concurrently. Examples of such alternate orderings may include overlapping, interleaved, interrupted, reordered, incremental, preparatory, supplemental, simultaneous, reverse, or other variant orderings, unless context dictates otherwise. Furthermore, terms like “responsive to,” “related to,” or other such transitive, relational, or other connections do not generally exclude such variants, unless context dictates otherwise.