A spreadsheet downloaded from Orlando's permitting portal can contain useful evidence about development activity without being a ready made count of new homes. The file's rows may describe applications, permit events or different kinds of work. Before creating a housing chart, a researcher must establish which records represent the question being asked and which quantity should be counted.
This guide explains how to document an Orlando permit data extraction so another person can repeat it. It does not present newly calculated city totals or a five year housing forecast. The examples are deliberately fictional. The original deliverable is an extraction specification and checking method that separates application records from housing unit counts, with clear treatment of dates, missing information and changing source versions.
Define the intended measure in one sentence
Write a sentence such as the number of residential units authorized in new buildings within the City of Orlando during a specified calendar year. Each phrase introduces a condition that must be supported by the data. Residential units is not the same as permit rows. New buildings excludes other work. Within the city is a geographic restriction. Authorized and during the year require a particular event date.
If the available dataset cannot support that sentence, revise the question or locate another source. Do not retain the ambitious label while quietly counting whatever rows are easiest to export. A more limited measure, such as building permit applications meeting documented filters, can still be useful if described accurately. The title should match the actual calculation rather than the hoped for interpretation.
Separate a city permit analysis from a regional market discussion. Orlando city, Orange County and a metropolitan area are different geographies. A Census metropolitan series should not be plotted beside a city portal extract as if both cover the same area. Record the precise geography and identifier for each source before considering a comparison.
Start from the city's documented route
The City of Orlando's View Permitting Data page links to its open data portal and Permit Applications dataset. It explains filtering by application type and permit issue date, exporting a static copy and using fewer filters or a longer period when a search is too restrictive. It also distinguishes the data route from the project lookup tool used to inspect a specific permit.
Open the dataset through that official route and review its available fields and metadata. Record the dataset name, source address, update information and retrieval date. Do not assume a field's meaning solely from a short column label. If housing units or status definitions are unclear, seek the data documentation or agency clarification before using the field in a published total.
The city's instructions say an account is not required simply to access the data, although saving selected data can involve an account. A downloaded file is a snapshot of what was available at retrieval. Save that original file before sorting, deleting columns or correcting formats. The untouched copy is the reference needed to explain how the analysis was produced.
Write the filter specification before exporting
List every intended condition in ordinary language and then record its exact implementation in the portal. Include application category, geography, date field, start date, end date and any status restriction. If a condition cannot be implemented directly, note how it will be handled after export. This prevents an undocumented manual step from becoming the hidden reason a total differs from someone else's result.
Use an explicit date boundary convention. For example, a calendar year extraction might include events from the start of January 1 through the end of December 31, or use a start inclusive and next year start exclusive rule in software. Either approach needs to be applied consistently. Test records near the boundary so an unintended time component does not exclude the last day or include the next year.
Save the filter description alongside the exported file. A screenshot can help, but a written specification is easier to reproduce if the interface changes. Include whether blank dates were excluded and why. A record without an issue date should not silently become an authorization in the year its application was submitted unless the measure explicitly uses application dates.
Identify the row's real meaning
Inspect several records with different types and statuses. Ask whether each row represents one application, one permit, one revision or another event. Then determine whether the dataset includes a reliable housing unit field for the intended analysis. A text description mentioning apartments is not automatically a structured count of new dwellings. Do not extract a number from a narrative without a documented and checked rule.
A fictional export might contain twelve rows but only eight distinct project identifiers. That does not mean four rows should automatically be deleted. They could represent separate components or meaningful events. Investigate the identifier structure and source documentation first. Deduplication should follow a stated rule connected to the measure, not a desire to make the spreadsheet look cleaner.
Likewise, a project with several permits may contain many dwellings, while a permit for an existing apartment building may add none. Counting permits as homes can produce a severe error even when every row is genuine. Keep a field identifying the measure actually available. If only document counts can be established, publish document counts and explain why housing units were not calculated.
Create a fictional extraction audit
Imagine a fictional initial export of one hundred records. Twenty concern categories outside the research question, ten lack the selected event date and five appear to repeat an event already represented. A preliminary audit would list each group separately, leaving sixty five records before the repeated entries are resolved. It would not immediately call those sixty five new homes.
The researcher then checks the five apparent repeats and discovers that two concern distinct work while three are duplicate representations under the chosen event rule. The audit is updated accordingly. This example demonstrates why a duplicate flag and a deletion decision are different things. In a real project, retain the identifiers and reasons for exclusion so another reviewer can test the decision.
Suppose only some retained records contain a verified unit count. Report the coverage of that field and do not treat blanks as zero. A subtotal based on known values is not the complete city total. If the missing information is material, the honest result may be that the available extract cannot support the proposed housing unit chart without additional records or a different source.
Use Census definitions for a separate comparison
The Census Building Permits Survey supplies a defined measure of privately owned new housing units authorized, with documented coverage and exclusions. Its definitions distinguish reported data from estimates with imputation and explain permit issuing geography. These concepts provide a useful comparison framework, but they do not automatically make the Orlando local extract equivalent to a Census series.
Before comparing, create a crosswalk listing each source's geography, ownership scope, construction type, event and revision status. A local dataset may include work outside the Census new construction definition. If the scope differs, explain the difference and keep the series separate. Do not interpret a numerical gap as an error until the definitions have been reconciled.
Avoid using a regional Census total as a substitute for an unavailable city figure. If the city value cannot be established, say so. A map or chart can display different geographies when clearly labeled, but the surrounding prose must not imply that one is a direct check of the other. Geographic honesty is more useful than a visually tidy comparison.
Handle revisions as part of the evidence
Save each downloaded release with a retrieval date and preserve the original values. If a later extraction changes an earlier period, compare records by the documented identifier and identify additions, removals or field changes. A revised historical count is not necessarily new activity in the retrieval month. It may reflect corrected or newly entered information about an earlier event.
For a five year display, use consistent extraction rules across all five years. Record whether the latest year is complete or partial. Do not compare a partial current year directly with full prior years without prominent explanation. If you calculate a same period comparison, state the exact months or dates included rather than calling it an annual trend.
Keep an exception file for unresolved dates, identifiers or categories. It should contain enough information to revisit the issue without exposing unnecessary personal details. If the exceptions materially affect interpretation, mention them with the findings. Hiding difficult rows in a separate folder does not remove their effect on the reliability of the analysis.
Validate the chart against the worksheet
Before publishing, check that every plotted value matches the final table and that the table can be reproduced from the preserved extract. Confirm units in the axis labels and title. A chart of applications should say applications; a chart of housing units should say housing units. Avoid a generic development label that obscures what was counted.
Show absolute quantities with percentage changes when both are used. A large percentage increase from a small base may represent few records, while a small percentage increase from a large base may represent many. If the prior value is zero, do not manufacture a conventional percentage growth rate. Describe the change in counts and explain the starting point.
Finally, separate the data finding from market interpretation. Permit activity alone does not establish completion dates, current vacancies or future rents. A reader can learn that a defined administrative measure changed without being promised an imminent supply outcome. Any broader claim needs additional evidence designed for that question.
Preserve a reproducible Orlando research package
The finished package should contain the original export, filter specification, field definitions, exclusion log, calculation table and source links. Add a short statement of what the measure can and cannot establish. This lets another analyst repeat the work or update it when the portal changes without guessing which choices produced the first result.
Orlando's open data route makes permitting information accessible, but reliable housing analysis still depends on careful definitions. Treat the export as evidence to be interpreted rather than a finished story. When row meaning, geography, event dates and missing values are documented, the resulting chart can support a useful discussion without overstating how many homes exist or when they will become available.