At CompanyData.com (BoldData), we provide verified company information sourced directly from official trade registers across the globe. For the Dominican Republic, we offer access to a detailed and accurate database of over 377,863 registered companies — giving you reliable insight into one of the Caribbean’s most active and diverse business markets.

Our Dominican Republic company database includes comprehensive firmographic data, such as company name, registration number (RNC), legal structure, industry classification (CIIU), estimated revenue, number of employees and ownership details. Where available, we also provide contact information, including names of key executives, job titles, email addresses and phone or mobile numbers.

Whether you're conducting KYC or AML compliance checks, building a B2B marketing strategy, enriching your CRM system, training AI models, or performing risk assessments, our verified Dominican company data supports accurate, effective and compliant decision-making.

We offer flexible delivery methods to fit your needs: • Custom-built company lists based on specific filters such as sector, size or location • Complete national datasets for in-depth analysis or strategic planning • Real time access through our API • File formats including Excel and CSV for seamless integration • Data enrichment services to clean and enhance your existing databases

With access to 377,863 verified company records in over 200 countries, CompanyData.com (BoldData) gives you global reach with local precision. Whether you're entering the Dominican Republic market or targeting international expansion, our data helps reduce risk, increase efficiency and drive growth.

Choose CompanyData.com for accurate, official business data in the Dominican Republic and around the world — empowering smarter decisions, better targeting and long-term success.

Database of Uniaxial Cyclic and Tensile Coupon Tests for Structural Metallic Materials

Background

This dataset contains data from monotonic and cyclic loading experiments on structural metallic materials. The materials are primarily structural steels and one iron-based shape memory alloy is also included. Summary files are included that provide an overview of the database and data from the individual experiments is also included.

The files included in the database are outlined below and the format of the files is briefly described. Additional information regarding the formatting can be found through the post-processing library (https://github.com/ahartloper/rlmtp/tree/master/protocols).

Usage

• The data is licensed through the Creative Commons Attribution 4.0 International.
• If you have used our data and are publishing your work, we ask that you please reference both:
  1. this database through its DOI, and
  2. any publication that is associated with the experiments. See the Overall_Summary and Database_References files for the associated publication references.

Included Files

• Overall_Summary_2022-08-25_v1-0-0.csv: summarises the specimen information for all experiments in the database.
• Summarized_Mechanical_Props_Campaign_2022-08-25_v1-0-0.csv: summarises the average initial yield stress and average initial elastic modulus per campaign.
• Unreduced_Data-#_v1-0-0.zip: contain the original (not downsampled) data
  • Where # is one of: 1, 2, 3, 4, 5, 6. The unreduced data is broken into separate archives because of upload limitations to Zenodo. Together they provide all the experimental data.
  • We recommend you un-zip all the folders and place them in one "Unreduced_Data" directory similar to the "Clean_Data"
  • The experimental data is provided through .csv files for each test that contain the processed data. The experiments are organised by experimental campaign and named by load protocol and specimen. A .pdf file accompanies each test showing the stress-strain graph.
  • There is a "db_tag_clean_data_map.csv" file that is used to map the database summary with the unreduced data.
  • The computed yield stresses and elastic moduli are stored in the "yield_stress" directory.
• Clean_Data_v1-0-0.zip: contains all the downsampled data
  • The experimental data is provided through .csv files for each test that contain the processed data. The experiments are organised by experimental campaign and named by load protocol and specimen. A .pdf file accompanies each test showing the stress-strain graph.
  • There is a "db_tag_clean_data_map.csv" file that is used to map the database summary with the clean data.
  • The computed yield stresses and elastic moduli are stored in the "yield_stress" directory.
• Database_References_v1-0-0.bib
  • Contains a bibtex reference for many of the experiments in the database. Corresponds to the "citekey" entry in the summary files.

File Format: Downsampled Data

These are the "LP_

• The header of the first column is empty: the first column corresponds to the index of the sample point in the original (unreduced) data
• Time[s]: time in seconds since the start of the test
• e_true: true strain
• Sigma_true: true stress in MPa
• (optional) Temperature[C]: the surface temperature in degC

These data files can be easily loaded using the pandas library in Python through:

import pandas
data = pandas.read_csv(data_file, index_col=0)

The data is formatted so it can be used directly in RESSPyLab (https://github.com/AlbanoCastroSousa/RESSPyLab). Note that the column names "e_true" and "Sigma_true" were kept for backwards compatibility reasons with RESSPyLab.

File Format: Unreduced Data

These are the "LP_

• The first column is the index of each data point
• S/No: sample number recorded by the DAQ
• System Date: Date and time of sample
• Time[s]: time in seconds since the start of the test
• C_1_Force[kN]: load cell force
• C_1_Déform1[mm]: extensometer displacement
• C_1_Déplacement[mm]: cross-head displacement
• Eng_Stress[MPa]: engineering stress
• Eng_Strain[]: engineering strain
• e_true: true strain
• Sigma_true: true stress in MPa
• (optional) Temperature[C]: specimen surface temperature in degC

The data can be loaded and used similarly to the downsampled data.

File Format: Overall_Summary

The overall summary file provides data on all the test specimens in the database. The columns include:

• hidden_index: internal reference ID
• grade: material grade
• spec: specifications for the material
• source: base material for the test specimen
• id: internal name for the specimen
• lp: load protocol
• size: type of specimen (M8, M12, M20)
• gage_length_mm_: unreduced section length in mm
• avg_reduced_dia_mm_: average measured diameter for the reduced section in mm
• avg_fractured_dia_top_mm_: average measured diameter of the top fracture surface in mm
• avg_fractured_dia_bot_mm_: average measured diameter of the bottom fracture surface in mm
• fy_n_mpa_: nominal yield stress
• fu_n_mpa_: nominal ultimate stress
• t_a_deg_c_: ambient temperature in degC
• date: date of test
• investigator: person(s) who conducted the test
• location: laboratory where test was conducted
• machine: setup used to conduct test
• pid_force_k_p, pid_force_t_i, pid_force_t_d: PID parameters for force control
• pid_disp_k_p, pid_disp_t_i, pid_disp_t_d: PID parameters for displacement control
• pid_extenso_k_p, pid_extenso_t_i, pid_extenso_t_d: PID parameters for extensometer control
• citekey: reference corresponding to the Database_References.bib file
• yield_stress_mpa_: computed yield stress in MPa
• elastic_modulus_mpa_: computed elastic modulus in MPa
• fracture_strain: computed average true strain across the fracture surface
• c,si,mn,p,s,n,cu,mo,ni,cr,v,nb,ti,al,b,zr,sn,ca,h,fe: chemical compositions in units of %mass
• file: file name of corresponding clean (downsampled) stress-strain data

File Format: Summarized_Mechanical_Props_Campaign

Meant to be loaded in Python as a pandas DataFrame with multi-indexing, e.g.,

tab1 = pd.read_csv('Summarized_Mechanical_Props_Campaign_' + date + version + '.csv',
          index_col=[0, 1, 2, 3], skipinitialspace=True, header=[0, 1],
          keep_default_na=False, na_values='')

• citekey: reference in "Campaign_References.bib".
• Grade: material grade.
• Spec.: specifications (e.g., J2+N).
• Yield Stress [MPa]: initial yield stress in MPa
  • size, count, mean, coefvar: number of experiments in campaign, number of experiments in mean, mean value for campaign, coefficient of variation for campaign
• Elastic Modulus [MPa]: initial elastic modulus in MPa
  • size, count, mean, coefvar: number of experiments in campaign, number of experiments in mean, mean value for campaign, coefficient of variation for campaign

Caveats

• The files in the following directories were tested before the protocol was established. Therefore, only the true stress-strain is available for each:
  • A500
  • A992_Gr50
  • BCP325
  • BCR295
  • HYP400
  • S460NL
  • S690QL/25mm
  • S355J2_Plates/S355J2_N_25mm and S355J2_N_50mm

We have made available two databases of the Brazilian flora. The “raw database” contains data on terrestrial plant species after excluding records with invalid or missing taxonomic and georeferenced information, records outside Brazil, or from uncertain sources (i.e., the pre-filter step of the workflow). The results of each test used to flag data quality are appended in separate fields in this database and retrieved as TRUE or FALSE, in which the former indicates correct records and the latter potentially problematic or suspect records. It is worth noting that the “raw” database contains records with names not found in the Flora do Brasil and with taxonomic, spatial, and temporal issues.The “fitness-for-use” database is a filter of the “raw” database and only contains valid records that passed all data quality tests. Consequently, the result of each cleaning test is not shown. This database includes verified and standardized data on species taxonomy, geolocation, and date of collection. The databases contain data on conservation status, distribution, and establishment retrieved directly from the Brazilian Flora 2020 and accessed through the flora R package (Carvalho, 2017). Importantly, records lacking information on collecting date were not removed because they are fit-for-use for some biodiversity applications even when date information is missing.We have made available two databases of the Brazilian flora. First, a “raw” database (n = 12,762,595 records) containing the results of data quality tests appended in separate fields. This database includes records of algae and fungi species, records of species with non-accepted names, and records with taxonomic, spatial, and temporal issues. Second, a “fit-for-use” or “cleaned” database, containing 4,070,313 records of 38,207 species from 432 families. This database includes data on land plants occurring in Brazil (angiosperm, gymnosperm, ferns and lycophytes, and bryophyte), except algae and fungi species and records lacking information on collecting data.

Since April 2012, the Green Factory Label of the Industrial Development Bureau, Ministry of Economic Affairs, has been accepting applications from manufacturers. As of May 2015, 23 green factory labels have been issued, and 59 manufacturers have passed the assessment of the Clean Production Evaluation System, indicating that the promotion of green factories has gradually gained attention from businesses. In order to commend and publicize the certified factories, the Industrial Development Bureau has established a database of "Certified Clean Production Manufacturers," providing comprehensive information on green factories and certified clean production manufacturers. In line with the government's promotion of open data, the Industrial Development Bureau of the Ministry of Economic Affairs is now providing a search service for company names, industries, certificate numbers, and pass dates for "Certified Clean Production Manufacturers" across Taiwan. Everyone is welcome to make use of this service.

This set of data provides a collection of place names in Northeast China. It includes the names of provinces, cities, counties, towns and villages in Northeast China. When we clean up specimens, we often encounter great difficulty determining the location. Many specimens, especially the older ones, have incomplete information when labeling the location, leading to many errors in the digitized information. Therefore, a detailed set of place names containing historical knowledge is necessary when cleaning up specimen records. This data set is an attempt to organize a complete set of geographical names in Northeast China. The current place name collection only includes the current names. In the follow-up update, our goal is to completely sort out the place names and their changes from the beginning of specimen collection 150 years ago. Our data will be collected from the Ministry of Civil Affairs of China, civil affairs departments of local governments at all levels, various atlases, local chronicles and place name research databases.

Clean outs are a widely used piece of infrastructure that allows access into pipes that are too small to justify the inclusion of a manhole. Attribute Information:Field Name DescriptionOBJECTIDESRI software specific field that serves as an index for the database.FacilityIDA unique identifier for the asset class. Infor required field.LocationDescriptionInformation related to the construction location or project name. Infor required field.CommentsA catch all for asset information that doesn't warrant it's own field.EnabledESRI software specific field related to the inclusion in a network.AncillaryRoleDenotes n auxiliary or additional function performed by a junction feature within a geometric network.GlobalIDESRI software specific field that serves as a unique identifier.created_userName of user whom created asset.created_dateDate when asset was created.last_edited_userName of user whom most recently edited asset.last_edited_dateDate when the asset was most recently updated.IsLocatedHas the location of the asset been field verified with a survey grade GPS unit?OwnerA value to denote ownership between public and private assets.DiameterDiameter of the asset in inches.ShapeESRI software specific field denoting the geometry type of the asset.InstallDateThe date when the asset was installed. Typically pulled from as-builts for consistency. Infor required field.LifecycleStatusThe current status of the asset with respect to its location in the asset management lifecycle. Infor required field.

Sustainable cities depend on urban forests. City trees -- a pillar of urban forests -- improve our health, clean the air, store CO2, and cool local temperatures. Comparatively less is known about urban forests as ecosystems, particularly their spatial composition, nativity statuses, biodiversity, and tree health. Here, we assembled and standardized a new dataset of N=5,660,237 trees from 63 of the largest US cities. The data comes from tree inventories conducted at the level of cities and/or neighborhoods. Each data sheet includes detailed information on tree location, species, nativity status (whether a tree species is naturally occurring or introduced), health, size, whether it is in a park or urban area, and more (comprising 28 standardized columns per datasheet). This dataset could be analyzed in combination with citizen-science datasets on bird, insect, or plant biodiversity; social and demographic data; or data on the physical environment. Urban forests offer a rare opportunity to intentionally design biodiverse, heterogenous, rich ecosystems. Methods See eLife manuscript for full details. Below, we provide a summary of how the dataset was collected and processed.

Data Acquisition We limited our search to the 150 largest cities in the USA (by census population). To acquire raw data on street tree communities, we used a search protocol on both Google and Google Datasets Search (https://datasetsearch.research.google.com/). We first searched the city name plus each of the following: street trees, city trees, tree inventory, urban forest, and urban canopy (all combinations totaled 20 searches per city, 10 each in Google and Google Datasets Search). We then read the first page of google results and the top 20 results from Google Datasets Search. If the same named city in the wrong state appeared in the results, we redid the 20 searches adding the state name. If no data were found, we contacted a relevant state official via email or phone with an inquiry about their street tree inventory. Datasheets were received and transformed to .csv format (if they were not already in that format). We received data on street trees from 64 cities. One city, El Paso, had data only in summary format and was therefore excluded from analyses.

Data Cleaning All code used is in the zipped folder Data S5 in the eLife publication. Before cleaning the data, we ensured that all reported trees for each city were located within the greater metropolitan area of the city (for certain inventories, many suburbs were reported - some within the greater metropolitan area, others not). First, we renamed all columns in the received .csv sheets, referring to the metadata and according to our standardized definitions (Table S4). To harmonize tree health and condition data across different cities, we inspected metadata from the tree inventories and converted all numeric scores to a descriptive scale including “excellent,” “good”, “fair”, “poor”, “dead”, and “dead/dying”. Some cities included only three points on this scale (e.g., “good”, “poor”, “dead/dying”) while others included five (e.g., “excellent,” “good”, “fair”, “poor”, “dead”). Second, we used pandas in Python (W. McKinney & Others, 2011) to correct typos, non-ASCII characters, variable spellings, date format, units used (we converted all units to metric), address issues, and common name format. In some cases, units were not specified for tree diameter at breast height (DBH) and tree height; we determined the units based on typical sizes for trees of a particular species. Wherever diameter was reported, we assumed it was DBH. We standardized health and condition data across cities, preserving the highest granularity available for each city. For our analysis, we converted this variable to a binary (see section Condition and Health). We created a column called “location_type” to label whether a given tree was growing in the built environment or in green space. All of the changes we made, and decision points, are preserved in Data S9. Third, we checked the scientific names reported using gnr_resolve in the R library taxize (Chamberlain & Szöcs, 2013), with the option Best_match_only set to TRUE (Data S9). Through an iterative process, we manually checked the results and corrected typos in the scientific names until all names were either a perfect match (n=1771 species) or partial match with threshold greater than 0.75 (n=453 species). BGS manually reviewed all partial matches to ensure that they were the correct species name, and then we programmatically corrected these partial matches (for example, Magnolia grandifolia-- which is not a species name of a known tree-- was corrected to Magnolia grandiflora, and Pheonix canariensus was corrected to its proper spelling of Phoenix canariensis). Because many of these tree inventories were crowd-sourced or generated in part through citizen science, such typos and misspellings are to be expected. Some tree inventories reported species by common names only. Therefore, our fourth step in data cleaning was to convert common names to scientific names. We generated a lookup table by summarizing all pairings of common and scientific names in the inventories for which both were reported. We manually reviewed the common to scientific name pairings, confirming that all were correct. Then we programmatically assigned scientific names to all common names (Data S9). Fifth, we assigned native status to each tree through reference to the Biota of North America Project (Kartesz, 2018), which has collected data on all native and non-native species occurrences throughout the US states. Specifically, we determined whether each tree species in a given city was native to that state, not native to that state, or that we did not have enough information to determine nativity (for cases where only the genus was known). Sixth, some cities reported only the street address but not latitude and longitude. For these cities, we used the OpenCageGeocoder (https://opencagedata.com/) to convert addresses to latitude and longitude coordinates (Data S9). OpenCageGeocoder leverages open data and is used by many academic institutions (see https://opencagedata.com/solutions/academia). Seventh, we trimmed each city dataset to include only the standardized columns we identified in Table S4. After each stage of data cleaning, we performed manual spot checking to identify any issues.