Daily utilization metrics for data.lacity.org and geohub.lacity.org. Updated monthly

SDCC Traffic Congestion Saturation Flow Data for January to June 2023. Traffic volumes, traffic saturation, and congestion data for sites across South Dublin County. Used by traffic management to control stage timings on junctions. It is recommended that this dataset is read in conjunction with the ‘Traffic Data Site Names SDCC’ dataset.A detailed description of each column heading can be referenced below;scn: Site Serial numberregion: A group of Nodes that are operated under SCOOT control at the same common cycle time. Normally these will be nodes between which co-ordination is desirable. Some of the nodes may be double cycling at half of the region cycle time.system: SCOOT STC UTC (UTC-MX)locn: Locationssite: Site numbersday: Days of the week Monday to Sunday. Abbreviations; MO,TU,WE,TH,FR,SA,SU.date: Reflects correct actual Date of when data was collected.start_time: NOTE - Please ignore the date displayed in this column. The actual data collection date is correctly displayed in the 'date' column. The date displayed here is the date of when report was run and extracted from the system, but correctly reflects start time of 15 minute intervals. end_time: End time of 15 minute intervals.flow: A representation of demand (flow) for each link built up over several minutes by the SCOOT model. SCOOT has two profiles:(1) Short – Raw data representing the actual values over the previous few minutes(2) Long – A smoothed average of values over a longer periodSCOOT will choose to use the appropriate profile depending on a number of factors.flow_pc: Same as above ref PC SCOOTcong: Congestion is directly measured from the detector. If the detector is placed beyond the normal end of queue in the street it is rarely covered by stationary traffic, except of course when congestion occurs. If any detector shows standing traffic for the whole of an interval this is recorded. The number of intervals of congestion in any cycle is also recorded.The percentage congestion is calculated from:No of congested intervals x 4 x 100 cycle time in seconds.This percentage of congestion is available to view and more importantly for the optimisers to take into account.cong_pc: Same as above ref PC SCOOTdsat: The ratio of the demand flow to the maximum possible discharge flow, i.e. it is the ratio of the demand to the discharge rate (Saturation Occupancy) multiplied by the duration of the effective green time. The Split optimiser will try to minimise the maximum degree of saturation on links approaching the node.

SDCC Traffic Data Collection Site Names. A detailed description of each column heading can be referenced below;scn: Site Serial numberregion: A group of Nodes that are operated under SCOOT control at the same common cycle time. Normally these will be nodes between which co-ordination is desirable. Some of the nodes may be double cycling at half of the region cycle time.system: SCOOT STC UTC (UTC-MX)locn: Locations

Analysis of ‘Popular Website Traffic Over Time ’ provided by Analyst-2 (analyst-2.ai), based on source dataset retrieved from https://www.kaggle.com/yamqwe/popular-website-traffice on 13 February 2022.

--- Dataset description provided by original source is as follows ---

About this dataset

Background

Have you every been in a conversation and the question comes up, who uses Bing? This question comes up occasionally because people wonder if these sites have any views. For this research study, we are going to be exploring popular website traffic for many popular websites.

Methodology

The data collected originates from SimilarWeb.com.

Source

For the analysis and study, go to The Concept Center

This dataset was created by Chase Willden and contains around 0 samples along with 1/1/2017, Social Media, technical information and other features such as: - 12/1/2016 - 3/1/2017 - and more.

How to use this dataset

• Analyze 11/1/2016 in relation to 2/1/2017
• Study the influence of 4/1/2017 on 1/1/2017
• More datasets

Acknowledgements

If you use this dataset in your research, please credit Chase Willden

Start A New Notebook!

--- Original source retains full ownership of the source dataset ---

The Top Websites in the World

How They Change Over Time

About this dataset

This dataset consists of the top 50 most visited websites in the world, as well as the category and principal country/territory for each site. The data provides insights into which sites are most popular globally, and what type of content is most popular in different parts of the world

How to use the dataset

This dataset can be used to track the most popular websites in the world over time. It can also be used to compare website popularity between different countries and categories

Research Ideas

• To track the most popular websites in the world over time
• To see how website popularity changes by region
• To find out which website categories are most popular

Acknowledgements

Dataset by Alexa Internet, Inc. (2019), released on Kaggle under the Open Data Commons Public Domain Dedication and License (ODC-PDDL)

License

License: CC0 1.0 Universal (CC0 1.0) - Public Domain Dedication No Copyright - You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission. See Other Information.

Columns

File: df_1.csv | Column name | Description | |:--------------------------------|:---------------------------------------------------------------------| | Site | The name of the website. (String) | | Domain Name | The domain name of the website. (String) | | Category | The category of the website. (String) | | Principal country/territory | The principal country/territory where the website is based. (String) |

Context There's a story behind every dataset and here's your opportunity to share yours.

Content What's inside is more than just rows and columns. Make it easy for others to get started by describing how you acquired the data and what time period it represents, too.

Acknowledgements We wouldn't be here without the help of others. If you owe any attributions or thanks, include them here along with any citations of past research.

Inspiration Your data will be in front of the world's largest data science community. What questions do you want to see answered?

Abstract: The task for this dataset is to forecast the spatio-temporal traffic volume based on the historical traffic volume and other features in neighboring locations.

Source: Liang Zhao, liang.zhao '@' emory.edu, Emory University.

Data Set Information: The task for this dataset is to forecast the spatio-temporal traffic volume based on the historical traffic volume and other features in neighboring locations. Specifically, the traffic volume is measured every 15 minutes at 36 sensor locations along two major highways in Northern Virginia/Washington D.C. capital region. The 47 features include: 1) the historical sequence of traffic volume sensed during the 10 most recent sample points (10 features), 2) week day (7 features), 3) hour of day (24 features), 4) road direction (4 features), 5) number of lanes (1 feature), and 6) name of the road (1 feature). The goal is to predict the traffic volume 15 minutes into the future for all sensor locations. With a given road network, we know the spatial connectivity between sensor locations. For the detailed data information, please refer to the file README.docx.

Attribute Information: The 47 features include: (1) the historical sequence of traffic volume sensed during the 10 most recent sample points (10 features), (2) week day (7 features), (3) hour of day (24 features), (4) road direction (4 features), (5) number of lanes (1 feature), and (6) name of the road (1 feature).

Relevant Papers: Liang Zhao, Olga Gkountouna, and Dieter Pfoser. 2019. Spatial Auto-regressive Dependency Interpretable Learning Based on Spatial Topological Constraints. ACM Trans. Spatial Algorithms Syst. 5, 3, Article 19 (August 2019), 28 pages. DOI:[Web Link]

Citation Request: To use these datasets, please cite the papers:

Liang Zhao, Olga Gkountouna, and Dieter Pfoser. 2019. Spatial Auto-regressive Dependency Interpretable Learning Based on Spatial Topological Constraints. ACM Trans. Spatial Algorithms Syst. 5, 3, Article 19 (August 2019), 28 pages. DOI:[Web Link]

Click Web Traffic Combined with Transaction Data: A New Dimension of Shopper Insights

Consumer Edge is a leader in alternative consumer data for public and private investors and corporate clients. Click enhances the unparalleled accuracy of CE Transact by allowing investors to delve deeper and browse further into global online web traffic for CE Transact companies and more. Leverage the unique fusion of web traffic and transaction datasets to understand the addressable market and understand spending behavior on consumer and B2B websites. See the impact of changes in marketing spend, search engine algorithms, and social media awareness on visits to a merchant’s website, and discover the extent to which product mix and pricing drive or hinder visits and dwell time. Plus, Click uncovers a more global view of traffic trends in geographies not covered by Transact. Doubleclick into better forecasting, with Click.

Consumer Edge’s Click is available in machine-readable file delivery and enables: • Comprehensive Global Coverage: Insights across 620+ brands and 59 countries, including key markets in the US, Europe, Asia, and Latin America. • Integrated Data Ecosystem: Click seamlessly maps web traffic data to CE entities and stock tickers, enabling a unified view across various business intelligence tools. • Near Real-Time Insights: Daily data delivery with a 5-day lag ensures timely, actionable insights for agile decision-making. • Enhanced Forecasting Capabilities: Combining web traffic indicators with transaction data helps identify patterns and predict revenue performance.

Use Case: Analyze Year Over Year Growth Rate by Region

Problem A public investor wants to understand how a company’s year-over-year growth differs by region.

Solution The firm leveraged Consumer Edge Click data to: • Gain visibility into key metrics like views, bounce rate, visits, and addressable spend • Analyze year-over-year growth rates for a time period • Breakout data by geographic region to see growth trends

Metrics Include: • Spend • Items • Volume • Transactions • Price Per Volume

Inquire about a Click subscription to perform more complex, near real-time analyses on public tickers and private brands as well as for industries beyond CPG like: • Monitor web traffic as a leading indicator of stock performance and consumer demand • Analyze customer interest and sentiment at the brand and sub-brand levels

Consumer Edge offers a variety of datasets covering the US, Europe (UK, Austria, France, Germany, Italy, Spain), and across the globe, with subscription options serving a wide range of business needs.

Consumer Edge is the Leader in Data-Driven Insights Focused on the Global Consumer

Data Dictionary: https://docs.google.com/spreadsheets/d/1ItvGzNG8O_Yj97Tf6am4T-QyhnxP-BeIRjm7ZaUeAxs/edit#gid=1499621902 GreenThumb provides programming and material support to over 550 community gardens in New York City. NYC Parks GreenThumb staff visit all active community gardens under the jurisdiction of NYC Parks once each calendar year, subject to staff capacity. These site visits typically occur during the summer months and representatives of licensed garden groups are invited to attend. During these site visits, NYC Parks GreenThumb staff observe and record quantitative and qualitative information related to the physical status of the garden, as well as its ongoing operation, maintenance, and programming. This information is used by NYC Parks GreenThumb to inform maintenance needs at the garden and to help NYC Parks GreenThumb understand the needs of garden groups so that we can plan accordingly. In addition, this information is necessary for NYC Parks GreenThumb to confirm that publicly accessible community gardens under its jurisdiction are being operated in safe manner and in accordance with the NYC Parks GreenThumb License Agreement and applicable NYS and NYC laws and regulations. NYC Parks GreenThumb may conduct additional site visits as deemed necessary.

Traffic volumes data across Dublin City from the SCATS traffic management system. The Sydney Coordinated Adaptive Traffic System (SCATS) is an intelligent transportation system used to manage timing of signal phases at traffic signals. SCATS uses sensors at each traffic signal to detect vehicle presence in each lane and pedestrians waiting to cross at the local site. The vehicle sensors are generally inductive loops installed within the road. 3 resources are provided: SCATS Traffic Volumes Data (Monthly) Contained in this report are traffic counts taken from the SCATS traffic detectors located at junctions. The primary function for these traffic detectors is for traffic signal control. Such devices can also count general traffic volumes at defined locations on approach to a junction. These devices are set at specific locations on approaches to the junction but may not be on all approaches to a junction. As there are multiple junctions on any one route, it could be expected that a vehicle would be counted multiple times as it progress along the route. Thus the traffic volume counts here are best used to represent trends in vehicle movement by selecting a specific junction on the route which best represents the overall traffic flows. Information provided: End Time: time that one hour count period finishes. Region: location of the detector site (e.g. North City, West City, etc). Site: this can be matched with the SCATS Sites file to show location Detector: the detectors/ sensors at each site are numbered Sum volume: total traffic volumes in preceding hour Avg volume: average traffic volumes per 5 minute interval in preceding hour All Dates Traffic Volumes Data This file contains daily totals of traffic flow at each site location. SCATS Site Location Data Contained in this report, the location data for the SCATS sites is provided. The meta data provided includes the following; Site id – This is a unique identifier for each junction on SCATS Site description( CAP) – Descriptive location of the junction containing street name(s) intersecting streets Site description (lower) - – Descriptive location of the junction containing street name(s) intersecting streets Region – The area of the city, adjoining local authority, region that the site is located LAT/LONG – Coordinates Disclaimer: the location files are regularly updated to represent the locations of SCATS sites under the control of Dublin City Council. However site accuracy is not absolute. Information for LAT/LONG and region may not be available for all sites contained. It is at the discretion of the user to link the files for analysis and to create further data. Furthermore, detector communication issues or faulty detectors could also result in an inaccurate result for a given period, so values should not be taken as absolute but can be used to indicate trends.

YouTube flows

US Automatic Traffic Recorder Stations Data

Vehicle Traffic Counts and Locations at US ATR Stations

By Homeland Infrastructure Foundation [source]

About this dataset

This comprehensive dataset records important information about Automatic Traffic Recorder (ATR) Stations located across the United States. ATR stations play a crucial role in traffic management and planning by continuously monitoring and counting the number of vehicles passing through each station.

The data contained in this dataset has been meticulously gathered from station description files supplied by the Federal Highway Administration (FHWA) for both Weigh-in-Motion (WIM) devices and Automatic Traffic Recorders. In addition to this, location referencing data was sourced from the National Highway Planning Network version 4.0 as well as individual State offices of Transportation.

The database includes essential attributes such as a unique identifier for each ATR station, indicated by 'STTNKEY'. It also indicates if a site is part of the National Highway System, denoted under 'NHS'. Other key aspects recorded include specific locations generally named after streets or highways under 'LOCATION', along with relevant comments providing additional context in 'COMMENT'.

Perhaps one of the most critical factors noted in this data set would be traffic volume at each location, measured by Annual Average Daily Traffic ('AADT'). This metric represents total vehicle flow on roads or highways for a year divided over 365 days — an essential numeric analyst's often call upon when making traffic-related predictions or decisions.

Location coordinates incorporating longitude and latitude measurements of every ATR station are documented clearly — aiding geospatial analysis. Furthermore, X and Y coordinates correspond to these locations facilitating accurate map plotting.

Additional information contained also includes postal codes labeled as 'STPOSTAL' where stations are located with respective state FIPS codes indicated under ‘STFIPS’. County specific FIPS code are documented within ‘CTFIPS’. Versioning information helps users track versions ensuring they work off latest datasets with temporal geographic attribute updates captured via ‘YEAR_GEO’.

Reference Source: Click Here

How to use the dataset

Introduction

Diving into the data

The dataset comprises a collection of attributes for each station such as its location details (latitude, longitude), AADT or The Annual Average Daily Traffic amount, classification of road where it's located etc. Additionally, there is information related to when was this geographical information last updated.

Understanding Columns

Here's what primary columns represent: - Sttnkey: A unique identifier for each station. - NHS: Indicates if the station is part of national highway system. - Location: Describes specific location of a station with street or highway name. - Comment: Any additional remarks related to that station. - Longitude,Latitude: Geographic coordinates. - STPostal: The postal code where a given station resides. - menu 4 dots indicates show more items** - ADT: Annual Average Daily Traffic count indicating average volume of vehicles passing through that route annually divided by 365 days - Year_GEO: The year when geographic information was last updated - can provide insight into recency or timeliness of recorded attribute values - Fclass: Road classification i.e interstate,dis,e tc., providing context about type/stature/importance or natureof theroad on whichstationlies 11.Stfips,Ctfips- FIPS codes representing state,county respectively

Using this information

Given its structure and contents,thisdatasetisveryusefulforanumberofpurposes:

1.Urban Planning & InfrastructureDevelopment Understanding traffic flows and volumes can be instrumental in deciding where to build new infrastructure or improve existing ones. Planners can identify high traffic areas needing more robust facilities.

2.Traffic Management & Policies Analysing chronological changes and patterns of traffic volume, local transportation departments can plan out strategic time-based policies for congestion management.

3.Residential/CommercialRealEstateDevelopment Real estate developers can use this data to assess the appeal of a location based on its accessibility i.e whether it sits on high-frequency route or is located in more peaceful, low-traffic areas etc

4.Environmental AnalysisResearch: Re...

A. SUMMARY San Francisco International Airport Report on Monthly Passenger Traffic Statistics by Airline. B. HOW THE DATASET IS CREATED Data is self-reported by airlines and is only available at a monthly level C. UPDATE PROCESS Data updated quarterly D. HOW TO USE THIS DATASET Airport data is seasonal in nature, therefore any comparative analyses should be done on a period-over-period basis (i.e. January 2010 vs. January 2009) as opposed to period-to-period (i.e. January 2010 vs. February 2010). It is also important to note that fact and attribute field relationships are not always 1-to-1. For example, Passenger Counts belonging to United Airlines will appear in multiple attribute fields and are additive, which provides flexibility for the user to derive categorical Passenger Counts as desired.

This data contains information about people involved in a crash and if any injuries were sustained. This dataset should be used in combination with the traffic Crash and Vehicle dataset. Each record corresponds to an occupant in a vehicle listed in the Crash dataset. Some people involved in a crash may not have been an occupant in a motor vehicle, but may have been a pedestrian, bicyclist, or using another non-motor vehicle mode of transportation. Injuries reported are reported by the responding police officer. Fatalities that occur after the initial reports are typically updated in these records up to 30 days after the date of the crash. Person data can be linked with the Crash and Vehicle dataset using the “CRASH_RECORD_ID” field. A vehicle can have multiple occupants and hence have a one to many relationship between Vehicle and Person dataset. However, a pedestrian is a “unit” by itself and have a one to one relationship between the Vehicle and Person table. The Chicago Police Department reports crashes on IL Traffic Crash Reporting form SR1050. The crash data published on the Chicago data portal mostly follows the data elements in SR1050 form. The current version of the SR1050 instructions manual with detailed information on each data elements is available here. Change 11/21/2023: We have removed the RD_NO (Chicago Police Department report number) for privacy reasons.

Please refer to the original data article for further data description: Jan Luxemburk et al. CESNET-QUIC22: A large one-month QUIC network traffic dataset from backbone lines, Data in Brief, 2023, 108888, ISSN 2352-3409, https://doi.org/10.1016/j.dib.2023.108888. We recommend using the CESNET DataZoo python library, which facilitates the work with large network traffic datasets. More information about the DataZoo project can be found in the GitHub repository https://github.com/CESNET/cesnet-datazoo. The QUIC (Quick UDP Internet Connection) protocol has the potential to replace TLS over TCP, which is the standard choice for reliable and secure Internet communication. Due to its design that makes the inspection of QUIC handshakes challenging and its usage in HTTP/3, there is an increasing demand for research in QUIC traffic analysis. This dataset contains one month of QUIC traffic collected in an ISP backbone network, which connects 500 large institutions and serves around half a million people. The data are delivered as enriched flows that can be useful for various network monitoring tasks. The provided server names and packet-level information allow research in the encrypted traffic classification area. Moreover, included QUIC versions and user agents (smartphone, web browser, and operating system identifiers) provide information for large-scale QUIC deployment studies. Data capture The data was captured in the flow monitoring infrastructure of the CESNET2 network. The capturing was done for four weeks between 31.10.2022 and 27.11.2022. The following list provides per-week flow count, capture period, and uncompressed size:

W-2022-44

Uncompressed Size: 19 GB Capture Period: 31.10.2022 - 6.11.2022 Number of flows: 32.6M W-2022-45

Uncompressed Size: 25 GB Capture Period: 7.11.2022 - 13.11.2022 Number of flows: 42.6M W-2022-46

Uncompressed Size: 20 GB Capture Period: 14.11.2022 - 20.11.2022 Number of flows: 33.7M W-2022-47

Uncompressed Size: 25 GB Capture Period: 21.11.2022 - 27.11.2022 Number of flows: 44.1M CESNET-QUIC22

Uncompressed Size: 89 GB Capture Period: 31.10.2022 - 27.11.2022 Number of flows: 153M

Data description The dataset consists of network flows describing encrypted QUIC communications. Flows were created using ipfixprobe flow exporter and are extended with packet metadata sequences, packet histograms, and with fields extracted from the QUIC Initial Packet, which is the first packet of the QUIC connection handshake. The extracted handshake fields are the Server Name Indication (SNI) domain, the used version of the QUIC protocol, and the user agent string that is available in a subset of QUIC communications. Packet Sequences Flows in the dataset are extended with sequences of packet sizes, directions, and inter-packet times. For the packet sizes, we consider payload size after transport headers (UDP headers for the QUIC case). Packet directions are encoded as ±1, +1 meaning a packet sent from client to server, and -1 a packet from server to client. Inter-packet times depend on the location of communicating hosts, their distance, and on the network conditions on the path. However, it is still possible to extract relevant information that correlates with user interactions and, for example, with the time required for an API/server/database to process the received data and generate the response to be sent in the next packet. Packet metadata sequences have a length of 30, which is the default setting of the used flow exporter. We also derive three fields from each packet sequence: its length, time duration, and the number of roundtrips. The roundtrips are counted as the number of changes in the communication direction (from packet directions data); in other words, each client request and server response pair counts as one roundtrip. Flow statistics Flows also include standard flow statistics, which represent aggregated information about the entire bidirectional flow. The fields are: the number of transmitted bytes and packets in both directions, the duration of flow, and packet histograms. Packet histograms include binned counts of packet sizes and inter-packet times of the entire flow in both directions (more information in the PHISTS plugin documentation There are eight bins with a logarithmic scale; the intervals are 0-15, 16-31, 32-63, 64-127, 128-255, 256-511, 512-1024, >1024 [ms or B]. The units are milliseconds for inter-packet times and bytes for packet sizes. Moreover, each flow has its end reason - either it was idle, reached the active timeout, or ended due to other reasons. This corresponds with the official IANA IPFIX-specified values. The FLOW_ENDREASON_OTHER field represents the forced end and lack of resources reasons. The end of flow detected reason is not considered because it is not relevant for UDP connections. Dataset structure The dataset flows are delivered in compressed CSV files. CSV files contain one flow per row; data columns are summarized in the provided list below. For each flow data file, there is a JSON file with the number of saved and seen (before sampling) flows per service and total counts of all received (observed on the CESNET2 network), service (belonging to one of the dataset's services), and saved (provided in the dataset) flows. There is also the stats-week.json file aggregating flow counts of a whole week and the stats-dataset.json file aggregating flow counts for the entire dataset. Flow counts before sampling can be used to compute sampling ratios of individual services and to resample the dataset back to the original service distribution. Moreover, various dataset statistics, such as feature distributions and value counts of QUIC versions and user agents, are provided in the dataset-statistics folder. The mapping between services and service providers is provided in the servicemap.csv file, which also includes SNI domains used for ground truth labeling. The following list describes flow data fields in CSV files:

ID: Unique identifier SRC_IP: Source IP address DST_IP: Destination IP address DST_ASN: Destination Autonomous System number SRC_PORT: Source port DST_PORT: Destination port PROTOCOL: Transport protocol QUIC_VERSION QUIC: protocol version QUIC_SNI: Server Name Indication domain QUIC_USER_AGENT: User agent string, if available in the QUIC Initial Packet TIME_FIRST: Timestamp of the first packet in format YYYY-MM-DDTHH-MM-SS.ffffff TIME_LAST: Timestamp of the last packet in format YYYY-MM-DDTHH-MM-SS.ffffff DURATION: Duration of the flow in seconds BYTES: Number of transmitted bytes from client to server BYTES_REV: Number of transmitted bytes from server to client PACKETS: Number of packets transmitted from client to server PACKETS_REV: Number of packets transmitted from server to client PPI: Packet metadata sequence in the format: [[inter-packet times], [packet directions], [packet sizes]] PPI_LEN: Number of packets in the PPI sequence PPI_DURATION: Duration of the PPI sequence in seconds PPI_ROUNDTRIPS: Number of roundtrips in the PPI sequence PHIST_SRC_SIZES: Histogram of packet sizes from client to server PHIST_DST_SIZES: Histogram of packet sizes from server to client PHIST_SRC_IPT: Histogram of inter-packet times from client to server PHIST_DST_IPT: Histogram of inter-packet times from server to client APP: Web service label CATEGORY: Service category FLOW_ENDREASON_IDLE: Flow was terminated because it was idle FLOW_ENDREASON_ACTIVE: Flow was terminated because it reached the active timeout FLOW_ENDREASON_OTHER: Flow was terminated for other reasons

Link to other CESNET datasets

https://www.liberouter.org/technology-v2/tools-services-datasets/datasets/ https://github.com/CESNET/cesnet-datazoo Please cite the original data article:

@article{CESNETQUIC22, author = {Jan Luxemburk and Karel Hynek and Tomáš Čejka and Andrej Lukačovič and Pavel Šiška}, title = {CESNET-QUIC22: a large one-month QUIC network traffic dataset from backbone lines}, journal = {Data in Brief}, pages = {108888}, year = {2023}, issn = {2352-3409}, doi = {https://doi.org/10.1016/j.dib.2023.108888}, url = {https://www.sciencedirect.com/science/article/pii/S2352340923000069} }

Traffic Volume (24hr count). Data are updated as needed by the Transportation department (typically in the summer), and subsequently copied to VicMap and the Open Data Portal the following day.Traffic speed and volume data are collected at various locations around the city, from different locations each year, using a variety of technologies and manual counting. Counters are placed on streets and at intersections, typically for 24-hour periods. Targeted information is also collected during morning or afternoon peak period travel times and can also be done for several days at a time to capture variability on different days of the week. The City collects data year-round and in all types of weather (except for extreme events like snowstorms). The City also uses data from our agency partners like Victoria Police, the CRD or ICBC. Speed values recorded at each location represent the 85th percentile speed, which means 85% or less traffic travels at that speed. This is standard practice among municipalities to reduce anomalies due to excessively speedy or excessively slow drivers. Values recorded are based on the entire 24-hour period.The Traffic Volume dataset is linear. The lines can be symbolized using arrows and the "Direction" attribute. Where the direction value is "one", use an arrow symbol where the arrow is at the end of the line. Where the direction value is "both", use an arrow symbol where there are arrows at both ends of the line. Use the "Label" field to add labels. The label field indicates the traffic volume at each location, and the year the data was collected. So for example, “2108(05)” means 2108 vehicles were counted in the year 2005 at that location.Data are automatically copied to the Open Data Portal. The "Last Updated" date shown on our Open Data Portal refers to the last time the data schema was modified in the portal, or any changes were made to this description. We update our data through automated scripts which does not trigger the "last updated" date to change. Note: Attributes represent each field in a dataset, and some fields will contain information such as ID numbers. As a result some visualizations on the tabs on our Open Data page will not be relevant.

SCATS – SCATS (Sydney Coordinated Adaptive Traffic System) is an adaptive urban traffic management system that synchronises traffic signals to optimise traffic flow across a whole city, region or corridor. Attributes: SiteID : Site (signal and SCATS Site) identifier Site_Description_Cap : Site description in capital letters Site_Description_Lower: site description in lower case letters Region: refers to SCATS regional servers Lat: Geographic location (Latitude) Long : Geographic location (Longitude) Site_Type : Site type; it has two values: SCATS or Signal Site SCATS means that both SCATS detectors and traffic signals (traffic lights) are present.

Unlock the Power of Behavioural Data with GDPR-Compliant Clickstream Insights.

Swash clickstream data offers a comprehensive and GDPR-compliant dataset sourced from users worldwide, encompassing both desktop and mobile browsing behaviour. Here's an in-depth look at what sets us apart and how our data can benefit your organisation.

User-Centric Approach: Unlike traditional data collection methods, we take a user-centric approach by rewarding users for the data they willingly provide. This unique methodology ensures transparent data collection practices, encourages user participation, and establishes trust between data providers and consumers.

Wide Coverage and Varied Categories: Our clickstream data covers diverse categories, including search, shopping, and URL visits. Whether you are interested in understanding user preferences in e-commerce, analysing search behaviour across different industries, or tracking website visits, our data provides a rich and multi-dimensional view of user activities.

GDPR Compliance and Privacy: We prioritise data privacy and strictly adhere to GDPR guidelines. Our data collection methods are fully compliant, ensuring the protection of user identities and personal information. You can confidently leverage our clickstream data without compromising privacy or facing regulatory challenges.

Market Intelligence and Consumer Behaviuor: Gain deep insights into market intelligence and consumer behaviour using our clickstream data. Understand trends, preferences, and user behaviour patterns by analysing the comprehensive user-level, time-stamped raw or processed data feed. Uncover valuable information about user journeys, search funnels, and paths to purchase to enhance your marketing strategies and drive business growth.

High-Frequency Updates and Consistency: We provide high-frequency updates and consistent user participation, offering both historical data and ongoing daily delivery. This ensures you have access to up-to-date insights and a continuous data feed for comprehensive analysis. Our reliable and consistent data empowers you to make accurate and timely decisions.

Custom Reporting and Analysis: We understand that every organisation has unique requirements. That's why we offer customisable reporting options, allowing you to tailor the analysis and reporting of clickstream data to your specific needs. Whether you need detailed metrics, visualisations, or in-depth analytics, we provide the flexibility to meet your reporting requirements.

Data Quality and Credibility: We take data quality seriously. Our data sourcing practices are designed to ensure responsible and reliable data collection. We implement rigorous data cleaning, validation, and verification processes, guaranteeing the accuracy and reliability of our clickstream data. You can confidently rely on our data to drive your decision-making processes.

Phishing Websites Dataset

Overview

This dataset is designed to aid in the analysis and detection of phishing websites. It contains various features that help distinguish between legitimate and phishing websites based on their structural, security, and behavioral attributes.

Dataset Information

• Total Columns: 31 (30 Features + 1 Target)
• Target Variable: Result (Indicates whether a website is phishing or legitimate)

Features Description

URL-Based Features

• Prefix_Suffix – Checks if the URL contains a hyphen (-), which is commonly used in phishing domains.
• double_slash_redirecting – Detects if the URL redirects using //, which may indicate a phishing attempt.
• having_At_Symbol – Identifies the presence of @ in the URL, which can be used to deceive users.
• Shortining_Service – Indicates whether the URL uses a shortening service (e.g., bit.ly, tinyurl).
• URL_Length – Measures the length of the URL; phishing URLs tend to be longer.
• having_IP_Address – Checks if an IP address is used in place of a domain name, which is suspicious.

Domain-Based Features

• having_Sub_Domain – Evaluates the number of subdomains; phishing sites often have excessive subdomains.
• SSLfinal_State – Indicates whether the website has a valid SSL certificate (secure connection).
• Domain_registeration_length – Measures the duration of domain registration; phishing sites often have short lifespans.
• age_of_domain – The age of the domain in days; older domains are usually more trustworthy.
• DNSRecord – Checks if the domain has valid DNS records; phishing domains may lack these.

Webpage-Based Features

• Favicon – Determines if the website uses an external favicon (which can be a sign of phishing).
• port – Identifies if the site is using suspicious or non-standard ports.
• HTTPS_token – Checks if "HTTPS" is included in the URL but is used deceptively.
• Request_URL – Measures the percentage of external resources loaded from different domains.
• URL_of_Anchor – Analyzes anchor tags (<a> links) and their trustworthiness.
• Links_in_tags – Examines <meta>, <script>, and <link> tags for external links.
• SFH (Server Form Handler) – Determines if form actions are handled suspiciously.
• Submitting_to_email – Checks if forms submit data directly to an email instead of a web server.
• Abnormal_URL – Identifies if the website’s URL structure is inconsistent with common patterns.
• Redirect – Counts the number of redirects; phishing websites may have excessive redirects.

Behavior-Based Features

• on_mouseover – Checks if the website changes content when hovered over (used in deceptive techniques).
• RightClick – Detects if right-click functionality is disabled (phishing sites may disable it).
• popUpWindow – Identifies the presence of pop-ups, which can be used to trick users.
• Iframe – Checks if the website uses <iframe> tags, often used in phishing attacks.

Traffic & Search Engine Features

• web_traffic – Measures the website’s Alexa ranking; phishing sites tend to have low traffic.
• Page_Rank – Google PageRank score; phishing sites usually have a low PageRank.
• Google_Index – Checks if the website is indexed by Google (phishing sites may not be indexed).
• Links_pointing_to_page – Counts the number of backlinks pointing to the website.
• Statistical_report – Uses external sources to verify if the website has been reported for phishing.

Target Variable

• Result – The classification label (1: Legitimate, -1: Phishing)

Usage

This dataset is valuable for:
✅ Machine Learning Models – Developing classifiers for phishing detection.
✅ Cybersecurity Research – Understanding patterns in phishing attacks.
✅ Browser Security Extensions – Enhancing anti-phishing tools.

This data release includes cross section survey data collected during site visits to USGS gaging stations located throughout the Willamette and Delaware River Basins and multispectral images of these locations acquired as close in time as possible to the date of each site visit. In addition, MATLAB source code developed for the Bathymetric Mapping using Gage Records and Image Databases (BaMGRID) framework is also provided. The site visit data were obtained from the Aquarius Time Series database, part of the USGS National Water Information System (NWIS), using the Publish Application Programming Interface (API). More specifically, a custom MATLAB function was used to query the FieldVisitDataByLocationServiceRequest endpoint of the Aquarius API by specifying the gaging station ID number and the date range of interest and then retrieve the QRev XML attachments associated with site visits meeting these criteria. These XML files were then parsed using another custom MATLAB function that served to extract the cross section survey data collected during the site visit. Note that because many of the site visits involved surveying cross sections using instrumentation that was not GPS-enabled, latitude and longitude coordinates were not available and no data values (NaN) are used in the site visit files provided in this data release. Remotely sensed data acquired as close as possible to the date of each site visit were also retrieved via APIs. Multispectral satellite images from the PlanetScope constellation were obtained using custom MATLAB functions developed to interact with the Planet Orders API, which provided tools for clipping the images to a specified area of interest focused on the gaging station and harmonizing the pixel values to be consistent across the different satellites within the PlanetScope constellation. The data product retrieved was the PlanetScope orthorectified 8-band surface reflectance bundle. PlanetScope images are acquired with high frequency, often multiple times per day at a given location, and so the search was restricted to a time window spanning from three days prior to three days after the site visit. All images meeting these criteria were downloaded and manually inspected; the highest quality image closest in time to the site visit date was retained for further analysis. For the gaging stations within the Willamette River Basin, digital aerial photography acquired through the National Agricultural Imagery Program (NAIP) in 2022 were obtained using a similar set of MATLAB functions developed to access the USGS EarthExplorer Machine-to-Machine (M2M) API. The NAIP quarter-quadrangle image encompassing each gaging station was downloaded and then clipped to a smaller area centered on the gaging station. Only one NAIP image at each gaging station was acquired in 2022, so differences in streamflow between the image acquisition date and the date of the site visit closest in time were accounted for by performing separate NWIS web queries to retrieve the stage and discharge recorded at the gaging station on the date the image was acquired and on the date of the site visit. These data sets were used as an example application of the framework for Bathymetric Mapping using Gage Records and Image Databases (BaMGRID) and this data release also provides MATLAB source code developed to implement this approach. The code is packaged in a zip archive that includes the following individual .m files: 1) getSiteVisit.m, for retrieving data collected during site visits to USGS gaging stations through the Aquarius API; 2) Qrev2depth.m, for parsing the XML file from the site visit and extracting depth measurements surveyed along a channel cross section during a direct discharge measurement; 3) orderPlanet.m, for searching for and ordering PlanetScope images via the Planet Orders API; 4) pollThenGrabPlanet.m, for querying the status of an order and then downloading PlanetScope images requested through the Planet Orders API; 5) organizePlanet.m, for file management and cleanup of the original PlanetScope image data obtained via the previous two functions; 6) ingestNaip.m, for searching for, ordering, and downloading NAIP data via the USGS Machine-to-Machine (M2M) API; 7) naipExtractClip.m, for clipping the downloaded NAIP images to the specified area of interest and performing file management and cleanup; and 8) crossValObra.m, for performing spectrally based depth retrieval via the Optimal Band Ratio Analysis (OBRA) algorithm using a k-fold cross-validation approach intended for small sample sizes. The files provided through this data release include: 1) A zipped shapefile with polygons delineating the Willamette and Delaware River basins 2) .csv text files with information on site visits within each basin during 2022 3) .csv text files with information on PlanetScope images of each gaging station close in time to the date of each site visit that can be used to obtain the image data through the Planet Orders API or Planet Explorer web interface. 4) A .csv text tile with information on NAIP images of each gaging station in the Willamette River Basin as close in time as possible to the date of each site visit, along with the stage and discharge recorded at the gaging station on the date of image acquisition and the date of the site visit. 5) A zip archive of the clipped NAIP images of each gaging station in the Willamette River Basin in GeoTIFF format. 6) A zip archive with source code (MATLAB *.m files) developed to implement the Bathymetric Mapping using Gage Records and Image Databases (BaMGRID) framework.