Page History
...
Styleclass | ||
---|---|---|
| ||
Naming Conventions
The CSVs containing geometry and aliases must all share a common name, suffixed with an underscore and the order of the CSV in the pack hierarchy.
Example
In the case of the Australian GeoPack we're creating, the CSV Geometry & Aliases files will be called:
- auspack_1.csv - this will contain the State information from the hierarhcy.
- auspack_2.csv - this will contain the Postcode information from the hierarhcy.
- auspack_3.csv - this will contain the Suburb information from the hierarhcy.
File Format
The CSVs will need to contain data in the following structure:
- First row containing the label for the level.
- Second row containing labels for each alias column, labels for the point and polygon columns should not be included.
- Remaining rows containing:
- Columns containing aliases (there can be as many aliases for a particular level as you require. Some levels may have one or two different aliases, but others may have several).
- If the CSV is not the top level it must now have a column containing the alias of the level above it that the row belongs to in order to link it to the level above.
Note: as each level can have more than one alias, the linking aliases are defined in the metadata file described later. - One Column containing a centroid Point.
- One Column containing Polygons (this can be left completely empty if polygons are not required or available for the level, but if it's populated, all rows must contain a polygon, no blanks will be accepted).
Example Level 1
For this example, when creating the top State CSV, we've decided to use two aliases; State Name, and State Code. This will mean that the file will look something like this:
Code Block |
---|
"State"
"State Name", "State Code"
"New South Wales", "NSW", "<WKT Point>", "<WKT Polygon>"
"Victoria", "VIC", "<WKT Point>", "<WKT Polygon>"
...
etc ...
|
Note: the <WKT Point> and <WKT Polygon> text displayed in the examples above will have to actually contain Point and Polygon data, we've just displayed these as place-holders. Coordinates should be listed in the WKT as latitude longitude, not the other way around.
Example Level 2
The second level of the hierachy, the Postcode CSV, might contain a single alias, and we've chosen to link it to the State level on the State Code field. This will mean that the file will look something like this:
Code Block |
---|
"Postcode"
"Postcode"
"2000", "NSW", "<WKT Point>", "<WKT Polygon>"
"2009", "NSW", "<WKT Point>", "<WKT Polygon>"
...
"3000", "VIC", "<WKT Point>", "<WKT Polygon>"
"3008", "VIC", "<WKT Point>", "<WKT Polygon>"
...
etc ...
|
Example Level 3
The third level of the hierarchy, the Suburb CSV, might again contain a single alias, and we link to the Postcode level on the only alias available, Postcode. This will mean that the file will look something like this:
Code Block |
---|
"Suburb"
"Suburb Name"
"Sydney CBD", "2000", "<WKT Point>", "<WKT Polygon>"
"Darling Harbour", "2000", "<WKT Point>", "<WKT Polygon>"
"Haymarket", "2000", "<WKT Point>", "<WKT Polygon>"
"Darling Island", "N2009", "<WKT Point>", "<WKT Polygon>"
...
"Melbourne CBD", "3000", "<WKT Point>", "<WKT Polygon>"
"Docklands", "3008", "<WKT Point>", "<WKT Polygon>"
...
etc ...
|
CSV Demographic File
Styleclass | ||
---|---|---|
| ||
...