API Reference¶
Nasa
- NASA API Wrapper¶
-
class
Nasa
([key=None])¶ Class object containing the methods for interacting with NASA API endpoints that require an API key.
- Parameters
key – The generated API key received from the NASA API. Registering for an API key can be done on the NASA API webpage. If
None
, a ‘DEMO_KEY’ with a much more restricted access limit is used.
Astronomy Picture of the Day¶
-
Nasa.
picture_of_the_day
([date=None][, hd=False])¶ Returns the URL and other information for the NASA Astronomy Picture of the Day.
- Parameters
date – String representing a date in YYYY-MM-DD format or a datetime object. If None, defaults to the current date.
hd – If True, returns the associated high-definition image of the Astrononmy Picture of the Day.
- Return type
dict. Dictionary object of the JSON data returned from the API.
# Initialize Nasa API Class with a demo key n = Nasa() # Return today's picture of the day n.picture_of_the_day() # Return a previous date's picture of the day with the high-definition URL included. n.picture_of_the_day('2019-01-01', hd=True)
Mars Weather Insight¶
-
Nasa.
mars_weather
()¶ Returns per-Sol (Martian Days) summary data for each of the last seven available Sols. Data is provided by NASA’s InSight Mars lander and as such data for particular Sols may be recalculated as more data is received. For more information on the data returned, please see NASA’s documentation.
- Return type
dict. Dictionary object representing the returned JSON data from the API.
# Initialize NASA API object with a demo key n = NASA() # Return the most recent data for the previous seven Sols (Martian Days) n.mars_weather()
Near Earth Objects¶
All the data is from the NASA JPL Asteroid team (http://neo.jpl.nasa.gov/). The API is maintained by the SpaceRocks team
-
Nasa.
asteroid_feed
([start_date][, end_date=None])¶ Returns a list of asteroids based on their closest approach date to Earth.
- Parameters
start_date – String representing a date in YYYY-MM-DD format or a datetime object.
end_date – String representing a date in YYYY-MM-DD format or a datetime object. If None, defaults to seven days after the provided
start_date
.
- Return type
dict. Dictionary representing the returned JSON data from the API.
# Initialize the NASA API with a demo key. n = NASA() # Get asteroids approaching Earth at the beginning of 2019. n.asteroid_feed(start_date='2019-01-01')
-
Nasa.
get_asteroids
([asteroid_id=None])¶ Returns data from the overall asteroid data-set or specific asteroids given an ID.
- Parameters
asteroid_id – If None, the entire asteroid data set is returned. If an
asteroid_id
is provided, data on that specific asteroid is returned.- Return type
dict. Dictionary object representing the returned JSON data from the NASA API.
n = Nasa() # Get entire asteroid data set. n.get_asteroids() # Get asteroid with ID 3542519 n.get_asteroids(asteroid_id=3542519)
DONKI (Space Weather Database of Notifications, Knowledge, and Information)¶
The Space Weather Database Of Notifications, Knowledge, Information (DONKI) is a comprehensive on-line tool for space weather forecasters, scientists, and the general space science community. DONKI provides chronicles the daily interpretations of space weather observations, analysis, models, forecasts, and notifications provided by the Space Weather Research Center (SWRC), comprehensive knowledge-base search functionality to support anomaly resolution and space science research, intelligent linkages, relationships, cause-and-effects between space weather activities and comprehensive webservice API access to information stored in DONKI.
-
Nasa.
coronal_mass_ejection
([start_date=None][, end_date=None][, accurate_only=True][, speed=0][, complete_entry=True][, half_angle=0][, catalog='ALL'][, keyword=None])¶ Returns data collected on coronal mass ejection events.
- Parameters
start_date – String representing a date in YYYY-MM-DD format or a datetime object. If None, defaults to 30 days prior to the current date in UTC time.
end_date – String representing a date in YYYY-MM-DD format or a datetime object. If None, defaults to the current date in UTC time.
accurate_only – If True (default), only the most accurate results collected are returned.
complete_entry – If True (default), only results with complete data is returned.
speed – The lower limit of the speed of the CME event. Default is 0
half_angle – The lower limit half angle of the CME event. Default is 0.
catalog – Specifies which catalog of data to return results. Defaults to ‘ALL’ and must be one of {‘ALL’, ‘SWRC_CATALOG’, ‘JANG_ET_AL_CATALOG’}.
keyword – Filter results by a specific keyword.
- Return type
list. List of results representing returned JSON data. If no data is returned, an empty dictionary is returned.
# Initialize NASA API with a demo key n = Nasa() # View data from coronal mass ejection events from the last thirty days n.coronal_mass_ejection() # View all CME events from the beginning of 2019. n.coronal_mass_ejection(start_date='2019-01-01', end_date=datetime.datetime.today())
-
Nasa.
geomagnetic_storm
([start_date=None][,end_date=None])¶ Returns data collected on geomagnetic storm events.
- Parameters
start_date – String representing a date in YYYY-MM-DD format or a datetime object. If None, defaults to 30 days prior to the current date in UTC time.
end_date – String representing a date in YYYY-MM-DD format or a datetime object. If None, defaults to the current date in UTC time.
- Return type
list: List of results representing returned JSON data. If no data is returned, an empty dictionary is returned.
# Initialize API connection with a Demo Key n = Nasa() # Get geomagnetic storm events from the last thirty days. n.geomagnetic_storm()
-
Nasa.
interplantary_shock
([start_date=None][, end_date=None][, location='ALL'][, catalog='ALL'])¶ Returns data collected on interplantary shock events.
- Parameters
start_date – String representing a date in YYYY-MM-DD format or a datetime object. If None, defaults to 30 days prior to the current date in UTC time.
end_date – String representing a date in YYYY-MM-DD format or a datetime object. If None, defaults to the current date in UTC time.
location – Filters returned results to specified location of the interplantary shock event. Defaults to ‘ALL’ and must be one of {‘ALL’, ‘Earth’, ‘MESSENGER’, ‘STEREO A’, ‘STEREO B’}
catalog – Filters results to a specified catalog of collected data. Defaults to ‘ALL’ and must be one of {‘ALL’, ‘SWRC_CATALOG’, ‘WINSLOW_MESSENGER_ICME_CATALOG’}
- Return type
list. List of results representing returned JSON data. If no data is returned, an empty list is returned.
-
Nasa.
solar_flare
([start_date=None][, end_date=None])¶ Returns data on solar flare events.
- Parameters
start_date – String representing a date in YYYY-MM-DD format or a datetime object. If None, defaults to 30 days prior to the current date in UTC time.
end_date – String representing a date in YYYY-MM-DD format or a datetime object. If None, defaults to the current date in UTC time.
- Return type
list. If data is available in the specified date range, a list of dictionary objects representing the data from the API is returned. If no data is available, an empty dictionary is returned.
# Initialize API connection with a Demo Key n = Nasa() # Get solar flare events from May of 2019 n.solar_flare(start_date='2019-05-01', end_date='2019-05-31')
-
Nasa.
solar_energetic_particle
([start_date=None][, end_date=None])¶ Returns data available related to solar energetic particle events.
- Parameters
start_date – String representing a date in YYYY-MM-DD format or a datetime object. If None, defaults to 30 days prior to the current date in UTC time.
end_date – String representing a date in YYYY-MM-DD format or a datetime object. If None, defaults to the current date in UTC time.
- Return type
list. If data is available in the specified date range, a list of dictionary objects representing the data from the API is returned. If no data is available, an empty dictionary is returned.
# Initialize API connection with a Demo Key n = Nasa() # Get data from April 2017 n.solar_energetic_particle(start_date='2017-04-01', end_date='2017-04-30')
-
Nasa.
magnetopause_crossing
([start_date=None][, end_date=None])¶ Returns data available related to magnetopause crossing events.
- Parameters
start_date – String representing a date in YYYY-MM-DD format or a datetime object. If None, defaults to 30 days prior to the current date in UTC time.
end_date – String representing a date in YYYY-MM-DD format or a datetime object. If None, defaults to the current date in UTC time.
- Return type
list. If data is available in the specified date range, a list of dictionary objects representing the data from the API is returned. If no data is available, an empty dictionary is returned.
# Initialize API connection with a Demo Key n = Nasa() # Get data on magnetopause crossing events from 2018 to the current date. n.magnetopause_crossing(start_date='2018-01-01')
-
Nasa.
radiation_belt_enhancement
([start_date=None][, end_date=None])¶ Returns data available related to radiation belt enhancement events.
- Parameters
start_date – String representing a date in YYYY-MM-DD format or a datetime object. If None, defaults to 30 days prior to the current date in UTC time.
end_date – String representing a date in YYYY-MM-DD format or a datetime object. If None, defaults to the current date in UTC time.
- Return type
list. If data is available in the specified date range, a list of dictionary objects representing the data from the API is returned. If no data is available, an empty dictionary is returned.
# Initialize API connection with a Demo Key n = Nasa() # Get data on radiation belt enhancement events from the last 30 days. n.radiation_belt_enhancement()
-
Nasa.
hight_speed_stream
([start_date=None][, end_date=None])¶ Returns data available related to hight speed stream events.
- Parameters
start_date – String representing a date in YYYY-MM-DD format or a datetime object. If None, defaults to 30 days prior to the current date in UTC time.
end_date – String representing a date in YYYY-MM-DD format or a datetime object. If None, defaults to the current date in UTC time.
- Return type
list. If data is available in the specified date range, a list of dictionary objects representing the data from the API is returned. If no data is available, an empty dictionary is returned.
# Initialize API connection with a Demo Key n = Nasa() # Get data on hight speed stream events from the beginning of September 2019. n.hight_speed_stream()
-
Nasa.
wsa_enlil_simulation
([start_date=None][, end_date=None])¶ - Parameters
start_date – String representing a date in YYYY-MM-DD format or a datetime object. If None, defaults to 30 days prior to the current date in UTC time.
end_date – String representing a date in YYYY-MM-DD format or a datetime object. If None, defaults to the current date in UTC time.
- Return type
list. If data is available in the specified date range, a list of dictionary objects representing the data from the API is returned. If no data is available, an empty dictionary is returned.
# Initialize API connection with a Demo Key n = Nasa() # Get data from the first simulation performed in 2019. wsa = n.wsa_enlil_simulation(start_date='2019-01-01')
EPIC (Earth Polychromatic Imaging Camera)¶
The EPIC API provides information on the daily imagery collected by DSCOVR’s Earth Polychromatic Imaging Camera (EPIC) instrument. Uniquely positioned at the Earth-Sun Lagrange point, EPIC provides full disc imagery of the Earth and captures unique perspectives of certain astronomical events such as lunar transits using a 2048x2048 pixel CCD (Charge Coupled Device) detector coupled to a 30-cm aperture Cassegrain telescope.
-
Nasa.
epic
([color='natural'][, date=None][, available=False])¶ - Parameters
color – Specifies the type of imagery to return. Must be one of ‘natural’ (default) or ‘enhanced’
date – String representing a date in ‘YYYY-MM-DD’ format or a datetime object
available – Alternative listing of all dates with specified color imagery
- Return type
list. List of dictionaries representing the returned JSON data from the EPIC API.
# Initialize API connection with a Demo Key n = Nasa() # Get EPIC data from the beginning of 2019. e = n.epic(date='2019-01-01') # Print the first result e[0]
Exoplanets¶
-
Nasa.
exoplanets
([table='exoplanets'][, select=None][, count=None][, colset=None][, where=None][, order=None][, ra=None][, dec=None][, aliastable=None][, objname=None][, return_df=False])¶ - Parameters
table – Specifies which table to query. Defaults to the ‘exoplanets’ table.
select – Specifies which columns within the chosen table to return. Multiple columns can be returned by comma-separating the column names and distinct values can be returned by adding ‘distinct ‘ in front of the desired column names.
count – Can be used to return the number of rows which fulfill the given query, including queries using where clauses or cone searches.
colset – Returns a set of pre-defined columns that have been created by the archive. Currently, this keyword is only used by the Composite Planet Data (‘compositepars’) table.
where – Takes a SQL-like query string to filter the returned results. Please see the examples section for more.
order – Returns the data sorted by the specified column. Append ‘ desc’ for descending or ‘ asc’ for ascending values.
ra – Specifies an area of the sky to search for all objects within that area.
dec – Specifies an area of the sky to search for all objects within that area.
aliastable – Requests a list of aliases for a particular confirmed planet.
objname – When parameter
aliastable
is specified,objname
must also be passed with the planet’s name.return_df – If
True
, returns the JSON data as a pandas DataFrame.
- Return type
dict or pandas DataFrame.
# Get all exoplanets data as a pandas DataFrame. exoplanets(return_df=True) # Get all confirmed planets in the Kepler field. exoplanets(where='pl_kepflag=1') # Stars known to host exoplanets as a pandas DataFrame. exoplanets(select='distinct pl_hostname', order='pl_hostname', return_df=True)
Earth Satellite Imagery¶
This endpoint retrieves the Landsat 8 image for the supplied location and date. The response will include the date and URL to the image that is closest to the supplied date. The requested resource may not be available for the exact date in the request.
-
Nasa.
earth_imagery
(lat, lon[, dim=0.025][, date=None][, cloud_score=False])¶ Retrieves the URL and other information from the Landsat 8 image database for the specified lat/lon location and date.
- Parameters
lat – Latitude of the desired imagery location
lon – Longitude of the desired imagery location
dim – Width and height of the image in degrees.
date – Date the image was taken. If specified, must be a string representing a date in ‘YYYY-MM-DD’ format or a datetime object. If None, the most recent image available from the current date is returned.
cloud_score – Calculate the percentage of the image covered by clouds.
- Return type
dict. Dictionary object representing the returned JSON data from the API.
# Initialize API connection with a Demo Key n = Nasa() # Get imagery at latitude 1.5, longitude 100.75 and include the computed cloud score calculation. n.earth_imagery(lon=100.75, lat=1.5, cloud_score=True)
-
Nasa.
earth_assets
(lat, lon[, dim=0.025][, begin_date=None][, end_date=None])¶ Retrieves the datetimes and asset names of available imagery for a specified lat-lon location over a given date range. The satellite that takes the images passes over each point approximately once every sixteen days.
- Parameters
lat – Latitude of the desired imagery location
lon – Longitude of the desired imagery location
begin_date – Beginning of date range in which to search for available assets. Must be a string representing a date in ‘YYYY-MM-DD’ format or a datetime object
end_date – End of date range in which to search for available assets. If not specified, defaults to the current date. If specified, Must be a string representing a date in ‘YYYY-MM-DD’ format or a datetime object
- Return type
dict. Dictionary object representing the returned JSON data from the API.
# Get assets available beginning from 2014-02-01 at lat-lon 100.75, 1.5 n.earth_assets(lat=100.75, lon=1.5, begin_date='2014-02-01')
Mars Rover Photos¶
-
Nasa.
mars_rover
([sol=None][, earth_date=None][, camera='all'][, rover='curiosity'][, page=1])¶ Retrieves image data collected by the Mars rovers Curiosity, Discovery and Spirit.
- Parameters
sol – The sol (Martian rotation or day) on which the images were collected. Either this parameter or
earth_date
must be provided. The parameterearth_date
is an alternative parameter for searching for a specific date. The sol values count up from the rover’s landing date, for example, the Curiosity’s 100th sol would be the 100th Martian rotation since the rover landed.earth_date – Alternative search parameter for finding data on a specific date. Must be a string representing a date in ‘YYYY-MM-DD’ format or a datetime object. Either
earth_date
orsol
must be specified.camera – Filter results to a specific camera on the Mars Curiosity, Opportunity or Spirit rovers. Defaults to ‘all’, which includes all cameras and must be one of {‘all’, FHAZ’, ‘RHAZ’, ‘MAST’, ‘CHEMCAM’, ‘MAHLI’, ‘MARDI’, ‘NAVCAM’, ‘PANCAM’, ‘MINITES’}
rover – Specifies the Mars rover to return data. Defaults to the Curiosity rover which has more available cameras. Must be one of {‘curiosity’, ‘opportunity’, ‘spirit’}
page – Page number of results to return. 25 results per page are returned.
- Return type
list. List of dictionaries representing the returned JSON data from the Mars Rover API.
GeneLab Search¶
-
Nasa.
genelab_search
(term=None, database='cgene', page=0, size=25, sort=None, order='desc', ffield=None, fvalue=None)¶ Retrieves available data from the GeneLab and other bioinformatics databases such as the National Institutes of Health (NIH) / National Center for Biotechnology Information (NCBI), Gene Expression Omnibus (GEO), the European Bioinformatics Institute’s (EBI) Proteomics Identification (PRIDE), and the Argonne National Laboratory’s (ANL) Metagenomics Rapid Annotations using Subsystems Technology (MG-RAST).
- Parameters
term – Search by specific keyword(s). Case-insensitive boolean operators (AND, OR, NOT) can be used as well to include and filter specific keywords.
database – Determines the database(s) to query. Defaults to the ‘cgene’ (GeneLab) database, but other available databases include ‘nih_geo_gse’ (NIH GEO), ‘ebi_pride’ (EBI PRIDE), or ‘mg_rast’ (MG-RAST). Multiple databases can be queried by separating values with commas. For example, ‘cgene,nih_geo_gse,ebi_pride,mg_rast’ will query all available databases.
page – Specifies the page of results to return. Defaults to the first page (0).
size – Specifies the number of results to return per page. Default is 25 results per page.
sort – Sorts by a specific field name in the returned JSON data.
order – Determines the sorting order. Must be one of ‘desc’ (descending) or ‘asc’ (ascending).
ffield – Filters the returned data based on the defined field. Should be paired with the
fvalue
parameter. Only the ‘cgene’ (GeneLab) database can be filtered.fvalue – Filters the returned data based on value or values in the specified
ffield
parameter field. Only the ‘cgene’ (GeneLab) database can be filtered.
- Return type
dict. Dictionary object representing the returned JSON data.
# Find Gene studies in the cgene database related to 'mouse liver' n.genelab_search(term='mouse liver')
Techport¶
The NASA TechPort system provides an API to make technology project data available in a machine-readable format. This API can be used to export TechPort data into either an XML or a JSON format.
-
Nasa.
techport
([project_id=None][, last_updated=None][, return_format='json'])¶ Retrieves available NASA project data.
- Parameters
project_id – The ID of the project record. If not specified, all available projects will be returned.
last_updated – Returns projects only updated after the specified date. Must be a string representing a date in ‘YYYY-MM-DD’ format or a datetime object.
return_format – Specifies the return format of the data. Defaults to ‘json’, but ‘xml’ formatted data is also available.
- Return type
dict or str. If
return_format
is ‘json’, a dictionary representing the JSON formatted data is returned. Otherwise, a string formatted for XML is returned.
TLE (Two-Line Element Set Data)¶
The TLE API provides up to date two line element set records, the data is updated daily from CelesTrak and served in JSON format. A two-line element set (TLE) is a data format encoding a list of orbital elements of an Earth-orbiting object for a given point in time.
-
tle
([search_satellite=None][, satellite_number=None])¶ Returns two-line element set records provided by CelesTrak.
- Parameters
search_satellite – Searches satellites by name designation.
satellite_number – Specfic satellite ID number.
- Return type
dict. Specfic satellite ID number.
tle(satellite_number=43553)
NASA Image and Video Library¶
-
media_search
([query=None][, center=None][, description=None][, keywords=None][, location=None][, media_type=None][, nasa_id=None][, page=1][, photographer=None][, secondary_creator=None][, title=None][, year_start=None][, year_end=None])¶ Performs a general search for images from the images.nasa.gov API based on parameters and criteria specified. At least one parameter must be provided.
- Parameters
query – Query terms to search.
center – NASA center that published the results.
description – Search for specific terms in the ‘description’ field of the resulting data.
keywords – Search and filter for specific terms in the ‘keywords’ field of the resulting data. Multiple values should be comma-separated.
location – Filter terms in the ‘locations’ field of the resulting data.
media_type – Filter results to specific media types. Options include ‘image’, ‘audio’, ‘image,audio’, ‘audio,image’. The default
None
includes all media types.nasa_id – The media asset’s NASA ID.
page – Page number of results to return. Starts at 1.
photographer – The primary photographer’s name.
secondary_creator – A secondary photographer/videographer’s name.
title – Search terms in the ‘title’ field of the resulting data.
year_start – The start year for results. If provided, must be a string representing a year in YYYY format or a datetime object.
year_end – The end year for results. If provided, must be a string representing a year in YYYY format or a datetime object.
- Return type
dict. Dictionary containing matching search results.
# Search for media related to 'apollo 11' with 'moon landing' in the description of the items. r = media_search(query='apollo 11', description='moon landing') # Output the first returned media item from the resulting collection. r['items'][0]
-
media_asset_manifest
(nasa_id)¶ Returns the media asset’s manifest, which contains the available versions of the asset and it’s metadata location.
- Parameters
nasa_id – The ID of the media asset.
- Return type
list. List of dictionaries containing the media asset’s manifest.
# Get the manifest for the NASA media asset 'as11-40-5874' media_asset_manifest(nasa_id='as11-40-5874')
-
media_asset_metadata
(nasa_id)¶ Retrieves the specified media asset’s metadata.
- Parameters
nasa_id – The ID of the media asset.
- Return type
dict. Dictionary containing the metadata of the provided media asset ID.
Retrieves the captions and location of the captions .srt file for a media asset from the NASA image API.
- Parameters
nasa_id – The ID of the media asset.
- Return type
dict. Dictionary object containing the resulting data from the API given the media asset ID. The dictionary will contain two keys,
location
andcaptions
. Thelocation
key can be used to download the .srt file directly while thecaptions
key can be used in conjunction with a library such as srt for parsing media asset captions.
Solar System Dynamics (SSD) and Center for Near-Earth Object Studies (CNEOS)¶
The following functions provide a Pythonic interface for NASA’s Solar System Dynamics and Center for Near-Earth Object Studies APIs.
-
close_approach
([date_min='now'][, date_max='+60'][, dist_min=None][, dist_max='0.05'][, h_min=None][, h_max=None][, v_inf_min=None][, v_inf_max=None][, v_rel_min=None][, v_rel_max=None][, orbit_class=None][, pha=False][, nea=False][, comet=False][, nea_comet=False][, neo=False][, kind=None][, spk=None][, des=None][, body='Earth'][, sort='date'][, limit=None][, fullname=False])¶ Provides data for currently known close-approach data for all asteroids and comets in NASA’s Jet Propulsion Laboratory’s (JPL) Small-Body Database.
- Parameters
date_min – Excludes data earlier than the given date. Defaults to ‘now’, representing the current date, but can also be a string representing a date in ‘YYYY-MM-DD’ format or ‘YYYY-MM-DDThh:mm:ss’ format or a datetime object.
date_max – Excludes data later than the given date. Defaults to ‘+60’, representing 60 days after the
date_min
parameter. Accepts a string of ‘+D’ where D represents the number of days or a string representing a date in ‘YYYY-MM-DD’ format or ‘YYYY-MM-DDThh:mm:ss’ format or a datetime object. ‘now’ is also an acceptable value and will exclude date later than the current date.dist_min – Excludes data with an approach distance less than the given value (if provided). The default unit is AU (astronomical units), and LD (lunar distance) is also available. For example, ‘0.05’ or 0.05 would return AU units whereas ‘0.05LD’ would return LD units.
dist_max – Excludes data with an approach distance greater than the given value (if specified). The default unit is AU (astronomical units), and LD (lunar distance) is also available. For example, ‘0.05’ would return AU units whereas ‘0.05LD’ would return LD units.
h_min – Exclude data from objects with H-values less than the given value.
h_max – Exclude data from objects with H-values greater than the given value.
v_inf_min – Exclude data with V-infinity less than this positive value in km/s
v_inf_max – Exclude data with V-infinity greater than this positive value in km/s
v_rel_min – Exclude data with V-relative less than this positive value in km/s
v_rel_max – Exclude data with V-relative greater than this positive value in km/s
orbit_class – Limits data to specified orbit-class
pha – If True, limits the resulting data to only PHA objects
nea – If True, limits the returned data to only NEA objects
comet – If True, limits the returned data to comet objects only
nea_comet – If True, limits the returned data to NEA comet objects only
neo – If True, limits the returned data to only NEO objects
kind – Filters returned data to specified type of object. Available options include ‘a’=asteroid, ‘an’=numbered-asteroids, ‘au’=unnumbered-asteroids, ‘c’=comets, ‘cn’=numbered-comets, ‘cu’=unnumbered-comets, ‘n’=numbered-objects, and ‘u’=unnumbered-objects
spk – Return data only for the matching SPK-ID.
des – Filters data to objects matching the given destination.
body – Filters data to close-approaches of the specified body. ‘ALL’ or ‘*’ returns all close-approaches to the available bodies.
sort – Sorts the returned data by the specified field. Defaults to ‘date’ ascending. To sort by descending, add a ‘-‘ in front of the sort value, for example, ‘-date’.
limit – Limit data to the first number of results specified by the parameter. Must be greater than 0.
fullname – Includes the full-format object name/designation
- Return type
dict
# Get all close-approach object data in the year 2019 with a maximum approach distance of 0.01AU. nasapy.close_approach(date_min='2019-01-01', date_max='2019-12-31', dist_max=0.01) # Get close-approach data for asteroid 433 Eros within 0.2AU from the years 1900 to 2100. nasapy.close_approach(des='433', date_min='1900-01-01', date_max='2100-01-01', dist_max=0.2) # Return close-approach data from the beginning of 2000 to the beginning of 2020 as a pandas DataFrame. nasapy.close_approach(date_min='2000-01-01', date_max='2020-01-01', return_df=True)
Each close-approach record is a list containing the following fields in the corresponding order:
des - primary designation of the asteroid or comet (e.g., 443, 2000 SG344)
orbit_id - orbit ID
jd - time of close-approach (JD Ephemeris Time)
cd - time of close-approeach (formatted calendar date/time)
dist - nominal approach distance (au)
dist_min - minimum (3-sigma) approach distance (au)
dist_max - maximum (3-sigma) approach distance (au)
v_rel - velocity relative to the approach body at close approach (km/s)
v_inf - velocity relative to a massless body (km/s)
t_sigma_f - 3-sigma uncertainty in the time of close-approach (formatted in days, hours, and minutes; days are not included if zero; example “13:02” is 13 hours 2 minutes; example “2_09:08” is 2 days 9 hours 8 minutes)
body - name of the close-approach body (e.g., Earth)
only output if the body query parameters is set to ALL
h - absolute magnitude H (mag)
fullname - formatted full-name/designation of the asteroid or comet
optional - only output if requested with the appropriate query flag
formatted with leading spaces for column alignment in monospaced font tables
-
fireballs
([date_min=None][, date_max=None][, energy_min=None][, energy_max=None][, impact_e_min=None][, impact_e_max=None][, vel_min=None][, vel_max=None][, alt_min=None][, alt_max=None][, req_loc=False][, req_alt=False][, req_vel=False][, req_vel_comp=False][, vel_comp=False][, sort='date'][, limit=None])¶ Returns available data on fireballs (objects that burn up in the upper atmosphere of Earth).
- Parameters
date_min – Excludes data earlier than the given date. Can be a string representing a date in ‘YYYY-MM-DD’ format or ‘YYYY-MM-DDThh:mm:ss’ format or a datetime object.
date_max – Excludes data later than the given date. Can be a string representing a date in ‘YYYY-MM-DD’ format or ‘YYYY-MM-DDThh:mm:ss’ format or a datetime object.
energy_min – Excludes data with total-radiated-energy less than the positive value of the specified value in joules \(\times 10^{10}\).
energy_max – Excludes data with total-radiated-energy greater than the positive value of the specified value in joules \(\times 10^{10}\).
impact_e_min – Excludes data with estimated impact energy less than the positive value of the specified value in kilotons (kt)
impact_e_max – Excludes data with estimated impact energy greater than the positive value of the specified value in kilotons (kt)
vel_min – Excludes data with velocity-at-peak-brightness less than the positive value of the specified value in km/s
vel_max – Excludes data with velocity-at-peak-brightness greater than the positive value of the specified value in km/s
alt_min – Excludes data from objects with an altitude less than the specified value
alt_max – Excludes data from objects with an altitude greater than the specified value
req_loc – If True, latitude and longitude required for object to be included in results.
req_alt – If True, objects without an altitude are excluded.
req_vel – If True, objects without a velocity are not included in results.
req_vel_comp – If True, excludes objects without velocity components.
vel_comp – If True, include velocity components
sort – Sorts data on specified field. Default sort order is ascending, for descending, prepend a ‘-‘. For example, for date descending, the sort value would be ‘-date’.
limit – Limits data to the first number of results specified. Must be greater than 0 if passed.
- Return type
dict.
# Get all available data in reverse chronological order nasapy.fireballs() # Return the earlieset record nasapy.fireballs(limit=1) # Get data from the beginning of 2019 nasapy.fireballs(date_min='2019-01-01') # Return fireball data from the beginning of the millennium to the beginning of 2020 as a pandas DataFrame. nasapy.fireballs(date_min='2000-01-01', date_max='2020-01-01', return_df=True)
-
mission_design
([des=None][, spk=None][, sstr=None][, orbit_class=False][, mjd0=None][, span=None][, tof_min=None][, tof_max=None][, step=None])¶ Provides access to the Jet Propulsion Laboratory/Solar System Dynamics small body mission design suite API.
- Parameters
des – The designation (provisional or IAU-number) of the desired object to search.
spk – The SPK-ID of the desired object to search.
sstr – Object search string.
orbit_class – If True, returns the orbit class in human readable format instead of the default three-letter code.
mjd0 – First launch date in Modified Julian Date. Must be between [33282, 73459].
span – Duration of the launch-date period to be explored in days. Must be between [10, 9200].
tof_min – Minimum time of flight in days. Must be between [10, 9200].
tof_max – Maximum time of flight in days. Must be between [10, 9200].
step – Time step used to advance the launch date and the time of flight. Size of transfer map is limited to 1,500,000 points.
- Return type
dict. Dictionary object representing the returned JSON data from the API.
# Search for mission design data for SPK-ID 2000433 r = nasapy.mission_design(spk=2000433) # Print the object data from the returned dictionary object. r['object'] # Get Missions to 1 Ceres r = nasapy.mission_design(des=1, mjd0=59000, span=1800, tof_min=120, tof_max=1500, step=5) r['object']
-
nhats
([spk=None][, des=None][, delta_v=12][, duration=450][, stay=8][, launch='2020-2045'][, magnitude=None][, orbit_condition_code=None][, plot=False])¶ Returns data available from the Near-Earth Object Human Space Flight Accessible Targets Study (NHATS) in the Small Bodies Database
- Parameters
spk – Returns data for a specific object by its SPK-ID.
des – Returns data for a specific object by its designation.
delta_v – Minimum total delta-v in km/s. Must be one of {12, 4, 5, 6, 7, 8, 9, 10, 11}
duration – Minimum total distribution in number of days. Must be one of {450, 60, 90, 120, 150, 180, 210, 240, 270, 300, 330, 360, 390, 420}
stay – Minimum stay in days. Must be one of {8, 16, 24, 32}
launch – The proposed launch window as a year range. Must be one of {‘2020-2045’, ‘2020-2025’, ‘2025-2030’, ‘2030-2035’, ‘2035-2040’, ‘2040-2045’}
magnitude – The object’s maximum absolute magnitude, also denoted as H. Must be one of {16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30}
orbit_condition_code – The object’s maximum orbit condition code (OCC). Must be one of {0, 1, 2, 3, 4, 5, 6, 7, 8}
plot – If True, include base-64 encoded plot image file content. Will include a new output field ‘plot_base64’ in the returned results if True.
- Return type
dict. Dictionary object representing the returned JSON data from the API.
# Get all available summary data for NHATS objects. n = nhats() # Get the results from a 'standard' search on the NHATS webpage. nhats(delta_v=6, duration=360, stay=8, magnitude=26, launch='2020-2045', orbit_condition_code=7) # Return data for a specific object by its designation nhats(des=99942)
-
scout
([tdes=None][, plot=None][, data_files=None][, orbits=None][, n_orbits=None][, eph_start=None][, eph_stop=None][, eph_step=None][, obs_code=None][, fov_diam=None][, fov_ra=None][, fov_dec=None][, fov_vmag=None])¶ Provides access and data available from NASA’s Center for Near-Earth Object Studies (CNEOS) Scout system.
- Parameters
tdes – Filter results by an object’s temporary designation.
plot – Includes the plot files for the specified object of the select type. Options include ‘el’ (elements), ‘ca’ (close approach) and sr (systematic-ranging) or any combination delimited by ‘:’. For example, ‘ca:el:sr’ would include plot files of each available type.
data_files – Returns available data files or the requested data file for the specified object. Currently only ‘mpc’ is available.
orbits – If True, returns the sampled orbits data for a specified object.
n_orbits – Limits the number of sampled orbits to this value. Must be in range [1, 1000].
eph_start – Get the ephemeris for the specified object at the specified time in UTC.
eph_stop – Sets the ephemeris stop-time. Also requires
eph_start
if specified.eph_step – Sets the ephemeris step size. Requires both
eph_start
andeph_stop
to be specified.obs_code – Gets the ephemeris for the specified object relative to the specified MPC observatory code.
fov_diam – Specifies the size (diameter) of the field-of-view in arc-minutes.
fov_ra – Specifies the field-of-view center (R.A component). Requires parameters
fov_diam
andfov_dec
to be set as well. Invalid ifeph_stop
is passed.fov_dec – Specifies the field-of-view center (Dec. component). Requires
fov_diam
andfov_ra
to be passed as well. Invalid ifeph_stop
is set.fov_vmag – Filters ephemeris results to those with V-magnitude of this value or brighter. Requires
fov_diam
to also be specified.
- Return type
dict. Dictionary object representing the returned JSON data from the API.
# Get all available summary data. scout() # Return all summary data as a pandas DataFrame. scout(return_df=True) # Return data and plot files for a specific object by its temporary designation. Note the object may no longer # exist in the current database scout(tdes='P20UvyK') # Get ephemeris data for a specific object at the current time with a Field of View diameter of 5 arc-minutes # with a limiting V-magnitude of 23.1. scout(tdes='P20UvyK', fov_diam=5, fov_vmag=23.1)
-
sentry
([spk=None][, des=None][, h_max=None][, ps_min=None][, ip_min=None][, last_obs_days=None][, complete_data=False][, removed=False])¶ Provides data available from the Center for Near Earth Object Studies (CNEOS) Sentry system.
- Parameters
spk – Returns data available for the object matching the specified SPK-ID.
des – Selects data for the matching designation.
h_max – Limits data to those with an absolute magnitude, less than or equal to the specified value. Must be in the range [-10:100].
ps_min – Limits results to those with a Palermo scale (PS) greater than or equal to the specified value. Must be in the range [-20:20].
ip_min – Filters data to that which has an impact probability (IP) greater than or equal to the specified value.
last_obs_days – Number of days since last observation. If negative, filters data to those which have not been observed within the specified number of days. If passed, must have an absolute value greater than 6.
complete_data – If True, requests the full dataset to be returned.
removed – If True, requests the list of removed objects to be returned.
- Return type
dict. Dictionary object representing the returned JSON data.
# Get summary data for available sentry objects. sentry() # Get summary data as a pandas DataFrame sentry(return_df=True) # Get data for a specific Sentry object by its designation. sentry(des=99942) # Get data for objects removed from the Sentry system. sentry(removed=1)
Other Methods¶
-
julian_date
([dt=None][, year=None][, month=1][, day=1][, hour=0][, minute=0][, second=0][, modified=True])¶ Calculates the Julian date or modified Julian date (if specified).
- Parameters
dt – Datetime object to convert into a Julian date. Note if a datetime object is supplied to
dt
the other parameters will not be evaluated. If None, returns the current datetime converted into a Julian date.year – Four digit year, such as 2019 or ‘2019’.
month – Month number. For example 1 = January, 12 = December.
day – Day of the month.
hour – Hour of the day.
minute – Minute of the day.
second – Second of the day.
modified – If True, returns the modified Julian date, which is the computed Julian Date - 24000000.5.
- Return type
float. The computed Julian or Modified Julian date.
# Return the modified Julian Date for the current time. julian_date() # Return the non-modified Julian Date for the current time. julian_date(modified=False) # Get the modified Julian Date for 2019-01-01 at midnight. julian_date(year=2019)
The equation for calculating the Julian date is defined as:
\[J = 367(Year) - /large[ \large( \frac{7(Year + \frac{Month + 9}{12})}{4} \large). \large] + \frac{275(Month)}{9}. + Day + 1721013.5 + \frac{\large( \frac{\frac{Second}{60} + Minute}{60} \large) + Hour}{24}\]


Sun Web Application Guidelines - Version 4.1
|
| Search Guidelines | Send Feedback | Developers.sun.com |
How To Use These Guidelines - An Introduction
Appendices > Appendix H
In software development, internationalization is the process of writing an application that is suitable for the global marketplace, taking into account variations in regions, languages, and cultures. Internationalization usually requires the separation of component text from code to ease the process of translation. A related term, localization, refers to the process of customizing an application for a particular language or region. Localization usually involves translation and often requires changes to colors, fonts, keyboard usage, number formats, and date and time formats. In this appendix, the term globalization refers to the combined tasks of internationalization (that is, i18n) and localization (that is, l10n).
An application that has not been effectively globalized is not only harder for international users to use, but might also be perceived as insensitive to their needs. In recognition of the importance of globalization, Sun mandates product internationalization and localization on its products. Key elements of this are:
Offering a comprehensive set of requirements for dealing with global differences is impossible. Therefore, the goal of this appendix is to provide a set of guidelines for application developers to help them become more aware of potential trouble areas. These guidelines cover layout and orientation, localized elements, and data formats. Also included is a section concerning testing and verification.
Additional information can be found in 1.4 Resources for Application Designers
When laying out your application, keep in mind that the application will be affected by localization. You must consider a number of factors so that the appearance and functionality of your application can adapt properly to the end user's locale. Factors include reading order, word order, sort order, font considerations and data entry fields.
Use a label and UI element pair to construct the User
Interface. Avoid using UI control elements in the middle of complete sentences.
Keep in mind that word order varies among languages, as shown in the following example. A drop-down menu that appears in the middle of an English sentence does not translate properly in French, where the adjective should come after the noun. (The correct French sentence is "Utilisez une Flèche Rouge.")
The following example corrects the problem by using a label before the drop-down menu. This format works well in both English and French.
More details are provided in H-4.2 Data Presentation.
Sorting of objects is locale sensitive. For example, in many European languages, sorting is commonly based on alphabetical order (which also varies from one language to another). In other languages, sorting might be based on phonetics, character radicals, the number of character strokes, and so on.
You must use the collation tools provided by your toolkit to ensure that sorting is performed properly for the locale in which your application will operate.
You can use the collator classes provided in the Java™ 2 SDK to enable the sorting of strings by locale. The Collator class in the java.text package enables locale-sensitive string sorting.
Fonts are closely coupled with the locale in which the application operates. Although there are fonts that support many languages, often, the font must be localized for proper appearance of the application in different locales.
You should always ensure that any fonts that you specify in your application can be localized.
Be sure to provide user control over font size in your application.
The guidelines above allow the application to be easily tested with a much larger font, which can be a measure of how well it will adapt to different locales. Many languages, such as Japanese, German, and Dutch often require substantially more space (in the same font size) to express the same idea as in English. Other languages, such as Chinese, might require substantially less space than English to express the same idea. The size of fonts is also an important consideration for users with visual limitations.
Languages across the globe use many different alphabets. Some alphabets require more horizontal space, more vertical space, or both, than others. Languages using an alphabet such as Latin, Cyrillic, Hebrew and German, tend to expand horizontally. For instance, the word "Cancel" is written as "Abbrechen"' in German. The German word is one and a half times the length of the English word, and the length can sometimes double. Many Asian languages tend to expand vertically. The characters used in these languages are often simply taller than the letters of the English alphabet and may require a much larger point size for legibility than the characters of the English alphabet. The characters used in these languages are represented by different charsets, or character encoding schemes. Applications must be aware of the charset that is in use, and be able to display text and accept user entries using any of the supported charsets. Since the height and length of text varies across the globe, these differences must be accounted for when internationalizing your application.
The best way to handle font changes is to specify them in cascading style sheets. This way, localizers can change the fonts in one place to affect the entire application.
Keep in mind that as text expands, page layout can be affected. Try to design your page such that text expansion does not completely alter the page layout. (See H-2 Layout and Orientation for more information.)
When considering how to handle text for internationalization, one of the most important tasks is to isolate the text so that it can be easily identified and localized. To do this, place text in resource bundles. Graphics files can also be placed in resource bundles (see section H-3.2.1 Icons and Images).
Data entry fields in your application should anticipate locale-specific entries. Expressing a certain idea can require a greater or lesser number of characters based on the end user's language. In addition, fields for data such as zip code, social security number, and so on will require different sizes and formats in different locales and cultures. Be sure to leave enough space to accommodate locale-specific entries. Consult with the localization teams about any data entry fields that you think might be culturally or linguistically sensitive. For more details, see H-4 Data Formats.
Elements that need to be localized include:
These elements are discussed in the following sections.
Use resource bundles to make your text easier to localize.
The following list identifies the kinds of text in your interface that must be localizable:
User interface elements, themselves, must also account for internationalization. This topic is covered in more detail in H-4.1 Variable Elements and Entry Fields.
Note that a product name displayed in the masthead is not a textual element. It is an image displaying text and it is not translated (for more details, see Chapter 4, Mastheads).
You can negatively or positively affect the internationalization of the text in your interface by the choice of words and phrases used in your interface. Following are some guidelines to help you create text that is appropriate for localizing.
Use standard typographical conventions for titles and sentences within your application. When the text is localized, the translators can adopt the standards to use in each target locale.
Do not use words or phrases that have culturally-defined meanings. Most jargon, slang, marketing terms, and humor do not translate well.
Check with translators before using acronyms and abbreviations in the user interface. These items are often not translated and must, therefore, be internationally acceptable or replaced with more appropriate terms.
Icons and images must be considered carefully. Images that make sense in one locale might not carry the same meaning, or might even be offensive, in another locale. For example, since the shape and size of a mailbox varies across locales, it would be difficult to arrive at a single image that represents a mailbox for users in different locales. Although the concept of "mailbox" might make sense to represent an email application, getting this meaning across graphically might not be easy.
It is particularly difficult to depict everyday objects, holidays, and seasons in a universally understood graphic image.
Creating multiple versions of localized graphics is costly. An example of an image that works well globally is an image of airplane that is used to represent an airplane. This image works because the concept of an airplane is shared across locales. Additionally, the image in this case is being used to represent its literal meaning, not a culturally-defined meaning.
When this strategy is not possible, try to get input from international sources when creating your graphics. If an image that works across your target locales cannot be found, plan to define locale-specific graphics.
Use globally understood graphics, whenever possible.
Images with text almost always have to be localized. When text is used in graphics, considerations for text expansion and font-size changes should be made in the image. However, this could potentially detract from the image. Additionally, localizers should receive a version of the graphic separated from the text. Users of Adobe™ Photoshop may accommodate this recommendation through the use of layers, which takes more time and effort, and increases cost.
Only text that does not need to be translated, such as the product name displayed in the masthead, should be included in an image.
Do not include text within graphic images or icons.
Avoid using graphics that might be offensive in some locales, including:
Put graphics in resource bundles so that translators can find and change them easily, if necessary.
Make sure that the meaning you associate with an icon is as literal as possible. Avoid culturally-defined meanings.
Do not use a single icon to represent multiple meanings within your application.
Show proposed icons and images to sales people and users in target locales to get feedback from them.
Note that a product name displayed in the masthead is not a textual element. It is an image displaying text and it is not translated (for more details, see Chapter 4, Mastheads).
Color has different meanings in different cultures. For example, red is considered a celebratory color in some countries, while in others it is associated with death. As another example, in some cultures, white is associated with death. In the United States, it is associated with purity. Because of these differences, user interface colors should be chosen carefully and, preferably, by visual designers who have been educated in the meaning of colors in various cultures.
It is also important to define and adhere to a consistent color palette within an application, set of applications, or entire product line. Doing so enables users to grow accustomed to the way color is used within an application or set of applications, and attribute the appropriate meaning to the use of the color. For example, if red is defined to mean error, it should be used as such consistently throughout the application or set of applications.
Use the color palette defined in 2.1 Color Palette for your primary color palette.
A sound can be meaningful in some countries, but not in others. For example, a game show buzzer sound for an incorrect answer is well known to people in the United States, but it can simply be a noise with no meaning to people in other countries.
Additionally, sounds that are generated when a mistake is made can be embarrassing if other people are nearby.
If sounds are included in your user interface, provide a variety of options for the sound, allowing users to select the desired sound or to turn sound off altogether.
When localizing an application, present the information to the user in a format that is meaningful to them. In the case of certain data formats such as dates and monetary currency, the application developer has to plan for these differences.
Applications must:
Fixed elements are not the only portions of the user interface that change order or expand with use in other languages. User entry areas also need more space for the data they receive. Making the elements flexible for localization is not enough. English products are often sold all over the world, and the user interface included with an English product must accommodate entry data from all over the world. In other words, the user interface can be in English, but the fields need to be locale-specific in format and order. In addition, application developers must consider the implications of a universal data entry field structure. For example, if a product allows the user to enter a date in a short format, how should the entry area appear?
The problem with forcing a date format is that it is not universal. Even calendars are not universal. As a shortcut, it is not uncommon for some applications to limit their capacity to the Gregorian calendar. But the mm/dd/yy format so common in the United States is not used anywhere else, and is very confusing.
Allow a user in a known locale to enter a date format commonly used in that locale.
If there is no way to know the locale, then the only acceptable universal date format is yyyy-mm-dd. The separator may be changed to a dot (.), or possibly a slash (/), but the rest of the fields must be in the specified order.
Another possible solution to the format issue is to provide users with a choice of formats, for example, in a preferences area. This way, you can display the chosen format next to the field, and know exactly how to parse the date format entered by the user.
Determine data field lengths by function, whenever possible, rather than hard-coding a single, assumed value.
Strings and currency values expand when localized, and data in other languages may require more space. Imagine the price of something expressed in Turkish Lira (the Turkish currency till 2005) which was over TRL 1,500,000/USD 1.00.
Use and store messages in entire phrases; do not build them from pieces.
This guideline includes user interface phrases formed by drop-down menu choices or numeric values in combination with fixed text. Word order and grammar change drastically from language to language. You may use placeholders for information that comes from the system (for example, file names, available disk space) as long as they can be reordered. If you do so, add comments in the resource file as to what the placeholders represent.
In addition, sentence order changes with different languages. Not only does the order change, but the phrase breaks change as well. So, simply allowing reordering might not be enough for a translation to look correct. For example, it is tempting to construct a calendar entry edit screen as follows:
However, most languages would have to rearrange the fields, and some (in this case, the am/pm) are superfluous and need to be removed. An additional example is provided in H-2.1 Word Order.
Do not include a particular sentence order as part of the design.
Numbers are commonly displayed using the Arabic numeral system; that is, digits 0-9. However, the convention to group the digits of a number varies from one culture to another. For example, in the U.S., a comma is used to separate digits into groups of three, for example, 10,000,000, whereas in France, the separator is a dot. In Japan, digits are separated into groups of four.
Make sure that your user interface allows numbers to be grouped as appropriate when localized.
Make sure entry areas are large enough to handle longer text entries.
The convention for displaying monetary value varies from one country to another; that is, the currency symbol and the position of the currency symbol. For example, to represent 5 U.S. dollars and 45 cents, you place the dollar symbol before the value--$5.45. In some locales, the currency symbol can appear after the value or even between the integral and fractional designations; for example, Portuguese 5$45 represents 5 escudo and 45 centavos.
Units of measurement can also vary from one locale to another. Standard metric units for length, volume, and weight include meters, liters, and grams. Standard imperial units include feet, ounces, and pounds. However, other region-specific measurements exist.
Clothing sizes change from region to region. For example, a U.S. ladies' dress size 10 is a U. K. size 14, and a U.S. ladies' shoe size 8 is a European size 39. Paper sizes change, packaged quantities change, temperature scales change. Anytime a measurement unit is involved, it is likely to vary in different locales.
Other field types that should be considered very carefully are names, addresses, and telephone numbers. Data formats are usually locale-specific, culture-specific, or both. Once again, English products are sold all over the world, so just making the arrangement localizable is not enough.
If the interface must be customized for the product to function properly, then create several locale profiles that can be loaded based on the user's locale. Or, less optimally, make it easily user customizable, and inform the customer that they are expected to customize the product for the locale.
A user registration form usually contains space for a name, address, and telephone number. Each country has different conventions for presenting this information.
To make user registration work internationally, you have to provide as generic a form as possible. Leave space that localizers can use for country-specific customizations.
If you use HTML forms for these entry fields, localizers can easily customize them by editing the HTML source. If you use Java applets for these entry fields, you need to provide the localizer with a way to customize them.
The number of given names, the order of the given name (usually the same as the first name) and the surname (mostly the same as the last name), and the terms by which these names are refered to may differ from country to country.
Most people have at least one given name (first name) and one surname (last name), provide two entry fields, one for a given (first) name and one for a surname (last name). (In some countires, the given name is not the same as the first name. )
If you need to know a middle name, use an optional field.
The content and order of addresses differs from country to country.
Provide address1, address2, city or town, state or province, country, and postal/zip code to account for the variances in address formats across the globe.
Address1 Address2 City/Town State/Province Country Postal Code
Addresses can vary from one culture to another. The following table provides examples of different address formats.
| Country | Format | Notes |
| China | [<Country>] <Province> <City> <Address1> <LastName> <FirstName> <Honorific> |
<Province>, which is represented by two uppercase letters in parentheses, is used only if the city is not a province capital. The line with <Country> should use a negative indent. |
| Italy | <Title> <FirstName> <LastName> [<CompanyName>] <Address> [blank line] [<Country>] |
Numbers, for example, house numbers, are always at the end of <Address> for example, via Palmanova 12. An optional blank line between <Address> and <Country> makes the address easier to read. |
| Russia | [<Country>] <PostalCode> [<State or Republic>] [<Region>] <City> <Address1> <Address2> [<CompanyName>] <LastName> <FirstName> <SecondName> |
The <State or Republic> and <Region> fields are only used in the following cases:
If <FirstName> and <SecondName> contain only initials followed by periods, it is more appropriate to include these fields on the same line with <LastName>, for example, LastName A. B. |
| Denmark | [<Honorific> <Title>] <FirstName> [<SecondName>] <LastName> [<CompanyName>] <Address1> <Address2> [<CountryCode>] <PostalCode><City> [<Country> |
Some countries have very special requirements if sending mail outside the country; Denmark is an example of this. The first and second lines can appear in reverse order, that is, <CompanyName> on the first line and <Honorific> to <LastName> on the second. There are two spaces between <PostalCode> and <City>. The postal code is four digits, without a separator. If mail is sent from abroad to Denmark, the prefix "DK-" (<CountryCode> plus one hyphen) is added to <PostalCode>. |
| Finland | [<Title>] <FirstName> [<SecondName>] <LastName> [<CompanyName>] <Address1> <Address2> <PostalCode> <City> [<Country>] |
Some countries have special requirements, depending on the mail recipient; Finland is an example of this. The personal name appears first if the letter is of a personal nature, but the company name appears first in a business letter. |
The format and number of digits in a telephone number vary from country to country, and even from city to city in some countries. Provide one long entry field, and allow localizers to customize the label name and length.
Do not hard code the expected length or format of phone numbers. Allow for the user to be able to
while providing the phone number.
The input field should be flexible enough to accept all of these, and an underlying process should be able to filter out punctuation etc. as appropriate.
Each culture has its own format, structure and ordering in date and time formats. For instance, in Asian locales, AM/PM string will usually appear before hour and minute digits and century number will appear as the first component of a date/time string. On the other hand, in Western European countries, time is either in 24-hour format or the AM/PM string usually appears after the hour and minute digits and the century number usually appears last. For more detail on standards for representing dates, see ISO 8601.
Due to such differences, if multiple date/time formatting conversion specifications are used to create a single date/time string, such as "%a %b %e %T %Z %Y", and cannot be localized, in many cases, the formatted date/time string would not be acceptable or correct for certain cultures. For instance, the above format string will give the following output for American English, Japanese, Simplified Chinese and French locales, respectively:
While the first one would be acceptable for American English locale users, for other locales, more culturally correct and acceptable ones would be:
Application software must be able to format and display the time and date data according to local cultural conventions.
The conventions to express time, date, and calendar data tend to vary by country and language. For example, the date November 22, 1999 is displayed in the mm/dd/yyyy format in the United States as 11/22/1999, but in the United Kingdom, it is displayed in dd/mm/yyyy format as 22/11/1999. The ISO 8601 standard describes time formats. This standard has been widely adopted in Europe.
The conventions for expressing time also differ, with varying formatting schemes using AM/PM, 24-hour clock, and designations for Daylight Saving Time.
Even though most of the locales support the Gregorian calendar by default, many locales support additional calendars. For example, the Japanese locale supports the Emperor Era calendar as well as the Gregorian calendar.
Even conventions such as the first working day of the week can vary between countries. While most Western countries consider Monday as the first working day, in the Middle East, Sunday is considered to be the first working day. This can be important when displaying calendar appointment data.
Application
software must be able to format and display calendar data according to local
cultural conventions.
The assumptions about these formats must not be embedded in the application software.
Software that provides interfaces for formatting these data according to cultural conventions or for modifying these cultural conventions is considered a provider. Software that takes advantage of the provider functions is a consumer.
Time and date information is commonly passed in protocols. Many transactions passed through protocols require a date and time stamp; for example, financial transactions, email messages, and status messages. In most cases, the information is passed using the coordinated universal time (UTC), sometimes referred to as Greenwich Mean Time (GMT). Local time zone information is then managed at the client level for display and input. The time is converted to UTC before using the protocol. In some situations, the protocol takes the time zone information as either part of the time format, as an offset to UTC, for example, or as a separate parameter.
"There are restrictions about which characters are valid in a URL. For a fuller discussion, see the World Wide Web Consortium (W3C) site http://www.w3.org/
Generally, HTML tags are enclosed in angle brackets, "<" and ">", and are not translatable.
The following attributes might need to be localized:
Hyperlinks
Internet Link: <a href="/"> ... </a>
Mail Link: <a<EMAIL_ADDRESS>... </a>
You cannot translate Internet URL and email addresses, but you can localize them by replacing them with the appropriate local contacts. This is a matter of product policy rather than translation.
For resources on globalization, including source material, sample code, testing tools, and useful links, see http://www.sun.com/developers/gadc/i18ntesting/checklists/index.html
| Privacy Policy | Terms of Use | Trademarks | Copyright 2007 Sun Microsystems, Inc. |


The Concurrent Processing Framework REST API allows client applications in Java, JavaScript or other programming languages to query the available business applications, create jobs and download the results of jobs on behalf of their users.


--- layout: page status: publish published: true title: Avalanche author: display_name: Jessie Pechmann login: jpechmann email<EMAIL_ADDRESS>url: '' author_login: jpechmann author_email<EMAIL_ADDRESS>wordpress_id: 3547 wordpress_url: http://gis.utah.gov/?page_id=3547 date: '2011-11-18 16:09:38 -0700' date_gmt: '2011-11-18 23:09:38 -0700' categories: [] tags: - sgid - Data - utah - gis - map - mapping - dataset - download - agrc - layer - shapefile - geodatabase - metadata - shp - gdb - kml - lyr - digital - geographic - information - database - state - statewide ---
Data Type: GIS Data Layer
Steward: AGRC
Abstract:
This dataset represents snow avalanche paths in the tri-canyon area of the Wasatch Front, Utah.
This dataset also contains the name, size of slidepath, return interval, starting zone elevation, vertical fall and starting zone aspect for some of the avalanches.
This data was prepared for the Salt Lake County Wasatch Canyons Master Plan originally published in September 1989.
Usage: There are no constraints or warranties with regard to the use of this dataset.
Last Update: 2009
Contact: AGRC
Links: FGDC Metadata


The Arduino Pro Mini is intended for advanced users who require flexibility, low-cost, and small size. It comes with the minimum of components (no on-board USB or pin headers) to keep the cost down. It's a good choice for a board you want to leave embedded in a project. Please note that there are two versions of the board: one that operates at 5V (like most Arduino boards), and one that operates at 3.3V. Be sure to provide the correct power and use components whose operating voltage matches that of the board.
The board comes without built-in USB circuitry, so an off-board USB-to-TTL serial convertor must be used to upload sketches. This can be a FTDI TTL-232R USB - TTL Level Serial Converter Cable for the 5V Arduino Mini Pro), or a FTDI TTL-232R-3V3 USB - TTL Level Serial Converter Cable or the SparkFun FTDI Basic Breakout Board for a 3.3V Arduino Mini Pro. One quick way to connect these is by inserting a six-pin 0.1" male pin header into the end of the FTDI cable or breakout board, and pressing it against the six hole programming header on the Mini Pro. If, however, you're going to be uploading lots of sketches to your Pro Mini, you'll probably want to solder some pins (male headers) to the holes.
If using the FTDI cable on Windows, you'll need to make one configuration change to enable the auto-reset. With the board connected, open the Device Manager (in Control Panels > System > Hardware), and find the USB Serial Port under Ports. Right-click and select properties, then go to Port Settings > Advanced and check Set RTS on Close under Miscellaneous Options.
For the 3.3V versions of the Arduino Pro Mini, select Arduino Pro or Pro Mini (3.3V, 8 MHz) w/ ATmega328 or Arduino Pro or Pro Mini (3.3V, 8 MHz) w/ ATmega168 from the Tools > Board menu (depending on the microcontroller on your board). For the 5V versions of the Arduino Pro Mini, select Arduino Duemilanove or Nano w/ ATmega328 or Arduino Diecimila, Duemilanove, or Nano w/ ATmega168.
The Arduino Pro Mini connected to (and powered by) an FTDI TTL-232R-3V3 USB - TTL Level Serial Converter Cable. The green and black wires align with the labels "GRN" and "BLK" written next to the holes.
The Arduino Pro Mini connected to (and powered by) a SparkFun FTDI Basic Breakout Board and USB Mini-B cable. Note that on earlier Pro Mini boards the orientation of the 6-pin header may be reversed; check that the words GRN and BLK align on the Pro Mini and FTDI Basic Breakout.
The board can be powered through USB via the six-pin programming header, or from a regulated 5V or 3.3V (depending on the model) supply applied to the VCC pin or an unregulated supply on the RAW pin.
Any standard 0.1" spaced header can be soldered to the holes on the Arduino Pro Mini. To use every pin requires two 12-pin headers, plus a six pin header for programming, if desired. Bare wire can also be soldered directly to the holes.
The text of the Arduino getting started guide is licensed under a Creative Commons Attribution-ShareAlike 3.0 License. Code samples in the guide are released into the public domain.